Chapter 2:

Software Process, Process Models

Software Engineering

Dr. Yahya Esmail Al-Ashmori

Ph.D. in Information Technology (IT)
Email: [email protected]
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 – The software to meet the
specification must be produced ;
– 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.
2
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.
What / who / why is Process Models?
◼ What: Go through a series of predictable steps--- a road
map that helps you create a timely, high-quality results.

◼ Who: Software engineers and their managers, clients also.

People adapt the process to their needs and follow it.

◼ Why: Provides stability, control, and organization to an

activity that can if left uncontrolled, become quite chaotic.
However, modern software engineering approaches must
be agile and demand ONLY those activities, controls and
work products that are appropriate.
4
What / who / why is Process Models?
◼ What Work products: Programs, documents, and data

◼ What are the steps: The process you adopt depends on the
software that you are building. One process might be good
for aircraft avionic system, while an entirely different process
would be used for website creation.

◼ How to ensure right: A number of software process

assessment mechanisms that enable us to determine the
maturity of the software process. However, the quality,
timeliness and long-term viability of the software are the5 best
indicators of the efficacy of the process you use.
Definition of Software Process (SP)
• A framework for the activities, actions, and tasks
that are required to build high-quality software.

• SP defines the approach that is taken as software

is engineered.

• SP Is not equal to software engineering, which

also encompasses technologies that populate
the process– technical methods and automated
tools.
6
A Generic Process Model

7
A Generic Process Model
◼ As we discussed before, a generic process
framework for software engineering defines five
framework activities - )communication, planning,
modeling, construction, and deployment(.

◼ In addition, a set of umbrella activities- project

tracking and control, risk management, quality
assurance, configuration management, technical
reviews, and others are applied throughout the 8

process.
A Generic Process Model

9
A Generic Process Model
◼ Next question is:

• How the framework activities and the actions and

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

• Linear process flow , An iterative process flow, A

parallel process flow ………

• See the process flow for answer in next slides

10
Process Flow

11
Process Flow
❑ Linear process flow executes each of the five activities in
sequence.

❑ An iterative process flow repeats one or more of the

activities before proceeding to the next.

❑ An evolutionary process flow executes the activities in a

circular manner. Each circuit leads to a more complete
version of the software.

❑ A parallel process flow executes one or more activities in

parallel with other activities ( modeling for one aspect of the
software in parallel with construction of another aspect of
12
the software(.
Identifying a Task Set
◼ Before you can proceed with the process model, a key
question: what actions are appropriate for a
framework activity given the nature of the problem, the
characteristics of the people and the stakeholders?
◼ A task set defines the actual work to be done to
accomplish the objectives of a software engineering
action.
◼ A list of the task to be accomplished
◼ A list of the work products to be produced
◼ A list of the quality assurance filters to be applied
13
Identifying a Task Set
◼ For example, a small software project requested by one
person with simple requirements, the communication
activity might encompass little more than a phone all with
the stakeholder. Therefore, the only necessary action is
phone conversation, the work tasks of this action are:

◼ 1. Make contact with 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. 14

Example of a Task Set for Elicitation
◼ The task sets for Requirements gathering action for a
simple project may include:
1. Make a list of stakeholders for the project.

2. Invite all stakeholders to an informal meeting.

3. Ask each stakeholder to make a list of features and

functions required.

4. Discuss requirements and build a final list.

5. Prioritize requirements.

6. Note areas of uncertainty. 15

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.

Software process models

17
The Waterfall Model

• It is the oldest paradigm for SE. When requirements are

well defined and reasonably stable, it leads to a linear
fashion.
• problems: 1. rarely linear, iteration needed. 2. hard to state all requirements
explicitly. Blocking state. 3. code will not be released until very late.)
• The classic life cycle suggests a systematic, sequential 18
approach to software development.
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 is the difficulty of

accommodating change after the process is underway. In
principle, a phase has to be complete before moving onto the

next phase.
The waterfall model

20
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.
The V-Model

22
The V-Model
• A variation of waterfall model depicts the relationship of
quality assurance actions to the actions associated with
communication, modeling and early code construction
activates.
• Team first moves down the left side of the V to refine
the problem requirements. Once code is generated, the
team moves up the right side of the V, performing a
series of tests that validate each of the models created
as the team moved down the left side.
23
Advantages of 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.

24
Disadvantages of 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.

25
When to use the V-model:
• The V-shaped model should be used for small to medium
sized projects where requirements are clearly defined and
fixed.

• The V-Shaped model should be chosen when ample technical

resources are available with needed technical expertise.

• High confidence of customer is required for choosing the V-

Shaped model approach. Since, no prototypes are produced,
there is a very high risk involved in meeting customer
expectations.

26
The Incremental Model

27
The Incremental Model
• When initial requirements are reasonably well defined, but
the overall scope of the development effort precludes a
purely linear process. A compelling need to expand a limited
set of new functions to a later system release.

• It combines elements of linear and parallel process flows.

Each linear sequence produces deliverable increments of
the software.

• The first increment is often a core product with many

supplementary features. Users use it and evaluate it28 with
more modifications to better meet the needs.
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.
29
Incremental development

30
Incremental development problems
From a management perspective, the incremental approach has
two 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.
31
Incremental development problems
• The problems of incremental development become
particularly acute for large, complex, long-lifetime
systems, where different teams develop different parts
of the system.

• Large systems need a stable framework or architecture

and the responsibilities of the different teams working
on parts of the system need to be clearly defined with
respect to that architecture. This has to be planned in
advance rather than developed incrementally.
32
Evolutionary Models
• Software system evolves over time as requirements often
change as development proceeds. Thus, a straight line to
a complete end product is not possible. However, a limited
version must be delivered to meet competitive pressure.
• Usually a set of core product or system requirements is
well understood, but the details and extension have yet to
be defined.
• You need a process model that has been explicitly
designed to accommodate a product that evolved over
time.
• It is iterative that enables you to develop increasingly more
complete version of the software.
• Two types are introduced, namely Prototyping and Spiral 33

models.
Evolutionary Models: Prototyping
• When to use: Customer defines a set of general objectives but
does not identify detailed requirements for functions and
features. Or Developer may be unsure of the efficiency of an
algorithm, the form that human computer interaction should
take.

34
Evolutionary Models: Prototyping
• What step: Begins with communication by meeting with
stakeholders to define the objective, identify whatever
requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and
modeling (quick design) occur. Quick design focuses on a
representation of those aspects the software that will be
visible to end users. ( interface and output). Design leads to
the construction of a prototype which will be deployed and
evaluated.

35
Evolutionary Models: Prototyping
• Stakeholder’s comments will be used to refine requirements.

• Both stakeholders and software engineers like the prototyping

paradigm. Users get a feel for the actual system, and
developers get to build something immediately. However,
engineers may make compromises in order to get a prototype
working quickly. The less-than-ideal choice may be adopted
forever after you get used to it.

36
Evolutionary Models: Prototyping

Quick plan
communication
Modeling
Quick design

Deployment
delivery & Construction
feedback Construction
of
prototype
of prototype

37
Evolutionary Models: The Spiral
• It couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model and
is a risk-driven process model generator that is used to guide
multi-stakeholder concurrent engineering of software
intensive systems.

• Two main distinguishing features: one is cyclic approach for

incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk. The other
is a set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system
38
solutions.
Evolutionary Models: The Spiral

39
Evolutionary Models: The Spiral

40
Evolutionary Models: The Spiral
• A series of evolutionary releases are delivered. During the
early iterations, the release might be a model or prototype.
During later iterations, increasingly more complete version of
the engineered system are produced.

• The first circuit in the clockwise direction might result in the

product specification; subsequent passes around the spiral
might be used to develop a prototype and then progressively
more sophisticated versions of the software. Each pass results
in adjustments to the project plan. Cost and schedule are
41

adjusted based on feedback. Also, the number of iterations will

be adjusted by project manager.
Evolutionary Models: The Spiral
• Good to develop large-scale system as software
evolves as the process progresses and risk should
be understood and properly reacted to. Prototyping
is used to reduce risk.

• However, it may be difficult to convince customers

that it is controllable as it demands considerable
risk assessment expertise.

42
Three Concerns on Evolutionary Processes

• First concern is that prototyping poses a problem to

project planning because of the uncertain number of
cycles required to construct the product.

• Second, it does not establish the maximum speed of

the evolution. If the evolution occur too fast, without
a period of relaxation, it is certain that the process
will fall into chaos. On the other hand if the speed is
too slow then productivity could be affected. .
43
Three Concerns on Evolutionary Processes

• Third, software processes should be focused on

flexibility and extensibility rather than on high
quality. We should prioritize the speed of the
development over zero defects. Extending the
development in order to reach high quality could
result in a late delivery of the product.

44
Concurrent Model
• Allow a software team to represent iterative and
concurrent elements of any of the process models.
For example, the modeling activity defined for the
spiral model is accomplished by invoking one or
more of the following actions: prototyping, analysis
and design.

45
Concurrent Model
• The Figure shows modeling may be in any one of
the states at any given time. For example,
communication activity has completed its first
iteration and in the awaiting changes state. The
modeling activity was in inactive state, now makes
a transition into the under development state. If
customer indicates changes in requirements, the
modeling activity moves from the under
development state into the awaiting changes state.
46
Concurrent Model

47
Concurrent Model
• Concurrent modeling is applicable to all types of software
development and provides an accurate picture of the current
state of a project. Rather than confining software
engineering activities, actions and tasks to a sequence of
events, it defines a process network. Each activity, action or
task on the network exists concurrently with other activities,
actions or tasks. Events generated at one point trigger
transitions among the states.

48
Concurrent Model

49
Still Other Process Models
• Component based development—the process to apply
when reuse is a development objective ( like spiral model)
• Formal methods—emphasizes the mathematical
specification of requirements ( easy to discover and
eliminate ambiguity, incompleteness and inconsistency)
• Aspect Oriented software development (AOSD)—provides
a process and methodological approach for defining,
specifying, designing, and constructing aspects
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned
with the Unified Modeling Language (UML) to model and
develop object-oriented system iteratively and
incrementally.

50
The Unified Process (UP)

The Unified Software Development Process or

Unified Process is a popular iterative and
incremental software development process
framework. The best-known and extensively
documented refinement of the Unified Process is the
Rational Unified Process (RUP).
Created by the Rational Software Corporation, a
division of IBM since 2003
51
Waterfall vs. Unified Process
Waterfall Unified Process
• Incremental and Iterative
• One dimensional • Two dimensional
• Each phase must be • Task is divided into
increments (phases)
completed before you
• Within each increment
begin the next phase. the developers have to
iterate (workflows) until
task is complete
• Consecutive series of
waterfall models
Phases of the Unified Process
• Inception :
– Determine whether it is worthwhile to develop product
– Initial scope and financial details
• Elaboration:
– Refine requirements, produce software management plan
• Construction
– Produce beta-release, initial user manual
• Transition
– Client feedback, correct faults, complete manuals
• Production:
– The ongoing use of the software is monitored, support for
the operating environment (infrastructure) is provided, and
defect reports and requests for changes are submitted
and evaluated.
Workflows in the Unified Process
• Different workflows (activities) are performed over
the entire life cycle
• However, there are times when one workflow may
be dominant
• Core Workflows
– Requirements
– Analysis
– Design
– Implementation
– Test
– support
The Unified Process (UP)

55
UP Phases

56
UP Work Products

57
Software Process Models Project
1. Agile development methodology
2. Scrum
3. DevOps deployment methodology
4. Lean Model
5. Rapid application development (RAD)
6. Extreme programming (XP)
7. Aspect Oriented software development (AOSD)
8. Object-oriented programming (OOP)
9. Personal Software Process (PSP)
10. Team Software Process (TSP)
11. Dynamic systems development method (DSDM),
12. Agile Unified Process (AUP)
13. Disciplined agile delivery (DAD)
14. Scaled Agile Framework (SAFe)
15. Large-Scale Scrum (LeSS)
16. Feature-Driven Development (FDD)
58