Lecture 2 Software Process Models

Lecture 2 Software Processes 1

Why process models?

SE is the application of a systematic, disciplined,

quantifiable approach to the development,
operation, and maintenance of software ...
(IEEE Standard Glossary of Software Engineering Terminology, 1990).

Definition of the term SE

requires studying models for
systematic software
development (main objective
of SE)!
The software process

A structured set of activities required to develop a

software system.
Many different software processes but all involve:
Specification defining what the system should do;
Design and implementation defining the organization of the
system and implementing the system;
Validation checking that it does what the customer wants;
Evolution changing the system in response to changing
customer needs.
A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.
Lecture 2 Software Processes 3
 Information flow in SW projects

How the customer How the Project How the Software How the How theTester
explained it Leader understood architect designed Programmer wrote left it
it it it

Source: unknown
How the Business How the project was How the customer How it was supportedWhat the customer
Consultant described it documented was billed really needed
Relevance of process models
Process models are relevant for

Qualitative assessment of SW
companies
Certification for ISO
Project organization: 9000/CMM
Otherwise: sporadic,
Project analysis:
uncoordinated project
What are the weak
management
points in the
Experience: development process?
high-quality SW is
impossible without a
systematic approach
to SW development Time and cost planning
Software process descriptions

When we describe and discuss processes, we usually

talk about the activities in these processes such as
specifying a data model, designing a user interface,
etc. and the ordering of these activities.
Process descriptions may also include:
Products, which are the outcomes of a process activity;
Roles, which reflect the responsibilities of the people involved in
the process;
Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.

Lecture 2 Software Processes 6

Plan-driven and agile processes

Plan-driven processes are processes where all of the

process activities are planned in advance and progress
is measured against this plan.
In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
In practice, most practical processes include elements of
both plan-driven and agile approaches.
There are no right or wrong software processes.

Lecture 2 Software Processes 7

Software process models

Lecture 2 Software Processes 8

Most familiar process models: overview

Classical phase model Iterative phase model

(waterfall model) (life cycle)

V model Process models

Incremental
model

Prototyping
(evolutionary SE) Spiral model
Software process models

The waterfall model

Plan-driven model. Separate and distinct phases of specification
and development.
Incremental development
Specification, development and validation are interleaved. May
be plan-driven or agile.
Integration and configuration
The system is assembled from existing configurable
components. May be plan-driven or agile.
In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
Lecture 2 Software Processes 10
The waterfall model

Lecture 2 Software Processes 11

Waterfall model phases

There are separate identified phases in the waterfall

model:
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
The main drawback of the waterfall model:
Difficulty of accommodating change after the process is
underway. In principle, a phase has to be complete before
moving onto the next phase.

Lecture 2 Software Processes 12

Waterfall model problems

Inflexible partitioning of the project into distinct stages

makes it difficult to respond to changing customer
requirements.
Therefore, this model is only appropriate when the requirements
are well-understood and changes will be fairly limited during the
design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.

Lecture 2 Software Processes 13

The V Model

14
V- Model

V- model means Verification and Validation model.

Just like the waterfall model, the V-Shaped life cycle is a
sequential path of execution of processes. Each
phase must be completed before the next phase
begins. Testing of the product is planned in parallel with
a corresponding phase of development.

15
Phases of the V-model

Requirements like BRS and SRS begin the life cycle model just like
the waterfall model. But, in this model before development is started,
a system test plan is created. The test plan focuses on meeting the
functionality specified in the requirements gathering.
The high-level design (HLD) phase focuses on system architecture
and design. It provide overview of solution, platform, system,
product and service/process. An integration test plan is created in
this phase as well in order to test the pieces of the software
systems ability to work together.
The low-level design (LLD) phase is where the actual software
components are designed. It defines the actual logic for each and
every component of the system. Class diagram with all the methods
and relation between classes comes under LLD. Component tests
are created in this phase as well.
16
Phases of the V-model..contd/

Coding is at the bottom of the V-Shape model. Module

design is converted into code by developers.
The implementation phase is, again, where all coding
takes place. Once coding is complete, the path of
execution continues up the right side of the V where the
test plans developed earlier are now put to use.

17
Validation phases

Unit Testing: Unit tests designed in the module design

phase are executed on the code during this validation
phase. Unit testing is the testing at code level and
helps eliminate bugs at an early stage, though all
defects cannot be uncovered by unit testing.
Integration Testing: Integration testing is associated
with the architectural design phase. Integration tests are
performed to test the coexistence and communication of
the internal modules within the system.

18
Validation phases..contd/

System Testing: System testing is directly associated with

the System design phase. System tests check the entire
system functionality and the communication of the system
under development with external systems. Most of the
software and hardware compatibility issues can be uncovered
during system test execution.
Acceptance Testing: Acceptance testing is associated with
the business requirement analysis phase and involves testing
the product in user environment. Acceptance tests uncover
the compatibility issues with the other systems available in the
user environment. It also discovers the non functional issues
such as load and performance defects in the actual user
environment.

19
Advantages of the V-model

Simple and easy to use.

Testing activities like planning, test designing happens
well before coding. This saves a lot of time. Hence
higher chance of success over the waterfall model.
Proactive defect tracking that is defects are found at
early stage.
Avoids the downward flow of the defects.
Works well for small projects where requirements are
easily understood.

20
Disadvantages of the V-model

Very rigid and least flexible.

Software is developed during the implementation phase,
so no early prototypes of the software are produced.
If any changes happen in midway, then the test
documents along with requirement documents has to be
updated.

21
Iterative & Incremental Development

To solve the major flaws of waterfall model:

Iterative Development
Incremental Development

What are the main difference/s??

Lecture 2 Software Processes 22

Iterative & Incremental Development

Lecture 2 Software Processes 23

 Iterative Software Development

In practice, development is always iterative, and all software phases

progress in parallel.
Analysis
Maintenance through iteration
Design
Requirements
Collections

Testing based on requirements Validation through prototyping

Testing Implementation

Testing throughout implementation

Iterative Development

An approach to building software in which overall

lifecycle is composed of several iterations in sequence
Each iteration is a self-contained mini-project composed
of activities such as requirements analysis, design,
coding and testing
Goal at the each of each iteration:
Iteration release a stable, integrated and tested partially
complete system
Most iteration releases are internal(development team)
Final iteration release is the complete product released on
the market or clients

Lecture 2 Software Processes 25

Incremental development

Lecture 2 Software Processes 26

Incremental development benefits

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.
More rapid delivery and deployment of useful software to
the customer is possible.
Customers are able to use and gain value from the software
earlier than is possible with a waterfall process.
Lecture 2 Software Processes 27
Incremental development 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.

Lecture 2 Software Processes 28