TE (CS)

Fall 2022 Semester

CS-326: Software Engineering

Lectures 03-04
Software Process Models
Dr Syed Zaffar Qasim
Assistant Professor (CIS)
1

Software Process Models

An abstract representation of a software process
▪ Each process model represents a process from a
particular perspective.
o e.g., a process activity model shows the activities
and their sequence
o but may not show the roles of people involved in
these activities.
➢Process models to be covered
1. The waterfall model
2. Evolutionary Development
3. Incremental development
4. Integration and Configuration models

Software Engineering (CS-326) 1

Software Process Models
▪ Sub-systems within a larger system may be
developed using different approaches.
▪ It should be understood that, in practice, different
process models are often combined.
1. The Waterfall Model
o The fundamental process activities of specification,
development, validation and evolution are
represented as separate process phases.

Fig 1: General Model of

distributed system

The waterfall model

▪ Suggests a systematic sequential approach to
software development.
▪ An example of a plan-driven process.
▪ Sometimes called the classic life cycle.
• The principal stages of the model:-
1. Requirements analysis and definition:
o The system’s services and constraints are established by
consultation with system users.
o They are then defined in detail and serve as a system
specification.

Software Engineering (CS-326) 2

The waterfall model
2. System and software design:
o Partitions the requirements to either hardware or
software systems.
o Establishes an overall system architecture.
o Software design involves identifying and describing
the fundamental software system abstractions and
their relationships.

The waterfall model

3. Implementation and unit testing:
o The software design is realized as a set of programs or
program units.
o Unit testing involves verifying that each unit meets its
specification.

4. Integration and system testing:

o The individual program units or programs are
integrated and tested as a complete system to ensure
that the software requirements have been met.
o After testing, the software system is delivered to the 6
customer.

Software Engineering (CS-326) 3

The waterfall model
5. Operation and maintenance:
o The system is installed and put into practical use.
o Involves correcting errors which were not discovered
in earlier stages of the life cycle, improving the
implementation and enhancing the system’s services
as new requirements are discovered.

The waterfall model

• Problems encountered
o Real projects rarely follow the sequential flow that
the model proposes. In practice, these stages
overlap and feed information to each other.
o It is often difficult for the customer to state all
requirements explicitly.
o A working version of the program(s) will not be
available until late in the project time-span.
• Advantages of the waterfall model
o Documentation is produced at each phase and
o It fits with other engineering process models.

Software Engineering (CS-326) 4

The waterfall model

▪ Where and When to use

o The waterfall model should only be used when the
requirements are well understood and unlikely to
change during system development.
❖When well-defined adaptations or enhancements
to an existing system must be made
❖(e.g. an adaptation to accounting software that
has been mandated because of changes to
government regulations).

The waterfall model

• Where and When to use
o Critical systems where there is a need for extensive
safety and security analysis of the software
specification and design.
❖In these systems, the specification and design
documents must be complete so that this analysis is
possible.
o Embedded systems where the software has to
interface with hardware systems.
❖Because of the inflexibility of hardware, it is not
usually possible to delay decisions on the
software’s functionality until it is being
implemented.
10

Software Engineering (CS-326) 5

The waterfall model
• Unsuitability
o The waterfall model is not the right process model
in situations where
❖informal team communication is possible and
❖software requirements change quickly.
o Iterative development and agile methods are better
for these systems.

11

Evolutionary Process Model

II.Evolutionary Model
▪ Plan-driven approaches not suitable under following
situations:-
1.Business and product requirements change
frequently as development proceeds.
2.Tight market deadlines make completion of a
comprehensive software product impossible.
o a limited version must be introduced to meet
competitive or business pressure.
3.A set of core product or system requirements is
well understood,
o but the details of product or system extensions
have yet to be defined.
12

Software Engineering (CS-326) 6

Evolutionary Process Model
▪ Evolutionary development: An iterative approach in
which specification, development and validation
activities are interleaved rather than separate with rapid
feedback across activities.

▪ Basic Process
o developing an initial implementation,
o exposing this to user comment and
o refining it through many versions until an adequate
system has been developed. 13

Evolutionary Process Model

▪ Two fundamental types of evolutionary
development:-
1.Exploratory development where the objective of
the process is to work with the customer to
explore their requirements and deliver a final
system.
o The development starts with the parts of the
system that are understood.
o The system evolves by adding new features
proposed by the customer.

14

Software Engineering (CS-326) 7

Evolutionary Process Model
▪ Two fundamental types of evolutionary
development:-
2.Throwaway prototyping where objective is to
understand customer’s requirements and hence
develop a better requirements definition for the
system.
o The prototype concentrates on experimenting
with the customer requirements that are
poorly understood.
o Although prototyping can be used as a
standalone process model, it is more
commonly used within the context of any one
of process models.
15

Evolutionary Process Model

▪ Prototyping process
o Customer communicates basic objectives to
software engineer.
o A prototyping pattern is planned quickly and quick
design is developed.
o The quick design focuses on visible aspects of
software (e.g., human interface layout or output
display formats).
o The prototype is built and then evaluated by the
customer/user.
o Feedback is used to refine requirements for the
software.

16

Software Engineering (CS-326) 8

Evolutionary Process Model
▪ Prototyping process (cont’)
o Iteration occurs as the prototype is tuned to satisfy
the needs of the customer, while at the same time
enabling the developer to better understand what
needs to be done.
▪ Advantage of evolutionary approach
o the specification can be developed incrementally.
o As users develop a better understanding of their
problem, this can be reflected in the software system.

17

Evolutionary Process Model

➢ From an engineering and management perspective, the
evolutionary approach has two problems:-
a. The process is not visible:
o Managers need regular deliverables to measure
progress.
o If systems are developed quickly, it is not cost-
effectiveness to produce documents that reflect every
version of the system.
b.Systems are often poorly structured:
o Continual change tends to corrupt the software
structure.
o Incorporating software changes becomes increasingly
difficult and costly.
18

Software Engineering (CS-326) 9

Evolutionary Process Model

▪ For small and medium-sized systems, the

evolutionary approach is the best approach to
development.
▪ The problems of evolutionary development
become particularly acute for large, complex,
long-life-time systems, where different teams
develop different parts of the system.
o It is difficult to establish a stable system
architecture in this approach, which makes it
hard to integrate contributions from the teams.

19

Evolutionary Process Model

▪ For large systems, a mixed process is

recommended:-
o Developing a throwaway prototype using an
evolutionary approach to resolve uncertainties
in the system specification.
o Then reimplement the system using a more
structured approach.
▪ Other parts of the system, such as the user-
interface,
o which are difficult to specify in advance,
o should always be developed using an
exploratory programming approach. 20

Software Engineering (CS-326) 10