SOFTWARE ENGINEERING

Subject Code : BCS501

MODULE 1
 CHAPTER 2 :

PROCESS MODELS
 Table of Contents

› A Generic Process Model

› Process Assessment and Improvement
› Prescriptive Process Models
› Specialized Process Models
› The Unified Process
 Quick Look
What is it? : When you work to build a product or system, it’s important to go through a series of predictable
steps—a road map that helps you create a timely, high-quality result. The road map that you follow is called
a “software process.”

Who does it? : Software engineers and their managers adapt the process to their needs and then follow it.

Why is it important? : Because it provides stability, control, and organization to an activity that can, if left
uncontrolled, become quite chaotic.

What are the steps? : At a detailed level, the process that you adopt depends on the software that you’re
building.

What is the work product? : From the point of view of a software engineer, the work products are the
programs, documents, and data that are produced as a consequence of the activities and tasks defined by
the process.
A Generic Process Model
A process was defined as a collection of work activities,
actions, and tasks that are performed when some work
product is to be created. Each of these reside within a
framework or model that defines their relationship
with the process and with one another.

Each software engineering action is defined by a task

set that identifies the work tasks that are to be
completed, the work products that will be produced,
the quality assurance points that will be required, and
the milestones that will be used to indicate progress.
A process flow describes how the frame work 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.

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 through the five
activities leads to a more complete version of the software.

A parallel process flow executes one or more activities in parallel with other activities.
Defining a Framework Activity

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. 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

Identifying a Task Set
Process Patterns
• Every software team encounters problems as it moves through the software process.

• 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.

• A process pattern provides you with a template, a consistent method for describing problem solutions
within the context of the software process.

• Process patterns provide an effective mechanism for addressing problems associated with any software
process.

• The patterns enable you to develop a hierarchical process description that begins at a high level of
abstraction.
Ambler has proposed a template for describing a process pattern:

Pattern Name : The pattern is given a meaningful name describing it within the context of the software
process.

Forces : The environment in which the pattern is encountered and the issues that make the problem visible
and may affect its solution.

Type : The pattern type is specified, Stage Pattern (Establishing Communication), Task Pattern (Requirements
Gathering), Phase Pattern (Spiral Model, Prototyping).

Initial context : Describes the conditions under which the pattern applies.

Problem : The specific problem to be solved by the pattern.

Solution : Describes how to implement the pattern successfully.

Resulting Context : Describes the conditions that will result once the pat tern has been successfully
implemented.
• What organizational or team-related activities must have occurred?

• What is the exit state for the process?

• What software engineering information or project information has been developed?

Related Patterns : Provide a list of all process patterns that are directly related to this one.

Known Uses and Examples : Indicate the specific instances in which the pattern is applicable.
 Process Assessment and Improvement
The existence of a software process is no guarantee that software will be delivered on time, that it will meet the
customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term quality characteristics.

A number of different approaches to software process assessment and improvement have been proposed over the past
few decades:

• 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.

• SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process assessment.

• 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.
 Prescriptive Process Models
Prescriptive process models were originally proposed to bring order to the chaos of software development.

History has indicated that these traditional models have brought a certain amount of useful structure to
software engineering work and have provided a reasonably effective road map for software teams.

Each process model also prescribes a process flow (also called a work flow)—that is, the manner in which
the process elements are interrelated to one another.

All software process models can accommodate the generic framework activities, but each applies a different
emphasis to these activities and defines a process flow that invokes each framework activity in a different
manner.
1. Waterfall Model

There are times when the requirements for a problem are well understood—when work flows from
communication through deployment in a reasonably linear fashion.

This situation is sometimes encountered when well-defined adaptations or enhancements to an existing

system must be made.

The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to
software development that begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in ongoing support of the completed
software.
A variation in the representation of the waterfall model
is called the V-model.

It depicts the relationship of quality assurance actions to

the actions associated with communication, modeling,
and early construction activities.

As a software team moves down the left side of the V,

basic problem requirements are refined into
progressively more detailed and technical
representations of the problem and its solution.

Once code has been generated, the team moves up the

right side of the V, essentially performing a series of
tests that validate each of the models created as the
team moved down the left side.
The waterfall model is the oldest paradigm for software engineering.

However, over the past three decades, criticism of this process model has caused even ardent supporters to
question its efficacy.

Among the problems that are sometimes encountered when the waterfall model is applied are:
• Real projects rarely follow the sequential flow that the model proposes.

• It is often difficult for the customer to state all requirements explicitly.

• The customer must have patience.

the linear nature of the classic life cycle leads to “blocking states” in which some project team members
must wait for other members of the team to complete dependent tasks.
2. Incremental Process Models

There are many situations in which initial software requirements are reasonably well defined, but the overall
scope of the development effort precludes a purely linear process.

There may be a compelling need to provide a limited set of soft ware functionality to users quickly and then
refine and expand on that functionality in later software releases.

The incremental model combines elements of linear and parallel process flows. Each linear sequence
produces deliverable “increments” of the software

For example, 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.
3. Evolutionary Process model

Software, like all complex systems, evolves over a period of time. The project requirements often change as
development proceeds.

Tight market deadlines make completion of a comprehensive software product impossible.

A set of core product or system requirements is well understood, but the details of product or system
extensions have yet to be defined.

Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software:
• Prototyping

• Spiral model
Prototyping

Often, a customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.

In other cases, the developer may be unsure of the efficiency of an algorithm, the adapt ability of an
operating system, or the form that human-machine interaction should take.

In these, and many other situations, a prototyping paradigm may offer the best approach. Although
prototyping can be used as a stand-alone process model, it is more commonly used as a technique that can
be implemented within the context of any one of the process models.
Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual
system, and developers get to build something immediately. Yet, prototyping can be problematic for the
following reasons:

Stakeholders see what appears to be a working version of the software, unaware that the prototype is held
together haphazardly, unaware that in the rush to get it working you haven’t considered overall software
quality or long-term maintainability.

As a software engineer, you often make implementation compromises in order to get a prototype working
quickly. An inappropriate operating system or programming language may be used simply because it is
available and known; an inefficient algorithm may be implemented simply to demonstrate capability.
Spiral Model

the spiral model is an evolutionary software process model that couples the iterative nature of proto typing
with the controlled and systematic aspects of the waterfall model.

It provides the potential for rapid development of increasingly more complete versions of the software.

Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the
release might be a model or prototype. During later iterations, increasingly more complete versions of the
engineered system are produced.

Anchor point milestones—a combination of work products and conditions that are attained along the path
of the spiral—are noted for each evolutionary pass
Spiral Model
As this evolutionary process begins, the software team performs activities that are implied by a circuit
around the spiral in a clockwise direction, beginning at the center.

The first circuit around the spiral might result in the development of a product specification. Subsequent
passes around the spiral might be used to develop a prototype and then progressively more sophisticated
versions of the software.

the spiral model can be adapted to apply throughout the life of the computer software. The first circuit
around the spiral might represent a “concept development project” that starts at the core of the spiral and
continues for multiple iterations until concept development is complete.

The spiral model is a realistic approach to the development of large-scale systems and software. Because
software evolves as the process progresses, the developer and customer better understand and react to risks
at each evolutionary level.
4. Concurrent Model

The spiral model is an evolutionary software process model that couples the iterative nature of proto typing
with the controlled and systematic aspects of the waterfall model. It provides the potential for rapid
development of increasingly more complete versions of the software.

The spiral development model is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems. It has two main distinguishing features.
One is a 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
 Specialized Process Models
Specialized process models take on many of the characteristics of one or more of the traditional models.

However, these models tend to be applied when a specialized or narrowly defined software engineering
approach is chosen.

• Component-Based Development

• The Formal Method Model

• Aspect –Oriented Software Development

1. Component-Based Development

Commercial off-the-shelf (COTS) software components, developed by vendors who offer them as products,
provide targeted functionality with well-defined interfaces that enable the component to be integrated into
the software that is to be built.

The component-based development model incorporates many of the characteristics of the spiral model. It is
evolutionary in nature, demanding an iterative approach to the creation of software. However, the
component-based development model constructs applications from prepackaged software components.

Modeling and construction activities begin with the identification of candidate components. These
components can be designed as either conventional software modules or object-oriented classes or
packages of classes.
Regardless of the technology that is used to create the components, the component-based development
model incorporates the following steps (implemented using an evolutionary approach):
• Available component-based products are researched and evaluated for the application domain in
question.
• Component integration issues are considered.
• A software architecture is designed to accommodate the components.
• Components are integrated into the architecture.
• Comprehensive testing is conducted to ensure proper functionality.
The component-based development model leads to software reuse, and reusability provides software
engineers with a number of measurable benefits. The software engineering team can achieve a reduction in
development cycle time as well as a reduction in project cost if component reuse becomes part of your
culture.
2. The Formal Methods Model

The formal methods model encompasses a set of activities that leads to formal mathematical specification
of computer software. Formal methods enable you to specify, develop, and verify a computer-based system
by applying a rigorous, mathematical notation. A variation on this approach, called cleanroom software
engineering is currently applied by some software development organizations.

When formal methods are used during development, they provide a mechanism for eliminating many of the
problems that are difficult to overcome using other software engineering paradigms. Ambiguity,
incompleteness, and inconsistency can be discovered and corrected more easily through the application of
mathematical analysis.

When formal methods are used during design, they serve as a basis for program verification and therefore
enable you to discover and correct errors that might otherwise go undetected.
Although not a mainstream approach, the formal methods model offers the promise of defect-free software.
Yet, concern about its applicability in a business environment has been voiced:
• The development of formal models is currently quite time consuming and expensive.

• Because few software developers have the necessary background to apply formal methods, extensive
training is required.

• It is difficult to use the models as a communication mechanism for technically unsophisticated customers.

The formal methods approach has gained adherents among software developers who must build safety-
critical software (developers of aircraft avionics and medical devices) and among developers that would
suffer severe economic hardship should software errors occur.
3. Aspect-Oriented Software Development

Regardless of the software process that is chosen, the builders of complex software invariably implement a
set of localized features, functions, and information content. These localized software characteristics are
modeled as components and then constructed within the context of a system architecture.

When concerns cut across multiple system functions, features, and information, they are often referred to as
crosscutting concerns. Aspectual requirements define those crosscutting concerns that have an impact
across the software architecture.

Aspect-oriented software development (AOSD), often referred to as aspect-oriented programming(AOP), is a

relatively new software engineering paradigm that provides a process and methodological approach for
defining, specifying, designing, and constructing aspects
A distinct aspect-oriented process has not yet matured. However, it is likely that such a process will adopt
characteristics of both evolutionary and concurrent process models.

The evolutionary model is appropriate as aspects are identified and then constructed.

The parallel nature of concurrent development is essential because aspects are engineered independently of
localized software components and yet, aspects have a direct impact on these components.
 The Unified Process
Today, the trend in software is toward bigger, more complex systems. That is due in part to the fact that
computers become more powerful every year, leading users to expect more from them. This trend has also
been influenced by the expanding use of the Internet for exchanging all kinds of information. We want
software that is better adapted to our needs, but that, in turn, merely makes the software more complex.

This has lead to need for a “use case driven, architecture-centric, iterative and incremental” software
process

In some ways 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.

UML—a unified modeling language that contains a robust notation for the modeling and development of
object-oriented systems. UML provided the necessary technology to support object-oriented software
engineering practice, but it did not provide the process framework to guide project teams in their
application of the technology.

Today, the Unified Process (UP) and UML are widely used on object-oriented projects of all kinds. The
iterative, incremental model proposed by the UP can and should be adapted to meet specific project needs.
Phases of Unified Process

a) Inception

b) Elaboration

c) Construction

d) Transition

e) Production
(i) 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.
• A plan for the iterative, incremental nature of the ensuing project is developed.

Fundamental business requirements are described through a set of preliminary use cases that describe
which features and functions each major class of users desires.

Architecture at this point is nothing more than a tentative outline of major subsystems and the function
and features that populate them. Later, the architecture will be refined and expanded into a set of models
that will represent different views of the system.

Planning identifies resources, assesses major risks, defines a schedule, and establishes a basis for the phases
that are to be applied as the software increment is developed.
(ii) 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 deployment model.

In some cases, elaboration creates an “executable architectural baseline” that represents a “first cut”
executable system.

The plan is carefully reviewed at the culmination of the elaboration phase to ensure that scope, risks, and
delivery dates remain reasonable.
(iii) 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 (the release) are then
implemented in source code. As components are being implemented, unit tests are designed and executed
for each. In addition, integration activities (component assembly and integration testing) are conducted.
(iv) 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.

In addition, the software team creates the necessary support information (e.g., user manuals,
troubleshooting guides, installation procedures) that is required for the release. At the conclusion of the
transition phase, the software increment becomes a usable software release.

(v) 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.

A software engineering workflow is distributed across all UP phases. a workflow identifies the tasks required
to accomplish an important software engineering action and the work products that are produced as a
consequence of successfully completing the tasks.
 Personal and Team Process Models
The best software process is one that is close to the people who will be doing the work. If a software process
model has been developed at a corporate or organizational level, it can be effective only if it is amenable to
significant adaptation to meet the needs of the project team that is actually doing software engineering
work.

In an ideal setting, you would create a process that best fits your needs, and at the same time, meets the
broader needs of the team and the organization. Alternatively, the team itself can create its own process,
and at the same time meet the narrower needs of individuals and the broader needs of the organization.
Personal Software Process (PSP)

Every developer uses some process to build computer software. The process may be haphazard or ad hoc; may
change on a daily basis; may not be efficient, effective, or even successful; but a “process” does exist.

The Personal Soft ware Process (PSP) emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product. In addition PSP makes the practitioner responsible for
project planning (estimating and scheduling) and empowers the practitioner to control the quality of all
software work products that are developed.

The PSP model defines five framework activities:

Planning, High-level design, High-level design review, Development, Postmortem

Personal Software Process (PSP)

Every developer uses some process to build computer software. The process may be haphazard or ad hoc; may
change on a daily basis; may not be efficient, effective, or even successful; but a “process” does exist.

The Personal Soft ware Process (PSP) emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product. In addition PSP makes the practitioner responsible for
project planning (estimating and scheduling) and empowers the practitioner to control the quality of all
software work products that are developed.

The PSP model defines five framework activities:

Planning, High-level design, High-level design review, Development, Postmortem

Team Software Process (TSP)

Because many industry-grade software projects are addressed by a team of practitioners, Watts Humphrey
extended the lessons learned from the introduction of PSP and proposed a Team Software Process (TSP). The
goal of TSP is to build a “self directed” project team that organizes itself to produce high-quality software.

Humphrey defines the following objectives for TSP:

• Build self-directed teams that plan and track their work, establish goals, and own their processes and
plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them sustain peak performance.
• Accelerate software process improvement by making CMM23 Level 5 behavior normal and expected.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
TSP defines the following framework activities: project launch, high-level design, implementation, integration
and test, and postmortem.

Like their counterparts in PSP these activities enable the team to plan, design, and construct software in a
disciplined manner while at the same time quantitatively measuring the process and the product. The
postmortem sets the stage for process improvements.