Software Process Models

Instructor: Mehroze Khan

1
Software Life Cycle

When the process involves the building of some product, we

sometimes refer to the process as a life cycle. Thus, the
software development process is sometimes called the
software life cycle, because it describes the life of a software
product from its conception to its implementation, delivery,
use, and maintenance.

2
Software Life Cycle

Software development usually involves the following stages:

• Requirements analysis and definition
• System design
• Program design
• Writing the programs (program implementation)
• Unit testing
• Integration testing
• System testing
• System delivery
• Maintenance

3
Process

• A process is defined as a collection of work activities, actions,

and tasks that are performed when some work product is to
be created.
• Each of these activities, actions, and tasks reside within a
framework or model that defines their relationship with the
process and with one another.
• A software process is a framework for the activities, actions,
and tasks that are required to build high-quality software.

4
Generic A generic process framework for
software engineering defines five
Process framework activities:
Framework • Communication
• Planning
• Modeling
• Construction
• Deployment

5
 Process Flow

• Process flow—describes how the framework activities and the

actions and tasks that occur within each framework activity are
organized with respect to sequence and time.

• A linear process flow executes each of the five framework

activities in sequence, beginning with communication and
culminating with deployment.

6
 Process Flow

• An iterative process flow repeats one or more of the activities

before proceeding to the next.

7
 Process Flow

• An evolutionary process flow executes the activities in a “circular”

manner. Each circuit through the five activities leads to a more
complete version of the software.

8
 Process Flow

• A parallel process flow executes one or more activities in parallel

with other activities (e.g., modeling for one aspect of the software
might be executed in parallel with construction of another aspect
of the software).

9
Task Set

For a small software project requested by one person (at a

remote location) with simple, straightforward requirements,
the communication activity might encompass little more than
a phone call with the appropriate stakeholder. Therefore, the
only necessary action is phone conversation, and the work
tasks (the task set) that this action encompasses are:
1. Contact stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of
requirements.
4. E-mail to stakeholder for review and approval.

10
Task Set

If the project was considerably more complex with many

stakeholders, each with a different set of (sometime
conflicting) requirements, the communication activity might
have six distinct actions:
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation.

11
 Task Set
• Inception: The initial stage where the project is conceived, and the goals and objectives are
outlined.
• Identifying the key stakeholders, understanding their initial requirements, and setting the project's overall
direction.
• Elicitation: The process of gathering information and requirements from stakeholders to
understand their needs and expectations.
• Conducting interviews, surveys, workshops, or other methods to extract relevant information from
stakeholders.
• Elaboration: The stage where gathered requirements are analyzed and detailed to create a
comprehensive understanding of the project scope.
• Breaking down high-level requirements into more detailed specifications, creating use cases, and
developing a more intricate project plan.
• Negotiation: The process of reconciling conflicting requirements and priorities among
stakeholders.
• Facilitating discussions and negotiations to resolve conflicts, finding compromises, and ensuring alignment
among stakeholders.
• Specification: The formal documentation and communication of detailed project
requirements and specifications.
• Creating detailed documentation, such as requirements documents, design specifications, and other
relevant materials that serve as a reference for project development.
• Validation: The stage where the documented requirements are reviewed and verified to
ensure they meet the stakeholders' expectations.
• Conducting reviews, inspections, and tests to validate that the project deliverables align with the specified
requirements and meet the intended objectives. 12
Software Development Process Models

• Waterfall model
• Classical
• With prototyping
• V model
• Prototyping model
• Phased development: increments and iterations
• Spiral model
• Unified process
• Rapid Application Development (RAD)
• Agile methods
• XP
• Scrum
• Kanban

13
The Waterfall Model

• One of the first process development models proposed

• Works for well understood problems with minimal or no
changes in the requirements
• Simple and easy to explain to customers
• It presents
• a very high-level view of the development process
• sequence of process activities
• Each major phase is marked by milestones and deliverables
(artefacts)

14
The Waterfall Model

15
The Waterfall Model

16
The Waterfall Model

⚫ Provides no guidance how to handle changes to products

and activities during development (assumes requirements
can be frozen)
⚫ Views software development as manufacturing process
rather than as building process
⚫ There are no iterative activities that lead to building a final
product
⚫ Long wait before a final product
⚫ Generates lots of documentation
⚫ Considered suitable for large projects

17
The Waterfall Model

⚫ Uncontrolled Software Development Process

⚫ No Iterations in WF?

18
Problems with Waterfall Model

It is often difficult for the

Real projects rarely follow customer to state all
the sequential workflow requirements explicitly at
that the model proposes. the beginning of most
projects.

The customer must have

patience because a working Major blunders may not be
version of the program(s) will detected until the working
not be available until late in program is reviewed.
the project time span.

19
Waterfall Model with Prototyping

⚫ A prototype is a partially developed product

⚫ Prototyping helps
⚫ developers assess alternative design strategies
(design prototype)
⚫ users understand what the system will be like (user
interface prototype)

20
Waterfall Model with Prototyping

21
 The V-Model

•A variant of the waterfall model

•Uses unit testing to verify procedural design
•Uses integration testing to verify architectural (system)
design
•Uses acceptance testing to validate the requirements
•If problems are found during verification and validation,
the left side of the V can be re-executed before testing
on the right side is re-enacted
• Verification: Each function works correctly
• Validation: All requirements have been implemented and each functionality
can be traced back to a particular requirement
22
The V-Model

23
Phased Development

•Cycle time
•Time between when requirements document was
written and when the system was delivered
•Shorter cycle time
•Decomposed system
•System delivered in pieces
•enables customers to have some functionality
while the rest is being developed
•Two systems functioning in parallel
•the production system (release n): currently being
used
•the development system (release n+1): the next
version
24
Phased Development

25
 Phased Development

•Incremental development: starts with small functional

subsystem and adds functionality with each new release

•Iterative development: delivers a full system at the very

beginning and then changes the functionality of each
subsystem with each new release.

26
Phased Development

•Training on early release

•Responsive developers
•Markets for early functionality
•Quick and Global fixing on unanticipated problems
•Ability to work on different areas of expertise with
different releases

27
 Prototyping Model

•Allows repeated investigation of the requirements or

design
•Reduces risk and uncertainty in the development

28
Prototyping Model

Pros:
• There is a reduced impact of requirement changes.
• The customer is involved early and often.
• It works well for small projects.
• There is reduced likelihood of product rejection.

Cons:
• Customer involvement may cause delays.
• There may be a temptation to “ship” a prototype.
• Work is lost in a throwaway prototype.
• It is hard to plan and manage.
29
References

1. Shari PFleeger, Joanne Atlee, Software Engineering: Theory

and Practice, 4th Edition
2. Roger S. Pressman, Software Engineering A Practitioner’s
Approach, 9th Edition. McGrawHill

30