The Software Process

The software process provides a strategy that a software development team employs in order to build quality
software. It is chosen based on the nature of the project and application, methods and tools to be used, and the
management and work products that are required. Pressman provides a graphical representation of the software
process. According to him, it provides the framework from which a comprehensive plan for software development
can be established. It consists of framework activities, tasks sets and umbrella activities.

Common Process Framework

Framework Activity 1
y2
T

yn

T
Mi T Task Set 1
Tasks
D
S D Milestones
S Deliverables
SQA Points

Umbrella Activities

Figure 1.2 Pressman's Software Process

Framework of Activities
These are activities that are performed by the people involved in the development process applicable to any
software project regardless of project size, composition of the development team, and complexity of the problem.
They are also known as phases of the software development process.
Task Sets
Each of the activities in the process framework defines a set of tasks. These tasks would have milestones,
deliverables or work products and software quality assurance (SQA) points. They are modified and adjusted to
the specific characteristic of the software project, and the requirements of the software.
Umbrella Activities
These are activities that supports the framework of activities as the software development project progresses
such as software project management, change management, requirements management, formal technical
reviews etc.

Types of Software Process Models

There are many types of software process models that suggest how to build software. Common process models
are discussed within this section.
Linear Sequential Model
The Linear Sequential Model is also known as the waterfall model or the classic life cycle. This is the first
model ever formalized, and other process models are based on this approach to development. It suggests a
systematic and sequential approach to the development of the software. It begins by analyzing the system,
progressing to the analysis of the software, design, coding, testing and maintenance. It insists that a phase
cannot begin unless the previous phase is finished. Figure 1.3 shows this type of software process model.

Requirements
Engineering

Design
Engineering

Coding

Testing

Operation
and
Maintenance

Figure 1.3 Linear Sequential Model

The advantages of this model are:

It is the first process model ever formulated.
It provides a basis for other software process models.
The disadvantages of this model are:
Real software projects rarely follow a strict sequential flow. In fact, it is very difficult to decide when
one phase ends and the other begins.
End-user involvement only occurs at the beginning (requirements engineering) and at the end
(operations and maintenance). It does not address the fact the requirements may change during the
software development project.
End-users sometimes have difficulty stating all of their requirements. Thus, it delays the
development of the software.

Prototyping Model
To aid in the understanding of end-user requirements, prototypes are built. Prototypes are partially developed
software that enable end-users and developers examine aspects of the proposed system and decide if it is
included in the final software product. This approach is best suited for the following situations:
A customer defines a set of general objectives for the software but does not identify detailed input,
processing, or output requirements.
The developer may be unsure of the efficiency of an algorithm, the adaptability of a technology, or
the form that human-computer interaction should take.
Figure 1.4 shows this process model.

Listen
to
Customers

Build or Revise
Prototype by
Developers

Test-drive the
Prototype by
Customer

Figure 1.4 Prototyping Model

The advantage of this process model is:

The end-users have an active part in defining the human-computer interaction requirements of the
system. They get the actual "feel" of the software.
The disadvantages of this process model are:
Customers may mistakenly accept the prototype as a working version of the software. Software
quality is compromised because other software requirements are not considered such as
maintainability.
Developers tent to make implementation compromises in order to have a working prototype without
thinking of future expansion and maintenance.

Rapid Application Development (RAD) Model

This process is a linear sequential software development process that emphasizes an extremely short
development cycle. It is achieved through a modular-based construction approach. It is best used for software
projects where requirements are well-understood, project scope is properly constrained, and big budget with
resources are available. Everybody is expected to be committed to a rapid approach to development.
In this process model, the software project is defined based on functional decomposition of the software.
Functional partitions are assigned to different teams, and are developed in parallel. Figure 1.5 shows this
process model.
FuntionalPartition
3- Team
Requirements
Engineering

FuntionalPartition

2- Team
Desig
n
Engineering

Requirements
Engineering

FuntionalPartition
1- Team
Requirements
Engineering

Design
Engineering

Design
Engineering

Coding

Coding

Coding

Testing

Testing

Testing

Turn-over

Turn-over

Turn-over

60 90 Days
Figure 1.5 Rapid Application Development

The advantage of this model is:

A fully functional system is created in a short span of time.
The disadvantages of this model are:
For large but scalable projects, this process requires a sufficient number of developers to have the
right number of development teams.
Developers and customers must be committed to the rapid-fire of activities necessary to develop the
software in a short amount of time.
It is not a good process model for systems that cannot be modularized.
It is not a good process model for systems that require high performance.
It is not a good process model for systems that make use of new technology or high degree of
interoperability with existing computer programs such as legacy systems.

Evolutionary Process Models

This process model recognizes that software evolves over a period of time. It enables the development of an
increasingly more complicated version of the software. The approach is iterative in nature. Specific evolutionary
process models are Incremental Model, Spiral Model, and Component-based Assembly Model.
Incremental Model
This process model combines the elements of a linear sequential model with the iterative philosophy of
prototyping. Linear sequences are defined where each sequence produces an increment of the software. Unlike
prototyping, the increment is an operational product. Figure 1.6 shows this process model.

First Increment

Second Increment

Third Increment

Requirements
Engineering

Requirements
Engineering

Requirements
Engineering

Design
Engineering

Design
Engineering

Coding

Design
Engineering

Coding

Testing

Coding

Testing

Delivery
of the 1st
Increment

Turn-over

Second SW
Increment
First
SW Increment

Testing

First
SW Increment

Figure 1.6 Incremental Process Model

Turn-over

Second SW
Increment

Third
SW
Increment

First
SW Increment

Spiral Model
It was originally proposed by Boehm. It is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of linear sequential model. It provides potential
rapid development of incremental versions of the software. An important feature of this model is that it has risk
analysis as one of its framework of activities. Therefore, it requires risk assessment expertise. Figure 1.7 shows
an example of a spiral model.
Planning
Communication

Risk Analysis

Evaluation

Analysis & Design

Coding & Release

A.
B.
C.
D.

Initial Software Project

Maintenance of New Software
Enhancement of Software
Development of another interrelated system
Figure 1.7 Spiral Model

Component-based Assembly Model

It is similar to Spiral Process Model. However, it makes use of object technologies where the emphasis of the
development is on the creation of classes which encapsulates both data and the methods used to manipulate the
data. Reusability is one of the quality characteristics that are always checked during the development of the
software. Figure 1.8 shows the Component-based Assembly Model.
Determine
Candidate
Classes

Planning
Communication

D C

Risk
Analysis
B

OO Analysis &
Design
Coding &
Release

A.
B.
C.
D.

Look for the

Classes in
the Library

Evaluation

Initial Software Project

Maintenance of New Software
Enhancement of Software
Development of another interrelated system

Build
New Class

Get the
Classes

Put New
Classes in
Library

Build the nth

Iteration of
Software
Figure 1.8 Component-based Assembly Model

Concurrent Development Model

The Concurrent Development Model is also known as concurrent engineering . It makes use of state charts to
represents the concurrent relationship among tasks associated within a framework of activities. It is represented
schematically by a series of major technical tasks, and associated states. The user's need, management
decisions and review results drive the over-all progression of the development. Figure 1.9 shows the concurrent
development model.

Analysis
Activity

Develop
Model

Start

Enter
as New
Baseline

Review
Model

Revise
Model

End

Wait for
Changes

Figure 1.9 Concurrent Development Model

Formal Methods
The Formal Methods is a software engineering approach which encompasses a set of activities that lead to
mathematical specification of the software. It provides a mechanism for removing many of the problems that are
difficult to overcome using other software engineering paradigm. It serves as a means to verify, discover and
correct errors that might otherwise be undetected.
Factors that Affect the Choice of Process Model
Type of the Project
Methods and Tools to be Used
Requirements of the Stakeholders
Common Sense and Judgment

Understanding Systems
The software project that needs to be developed revolves around systems. Systems consists of a group of
entities or components, interacting together to form specific interrelationships, organized by means of structure,
and working together to achieve a common goal. Understanding systems provides a context for any project
through the definition of the boundaries of the projects. It asks the question, "What is included in the project?
What is not?" In defining the system boundaries, a software engineer discovers the following:
entities or group of entities that are related and organized in some way within the system, either they
provide input, do activities or receive output;
activities or actions that must be performed by the entities or group of entities in order to achieve the
purpose of the system;
a list of inputs; and
a list of outputs.
As an example, Figure 1.10 shows the system boundaries of the case study. It shows elements of this system
through the use of the context diagram.
ENTITIES

INPUTS

OUTPUTS

ENTITIES

Applicant

Coach
application form

mock
try-out
schedule

ACTIVITIES:
submit application
schedule mock try-outs
assign applicants to a squad

membership
reports

squad
listings

Club Staff

Club Staff

Figure 1.10 Club Membership Application System Boundaries

Entities that are involved in this system are the applicant, club staff and coach. They are represented as
rectangular boxes. They are related with one another by performing certain activities within this system. The
major activities that are performed are the submission of the application forms, scheduling of mock try-outs and
the assignment of the applicant to a squad. They are represented by a circle in the middle that defines the
functionality of maintaining club membership information. To perform these actions, a list of inputs are necessary,
specifically, application forms and the schedule of the mock try-outs. They are represented by an arrow with the
name of the data being passed. The arrow head indicates the flow of the data. The results that are expected from
this system are the membership reports and importantly, the squad listings. Again, they are represented by an
arrow with the name of the data being passed. The arrow head indicates the flow of the data. The goal of this
system is to handle club membership application.

General Principles of Systems

Some general principles of systems are discussed below. This would help the software engineer study the
system where the software project revolves.
The more specialized a system, the less it is able to adapt to different circumstances. Changes
would have a great impact on the development of such systems. One should be carefully that there
is no dramatic changes in the environment or requirements when the software is being developed.
Stakeholders and developers should be aware of the risks and costs of the changes during the
development of the software.
The larger the system is, the more resources must be devoted to its everyday maintenance. As an
example, the cost of maintaining a mainframe is very expensive compared to maintaining several
personal computers.
Systems are always part of larger systems, and they can always be partitioned into smaller systems.
This is the most important principle that a software engineer must understand. Because systems are
composed of smaller subsystem and vice versa, software systems can be developed in a modular
way. It is important to determine the boundaries of the systems and their interactions so that the
impact of their development is minimal and can be managed and controlled.
Components of Automated Systems
There are two types of systems, namely, man-made systems and automated systems. Man-made systems are
also considered manual systems. They are not perfect. They will always have areas for correctness and
improvements. These areas for correctness and improvements can be addressed by automated systems.
Automated systems are examples of systems. It consists of components that supports the operation of a domainspecific system. In general, it consists of the following:
1. Computer Hardware. This component is the physical device.
2. Computer Software. This component is the program that executes within the machine.
3. People. This component is responsible for the use of the computer hardware and software. They
provide the data as input, and they interpret the output (information) for day-to-day decisions.
4. Procedures. This component is the policies and procedures that govern the operation of the
automated system.
5. Data and Information. This component provides the input (data) and output (information).
6. Connectivity. This component allows the connection of one computer system with another computer
system. It is also known as the network component.