Transcript Introduction - DCU School of Computing

Systems Development Life Cycle (SDLC)
Strategy
Planning
Feasibility Study
Feasibility
Analysis
Design
Implementation
Maintenance
S
S
A
D
M
Requirements
Analysis
Requirements
Specification
Logical System
Specification
Physical Design
Structured Methodologies
 Structured methods consist of three basic elements:
 A default structure of steps and tasks which the project team
should consider following.
 A set of techniques to be applied in each step that provide
(largely diagrammatic) structured definitions of user requirements
and system components.
 A set of products developed by each of the techniques.
 Features:









Rigorous “top down” analysis of user requirements
Project Management
Communication and consistency
Lower LIFETIME costs
Documentation
Widely understood and adopted
Flexible and adaptable
Information Systems (database) specific
Require careful planning and customisation
Other Methodologies
 Object Oriented Development
 Suited to process oriented systems implemented in OO
environment
 “systems that are strongly database-oriented……are not ideally
suited to object oriented development” - Bennett, McRobb & Farmer
 Requires high level of expertise
 Often used for customisable packages (e.g. SAP)
 RAD




Iterative development
Process and user expectations must be carefully handled
Can be used in conjunction with Structured Methods
Particularly suited to small projects and user interface
development
 DSDM
3-Schema Architecture
External Design
Conceptual Model
P
r
o
Sup
d
plie
u
r's
ct
Pro
duc
t
User and System
Interfaces
Pu
rc
123
ha
se
Or
Pur
ch
as
Pur
eL
ch
i
Or
as
n
der
ee
Or
der
S
Purc
e
hase
Purc
t
Ord
has
o22
12
er
e
f 12
90
Item
Ord
S
u
p
pl
ie
r
Physical/Internal
Design
LDM
ECDs
ELHs
UPMs
etc
Proc
se
ess
Ord
Purc
Pr
er Purc
Pro
S haoc Quehas
ces
1up
234
es
ry
sPr
Purc
pli
e
oc
s
Set
has
er
Ord
ofes
e
er
s
Ord
er
Su
ppli
2
222
er
6789
Pro
Physical
Data
Storage
Pro
ces
4
s
Nex
t
P.O
.
FCIM
PDI
Systems Development Template
Investigation
Specification
Conceptual Model
Internal Design
Construction
External Design
Basic SSADM Concepts
 Separation of Logical and Physical
 Physical or historical constraints
 Implementation independence
 Re-use
 The Three Views of SSADM
 Data
 Processing
 Events (Time)
CASE Tools
 The claims made in their favour by suppliers are often
exaggerated, but most will provide a mix of the following
features:





Diagramming tools
Diagram validation
Automatic generation of first-cut low level diagrams
Report production
Code generation
Getting Started
 Learning Outcomes:
 Assemble a Project Initiation Document;
 Understand the need for and application of Project Management
principles;
 Assess the technical, operational and financial feasibility of a
project.
Why Projects Fail
 Lack of business wide understanding of and commitment
to the project;
 Lack of clearly defined objectives, deliverables and
success criteria;
 Lack of ownership or sponsorship within the business;
 Problems establishing the right project team;
 Plans that are too optimistic and lack contingency;
 Poor day-to-day management of issues and control of
project tasks;
 Lack of awareness of change management and business
impact issues;
 Lack of focus on project goals and milestones;
 Poor understanding of risks and project dependencies.
Project Initiation






Define objectives, deliverables and scope of project;
Establish a sound financial business case for the project;
Assess costs and business benefits;
Agree plans, resources and organisation for the project;
Establish key risks and success criteria;
Formalise controls and reporting lines.
Project Management

Three components:




Planning
Controls
Organisation
Planning
1. Break the project into a number of stages or phases (e.g. project
initiation, feasibility study, analysis, testing).
2. Identify the activities to be undertaken in each phase.
3. Break down the activities in the first stage into a detailed task list.
4. Estimate effort required to complete each task or activity.
5. Assign resources to each task and activity.
6. Schedule the project.
Gantt
Chart:
Project Controls
 While no project is helped by unnecessary bureaucracy,
there are some formal controls that are invaluable in
ensuring that a project is effectively managed, regardless
project size:




Progress Reports
Project Issues
Change Control
Risk Log
Project Organisation
 A well-defined project structure ensures that the right
people are involved in the project and that roles
responsibilities are clearly defined.
 Key Roles:
 Project Manager
 Project Sponsor
 User Representation
 Project Board
Note
On student projects the role of the Project Sponsor will be undertaken by a representative of the
organisation that will be the recipient of the final deliverable(s). In addition there will be an academic
Supervisor who will act as a co-sponsor, and is responsible for both the mentoring of the Project
Manager (student) and agreeing the academic objectives of the project.
Feasibility Study
 Feasibility assessment is an activity that can take many
forms, varying from an informal study carried out as part
of strategy planning or project initiation, to a high level
systems analysis “mini project”, depending on the size or
complexity of overall project.
 The basic questions to be answered in any kind of
feasibility study are:
 Is there a computer solution to the given business problem?
 Is the solution justifiable in business terms, both organisationally
and financially? For example:
• Will benefits outweigh costs?
• Will the proposed solution be politically acceptable?
• Can the solution be developed in time?
• Can the level of change associated with the system be
absorbed at this time?
• Are the skills in place and the people available to develop
and manage the system?
• Is the risk of project failure acceptable to the organisation?
Feasibility Study (continued)

There are several points in the life cycle where a decision to drop the
project might be made. The Feasibility Study provides easily the most cost
effective point to do so.
Whether an informal approach or an SSADM Feasibility Study is
undertaken, the basic steps we go through will be the same:

1.
Define the business problem to be solved;
2.
Develop high-level alternatives (or
“options”) for its solution;
Assess the feasibility of the options
and select options for discussion with
the Project Board;
Make recommendations to and
document the decision of the Project
Board;
Develop action plan for further analysis
and subsequent development of the
chosen option.
3.
4.
5.
Define the
Problem
Strategy
Planning
Project Definition Statement
Select
Feasibility
Option
Action Plan
Feasibility Options
Assemble
Feasibility
Report
Feasibility Report
SSADM Feasibility Products
 Problem Definition Statement
 A Problem Definition Statement provides a textual summary of
requirements and their relative priority. It should include
references to formal SSADM products (which it does not replace
but merely supplements), and should include a list of the
minimum requirements.
 We should attempt to be efficient and methodical by using the
PID to identify the major functional areas that the system will be
required to support, and using these as a checklist of high level
processes to be covered by the overview DFD.
Feasibility Options
 Feasibility Options
 At the centre of a Feasibility Option is a high level combination of
two standard SSADM products:
 Business System Option (BSO). A BSO defines the functional
scope of a proposed solution. At its most basic level it consists of
textual descriptions of those requirements satisfied by the
solution. All BSOs must satisfy the minimum requirement as
identified by user representatives.
 Technical Systems Option (TSO). A TSO defines a possible
technical environment for the implementation of the system. It will
include descriptions of hardware and software, technical support
arrangements, distribution of the system and development tools.
Feasibility Options (continued)

Feasibility Options (continued)
 Functional support. Textual descriptions can be supplemented with
process and data models showing the subset of functional requirements
covered by the option.
 Costs. These will be very approximate and must include: hardware;
software; human resources; consultancy; training; together with
maintenance and running costs (which are frequently higher than the
development costs).
 Benefits. Including financial benefits (e.g. increased profits or reduced
costs), strategic benefits (i.e. the meeting of strategic business
objectives), removal of problems (e.g. capacity constraints) etc.
 Organisational Impact Analysis. Again this will be at a high level, and
will describe the cultural and operational changes associated with the
option.
 Development approach and approximate timings.
• Is SSADM the most suitable method for developing the option? If
not, what method should be used?
• How many projects are necessary? If the proposed system is large
or complex, a phased approach may be best;
• Who will develop the option? Possibilities include in-house project
teams, contractors, software houses, package vendors, etc.
Tips on presenting options will be given in Lecture 7 (Business System Options).
Assessing Financial Feasibility
 Financial feasibility has two key elements:
 Are funds are available for the solution to be developed and
maintained?
 Is there a positive balance of costs and benefits over time?
 Cost Benefit Analysis
 Financial costs are usually easier to estimate than the financial
benefits.
 For example a system may claim to improve the decision making of
a set of employees, but measuring the increased profits generated
directly by that improvement might well prove impossible.
 There are a number of methods for assessing cost benefits,
including Return on Investment and Payback Periods as outlined
below. Most organisations will have internal standards for which of
the methods should be used in conducting a CBA, and what result
will be considered acceptable in assessing feasibility.
Return on Investment
 Return on Investment (RoI)
 RoI is the simplest, and one of the most frequently used,
measures of financial feasibility. It delivers a percentage figure
that can be compared against prevailing interest rates, in order to
assess whether the proposed investment is financially
worthwhile.
 The basic formula is:
RoI = (Net Benefit / Investment) x 100
 Where Net Benefit = the sum of tangible benefits – Total costs,
including annual running and development costs.
 Standards vary from organisation to organisation as to what
period the costs and benefits are measured. A common standard
is to use the sums of annual costs and benefits over a four-year
period; another is to use the costs and benefits over the expected
life of the solution.
 Standards also vary as to what RoI rate is acceptable, with
values such as twice bank base rate, or base rate plus 5% being
fairly typical.
Payback Period

Payback Period
 Another common measure is that of Payback Period. This is a measure
of when sufficient benefits will have accrued to cover both the initial
investment costs and the on-going running costs of the solution.
 For example a project with an investment cost of £120,000, annual
running costs of £20,000, and annual benefits of £50,000 will pay back
the investment in 4 years.

In assessing overall cost benefit, measures such as RoI and
Payback Period will frequently be used in combination, and
viewed differently by different organisations.
 For example some might view a RoI of 20% with a pack back of 2 years
as preferable to a RoI of 30% with a Payback Period of 4 years,
depending on their strategic aims and current financial position.
For a full description of these methods the reader is referred to a text such as
Robson (1997).