Robert Jay A.

Reyes BSIT 3-4

*SOFTWARE PROCESS MODELS*

SOFTWARE DEVELOPMENT PROCESS

- A software development process is a structure imposed on the development of

a software product. Similar terms include software life cycle and software process. There are
several models for such processes, each describing approaches to a variety of tasks or
activities that take place during the process. Some people consider a lifecycle model a more
general term and a software development process a more specific term.

- A process model for a software engineering is chosen based on the nature of the
project and application, the methods and tools to be used and the controls and deliverables
that are required. It is a structured set of activities required to develop a software system. The
interim work products are more clearly defined and justified.

WATERFALL/CLASSIC LIFE CYCLE

Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance

The waterfall model shows a process, where developers are to follow these phases in order:

 Requirements analysis and definition

 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
 - In a strict Waterfall model, after each phase is finished, it proceeds to the next one.
Reviews may occur before moving to the next phase which allows for the possibility of changes
(which may involve a formal change control process). Reviews may also be employed to ensure
that the phase is indeed complete; the phase completion criteria are often referred to as a
"gate" that the project must pass through to move to the next phase. Waterfall discourages
revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall
model has been a source of criticism by other more "flexible" models.

- The linear sequential model is also known as the "classic life cycle" or "waterfall
model". System development proceeds through the phases (analysis, design, coding, testing,
support) in order. This is a good model to use when requirements are well understood. If a
phase must be revisited in this model, process failure is indicated (more thorough requirements
analysis is needed).

RAPID APPLICATION DEVELOPMENT (RAD)

The rapid application deployment model is a high-speed adaptation of the linear

sequential model. Project requirements must be well understood and the project scope tightly
constrained. Developers are often able to use component-based construction techniques to
build a fully functional system in a short time period.

PROTOTYPING MODEL

 Gather requirements
  Developer & customer define overall objectives, identify areas needing more
investigation – risky requirements
 Quick design focusing on what will be visible to user – input & output formats
 Use existing program fragments, program generators to throw together working version
 Prototype evaluated and requirements refined

This model is good to use when the customer has legitimate needs, but is not able to
articulate the details at the start of the project. A small mock-up of a working system is
developed and presented to the customer. Sometimes this first system is discarded and
sometimes it is extended based on the customer's feedback.

EVOLUTIONARY PROCESS MODEL

The two most important models in this section are the incremental model and the spiral
model. The incremental model combines elements of the linear sequential model applied
repetitively with the iterative philosophy of the prototyping model. Each increment produces a
working version of a software product with increasing functionality. There is no throwaway
code. The spiral model also combines the iterative nature of prototyping with the systematic
control found in the linear sequential model. An essential component of the spiral model is that
assessment of both management and technical risks is performed as each incremental release
is completed.

Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

INCREMENTAL DEVELOPMENT MODEL

 Define outline Assign requirements Design system
requirements to increments architecture

Develop system Valida te Integrate Valida te

increment increment increment system
Final
system
System incomplete

The incremental model combines elements of the linear sequential model applied
repetitively with the iterative philosophy of the prototyping model. Each increment produces a
working version of a software product with increasing functionality. There is no throwaway
code.
 Rather than deliver the system as a single delivery, the development and delivery is
broken down into increments with each increment delivering part of the required
functionality
 User requirements are prioritised and the highest priority requirements are included in
early increments
 Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve
 Customer value can be delivered with each increment so system functionality is
available earlier
 Early increments act as a prototype to help elicit requirements for later increments
 Lower risk of overall project failure
 The highest priority system services tend to receive the most testing

SPIRAL MODEL

The key characteristic of a Spiral model is risk management at regular stages in the
development cycle. In 1988, Barry Boehm published a formal software system development
"spiral model", which combines some key aspect of the waterfall model and rapid
prototyping methodologies, but provided emphasis in a key area many felt had been neglected
by other methodologies: deliberate iterative risk analysis, particularly suited to large-scale
complex systems.
 The Spiral is visualized as a process passing through some number of iterations, with the
four quadrant diagram representative of the following activities:

1. formulate plans to: identify software targets, selected to implement the program, clarify
the project development restrictions;
2. Risk analysis: an analytical assessment of selected programs, to consider how to identify
and eliminate risk;
3. the implementation of the project: the implementation of software development and
verification;
Risk-driven spiral model, emphasizing the conditions of options and constraints in order to
support software reuse, software quality can help as a special goal of integration into the
product development. However, the spiral model has some restrictive conditions, as follows:

1. spiral model emphasize risk analysis, but require customers to accept and believe that
much of this analysis, and make the relevant response is not easy, therefore, this model
is often adapted to large-scale internal software development.
2. If the implementation of risk analysis will greatly affect the profits of the project, then
risk analysis is meaningless, therefore, spiral model is only suitable for large-scale
software projects.
3. Good software developers should look for possible risks, an accurate analysis of risk,
otherwise it will lead to greater risk.
First stage is to determine the stage of the goal of accomplishing these objectives, options
and constraints, and then from the perspective of risk analysis program, development strategy,
and strive to remove all potential risks, and sometimes necessary to achieve through the
construction of the prototype. If some risk cannot be ruled out, the program to end
immediately, or else start the development of the next steps. Finally, evaluation results of the
stage, and the design of the next phase.
The spiral model also combines the iterative nature of prototyping with the systematic
control found in the linear sequential model. An essential component of the spiral model is that
assessment of both management and technical risks is performed as each incremental release
is completed.

 Process is represented as a spiral rather than as a sequence of activities with

backtracking
 Couples iterative nature of prototyping with controlled and systematic stepwise
approach of the linear sequential model

 Allows for the fact that some software evolves

 On each iteration, plans, costs, risks and schedules updated and project manager get
more accurate estimate of number of required iterations

 Each loop in the spiral represents a phase in the process.

  No fixed phases such as specification or design - loops in the spiral are chosen
depending on what is required

 Risks are explicitly assessed and resolved throughout the process

 Difficult to convince customers that process will end

 Demands considerable risk assessment expertise

 customer communication – tasks required to establish effective communication

between developer and customer

 planning – tasks required to define resources, timelines and other project related
information

 risk analysis – tasks required to assess both technical and management risks

 engineering – tasks required to build one or more representations of the application

 construction and release – tasks required to construct, test, install and provide user
support (e.g. documentation & training)

 customer evaluation – tasks required to get customer feedback on evaluation of the

software representations created during the engineering stage and implemented during
the installation stage

AGILE DEVELOPMENT MODEL

Agile software development uses iterative development as a basis but advocates a

lighter and more people-centric viewpoint than traditional approaches. Agile processes use
feedback, rather than planning, as their primary control mechanism. The feedback is driven by
regular tests and releases of the evolving software.
There are many variations of agile processes:

In Extreme Programming (XP), the phases are carried out in extremely small (or
"continuous") steps compared to the older, "batch" processes. The (intentionally incomplete)
first pass through the steps might take a day or a week, rather than the months or years of each
complete step in the Waterfall model. First, one writes automated tests, to provide concrete
goals for development. Next is coding (by a pair of programmers), which is complete when all
the tests pass, and the programmers can't think of any more tests that are needed. Design and
architecture emerge out of refactoring, and come after coding. Design is done by the same
people who do the coding. (Only the last feature — merging design and code — is common
to all the other agile processes.) The incomplete but functional system is deployed or
demonstrated for (some subset of) the users (at least one of which is on the development
team). At this point, the practitioners start again on writing tests for the next most important
part of the system.
  New approach to development based on the development and delivery of very small
increments of functionality
 Relies on constant code improvement, user involvement in the development team and
pair wise programming

COMPONENT BASED DEVELOPMENT MODEL

Object-based technologies provide the technical framework for component-based

software engineering. The component-based development (CBD) model incorporates many of
the iterative characteristics of the spiral model. The main difference is that in CBD the emphasis
is on composing solutions from pre-packaged software components or classes. This CBD
emphasizes software reusability. The unified software development process is an example of
CBD that has been proposed for industrial use. The unified modelling language (UML) is used to
define the components and interfaces used in the unified software development process.

FORMAL DEVELOPMENT METHODS

Formal methods are mathematical approaches to solving software (and hardware)

problems at the requirements, specification and design levels. Examples of formal methods
include the B-Method,Petri nets, Automated theorem proving, RAISE and VDM. Various formal
specification notations are available, such as the Z notation. More generally, automata
theory can be used to build up and validate application behavior by designing a system of finite
state machines. Finite state machine (FSM) based methodologies allow executable software
specification and by-passing of conventional coding.
Formal methods in software development require the use of rigorous mathematical
notation to specify, design, and verify computer-based systems. Mathematical proof is used to
verify the correctness of a system (not empirical testing). Cleanroom software engineering is an
example of this approach. While formal methods have the potential to produce defect-free
software, the development of formal models is both time-consuming and expensive.

Requirements Formal Formal Integration and

definition specification transformation system testing

Formal transformations
T1 T2 T3 T4

Formal R1 Executable
R2 R3
specification program

P1 P2 P3 P4

Proofs of transformation correctness

  Based on the transformation of a mathematical specification through different
representations to an executable program
 Transformations are ‘correctness-preserving’ so it is straightforward to show that the
program conforms to its specification
 Embodied in the ‘Cleanroom’ approach to software development

EXTREME PROGRAMMING

In Extreme Programming (XP), the phases are carried out in extremely small (or
"continuous") steps compared to the older, "batch" processes. The (intentionally incomplete)
first pass through the steps might take a day or a week, rather than the months or years of each
complete step in the Waterfall model. First, one writes automated tests, to provide concrete
goals for development. Next is coding (by a pair of programmers), which is complete when all
the tests pass, and the programmers can't think of any more tests that are needed. Design and
architecture emerge out of refactoring, and come after coding. Design is done by the same
people who do the coding. (Only the last feature — merging design and code — is common
to all the other agile processes.) The incomplete but functional system is deployed or
demonstrated for (some subset of) the users (at least one of which is on the development
team). At this point, the practitioners start again on writing tests for the next most important
part of the system.

 New approach to development based on the development and delivery of very small
increments of functionality
 Relies on constant code improvement, user involvement in the development team and
pairwise programming