Systems Development Life Cycle (SDLC)

1
Systems Development Life Cycle (SDLC)
2
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

3
Other Methodologies

• Object Oriented Development
• Suited to process oriented systems implemented in
  OO environment
• systems that are strongly database-orientedare
  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

4
3-Schema Architecture
5
Systems Development Template
6
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)

7
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

8
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.

9
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.

10
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.

11
Project Management

• Three components
• Planning
• Controls
• Organisation
• Planning
• Break the project into a number of stages or
  phases (e.g. project initiation, feasibility
  study, analysis, testing).
• Identify the activities to be undertaken in each
  phase.
• Break down the activities in the first stage into
  a detailed task list.
• Estimate effort required to complete each task or
  activity.
• Assign resources to each task and activity.
• Schedule the project.

12
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

13
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.
14
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?

15
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

• Develop high-level alternatives (or options)
  for its solution

1. Assess the feasibility of the options and select
   options for discussion with the Project Board

1. Make recommendations to and document the decision
   of the Project Board

• Develop action plan for further analysis and
  subsequent development of the chosen option.

16
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.

17
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.

18
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).

19
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.

20
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.

21
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).