LECTURE NO.

Software Process
Software Process
• Fundamental Assumption:
– Good processes lead to good software
– Good processes reduce risk
– Good processes enable teamwork
• Varity of software processes
– Software products are very varied. Therefore, there is
no standard process for all software engineering
projects
– BUT successful software development projects always
need to address similar issues. This creates a number of
process steps that should be part of all software
projects.
The software process (Simplified)
Feasibility and
Planning Requirements

Design

Implementation Operation and

Maintenance
Basic Software Process Steps
• Feasibility and Planning
• Requirements
These steps may be
• System and Program design repeated many
• Implementation times during the
development cycle.
• Acceptance and Release
• Operation and Maintenance
Process Step: Feasibility and Planning
A feasibility study precedes the decision to begin a project.

What is the scope of the proposed project?

Is the project technically feasible?

What are the projected benefits?

What are the costs?

Are the resources available?

What are the risks and how can they be managed?

A feasibility study leads to a decision: go or no-‐go.

Process Step: Requirement

Requirements define the function of the system

from the client's viewpoint.

The requirements establish the system's

functionality, constraints, and goals by consultation
with the client, customers, and users.

They must be developed in a manner that is

understandable by both the client and the
development staff.
Process Step: Requirement

This step is 1.Requirements analysis

occasionally 2.Requirements definition
3.Requirements specification
divided into:

The requirements may be developed in a

limited manner or may emerge incrementally.

Failure to agree on the requirements and

define them adequately is one of the biggest
cause of software projects failing.
Process Step: System Design
Design describes the system from the software
developers' viewpoint
• Establish a system architecture, both hardware and
System design: software, that matches the requirements

Program • Represent the software functions in a form that can be

transformed into one or more executable programs
design:
Models are used to represent the requirements,
system architecture, and program design.
Process Step: Implementation
• The software design is realized as a set of
programs or program units.
Implementation • These software components may be written by
the development team, acquired from
(coding) elsewhere, or modified from existing
components.

• Program testing by the development staff is an

integral part of implementation.
• Individual components are tested against the
Program testing design.
• The components are integrated and tested
against the design as a complete system.
Process Step: Operation and Maintenance

Operation: • The system is put into practical use.

Maintenance: • Errors and problems are identified and fixed.

• The system evolves over time as requirements

Evolution: change, to add new functions, or adapt to a
changing technical environment.

Phase out: • The system is withdrawn from service.

This is called the Software Life Cycle

Sequence of Process Steps
We will look at three categories of software development processes:

As far as possible, complete each

Sequential: process step before beginning the
next. Waterfall model.

Go quickly through all process

steps to create a rough system,
Iterative: then repeat them to improve the
system. Iterative refinement.

A variant of iterative refinement in

which small increments of software
Incremental: are placed in production (sprints).
Agile development.
Heavy Weight and Light Weight Software
Development

In a heavyweight process, the development team

works through the process steps slowly and • Example:
systematically, with the aim of fully completing Waterfall
each process step and deliverables for that step Model
that will need minimal changes and revision.

In a lightweight process, the development team

releases working software in small increments, • Example:
and develops the plans incrementally, based on Agile
experience. Each increment includes all the Software
process steps. There is an expectation that Development
changes will be made based on experience.
Deliverables

A deliverable is some work product that is

delivered to the client.

In a heavyweight process each process step

creates a deliverable, usually documentation,
e.g., a requirements specification.
In a lightweight process, the deliverables are
incremental working code, with minimal
supporting documentation.
Quality Control Steps in all Software
Development
Validating the requirements

Validating the system and program design

Usability testing

Program testing

Acceptance testing

Some of these steps will be repeated many times

during the life of the system
SOFTWARE
PROCESS MODELS
Process Models
– The Waterfall Model
– Incremental Process Models
– Evolutionary Process Models
• Prototyping
• The Spiral Model
– Concurrent Models
• V-Model (V-Software Development Process
Model)
THE WATER FALL MODEL
The Water Fall Model
The Water Fall Model
• Requirements – defines needed information, function,
behavior, performance and interfaces.
• Design – data structures, software architecture, interface
representations, algorithmic details.
• Implementation – source code, database, user
documentation, testing.
• Test – check if all code modules work together and if the
system as a whole behaves as per the specifications.
• Installation – deployment of system, user-training.
• Maintenance – bug fixes, added functionality (an on-going
process).
The Water Fall Model
Advantages Disadvantages
• Easy to understand, easy to • All requirements must be
use known upfront
• Provides structure to • Difficult for the customer to
inexperienced staff state all requirements
explicitly
• Milestones are well
• Integration is one big bang at
understood
the end
• Sets requirements stability
• Little opportunity for
• Good for management customer to preview the
control (plan, staff, track) system (until it may be too
late)
When to use Water Fall Model
• Requirements are very well known
• When it is possible to produce a stable design
– E.g. a new version of an existing product
– E.g. porting an existing product to a new
platform.
V-Model
• Verification and Validation
Model
• Extension of the
waterfall model
• Based on the association
of a testing phase for each
corresponding
development stage
When to Use the V-Model
1. Suitable when project requirements are well-defined and stable.
2. Effective for small to medium-sized projects with relatively stable
requirements.
3. Commonly used in the development of critical systems and safety-critical
applications.
4. Aligns well with organizations following a waterfall-like development approach.
5. Advantages in projects where there is a strong emphasis on testing and quality
assurance.
6. Clients or stakeholders may request the V-Model, especially for regulatory
compliance.
7. Appropriate when the risk of requirement changes during development is low.

• Remember: Assess project characteristics, requirement stability, and team

expertise when deciding to use the V-Model.
Incremental Process Model
Incremental Process Model
Combines elements of the waterfall model
applied in an iterative fashion.

Incremental applies linear sequences as the

calendar time progress.

Limited software functionalities and expands

functionalities in later software release.
Increment Model
Each linear sequence
produces a deliverable
increment of the software First increment is often a
• Eg. Word processing core product
software

Customers evaluate this core

Basic requirements are
product, and the next
addressed, but many
increment is planned based
supplementary remains
on suggestions and next set
undelivered.
of features

The plan addresses the

Process is repeated until
modification of core product
complete product is
and delivery of additional
produced.
features and functionalities.
Increment Model
• Useful when
– Staff is unavailable for complete implementation
and deadline is tight
– If core product is well received, additional staff
can implement next increment
– Increment can be planned to manage technical
risks
– Partial functionalities can be delivered to end –
user without inordinate delay.
Incremental Model
Advantages Disadvantages
• Generates working software • Needs good planning and
quickly and early during the design.
software life cycle. • Needs a clear and complete
• It is easier to test and debug definition of the whole
during a smaller iteration. system before it can be
• Customer can respond to broken down and built
each built. incrementally.
• Lowers initial delivery cost. • Total cost is higher than
• Easier to manage risk waterfall.
because risky pieces are
identified and handled
during iteration.
Evolutionary Process Model
• These models are more suited to object-oriented
systems.
• They are iterative.
• They enable the software developer to develop
increasingly more complex versions of the software
• Like all complex systems, software evolves over a
period of time and hence evolutionary models are
more suited to software development.
• Requirements change while software gets developed.
Prototype Model
• Customer defines objective to software
engineer, but not specifies input ,
process ,output requirements.
• Developer may be unsure about efficiency of
algorithm, adaptability of OS, or human-
machine interaction
• In this situation Prototype is best approach
Prototype Model
• Used as standalone Process model
• Used as a technique implemented in any
process model
• Prototype paradigm assists software and
customer to better understand and build the
software when requirement is fuzzy
Prototype Model
Prototype Model
Communication:
• Software Engineer and customer defines overall objective
• Identifies requirements and outline area
• Definition is mandatory

Quick plan is made

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)

Leads the construction of prototype

Deployed and evaluated

• by stakeholders, who provide feedback that is used to further refine
requirements.
Prototype Model
• Limitations
– Prototype is quick and dirty solution
– At the prototype level no focus on software
quality or long-term maintainability
– Too much changes can disturb rhythm of
developer
– It is a thrown away prototype when the users are
confused with it
Spiral Model

Proposed by Barry Boehm - Evolutionary software process model

Couples Iterative nature of prototyping + waterfall model

Potential for rapid development of increasingly more complete version of

software

Spiral Model - software is developed in a series of evolutionary releases.

Early iteration - Paper model / prototype (trial product)

Later increasingly more complete version of engineering software is

produced
Spiral Model
Briefer diagram
Spiral Model
Each loop in the spiral is split into four sectors

Objective setting

• Specific objectives for the phase are identified.

• Constraints on the process and the product are identified
and a detailed management plan is drawn up
• Project risks are identified

Risk assessment and reduction

• Risks are assessed and activities put in place to reduce the

key risks.
• For example, if there is a risk that the requirements are
inappropriate, a prototype system may be developed
Spiral Model…..continued
Development and validation

• A development model for the system is chosen which can be any

of the generic models.
• For example, throwaway prototyping may be the best
development approach if user interface risks are dominant.
• If safety risks are the main consideration, development based on
formal transformations may be the most appropriate process.
• If the main identified risk is sub-system integration, the waterfall
model may be the best development model to use

Planning

• The project is reviewed, and the next phase of the spiral is

planned.
Spiral Model
Advantage: Disadvantage
• Realistic approach of • Can be a costly model to use.
development in large scale • Risk analysis requires highly
• Developer and customer specific expertise.
satisfaction
• Project’s success is highly
• Reacts to risk at evolutionary
dependent on the risk analysis
level
phase.
• Uses prototype - Risk
reduction mechanism • Doesn’t work well for smaller
• Enables developer to apply projects.
prototype in any stage
• Direct consideration of
technical risk at all step.
When to use Spiral Model
When costs and risk evaluation is important

For medium to high-risk projects

Long-term project commitment unwise because of potential changes to

economic priorities

Users are unsure of their needs

Requirements are complex

Significant changes are expected (research and exploration)

THANK YOU