Software Process Models

Software Process

 A process is a collection of activities, actions, and tasks

that are performed when some work product is to be
created.
 An activity strives to achieve a broad objective (e.g.,
communication with stakeholders) and is applied regardless of
the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be
applied.
 An action (e.g., architectural design) encompasses a set of tasks
that produce a major work product (e.g., an architectural model).
 A task focuses on a small, but well defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.
Software Process (2)

 In the context of software engineering, a process is not a rigid

prescription for how to build computer software. Rather, it is an
adaptable approach that enables the people doing the work
(the software team) to pick and choose the appropriate set of
work actions and tasks. The intent is always to deliver software
in a timely manner and with sufficient quality to satisfy those
who have sponsored its creation and those who will use it.
The process framework

 A process framework establishes the foundation for a complete

software engineering process by identifying a small number of
framework activities that are applicable to all software projects,
regardless of their size or complexity.
 A generic process framework for software engineering
encompasses five activities:
 Communication. Before any technical work can commence, it is
critically important to communicate and collaborate with the customer
(and other stake-holders). The intent is to understand stakeholders’
objectives for the project and to gather requirements that help define
software features and functions.
The process framework (2)
 Planning. Any complicated journey can be simplified if a map exists. A
software project is a complicated journey, and the planning activity
creates a “map” that helps guide the team as it makes the journey.
The map—called a software project plan—defines the software
engineering work by describing the technical tasks to be conducted,
the risks that are likely, the resources that will be required, the work
products to be produced, and a work schedule.
 Modeling. Whether you’re a landscaper, a bridge builder, an
aeronautical engineer, a carpenter, or an architect, you work with
models every day. You create a “sketch” of the thing so that you’ll
understand the big picture—what it will look like architecturally, how the
constituent parts fit together, and many other characteristics. If
required, you refine the sketch into greater and greater detail in an
effort to better understand the problem and how you’re going to solve
it. A software engineer does the same thing by creating models to
better understand software requirements and the design that will
achieve those requirements.
 The process framework (3)
 Construction. What you design must be built. This activity
combines code generation (either manual or automated) and
the testing that is required to uncover errors in the code.
 Deployment. The software (as a complete entity or as a partially
completed increment) is delivered to the customer who
evaluates the delivered product and provides feedback based
on the evaluation.
Process models

 Process models were originally proposed to bring order to the

chaos of software development.
 A prescriptive process model strives for structure and order in
software development.
 All software process models can accommodate the generic
framework activities.
Process models - Waterfall

• The oldest software process model

• Problems
 Real projects rarely follow the sequential flow that the model proposes
 It is often difficult for the customer to state all requirements explicitly.
 Customers must have patience
Process models – Waterfall (2)
The principal stages of the waterfall model directly reflect the
fundamental development activities:
 Requirements analysis and definition. The system’s
services, constraints, and goals are established by consultation
with system users. They are then defined in detail and serve as
a system specification.
 System and software design. The systems design process
allocates the requirements to either hardware or software
systems by establishing an overall system architecture.
Software design involves identifying and describing the
fundamental software system abstractions and their
relationships.
 Implementation and unit testing. During this stage, the
software design is realized as a set of programs or program
units. Unit testing involves verifying that each unit meets its
specification.
Process models – Waterfall (3)
The principal stages of the waterfall model directly reflect the
fundamental development activities (cont):
 Integration and system testing. The individual program units
or programs are integrated and tested as a complete system to
ensure that the software requirements have been met. After
testing, the software system is delivered to the customer.
 Operation and maintenance. Normally (although not
necessarily), this is the longest life cycle phase. The system is
installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of
the life cycle, improving the implementation of system units and
enhancing the system’s services as new requirements are
discovered.
Process models – Waterfall (4)
 In principle, the result of each phase is one or more documents that are
approved (‘signed off’).
 The following phase should not start until the previous phase has finished.
In practice, these stages overlap and feed information to each other.
 During design, problems with requirements are identified. During coding,
design problems are found and so on. The software process is not a
simple linear model but involves feedback from one phase to another.
Documents produced in each phase may then have to be modified to
reflect the changes made.
 The waterfall model is consistent with other engineering process models
and documentation is produced at each phase. This makes the process
visible so managers can monitor progress against the development plan.
 Its major problem is the inflexible partitioning of the project into distinct
stages. Commitments must be made at an early stage.. in the process,
which makes it difficult to respond to changing customer requirements
 In principle, the waterfall model should only be used when the
requirements are well understood and unlikely to change radically during
system development.
Process models – V-Model

• Variation of waterfall model

 Depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling,
and early construction
activities.
Process models – Incremental
Process models – Incremental (2)
 There are many situations in which initial software requirements
are reasonably well defined, but the overall scope of the
development effort precludes a purely linear process. In
addition, there may be a compelling need to provide a limited
set of software functionality to users quickly and then refine and
expand on that functionality in later software releases. In such
cases, you can choose a process model that is designed to
produce the software in increments.
 For example, word-processing software developed using the
incremental paradigm might deliver basic file management,
editing, and document production functions in the first
increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar
checking in the third increment; and advanced page layout
capability in the fourth increment.
Process models – Incremental (3)
 Incremental software development, which is a fundamental part
of agile approaches, is better than a waterfall approach for most
business, e-commerce, and personal systems.
 Incremental development reflects the way that we solve
problems. We rarely work out a complete problem solution in
advance but move toward a solution in a series of steps,
backtracking when we realize that we have made a mistake.
Process models – Incremental (4)
Incremental development has three important benefits,
compared to the waterfall model
 The cost of accommodating changing customer requirements is
reduced. The amount of analysis and documentation that has to
be redone is much less than is required with the waterfall
model.
 It is easier to get customer feedback on the development work
that has been done. Customers can comment on
demonstrations of the software and see how much has been
implemented. Customers find it difficult to judge progress from
software design documents.
 More rapid delivery and deployment of useful software to the
customer is possible, even if all of the functionality has not
been included. Customers are able to use and gain value from
the software earlier than is possible with a waterfall process.
Process models – Incremental (5)
From a management perspective, the incremental approach has
two problems:
 The process is not visible. Managers need regular deliverables
to measure progress. If systems are developed quickly, it is not
cost-effective to produce documents that reflect every version
of the system.
 System structure tends to degrade as new increments are
added. Unless time and money is spent on refactoring to
improve the software, regular change tends to corrupt its
structure. Incorporating further software changes becomes
increasingly difficult and costly.
Process models – Incremental (6)
 The problems of incremental development become particularly
acute for large complex, long-lifetime systems, where different
teams develop different parts of the system. Large systems
need a stable framework or architecture and the responsibilities
of the different teams working on parts of the system need to be
clearly defined with respect to that architecture. This has to be
planned in advance rather than developed incrementally.
Evolutionary Process models

 Evolutionary models are iterative. They are characterized in a

manner that enables you to develop increasingly more
complete versions of the software.
Evolutionary Process models – Prototyping

 Prototyping may offer best

approach for:
 customer defines a set of general
objectives for software, but does not
identify detailed requirements for
functions and features
 the developer may be unsure of the
efficiency of an algorithm, the adapt-
ability of an operating system, or the
form that human-machine interaction
should take.
Evolutionary Process models – Prototyping
(2)
 The prototyping paradigm begins with communication. You
meet with other stakeholders to define the overall objectives for
the software, identify whatever requirements are known, and
outline areas where further definition is mandatory. A
prototyping iteration is planned quickly, and modeling (in the
form of a “quick design”) occurs. A quick design focuses on a
representation of those aspects of the software that will be
visible to end users (e.g., human interface layout or output
display formats). The quick design leads to the construction of a
prototype. The prototype is deployed and evaluated by
stakeholders, who provide feedback that is used to further
refine requirements. Iteration occurs as the prototype is tuned
to satisfy the needs of various stakeholders, while at the same
time enabling you to better understand what needs to be done.
Evolutionary Process models – Spiral model

Using the spiral model,

software is developed
in a series of
evolutionary re-
leases. During early
iterations, the release
might be a model or
prototype. During
later iterations,
increasingly more
complete versions of
the engineered system
are produced.
Evolutionary Process models – Spiral model (2)

 Each pass through the planning region results in adjustments to

the project plan. Cost and schedule are adjusted based on
feedback derived from the customer after delivery. In addition,
the project manager adjusts the planned number of iterations
required to complete the software.
 The spiral model is a realistic approach to the development of
large-scale systems and software. Because software evolves
as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.
 It may be difficult to convince customers (particularly in contract
situations) that the evolutionary approach is controllable. It
demands considerable risk assessment expertise and relies on
this expertise for success. If a major risk is not uncovered and
man-aged, problems will undoubtedly occur.
Discussion

 Which Software process is the best one?

 Please define some consideration(s) to choose the ‘best’
software process!

 Read: specialized process models, Unified models, Personal &

team process models (chp 4.2-4.4 of Pressman’s book)