Week-2

Software Process Models

CS2004-Fundamentals of Software Engineering- Spring’26
Course Instructor: Mahrukh Khan
 Process

Defines Who is doing What,When to do it, and How to reach a certain goal.

• Workers, the ‘who’

• Activities, the ‘how’
• Artifacts, the ‘what’
• Workflows, the ‘when’
SDA 2
 Software Process Models

It is a description of Why Process Model?

i) what tasks need to be performed Provide “guidance” for a systematic
in coordination and controlling of
a) the tasks and of
ii) what sequence under b) the personnel who perform
the tasks
iii) what conditions by
iv) whom to achieve the “desired
results.”

Note the key words: coordination/control , tasks, people

SDA 3
 Software Process Activities

 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.
 1. Software Specification

 The process of establishing what services are required and the constraints on the
system’s operation and development.

[Link] elicitation and analysis [Link] specification

• What do the system stakeholders require or • Defining the requirements in detail
expect from the system? • Business requirements
• Project objectives and boundaries • User requirements
• Vision and scope document • System requirements

[Link] validation
• Checking the validity of the
requirements.
• Test-cases often reveals ambiguity.
• SRS inspection by developers, testers.
 2. Software Design and
Implementation
The process of converting the system specification into an executable system.
Software design:
• Design a software structure that realizes the specification
Implementation:
• Translate this structure into an executable program
The activities of design and implementation are closely related and may be inter-leaved.
General Model of Design Phase
 3. Software Validation
 Verification and validation (V & V) is intended to show that a system conforms to its
specification and meets the requirements of the system customer.
 Involves checking and review processes and system testing.
 System testing involves executing the system with test cases that are derived from the
specification of the real data to be processed by the system.
 Testing is the most commonly used V & V activity.
 4. Software Evolution

▪ Software is inherently flexible and can change.

▪ As requirements change through changing business
circumstances, the software
that supports the business must also evolve and
change.
 Process

 A particular method of accomplishing a task, involving some steps.

 When we discuss processes in SE, 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.
 Software Process Flow

Define a framework
activity.
Identify a Task Set
 Generic Process Flows

◾ Linear process flow

◾ Iterative process flow
◾ Incremental process flow

SDA 6
Generic Process Flow
 Plan-driven and Agile Processes

Plan-driven processes are

processes where all of the process In agile processes, planning is
activities are planned in advance incremental and it is easier to
and progress is measured against
this plan. 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.
 TESTING PHASES IN A PLAN-DRIVEN
SOFTWARE PROCESS
Component testing:
• Individual components are
tested independently;
• Components may be
functions or objects or
coherent groupings of these
entities.
System testing:
• Testing of the system as a
whole.
Customer testing:
• Testing with customer data
to check that the system
meets the customer’s needs.
 Software Process Models
 A software life cycle model (or process model):
 a descriptive and diagrammatic model of software life cycle
 A process model for software engineering is chosen based on the nature of the project and
application, the method and tools to be used and the controls and deliverables that are
required.
 Waterfall Model
 V Model
 Incremental Model
 Evolutionary Models ( Prototype, Spiral)
 Specialized Process Models (Component Based Development, Formal Methods Model,
Aspect-Oriented Software Development)
 Waterfall Model
A sequential, plan driven-
process where you must plan and When to consider:
schedule all your activities before
starting the project. 1. Requirements are very well understood.
2. Team has experience building similar projects (like ATM
Machine).
3. Technology is understood and not dynamic.
4. No ambiguous requirements.
 Waterfall Model
Pros:
 Easy to understand and simple
 Predictable

Cons:
 First release take a long time, hence It suffers from the fact that the client
feedback is received when the product is finally delivered and hence
any errors in the requirement specification are not discovered until the
product is sent to the client after completion.
 A phase has to be complete before next phase (no back track) .Not
flexible for a change.
 Unrealistic to expect accurate requirements so early in project
 V Model

 The V model (Verification and Validation model)

is an extension of the waterfall model. All the
requirements are gathered at the start and
cannot be changed. You have a corresponding
testing activity for each stage. For every phase in
the development cycle, there is an associated
testing phase.
 V model a good choice for software where
downtimes and failures are unacceptable.
 it isn’t good for complex projects or projects that
have unclear or changing requirements.
 Example 01:
Analyze the situation and suggest the Model
Let's say there is a solution company that basically experts in installing particular HR
management system in big retailers.
So let's say company X needs to install a well known HR management system at a big
retailer's headquarter. And they have done this install many times with similar retailers, big
retailers before. So the question is, what model will fit best in this situation?

✔Well known problem

✔Well known solution

Waterfall Model
 Incremental Model

• It combines linear and parallel process flows. The incremental

model divides the system’s functionality into small increments that
are delivered one after the other in quick succession. The most
important functionality is implemented in the initial increments.
• The incremental model is great for projects that have loosely
coupled parts and projects with complete and clear requirements.

Example:
A 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.
 Incremental Model

Benefits Drawbacks

The cost of accommodating Managers need regular

changing customer deliverables to measure
requirements is reduced. progress. If systems are
developed quickly, it is not
cost-effective to produce
documents that reflect every
version of the system.

It is easier to get customer Regular change tends to

feedback on the development corrupt its structure.
work that has been done. Incorporating further software
changes becomes increasingly
difficult and costly. regularly
refactor the software is
suggested

More rapid delivery and

deployment of useful software
to the customer is possible.
 Evolutionary Process Models

 Software, like all complex systems, evolves over a period of time.

 The iterative development model develops a system by building small portions of all the
features.
 This helps to meet the initial scope quickly and release it for feedback.
 easy to identify and fix any functional or design flaws. It also makes it easier to manage risk
and change requirements.
 Iterative v/s Incremental
Incremental Model (Iterative
Aspect Iterative Model
Enhanced Model)
Development Approach Repetitive cycles with continuous refinement Delivering the software in functional parts

Flexibility Highly flexible and adaptive to changes Offers flexibility but less than iterative

Testing Testing is integrated throughout the cycle Testing is done for each increment

Complete features are developed in each

Delivery of Features Features are delivered incrementally
iteration

Risk Management Risks are identified and addressed in each cycle Risks are managed as increments are delivered

Feedback is collected and incorporated

Client Feedback Feedback is obtained after each increment
regularly

Offers visible progress with each delivered

Project Visibility Provides a clearer view of the project's progress
increment

Dependencies can be identified and resolved Dependencies between increments need

Dependency Management
in each iteration careful management

May take longer to deliver the complete

Completion Time Allows for partial delivery in shorter timeframes
product

Example Analogy Writing a draft and refining it multiple times Building a house floor by floor
Incremental delivery
 Evolutionary Models: Prototype

• A prototype is an initial version of a system

used to demonstrate concepts and try out
design options.
• Can be used as a standalone Process
model but more commonly used within the
context of any process model. A prototype
can be used in:
• The requirements engineering process to
help with requirements elicitation and
validation;
• In design processes to explore options
and develop a UI design;
• In the testing process to run back-to-
back tests
 Prototyping

• May involve leaving out functionality

• Prototype should focus on areas
of the product that are not well-
understood;
• Error checking and recovery may
not be included in the prototype;
• Focus on functional rather than
non-functional requirements such
as reliability and security
• Users may get confused in the
prototypes and actual systems.
• Developers may try to reuse the
existing prototypes to build the actual
system, even when it is not technically
feasible.
Throwaway Prototyping

• Prototypes should be discarded after development as

they are not a good basis for a production system:
• It may be impossible to tune the system to meet non-functional requirements;
• Prototypes are normally undocumented;
• The prototype structure is usually degraded through rapid change;
• The prototype probably will not meet normal organizational quality standards
 Evolutionary Models: Spiral

 Risk-driven iterative software process

model proposed by Barry Boehm.
 It couples the iterative nature of
prototyping with control and systematic
aspects of Waterfall Model.
 Each loop in the spiral represents a phase
of the software process. Thus, the
innermost loop might be concerned with
system feasibility, the next loop with
requirements definition, the next loop with
system design, and so on.
 The spiral model combines change
avoidance with change tolerance. It
assumes that changes are a result of
project risks and includes explicit risk
management activities to reduce these
risks.
Spiral Model
 Example 02
Analyze the situation and suggest the Model
 A hospital wanted to automate their processes. And so they have hired a company that is
expert in this area and has done similar automation for hospitals but not at this scale, So
they have done it, but not at this scale. And then hospital management also wants
consistency across the globe. So they want their processes to be consistent across the
globe, but of course, every country has their own culture. And so they know that they'll be
some new answers in different parts of the world, so they want to customize it over
different places. And then they also realize that some of the places will greatly benefit
from immediately deploying this kind of automation.

✔Fairly known problem

✔Known solution but in big scale
✔Consistency

Incremental model
 Rational Unified Process

 UP is an attempt to draw on the best features and characteristics of conventional

s/w process models and also implements many of the best principles of agile
software development
 UP is a framework for object-oriented software engineering using UML (Unified
Modeling Language)
Suggest the most appropriate generic
software process model.
 A system to control antilock braking in a car
 A virtual reality system to support software maintenance
 A university accounting system that replaces an existing system
 An interactive travel planning system that helps users plan journeys with the
lowest environmental impact
 Phases of UP

• UP is an attempt to draw on the best

f eat ures a n d c h a r a c t e r i s t i c s o f
conventional s/w process models
• Also implements many of the best
principles of agile software
development
• UP is a framework for object-
oriented software engineering using
UML (Unified Modeling Language)
Integration and Configuration

Three types of software components are frequently reused

1. Stand-alone application systems that are configured for use in a
particular environment. These systems are general-purpose systems that
have many features, but they have to be adapted for use in a specific
application.
2. Collections of objects that are developed as a component or as a
package to be integrated with a component framework such as the
Java Spring framework (Wheeler and White 2013).
3. Web services that are developed according to service standards and
that are available for remote invocation over the Internet.
 Re-usable Softwares

 Based on software reuse where systems are integrated from existing

components or application systems (sometimes called COTS -Commercial-
off-the-shelf) systems.
 COTS Software Components, developed by vendors, who offer them a
products, provide targeted functionality with well defined interfaces that
enable the component to be integrated into the software that is to be built.
 Example Microsoft Office, Oracle etc
 Key process stages
I. Requirements specification
II. Software discovery and
evaluation
III. Requirements refinement
IV. Application system
configuration
V. Component adaptation and
integration
 Coping with change

Change is inevitable in all large software projects.

• Business changes lead to new and changed system requirements.
• New technologies open up new possibilities for improving implementations.
• Changing platforms require application changes.
Approaches to reduce the costs of rework
1. Change anticipation:
• Where the software process includes activities that can
anticipate possible changes before significant rework is required.
• For example, a prototype system may be developed to show some key features of the system
to customers.

2. Change tolerance:
• Where the process is designed so that changes can be
accommodated at relatively low cost.
• This normally involves some form of incremental development.
 Process Improvement
• Process measurement
• You measure one or more attributes of the software process or product. These measurements forms a
baseline that helps you decide if process improvements have been effective.
• Process analysis
• The current process is assessed, and process weaknesses and bottlenecks are identified. Process models
(sometimes called process maps) that describe the process may be developed.
• Process change
• Process changes are proposed to address some of the identified process weaknesses. These are introduced
and the cycle resumes to collect data about the effectiveness of the changes.
 Process Metrics
• Time taken for process activities to be completed
• E.g. Calendar time or effort to complete an activity or process.
• Resources required for processes or activities
• E.g. Total effort in person-days.
• Number of occurrences of a particular event
• E.g. Number of defects discovered.
 Process measurement

• Wherever possible, quantitative process data

should be collected
• However, where organizations do not have clearly defined process standards
this is very difficult as you don’t know what to measure. A process may have
to be defined before any measurement is possible.

• Process measurements should be used to

assess process improvements
• But this does not mean that measurements should drive the improvements.
The improvement driver should be the organizational objectives.
CMM

 Software Engineering Institute (SEI) proposed their model of process

capability maturity (Humphrey 1988). The maturity of a software
company’s processes reflects the process management,
measurement, and use of good software engineering practices in
the company and identify areas for improvement
 It is based on profound feedback and development practices
adopted by the most successful organizations worldwide.
 This model describes a strategy for software process improvement
that should be followed by moving through 5 different levels. Each
level of maturity shows a process capability level. All the levels
except level 1 are further described by Key Process Areas (KPA).
 CMM-Levels

• Initial
• Essentially uncontrolled , processes are unpredictable
• Managed
• Product management procedures defined and used at project level.
• Defined
• Process management procedures and strategies defined and used
at organization level.
• Quantitatively Managed
• Processes are controlled using statistical techniques.
• Optimizing
• Process improvement strategies defined, processes are continuously
improved.
CMM Levels
 When to use Waterfall

 [Link] 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.
 2. Critical systems where there is a need for extensive safety and
security analysis of the software specification and design must be
complete so that this analysis is possible. Safety related problems in
the specification and design are usually very expensive to correct
at the implementation stage.
 3. Large software systems that are part of broader engineering
systems developed by several partner companies. The hardware in
the systems may be developed using a similar model, and
companies find it easier to use a common model for hardware and