Faculty of Computers and Artificial intelligence

Software Process and Quality

Management
COURSE CODE: SCS253

Dr. Lamia Abo Zaid presented by: Dr. Amr Galal

l .a bozai d@fci -cu.ed u.eg a mrgal al @aucegypt .edu
 Course Contents
Introduction

The Software Lifecycle

Software Engineering Development Models

 Waterfall Model

 The “V” Model

 Spiral Model

 Rational Unified Process

 Agile Processes

The Personal Software Process

The Team Software Process

Quality In The Software Process

Software Configuration Management

Open Issues in Process Management

Types of Process Models Observing the processes
actually performed
Descriptive

Describes current practice

Process Model
Aims to address all issues of
software development
Prescriptive
Tells people to do (some)
things differently
Types of Process Models
1. Current processes are modelled and transferred into a descriptive process model.
2. Using this model, problems are identified and mitigated by changes to the process
model 1
3. This model then becomes a prescriptive process model
effectively instructing people to do things differently
4 2
4. The process model becomes descriptive when the
changed process is fully integrated into people’s daily
work
5. A new improvement cycle can start
3
The Product–Process Relationship
The problems addressed by process changes are typically properties of the
software product or the project that produces or modifies the product.
If a problem is detected with the product, then one should aim at solving this
problem by changing the process.
Rombach defines the Product process–product relationship model as :
Q ≈ f (Process, Context)
o Q here means some quality aspect of the product, e.g. reliability, cost and can be
generalized to Goal
o f is an empirical relation
The Product–Process Relationship
Well understood means that the effects of methods
and processes on goal properties in varying are
known.

Software engineering research is still quite immature in

determining the function f because the methods and processes
are not yet well understood and thus not completely manageable.
Manageable means that for a given project context,
processes can be chosen so that they guarantee the
expected effects
Creating Prescriptive Process Models
The impact of changes to the process or context can be determined through
(combinations of) empirical studies of different types (e.g., qualitative or
quantitative studies, controlled experiments or case studies, real studies or
simulations).
The results obtained in such studies can be used to create prescriptive process
models that are proven to be beneficial in certain contexts and thus guarantee
specific product qualities.
Prescriptive Process Model Prerequisites
1. The scope of validity should be known. I.e. context(s) and goal(s) the process model is valid
for
a) context(s : Domain characteristics, organizational characteristics, project characteristics

b) Goals: e.g. the reduction of cycle time, improvement of code quality, improvement of reliability,
performance, etc.

2. The impact of a process should be known.

3. The degree of confidence should be known

4. The process should be tailorable

Prescriptive Process Models
Two types of Prescriptive process models can be distinguished:
1. Lifecycle Models
oLifecycle process models capture the complete lifecycle of a software product.
Typically, they abstract from a number of details, and instead provide a broader view
on the process (focus on “what,” not on “how”).
2. Engineering Models.
oEngineering process models describe (possibly in very much detail) a fraction of the
complete software lifecycle process, for example a specific type of inspection.
oEngineering process models can be very detailed, often not only describing “what” to
do, but also explaining “how” to do it.
Prescriptive Process Models
Two types of Prescriptive process models can be distinguished:
1. Lifecycle Models
◦ Waterfall Model
◦ The Iterative Enhancement Model
◦ The Prototyping Model
◦ The Spiral Model
◦ Unified Process Model

2. Engineering Models.
◦ Hybrid Cost Estimation
◦ Extreme Programming Process Model
The Software Lifecycle
Commonly has these activities:
1. Requirements analysis,

2. Design

3. Coding,

4. Testing,

5. Delivery

Different models perform them in different manner!

SOFTWARE PROCESS 11
1. Requirement Analysis
State the problem precisely!
Forms the basis of agreement between user and developer
Specifies “what” not “how”
Hard task - needs often not understood well
Requirement specifications of even medium systems can be many
hundreds of pages
Output is the SW Requirements Spec (SRS) document
SOFTWARE PROCESS 12
2. Design
A major step in moving from problem domain to solution domain
Three main tasks
1. Architecture design – components and connectors that should be there in the system
2. High level design – modules and data structures needed to implement the architecture
3. Detailed design – logic of modules

Most methodologies focus on architecture or high level design

Outputs are architecture /design/logic design docs

SOFTWARE PROCESS 13
3) Coding
Converts design into code in specific language
Goal: Implement the design with simple and easy to understand
code
Coding phase affects both testing and maintenance
oWell written code reduces testing and maintenance effort

Output is code

SOFTWARE PROCESS 14
4) Testing & Quality Assurance
Defects are introduced in each phase
Defects must be found and removed
Goal: Identify most of defects
Very expensive task; must be properly planned and executed
Outputs are
oTest plans/results,
oThe final tested (hopefully reliable) code
SOFTWARE PROCESS 15
When Are Defects Introduced?
Distribution of error occurrences by phase is
oRequirements - 20%
oDesign - 30%
oCoding - 50%

Defects can be injected at any of the major phases.

Cost of latency: Cost of defect removal increases exponentially with

latency time.

SOFTWARE PROCESS 16
Defects…

Cheapest way to detect and remove defects is close to where it is

injected.

 must check for defects after every phase.

SOFTWARE PROCESS 17
Prescriptive Process Models
Two types of Prescriptive process models can be distinguished:
1. Lifecycle Models
◦ Waterfall Model
◦ The Iterative Enhancement Model
◦ The Prototyping Model
◦ The Spiral Model
◦ Unified Process Model

2. Engineering Models.
◦ Hybrid Cost Estimation
◦ Extreme Programming Process Model
The Waterfall Process Model

 Introduced by Royce 1970

 The waterfall model is the classic lifecycle model – it is widely known,

understood and commonly used.

 In some respect, waterfall is the ”common sense” approach.

 phase
User Requirements output User Requirements Document

Software Requirements Software Requirements

Document

Architecture Design Architectural Design

Document

Detailed design & Coding Detailed

Design
& Code

Testing
The Waterfall
Lifecycle Model
Delivery
Time
The Waterfall Process Model- Advantages
1. Easy to understand and implement.
2. Reinforces good habits: define-before- design, design-before-
code
4. Identifies deliverables and milestones
5. Document driven, URD, SRD, … etc. Published documentation
standards, e.g. PSS-05.
6. Works well on mature products and weak teams.
The Waterfall Process Model Disadvantages
1. Idealised, doesn’t match reality well.
2. Unexpected requirements or context changes pose high risks
3. Doesn’t reflect iterative nature of exploratory development.
4. Unrealistic to expect accurate requirements so early in project
5. Difficult to integrate risk management
6. The documentation created is often voluminous and heavyweight.
7. The waterfall approach does not scale very well for large projects and long
cycle times.
Iterative Enhancement Process Model

SOFTWARE PROCESS 23
Iterative Enhancement Process Model
 The first iteration (checkerboard
pattern) develops the core part of the
complete system
 the second iteration (vertical stripes)
adds functionality
 the third iteration (horizontal stripes)
adds functionality

 To apply it the problem should permit

incremental development
Iterative Enhancement Process Model
Most Software Products follow it
Used commonly in customized development
oBusinesses want quick response for software
oCannot afford the risk of all-or-nothing

 Newer approaches like Extreme Programming, Unified Process

and Agile rely on iterative development

SOFTWARE PROCESS 25
Iterative Enhancement Process Model
Advantages
early customer involvement , getting feedback
Iterative projects support efficient learning
the core of the final product is available very early

Disadvantages
Architecture/design may not be optimal
A risk that requirements showing up later may be expensive to fulfil
Integration may become increasingly difficult with the number of iterations
Version and configuration management is necessary to distinguish increments.

SOFTWARE PROCESS 26
The Prototyping Model
Prototyping concentrates on the
development of an executable version of
the system that fulfils a limited number of
requirements.
The primary goal of building prototypes
is to gain initial experience
A prototype is a great way to clarify
ambiguous or unknown requirements;
however, it should not be confuse it with
the first version of the actual system!
The Prototyping Model
Advantages.
A prototype can be developed when the final properties are not clear.
Direct contact between customer and developer reduces misunderstandings.
Inconsistent requirements are discovered earlier.
Prototypes may even be used for evaluating business models
Disadvantages
Risk that side effects are not sufficiently considered
High cost
 The Spiral Process Model
 A risk-driven approach, Boehm 1986
 When end-user requirements are hard to
obtain/define, it is natural to develop
software in an experimental way.
 The first step of each spiral cycle identifies
the objectives of the product
part being elaborated
 next step evaluates the identified
alternatives and identifies and resolves
risks
 the complete cycle is reviewed by the
stakeholders
The Spiral Process Model
Advantages
The spiral model is very flexible.
The explicit consideration of risks avoids many of the difficulties of other process
models
Disadvantage
For contract software, the spiral model is difficult to apply because individual
project phases are not fully determined during project setup.
A bad risk assessment may lead to the selection of bad alternatives or development
The Incremental Commitment Spiral Model
In 2008, Boehm proposed the incremental commitment model (ICM) as a lifecycle model for
developing large systems with high development risks
it consists of a spiral covering the development lifecycle of a system.
However, it makes the risk-driven decisions explicit, accentuated by the stakeholder commitment
reviews
Each of these reviews constitutes a decision point with four possible exits
Being an incremental model, each spiral concurrently addresses all of the
activities of product development
The ICSM was developed for very large, very risky projects
where one does not know at the beginning whether and to what extent the
goal can be reached
V-Shaped Process Model
the V-Shaped process model also called Verification and Validation model is a variation of the
waterfall model.
o Each phase must be completed before the next phase begins.

o Testing is emphasized more than the waterfall model

The testing procedures are developed early in the life cycle before any coding is done

Software safety lifecycle model

33
V-Shaped Process Model

34
V-Shaped Process Model
Advantages

Follows a logical flow that is easily understandable

 Balances development activities with their corresponding testing activities

Disadvantages

Very rigid, little flexibility and adjusting scope is difficult and expensive.

Software is developed during the implementation phase, so no early prototypes of the

software are produced.

Model doesn’t provide a clear path for problems found during testing phases.

35
The Unified Process Model
The Unified Process is defined by Jacobson, Booch, and Rumbaugh in 1999.
The Unified Process is iterative and incremental
The Unified Process (UP) is a use-case-driven, architecture-centric, iterative and
incremental development process.
The Unified Process is component based
o the system is compiled from software components that are interconnected via well-defined
interfaces.
o The Unified Modelling Language (UML) is used to model all central artefacts describing the
system

36
The Unified Process Model
Use cases are central to system development, also driving design,
implementation, and testing.
Use cases and system architecture are developed in parallel
o Whereas the use cases describe the function of the system, the architecture describes its form

The system architect must find an architecture that satisfies the external factors
as well as the requirements stated in the use cases.
Typically UP starts with a part of the architecture that is not specific to the use
cases, as soon as a set of use cases is available that describes the key functions of
the system, the architecture is refined
37
 The Unified Process Model
A project typically goes through the phases:
oInception
oElaboration
oConstruction
oTransition

38
Questions ?
Assignment 1
Compare between the Unified Process Model and the The
Incremental Commitment Spiral Model.
Mention
oThe point of comparison (at least 4)
oThe references