Lecture 2

Software processes

A software process is a set of related activities that leads to the production of a software
product.
These activities may involve the development of software from scratch in a standard
programming language like however, business applications are not necessarily developed
in this way.
There are many different software processes but all must include four activities that are
fundamental to software engineering:
1. Software specification The functionality of the software and constraints on its
operation must be defined.
2. Software design and implementation The software to meet the specification must
be produced.
3. Software validation The software must be validated to ensure that it does what the
customer wants.
4. Software evolution The software must evolve to meet changing customer needs.

Software processes are complex and, like all intellectual and creative processes, rely on
people making decisions and judgments.
Processes are categorized as either plan-driven or agile processes.
Plan-driven processes are processes where all of the process activities are planned in
advance and progress is measured against this plan.
Agile processes, planning is incremental and it is easier to change the process to
reflect changing customer requirements.
Hence, there is a need to find a balance between plan-driven and agile processes.

Software process models

Software process model is a simplified representation of a software process. Each process

model represents a process from a particular perspective, and thus provides only partial
information about that process.
The generic models presented here are not definitive descriptions of software processes.
Rather, they are abstractions of the process that can be used to explain different
approaches to software development. They can be adapted to create more specific
software engineering processes.

i) The waterfall model

The waterfall model this takes the fundamental process activities of specification,
development, validation, and evolution and represents them as separate process phases
such as requirements specification, software design, implementation, testing, and so on.
Because of the cascade from one phase to another, this model is known as the ‘waterfall
model’ or software life cycle.
It is an example of a plan-driven process—in principle, you must plan and schedule all of
the process activities before starting work on them.

COMP 212 Software Engineering 1 Page 1

Fig: Waterfall model

The principal stages of the waterfall model directly reflect the fundamental development
activities:

1. Requirements analysis and definition The system’s services, constraints, and goals are
established by consultation with system users. They are then defined in detail and serve as
a system specification.
2. System and software design The systems design process allocates the requirements to
either hardware or software systems by establishing an overall system architecture.
Software design involves identifying and describing the fundamental software system
abstractions and their relationships.
3. Implementation and unit testing During this stage, the software design is realized as a
set of programs or program units. Unit testing involves verifying that each unit meets its
specification.
4. Integration and system testing The individual program units or programs are integrated
and tested as a complete system to ensure that the software requirements have been met.
After testing, the software system is delivered to the customer.
5. Operation and maintenance Normally (although not necessarily), this is the longest life
cycle phase. The system is installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of the life cycle, improving the
implementation of system units and
enhancing the system’s services as new requirements are discovered.

In principle, the result of each phase is one or more documents that are approved (‘signed
off’). The following phase should not start until the previous phase has finished.

The waterfall model is consistent with other engineering process models and
documentation is produced at each phase. This makes the process visible so managers can
monitor progress against the development plan.
Its major problem is the inflexible partitioning of the project into distinct stages.
Commitments must be made at an early stage in the process, which makes it difficult to
respond to changing customer requirements.
The waterfall model should only be used when the requirements are well understood and
unlikely to change radically during system development However, the waterfall model
reflects the type of process used in other engineering projects. Variant of this is formal
development model

ii) V-Model
COMP 212 Software Engineering 1 Page 2
The V-model is a variation of the waterfall model that makes explicit the dependency
between development activities and verification activities.
The difference between the waterfall model and the V-model is that the latter depicts the
level of abstraction. All activities from requirements to implementation focus on building an
increasingly detailed representation of the system, whereas all activities from
implementation to operation focus on validating the system.

Fig: V-Model

Higher levels of abstractions of the V-model deal with the requirements in terms of
elicitation and operation. The middle level of the V-model focuses on mapping the problem
into a software architecture.
The weakness of these models is that they assume that after an activity is finished and
reviewed, the associated work product can be baseline

iii) Prototyping Model

Prototyping Model is used to overcome issues related to understanding and capturing of

user requirements.
A mock-up application is created ―rapidly‖ to solicit feedback from the user. Once the user
requirements are captured in the prototype to the satisfaction of the user, a proper
requirement specification document is developed and the product is developed from
scratch.
The sole purpose of prototype is to capture the client needs hence the internal structure is
not really important.
Prototype in most cases is combined with waterfall model hence prototype is used for
requirement gathering which would then be followed by the activities performed in the
waterfall model.

COMP 212 Software Engineering 1 Page 3

 iv) Incremental development

Incremental development is based on the idea of developing an initial implementation,

exposing this to user comment and evolving it through several versions until an adequate
system has been developed.
Specification, development, and validation activities are interleaved rather than separate,
with rapid feedback across activities.
Incremental development reflects the way that we solve problems in real life.
Incremental software development, which is a fundamental part of agile approaches, is
better than a waterfall approach for most business, e-commerce, and personal systems.
By developing the software incrementally, it is cheaper and easier to make changes in the
software as it is being developed.

Fig: Incremental Model

Each increment or version of the system incorporates some of the functionality that is
needed by the customer.
Incremental development has three important benefits, compared to the waterfall model:
i. The cost of accommodating changing customer requirements is reduced.
ii. 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.
iii. More rapid delivery and deployment of useful software to the customer is
possible, even if all of the functionality has not been included
Incremental development in some form is now the most common approach for the
development of application systems. This approach can be either plan-driven, agile, or,
more usually, a mixture of these approaches

COMP 212 Software Engineering 1 Page 4

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

Rapid Application Development (RAD)

Rapid application development is another form of incremental model. It is a high speed
adaptation of the linear sequential model in which fully functional system in a very short
time (2-3 months). This model is only applicable in the projects where requirements are
well understood and project scope is constrained. Because of this reason it is used primarily
for information systems.

v) Spiral Model
This model was developed by Barry Boehm[Boehm, 1987] is an activity-centered life cycle
model that was devised to address the source of weaknesses in the waterfall model, in
particular, to accommodate infrequent change during the software development.

It is based on the same activities as the waterfall model; however, it adds several activities
such as risk management, reuse, and prototyping to each activity.
The spiral model focuses on addressing risks incrementally, in order of priority. Each round
is composed of four phases

Phases:

- During the first phase (upper left quadrant) developers explore alternatives, define
constraints, and identify objectives.
- During the second phase (upper right quadrant), developers manage risks associated with
the solutions defined during the first phase.
- During the third phase (lower right quadrant), developers realize and validate a prototype
or the part of the system associated with the risks addressed in this round.
- The fourth phase (lower left quadrant) focuses on planning the next round based on the
results of the current round usually conducted as a review involving the project
participants, including developers, clients, and users.

COMP 212 Software Engineering 1 Page 5

Fig: Boehm’s spiral model

The distance from the origin represents the cost accumulated by the project. The angle
from the horizontal represents the type of activity.

The main strength of the Spiral Model comes from the fact that it is very sensitive to the
risk therefore used for large-scale software development.

vi) Unified Software Development Process

The Unified Software Development Process (also called the Unified Process or
Rational Unified model) is a life cycle model proposed by Booch, Jacobson, and
Rumbaugh [Jacobson et al., 1999].
The unified process distinguishes important time ranges called cycles in the lifetime of a
software system. Each cycle can be in one of four states called phases: Inception,
Elaboration, Construction, and Transition
Phases:
- During the inception phase, the scope of the system is established, in particular what
should be included and not included. A first estimation and schedule for the entire

COMP 212 Software Engineering 1 Page 6

 project, including detailed estimates for the elaboration phase, are also established
during this phase
- During the elaboration phase, the user’s view of the requirements is captured in a
repository. The software architecture is designed, and an initial set of build vs. buy
decisions is made, so that cost, schedule, and resource estimates can be derived.
- During the construction phase, components are bought or built, and the release is
compared with the acceptance criteria.
- The transition phase is entered when the baseline system is mature enough for
deployment to the user community

Each phase can consist of a number of iterations. For the duration of each iteration, several
activities are performed in parallel.
The RUP has been designed in conjunction with the UML, so the workflow description is
oriented around associated UML models such as sequence models, object models.

The most important innovations in the RUP are the separation of phases and workflows,
and the recognition that deploying software in a user’s environment is part of the process.
Phases are dynamic and have goals.
Workflows are static and are technical activities that are not associated with a single phase
but may be used throughout the development to achieve the goals of each phase.

vii) Reuse-oriented software engineering

In the majority of software projects, there is some software reuse. This often happens
informally when people working on the project know of designs or code that is similar to
what is required. They look for these, modify them as needed, and incorporate them into
their system.
Reuse-oriented approaches rely on a large base of reusable software components and an
integrating framework for the composition of these components.

COMP 212 Software Engineering 1 Page 7

Fig: Reuse Oriented Software

A general process model for reuse-based development is:

1. Component analysis Given the requirements specification, a search is made for
components to implement that specification. Usually, there is no exact match and the
components that may be used only provide some of the functionality required.
2. Requirements modification During this stage, the requirements are analyzed using
information about the components that have been discovered. They are then modified to
reflect the available components. Where modifications are impossible, the component
analysis activity may be re-entered to search for alternative solutions.
3. System design with reuse During this phase, the framework of the system is designed or
an existing framework is reused. The designers take into account the components that are
reused and organize the framework to cater for this. Some new software may have to be
designed if reusable components are not available.
4. Development and integration Software that cannot be externally procured is developed,
and the components and COTS systems are integrated to create the new system. System
integration, in this model, may be part of the development process rather than a separate
activity.

Types of software component that may be used in a reuse-oriented process may be:

1. Web services that are developed according to service standards and which are available
for remote invocation.
2. Collections of objects that are developed as a package to be integrated with a
component framework such as .NET or J2EE.
3. Stand-alone software systems that are configured for use in a particular environment

Agile software development

Businesses now operate in a global, rapidly changing environment. They have to respond to
new opportunities and markets, changing economic conditions, and the emergence of
competing products and services
Agile methods are incremental development methods in which the increments are small
and, typically, new releases of the system are created and made available to customers
every two or three weeks.
They involve customers in the development process to get rapid feedback on changing
requirements. They minimize documentation by using informal communications rather than
formal meetings with written documents.
Agile methods universally rely on an incremental approach to software specification,
development, and delivery.

COMP 212 Software Engineering 1 Page 8

They are best suited to application development where the system requirements usually
change rapidly during the development process.

The philosophy behind agile methods is reflected in the agile manifesto that was
agreed on by many of the leading developers of these methods. This manifesto states:
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left
more.

i) Extreme programming

Extreme programming (XP) is perhaps the best known and most widely used of the agile
methods
The approach was developed by pushing recognized good practice, such as iterative
development, to
‘extreme’ levels. For example, in XP, several new versions of a system may be developed
by different programmers, integrated and tested in a day

Fig: Extreme programming (XP)

Extreme programming involves a number of practices, which reflect the principles of agile
methods:
1. Incremental development is supported through small, frequent releases of the system.
Requirements are based on simple customer stories or scenarios that are used as a basis
for deciding what functionality should be included in a system increment.
2. Customer involvement is supported through the continuous engagement of the customer
in the development team. The customer representative takes part in the development and
is responsible for defining acceptance tests for the system.

COMP 212 Software Engineering 1 Page 9

3. People, not process, are supported through pair programming, collective ownership of
the system code, and a sustainable development process that does not involve excessively
long working hours.
4. Change is embraced through regular system releases to customers, test-first
development, refactoring to avoid code degeneration, and continuous integration of new
functionality.
5. Maintaining simplicity is supported by constant refactoring that improves code quality
and by using simple designs that do not unnecessarily anticipate future changes to the
system.

One very important feature of eXtreme programming is the concept of pair programming.
In this, a team of two developers develop the software, working in team as a pair to the
extent that they even share a single computer.

The Scrum approach: It is a general agile method but its focus is on managing iterative
development rather than specific technical approaches to agile software engineering.

Fig: The Scrum approach (Schwaber, 2004; Schwaber and Beedle, 2001)

There are three phases in Scrum.

Outline planning phase where you establish the general objectives for the project and
design the software architecture.
Sprint cycles, where each cycle develops an increment of the system
Project closure phase wraps up the project, completes required documentation such as
system help frames and user manuals, and assesses the lessons learned from the project.

At the end of a sprint, the completed functionality is delivered to stakeholders. Key

characteristics of this process are
1. Sprints are fixed length, normally 2–4 weeks. They correspond to the development of a
release of the system in XP.
2. The starting point for planning is the product backlog, which is the list of work to be done
on the project. During the assessment phase of the sprint, this is reviewed, and priorities

COMP 212 Software Engineering 1 Page 10

and risks are assigned. The customer is closely involved in this process and can introduce
new requirements or tasks at the beginning of each sprint.
3. The selection phase involves all of the project team who work with the customer to
select the features and functionality to be developed during the sprint.
4. Once these are agreed, the team organizes themselves to develop the software.
5. At the end of the sprint, the work done is reviewed and presented to stakeholders.
The next sprint cycle then begins.

Others agile methods

Crystal (Cockburn, 2001; Cockburn, 2004)
Adaptive Software Development (Highsmith, 2000),
Feature Driven Development (Palmer and Felsing, 2002).

Comparison of Lifecycle Models

As discussed above, each lifecycle model has some strengths and weaknesses. These are
summarized in the following table:

Software development tools

COMP 212 Software Engineering 1 Page 11
Software development tools (sometimes called Computer-Aided Software Engineering or
CASE tools) are programs that are used to support software engineering process activities.
These tools therefore include design editors, data dictionaries, compilers, debuggers,
system building tools, etc.
Software tools provide process support by automating some process activities and by
providing information about the software that is being developed. Examples of activities
that can be automated include:
- The development of graphical system models as part of the requirements
specification or the software design
- The generation of code from these graphical models
- The generation of user interfaces from a graphical interface description that is
created interactively by the user
- Program debugging through the provision of information about an executing program
- The automated translation of programs written using an old version of a
programming language to a more recent version
- Tools may be combined within a framework called an Interactive Development
Environment or IDE.
This provides a common set of facilities that tools can use so that it is easier for tools to
communicate and operate in an integrated way. The ECLIPSE IDE is widely used and has
been designed to incorporate many different types of software tools.

COMP 212 Software Engineering 1 Page 12