Lifecycles 2

1
Lifecycles 2
2
Evolutionary Models

• Used in projects where all requirements cant be
  known in advance.
• Heavy use of prototyping
• Prototypes imply user involvement, evaluation,
  feedback and iteration in the development process

3
Spiral Model

• Use an iterative approach where a prototype is
  refined to a product in a series of cycles.
• Each cycle contains
• Planning
• Risk Analysis
• Software Development
• User Evaluation
• The output of each stage feeds into the next.
• The output of each cycle (user evaluation) feeds
  into the next cycle (Planning).

4
(No Transcript)
5
Spiral Model

• Focuses on prototyping and formalises an
  evolutionary approach to software development,
• Requires an explicit cost-benefit analysis during
  each cycle.
• User involvement throughout the development
  process.
• Validation and prioritisation of requirements.
• Tends to work best for small projects.

6
Dynamic Systems Development Model (DSDM) - a RAD
methodology

• The philosophy behind DSDM is that of
  sufficiency.
• A system that delivers the quality and
  functionality required, and that satisfies the
  given constraints, is a successful system.
• It may not be the best system, but it is good
  enough.
• DSDM requires an empowered development team which
  includes users and IT specialists.

7
DSDM

• Involves iterative development and evolutionary
  delivery.
• Focuses on quality and satisfying the business
  needs of the organisation.
• It is claimed that DSDM is not a method for
  developing systems, but a framework of controls
  for RAD.
• At a high level, it defines a process and a set
  of products, but does not constrain the detail of
  how it is applied in any given situation.
• It covers project management, system development,
  support and maintenance.

8
The DSDM Process

• Five stages
• Feasibility Study
• Business Study
• Functional Model Iteration
• Design and Build Iteration
• Implementation

9
The Role of the User in DSDM

• An empowered ambassador user forms part of the
  development team.
• He or she is an advocate for the Business Needs
  of the system
• Improves communications and minimises time spent
  waiting for decisions to be made or authorised.

10
Advantages of such User Involvement

• Users own the system. They have a stake in
  developing it and do not have a final product
  thrust upon them.
• There is a higher probability of meeting Business
  goals
• Users are involved in the design and development
  of the system and thus require less formal
  training during implementation
• Implementation may proceed more smoothly

11
The Role of Prototyping

• Prototyping in DSDM is used to improve
  communication and facilitate system evolution
  towards a satisfactory solution.
• Provides a medium for understanding system
  requirements and user and technical constraints
  and capabilities, for testing out potential
  solutions to problems and for easing the
  development of the test strategy.

12
Feasibility Study

• A short intensive exploration of the problem
• Typically just a few weeks
• The technical feasibility of the high level
  solution is assessed, and a cost-benefit analysis
  of the value of the new system to the
  organisation is performed.

13
Feasibility Study (cont.)

• Also, the applicability of DSDM is assessed
• Is the functionality of the system visible at the
  user interface?
• Are all classes of end user identifiable?
• Is the computational complexity of the
  application minimal?
• If it is large, can the proposed system be
  decomposed into smaller incremental chunks?
• Is the project time constrained?
• Are requirements high level and flexible?

14
Feasibility Study (cont.)

• The products of the feasibility study are
• The feasibility report
• An outline plan for development
• An optional prototype to demonstrate technical
  feasibility

15
The Business Study

• Also a short intensive exercise
• Enables the understanding of the Business
  requirements and the constraints which will
  surround it.
• A collaborative exercise, involving workshops of
  involved, motivated and articulate staff who will
  agree on the goals and priorities.

16
The Business Study (cont.)

• The products of the Business Study are
• The Business Area Definition
• a prioritised, high level view of the processes
  and the classes of user
• The System Architecture Definition
• hardware and software high level architecture
• Outline Prototyping Plan
• prototyping strategy and Configuration Management
  plan

17
The Functional Model Iteration

• This stage is used to develop the functional and
  informational requirements of the system.
• Each cycle of the iteration consists of the
  following four steps
• Identify what is to be done
• Get agreement
• Do it
• Check that it has been done correctly

18
The Functional Model Iteration (cont.)

• The products of each iteration are analysis
  models and tested software components.
• Much of the functionality and usability of the
  system is built into prototypes here.
• The prototypes are successively refined into
  software components of the evolving system.
• Functional aspects of the systems are tested in
  this cycle while the majority of the
  non-functional aspects of the system are tested
  in the design and build iteration.

19
Products of the Functional Model Iteration

• Prioritised functions
• Functional prototyping review documents
• A list of non-functional requirements
• A risk analysis of future development

20
The Design and Build Iteration

• During this cycle, the working system is
  engineered to an acceptable level of quality.
• The products of Design and Build Iteration are
• The tested system containing the Minimal Usable
  Subset of functions or core requirements
• Design Prototypes
• Design prototype Review Documents

21
Implementation

• The implementation stage involves training the
  users, and handing over the system
• The products of Implementation are
• The working system
• System documentation
• User Manual
• Trained Users
• Project review Document

22
Possible outcomes of Implementation

• All requirements satisfied
• Another area of business functionality has been
  identified
• proposal for a new project
• Low priority functionality was ignored
• proposal for a new project to include it
• Low priority non-functional aspects of the system
  were ignored
• proposal for a new project to include them