The Software Process

Process Models

1
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.
 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 the best
indicators of the efficacy of the process you use. 2
Definition of Software
Process
• 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.

• Is not equal to software engineering, which also

encompasses technologies that populate the process–
technical methods and automated tools.
3
•A Process Framework establishes the foundation for a complete software process by
identifying a small number of framework activities that are applicable to all s/w projects,
regardless of size/complexity and set of umbrella activities which are applicable across
entire s/w process.

•Each framework activity is populated by a set of S/W engg actions – a collection of related
tasks that produces a major S/W eng work product (Design is a S/W eng action). 4
A Generic Process Model

5
 A Generic Process
Model
 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
process.
 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? See the
process flow for answer. 6
Process Flow

7
 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 the
software. 8
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

9
 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 call 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.
[Link] notes into a brief written statement of

requirements.
4. E-mail to stakeholder for review and approval.10
 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.

11
 Example of a Task Set for Elicitation

 The task sets for Requirements gathering action for a big project may include:
1. Make a list of stakeholders for the project.
2. Interview each stakeholders separately to determine overall wants and needs.
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the system.
12. Discuss methods for validating the system.

 Both do the same work with different depth and formality. Choose the task sets that achieve the goal
and still maintain quality and agility.

12
13
Process Patterns
• A process pattern
• describes a process-related problem that is encountered
during software engineering work,
• identifies the environment in which the problem has been
encountered, and
• suggests one or more proven solutions to the problem.

• Stated in more general terms, a process pattern provides you

with a template [Amb98]—a consistent method for describing
problem solutions within the context of the software process.
( defined at different levels of abstraction)
1. Problems and solutions associated with a complete process
model (e.g. prototyping).
2. Problems and solutions associated with a framework activity
(e.g. planning) or
3. an action with a framework activity (e.g. project estimating).
14
Process Pattern
Types
• Stage patterns—defines a problem associated with a framework
activity for the process. It includes multiple task patterns as well.
For example, Establishing Communication would incorporate the
task pattern Requirements Gathering and others.
• Task patterns—defines a problem associated with a software
engineering action or work task and relevant to successful software
engineering practice
• Phase patterns—define the sequence of framework activities that
occur with the process, even when the overall flow of activities is
iterative in nature. Example includes Sprial Model or Prototyping.

15
 Process Assessment and
Improvement
SP cannot guarantee that software will be delivered on time, meet the needs, or has the desired
technical characteristics. However, the process can be assessed to ensure that it meets a set of
basic process criteria that have been shown to be essential for a successful software engineering.

•Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five
step process assessment model that incorporates five phases: initiating, diagnosing, establishing,
acting and learning.
•CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—
provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment
[Dun01]
•SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements
for software process assessment. The intent of the standard is to assist
organizations in developing an objective evaluation of the efficacy of any
defined software process. [ISO08]
•ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products, systems,
or services that it provides. Therefore, the standard is directly applicable
16 to
software organizations and companies. [Ant06]
17
 Prescriptive Models
• Prescriptive process models advocate an orderly approach to software
engineering. However, will some extent of chaos (less rigid) be beneficial
to bring some creativity?

That leads to a few questions …

• If prescriptive process models strive for structure and order (prescribe a
set of process elements and process flow), are they inappropriate for a
software world that thrives on change?
• Yet, if we reject traditional process models (and the order they imply) and
replace them with something less structured, do we make it impossible to
achieve coordination and coherence in software work?
18
 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 approach

19
to software development.
 A variation of waterfall model
depicts the relationship of
The V-Model
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.

20
The
Incremental
Model

21
 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 it with more
modifications to better meet the needs.
22
 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 models.
23
 Evolutionary Models:
• When to use: Customer defines a set of general objectives but does not identify
Prototyping
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.
• 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.
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 to24get a
prototype working quickly. The less-than-ideal choice may be adopted forever
after you get used to it.
Evolutionary Models:
Prototyping
Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

25
 Evolutionary Models: The
• It couples the iterative nature of prototyping with the controlled and systematic aspects of
Spiral
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 solutions.
• 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 adjusted based on feedback. Also,
the number of iterations will be adjusted by project manager.
• Good to develop large-scale system as software evolves as the process progresses and 26 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.
Evolutionary Models: The
Spiral

27
 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.
• 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 when the opportunity niche has
disappeared.
28
The Unified Process
(UP)
•Unified process (UP) is an architecture-centric, use-case driven, iterative and
incremental development process. UP is also referred to as the unified software
development process.
•The Unified Process is an attempt to draw on the best features and characteristics of
traditional software process models, but characterize them in a way that implements many
of the best principles of agile software development.
• The Unified Process recognizes the importance of customer communication and
streamlined methods for describing the customer’s view of a system. It emphasizes the
important role of software architecture and “helps the architect focus on the right goals,
such as understandability, reliance to future changes, and reuse” .
•It suggests a process flow that is iterative and incremental, providing the
evolutionary feel that is essential in modern software development. 29
A Brief History

•During the early 1990s James Rumbaugh, Grady Booch, and Ivar
Jacobson began working on a “unified method” that would combine the
best features of each of their individual object-oriented analysis and
design methods and adopt additional features proposed by other experts
in object- oriented modeling.
•The result was UML—a unified modeling language that contains a
robust notation for the modeling and development of object-oriented
systems.
•They developed the Unified Process, a framework for object-oriented
software engineering using UML.
30
Phases of the Unified Process
This process divides the development process
into five phases:


Inception

Elaboration

Construction

Transition

Production
31
The Unified Process (UP)

32
Inception phase
•The inception phase of the UP encompasses both customer communication and
planning activities. By collaborating with stakeholders, business requirements for the
software are identified; a rough architecture for the system is proposed; and a plan for
the iterative, incremental nature of the ensuing project is developed.

Elaboration phase
•The elaboration phase encompasses the communication and modeling activities of
the generic process model. Elaboration refines and expands the preliminary use cases
that were developed as part of the inception phase and expands the architectural
representation to include five different views of the software—the use case model,
the requirements model, the design model, the implementation model, and the

33 that
deployment model. Elaboration creates an “executable architectural baseline”
represents a “first cut” executable system.
 • Construction phase

• The construction phase of the UP is identical to the construction activity defined for the generic software process. Using
the architectural model as input, the construction phase develops or acquires the software components that will make each use
case operational for end users.
• To accomplish this, requirements and design models that were started during the elaboration phase are completed to
reflect the final version of the software increment.
• All necessary and required features and functions for the software increment (i.e., the release) are then implemented in
source code.
•

34
Transition phase
•The transition phase of the UP encompasses the latter stages of the
generic construction activity and the first part of the generic
deployment (delivery and feedback) activity.
•Software is given to end users for beta testing and user feedback
reports both defects and necessary changes.
•At the conclusion of the transition phase, the software increment
becomes a usable software release.
35
Production phase

•The production phase of the UP coincides with the deployment

activity of the generic process. During this phase, 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.
•It is likely that at the same time the construction, transition, and
production phases are being conducted, work may have already
begun on the next software increment.
•This means that the five UP phases do not occur in a sequence, but
rather with staggered concurrency. 36
UP
Phases

37
UP Work
Products

38