Lifecycles

1
Lifecycles
2
Statistics

• Only 27 of software development projects are
  delivered on time, within budget, and meet user
  expectations.
• Approximately 67 of all major IT projects are
  delivered late.
• More than 50 of all large software projects
  exceed their budget.
• Cost of system failure in the US is approx. 1bn
  per year
• Average cost of related downtime in the financial
  sector estimated at 6.45m per hour.
• In the last 6 years, over-budget and cancelled UK
  government IT projects has cost us 1.5bn.

3
Examples of Project Failure

• The US 4 billion Tax Systems Modernization
  Program failed because it took a "big bang"
  approach
• tried to build a new and gigantic information
  system to integrate many disparate and
  out-of-date systems.
• The London Stock Exchanges system took 3 years
  to develop at a cost of 483m and was cancelled
  before it became operational.
• Remember
• The London Ambulance Services emergency dispatch
  system.
• Ariane 5.

4
Factors Leading to Failure

• Very large projects.
• Underestimating time to deliver.
• Lack of
• user involvement in design and development.
• understanding, quantification and prioritisation
  of requirements.
• Testing.
• financial justification.
• risk management.

5
Project size

• As the size of the project increases so does
• the complexity of the software.
• the size of the project team.
• the number and variety of users.
• the project duration.
• This implies an increased probability that
  requirements will change during the life of the
  project.
• These factors all increase the exposure of the
  project to risk of failure.

6
Changing System Requirements

• Users often cant initially envisage a new system
  
• Only when they see it they get ideas
• requirements change.
• Also, things change (i.e. the environment is
  dynamic) while a system is being developed.
• This may mean requirements have to change.

7
Cont. Changing System Requirements

• Different stakeholders may even have conflicting
  requirements.
• Marketing wants it blue
• Sales wants it green
• Finance wants it cheap
• Director wants it now
• Bob doesnt want it
• John and Bob are close friends, so John agrees
  with Bob.
• Andy hates Bob so he opposes him.
• The result may be requirements thrash which leads
  to impotence and project disaster.

8
How to Reduce Risk of Failure

• Choose the right Software Development Process and
  follow it.

9
The System (Development) Lifecycle

• System development lifecycles and system
  lifecycles are not the same thing!
• The (system) lifecycle is inevitable.
• occurs in nature, consumer goods, technology,
  fashion, etc.
• something grows, matures and the declines

10
The System Lifecycle
11
The System Development Life Cycle(SDLC)

• A structure imposed on the development of a
  system.
• Predominantly happens during the growth (birth)
  phase of the system's overall lifecycle
• Takes account of the major activities that go
  into developing an information system.
• Numerous models for the development life cycle.
• The maintenance phase of a software development
  process extends into the maturity and declining
  regions of the system life cycle.

12
SDLC Models
SDLC Models.
Sequential Models
Evolutionary Models

• Incremental Models

Waterfall
RAD
Staged Delivery
Spiral
V Model
Parallel Development
DSDM
13
Sequential SDLC Models

• First SDLC models to address software specific
  issues.
• Such models assume that
• A problem can be completed understood and
  described before a solution is designed.
• A full design can be devised before
  implementation.
• All implementation can be done before testing and
  delivery.

14
The Waterfall Model
Youll find there are a number of equally
correct versions of this model.
15
Requirements Analysis

• May include a feasibility study.
• Establish the technical, operational and economic
  feasibility of the proposed system.
• Establish terms of reference and system
  boundaries.
• Analyse existing system, identifying problems and
  opportunities.
• Identify requirements of the new system.
• An iterative process.
• Identify constraints on hardware, software and
  human participation.
• Identify resources required to complete the
  design specification.
• The deliverable is usually a report.

16
Design Specification

• Once this information has been analysed in terms
  of data and processes which must be supported,
  various solutions are considered and compared.
• Document existing system in detail, identifying
  problem areas.
• Identify the outputs of the system in terms of
  documents and information.
• Identify all tasks and functions performed by the
  system.
• Identify the inputs to the system.
• Identify major components, interfaces, functions,
  information and control flow.
• Specify major performance criteria.
• Outline possible solutions, providing a cost
  benefit justification for each.
• Justify the choice of solution.
• Estimate resource required to develop the new
  system.
• The deliverable is usually another report.

17
Design Specification (continued)

• Other tasks
• Design style sheets.
• Design documents templates.
• Choose algorithms and data structures for
  implementation.
• Choose technologies
• Design databases.
• Develop test strategies.

18
Implementation

• The building, testing and evaluation stage
• The most resource intensive stage
• involves users and IT professionals.
• requires detailed planning and careful project
  control.
• Activities
• Generate code.
• Train users.
• Test - components, interfaces, databases
  interactions, user interactions, tasks.
• System acceptance test - to agreed specification.

19
Implementation (cont.)

• Deliverables
• Source code.
• Executables
• Documentation.
• User guides
• Developer guides
• Various Diagrams
• Test reports.

20
Integration

• Essentially an extension of implementation
• Different components are brought together
• An interface or some middleware is often
  required.
• Many descriptions of waterfall do not mention
  this phase.

21
Maintenance ( Review)

• All systems work within a changing environment.
• User requirements are dynamic and the system must
  change to meet new needs, or become obsolete.
• Maintenance is concerned with prioritising and
  scheduling change, and ensuring that
  modifications are properly tested and integrated
  into the system at appropriate times.
• Review measures the performance of the system in
  relation to its stated objectives at agreed
  points in time.

22
Maintenance ( Review) Activities

• Change the system after delivery.
• Adaptive (due to the changing environment within
  which the system operates).
• Corrective (bugs).
• Perfective (enhancements due to new
  requirements).
• Review the system and audit of the system at
  agreed intervals.
• Testing after changes.
• Documentation revision.
• Analysing defect reports.
• Prioritising requests for change and enhancement.
  
• Version control.

23
Waterfall Summary

• Easy to understand and plan.
• Can be used in projects with experienced
  developers, working on a well-known problem and
  using a well-known technology.
• BUT
• Projects are seldom so clear-cut and linear
• Most require some iteration
• More and better information becomes available as
  the project develops.
• Typically, it is late in the project by the time
  a working version of the system is available for
  the user to test and criticise.
• Any misunderstandings between the users and the
  systems engineers are often not discovered until
  the project is nearly complete, and the problems
  are expensive to fix.

24
Waterfall Summary (cont.)

• The earlier in the development process an error
  or misconception is identified, the smaller the
  cost of correcting the defect.
• Errors detected in the testing phase may be fifty
  times more costly to fix than if they were
  detected during requirements analysis or
  high-level design (logical design).
• So, if more effort and resource is spent on
  capturing requirements and testing high level
  designs, then the overall project costs will be
  much smaller.