SOFTWARE DEVELOPMENT PROCESS

1. Introduction

Computers are becoming a key element in our daily lives. Slowly and surely they are
taking over many of the functions that affect our lives critically. They are now
controlling all forms of monetary transactions, manufacturing, transportation,
communication, defense systems, process control systems, and so on. In the near
future, they will be found in our homes, controlling all forms of appliances. Left to
themselves, they are harmless pieces of hardware. Load the right kind of software;
they can take you to the moon, both literally and figuratively. It is the software that
gives life to them. When they are going to play such a crucial role, one small flaw
either in the hardware or the software can lead to catastrophic consequences. The
sad part is, while there are well defined processes based on theoretical foundations
to ensure the reliability of the hardware, same thing can not be said about software.
There is no theory for software development as yet. But at the same time, it is
mandatory that software always behaves in a predictable manner, even in
unforeseen circumstances. Hence there is a need to control its development through
a well defined and systematic process. The old fashioned 'code & test' approach will
not do any more. It may be good enough for 'toy' problems, but in real life, software
is expected to solve enormously complex problems. Some of the aspects of real life
software projects are:

• Team effort: Any large development effort requires the services of a team of
specialists. For example the team could consist of domain experts, software
design experts, coding specialists, testing experts, hardware specialists, etc.
Each group could concentrate on a specific aspect of the problem and design
suitable solution. However no group can work in isolation. There will be
constant interaction among team members.
• Methodology: Broadly there are two types of methodologies, namely,
'procedure oriented methodolgies' and 'object oriented methodologies'.
Though theoretically either of them could be used in any given problem
situation, one of them should be chosen in advance.
• Documentation: Clear and unambiguous documentation of the artifacts of
the development process are critical for the success of the software project.
Oral communication and 'back of the envelop designs' are not sufficient. For
example, documentation is necessary if client signoff is required at various
stages of the process. Once developed, the software lives for a long time.
During its life, it has to undergo lot of changes. Without clear design
specifications and well documented code, it will be impossible to make
changes.
• Planning: Since the development takes place against a client's requirements
it is imperative that the whole effort is well planned to meet the schedule and
cost constraints.
• Quality assurance: Clients expect value for money. In addition to meeting
the client's requirements, the software also should meet additional quality
constraints. They could be in terms of performance, security, etc.
• Lay user: Most of the time, these software packages will be used by non-
computer savvy users. Hence the software has to be highly robust.
• Software tools: Documentation is important for the success of a software
project, but it is a cumbersome task and many software practitioners balk at
the prospect of documentation. There are tools known as Computer Aided
Software Engineering (CASE) tools which simplify the process of
documentation.
• Conformance to standards: We need to follow certain standards to ensure
clear and unambiguous documentation. For example, IEEE standards for
requirements specifications, design, etc. Sometimes, clients may specify the
standards to be used.
• Reuse: The development effort can be optimised, by reusing well-tested
components. For example, mathematical libraries, graphical user interface
tool kits, EJBs, etc.
• Non-developer maintenance: Software lives for a long time. The
development team, may not be available to maintain the package. Some
other team will have to ensure that the software continues to provide
services.
• Change management: Whenever a change has to be made, it is necessary
to analyse its impact on various parts of the software. Imagine modifying the
value of global variable. Every function that accesses the variable will be
 effected. Unless care is taken to minimise the impact, the software may not
behave as expected.
• Version control: Once changes are made to the software, it is important
that the user gets the right copy of the software. In case of failures, it should
be possible to roll back to the previous versions.
• Subject to risks: Any large effort is subject to risks. The risks could be in
terms of non-availability of skills, technology, inadequate resources, etc. It is
necessary to constantly evaluate the risks, and put in place risk mitigation
measures.

2. Software Quality

The goal of any software development process is to produce high quality software.
What is software quality? It has been variously defined as:

• Fitness for purpose

• Zero defects
• Conformability & dependability
• The ability of the software to meet customer's stated and implied needs

Some of the important attributes that can be used to measure software quality are:

• Correctness: Software should meet the customer's needs

• Robustness: Software must always behave in an expected manner, even when
unexpected inputs are given
• Usability: Ease of use. A software with a graphical user interface is considered
more user-friendly than one without it
• Portability: The ease with which software can be moved from one platform to
another
• Efficiency: Optimal resource (memory & execution time) utilization
• Maintainability: Ease with which software can be modified
• Reliability: The probability of the software giving consistent results over a
period of time
• Flexibility: Ease with which software can be adapted for use in different
contexts
 • Security: Prevention of unauthorised access
• Interoperabilty: The abilty of the software to integrate with existing systems
• Performance: The ability of the software to deliver the outputs with in the
given constraints like time, accuracy, memory usage

Correctness is the most important attribute. Every software must be correct. The
other attributes may be present in varying degrees. For example, it is an expensive
proposition to make a software 100% reliable and it is not required in all contexts. If
the software is going to be used in life critical situations, then 100% reliability is
mandatory. But, say, in a weather monitoring system, a little less reliability may be
acceptable. However, the final decision lies with the client. One should keep in mind
that some of the above attributes conflict with each other. For example, portability
and efficiency could conflict with each other. To improve efficiency, one may resort to
using system dependent features. but that will effect the portability. In the days,
when DOS ruled the world, it was possible to access the internal architecture directly
to improve performance. To port such a program to any other platform would require
enormous changes. So in practice there will always be a tradeoff.

3.1 What is a Process?

A Process is a series of definable, repeatable, and measurable tasks leading to a

useful result. The benefits of a well defined process are numerous.

• It provides visibility into a project. Visibility in turn aids timely mid-course

corrections
• It helps developers to weed out faults at the point of introduction. This avoids
cascading of faults into later phases
• It helps to organize workflow and outputs to maximize resource utilization
• It defines everybody's roles and responsibilities clearly.
• Individual productivity increases due to specialization and at the same time
the team's productivity increases due to coordination of activities

A good software development process should:

• view software development as a value added business activity and not merely
as a technical activity
 • ensure that every product is checked to see if value addition has indeed taken
place
• safeguard against loss of value once the product is complete
• provide management information for in-situ control of the process

To define such a process the following steps need to be followed:

• Identify the phases of development and the tasks to be carried out in each
phase
• Model the intra and inter phase transitions
• Use techniques to carry out the tasks
• Verify and Validate each task and the results
• Exercise process and project management skills

The words 'verify' and 'validate' need some clarification. Verify means to check if the
task has been executed correctly, while validate means to check if the correct task
has been executed. In the context of software, the process of checking if an
algorithm has been implemented correctly, is verification, while the process of
checking if the result of the algorithm execution is the solution to the desired
problem, is validation.

The generic phases that are normally used in a software development process are:

• Analysis: In this phase user needs are gathered and converted into software
requirements. For example, if the user need is to generate the trajectory of a
missile, the software requirement is to solve the governing equations. This
phase should answer the question: what is to be done to meet user needs?
• Design: This phase answers the question: How to meet the user needs? With
respect to the above example, design consists of deciding the algorithm to be
used to solve the governing equations. The choice of the algorithm depends
on design objectives like execution time, accuracy, etc. In this phase we
determine organisation of various modules in the software system
• Construction: Coding is the main activity in this phase
• Testing: There are three categories of testing: unit testing, integration
testing, and system testing. There are two types of testing: Black box testing
and White box testing. Black box testing focuses on generating test cases
 based on requirements. White box testing focuses on generating test cases
based on the internal logic of various modules
• Implementation

4. Software Life Cycle Models

In practice, two types of software life cycle models are used - sequential model and
iterative model.

4.1 Waterfall Model:

Sequential model, also known as water fall model, is pictorially shown thus:

It represents the development process as a sequence of steps (phases). It requires

that a phase is complete before the next phase is started. Because of the explicit
recognition of phases and sequencing, it helps in contract finalisation with reference
to delivery and payment schedules.
In practice it is difficult to use this model as it is, because of the uncertainity in the
software requirements. It is often difficult to envisage all the requirements a priori. If
a mistake in understanding the requirements gets detected during the coding phase,
then the whole process has to be started all over again. A working version of the
software will not be available until late in the project life cycle. So, iteration both
within a phase and across phases is a necessity.
4.2 Prototyping

Prototyping is discussed in the literature as a separate approach to software

development. Prototyping as the name suggests, requires that a working version of
the software is built early in the project life. There are two types of prototyping
models, namely:

• Throw away prototype and

• Evolutionary prototype

The objective of the throw away prototyping model is to understand the

requirements and solution methodologies better. The essence is speed. Hence, an
ad-hoc and quick development approach with no thought to quality, is resorted to. It
is akin to 'code and test'. However, once the objective is met, the code is discarded
and fresh development is started, ensuring that quality standards are met. Since the
requirements are now well understood, one could use the sequential approach. This
model suffers from wastage of effort, in the sense that developed code is discarded,
because it does not meet the quality standards.
Evolutionary prototyping takes a different approach. The requirements are prioritised
and the code is developed for the most important requirements first, always with an
eye on quality. Software is continuously refined and expanded with feedback from
the client. The chief advantage of prototyping is that the client gets a feel of the
product early in the project life cycle.

As can be seen, evolutionary prototyping is an iterative model. Such a model can be

characterised by doing a little analysis, design, code, test and repeat the process till
the product is complete.

4.3 Spiral Model

Barry Boehm has suggested another iteartive model called the spiral model. It is
more in the nature of a framework, which needs to be adapted to specific projects.
Pictorially it can be shown thus:
 It allows best
mix of other
approaches
and focusses
on eliminating
errors and
unattractive
alternatives
early. An
important
feature of this
model is the
stress on risk analysis. Once the objectives, alternatives, and constraints for a phase
are identified, the risks involved in carrying out the phase are evaluated, which is
expected to result in a 'go, no go' decision. For evaluation purposes, one could use
prototyping, simulations, etc. This model is best suited for projects, which involve
new technology development. Risk analysis expertise is most critical for such
projects.

4.4 ETVX model

IBM introduced the ETVX model during the 80's to document their processes. 'E'
stands for the entry criteria which must be satisfied before a set of tasks can be
performed, 'T' is the set of tasks to be performed, 'V' stands for the verification &
validation process to ensure that the right tasks are performed, and 'X' stands for the
exit criteria or the outputs of the tasks. If an activity fails in the validation check,
either corrective action is taken or a rework is ordered. It can be used in any
development process. Each phase in the process can be considered as an activity and
structured using the ETVX model. If required, the tasks can be further subdivided
and each subtask can be further structured using the ETVX model.
4.5 Rational Unified Process Model

Among the modern process models, Rational Unified Process (RUP) developed by
Rational Corporation is noteworthy. It is an iterative model and captures many of the
best practices of modern software development. RUP is explained more fully in the
module OOAD with UML. More information on RUP can be obtained from
http://en.wikipedia.org/wiki/Rational_Unified_Processand from http://www-
128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIsthe
RationalUnifiedProcessJan01.pdf

4.6 Agile Methodologies

All the methodologies described before are based on the premise that any software
development process should be predictable and repeatable. One of the criticisms
against these methodologies is that there is more emphasis on following procedures
and preparing documentation. They are considered to be heavyweight or rigorous.
They are also criticised for their excessive emphasis on structure. There is a
movement called Agile Software Movement, questioning this premise. The
proponents argue that software development being essentially a human activity,
there will always have variations in processes and inputs and the model should be
flexible enough to handle the variations. For example: the entire set of software
requirements cannot be known at the begining of the project nor do they remain
static. If the model cannot handle this dynamism, then there can be lot of wastage of
effort or the final product may not meet the customer's needs. Hence the agile
methodolgies advocate the principle "build short, build often". That is the given
project is broken up in to subprojects and each subproject is developed and
integrated in to the already delivered system. This way the customer gets continuous
delivery of useful and usable systems. The subprojects are chosen so that they have
short delivery cycles, usually of the order of 3 to 4 weeks. The development team
also gets continuous feedback. A number of agile methodologies have been
proposed. The more popular among them are SCRUM, DYNAMIC SYSTEMS
DEVELOPMENT METHOD (DSDM), CRYSTAL METHODS, FEATURE-DRIVEN
DEVELOPMENT, LEAN DEVELOPMENT (LD), EXTREME PROGRAMMING (XP). A short
description of each of these methods follows:

• SCRUM: It is a project management framework. It divides the development

in to short cycles called sprint cycles in which a specified set of features are
delivered. It advocates daily team meetings for coordination and integration.
More information on SCRUM can be obtained http://www.controlchaos.com/
• DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM): It is characterised
by nine principles:
1. Active user involvement
2. Team empowerment
3. Frequent delivery of products
4. Fitness for business purpose
5. Iterative and incremental development
6. All changes during development are reversible
7. Baselining of requirements at a high level
8. Integrated testing
9. Collaboration and cooperation between stakeholders

More information on DSDM can be obtained http://www.dsdm.org/

• CRYSTAL METHODOLOGIES: They are a set of configurable methodologies.

They focus on the people aspects of development. The configuration is carried
out based on project size, criticality and objectives. Some of the names used
for the methodologies are Clear, Yellow, Orange, Orange web, , Red , etc.
More information can be obtained from http://crystalmethodologies.org/

• FEATURE DRIVEN DEVELOPMENT (FDD): It is a short iteration framework

for software development. It focuses on building an object model, build
 feature list, plan by feature, design by feature, and build by feature. More
informtion can be obtained from http://www.featuredrivendevelopment.com

• LEAN DEVELOPMENT (LD): This methodology is derived from the principles

of lean production, the restructuring of the Japanese automobile
manufacturing industry that occurred in the 1980s. It is based on the
following principles of lean thinking: Eliminate waste, Amplify learning, Decide
as late as possible, Deliver as fast as possible, Empower the team, Build the
integrity in, See the whole. More informtion can be obtained from
http://www.poppendieck.com/

• EXTREME PROGRAMMING (XP): This methodology is probably the most

popular among the agile methodologies. It is based on three important
principles, viz., test first, continuous refactoring, and pair programming. More
information can be obtained from http://www.extremeprogramming.org/

One of the important concepts popularised by XP is pair programming. Code is

always developed in pairs. While one person is keying in the code, the other person
would be reviewing. http://pairprogramming.com/ is dedicated to pair programming.
The paper http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF by Laurie
Williams et al., demonstrates the efficacy of pair programming.

The site agilealliance.com is dedicated to promoting agile software development

methodologies.
5. How to choose a process

Among the plethora of available processes, how can we choose one? There is no
single answer to this question. Probably the best way to attack this problem is to
look at the software requirements.

• If they are stable and well understood, then waterfall model may be
sufficient.
• If they are stable, but not clear, then throw away prototyping can be used.
• Where the requirements are changing, evolutionary prototyping is better.
• If the requirements are coupled with the underlying business processes,
which are going through a process of change, then a model based on Boehm's
spiral model, like the Rational Unified Process should be used.
• In these days of dynamic business environment, where 'time to market' is
critical, and project size is relatively small, an agile process should be chosen.

These are but guidelines only. Many organisations choose a model and adapt it to
their business requirements. For example, some organisations use waterfall model,
modified to include iterations within phases.

6. Conclusions

The most important take away from this module is that software development should
follow a discplined process. The choice of the process should depend upon the
stabilty of the requirements, completeness of requirements, underlying business
processes, organisational structure, and the prevailing business environment.

7. References

For Further Reading

In addition to the links provided, the following references may be consulted:

1. " An Integrated Approach to Software Engineering", by Pankaj Jalote,

Springer-Verlag
2. " Software Engineering: A Practitioner's Approach", by Roger S. Pressman,
McGraw-Hill, Inc.
3. " Software Engineering", by Ian Sommerville, Addison-Wesley Publishing
Company
4. " The Rational Unified Process, An Introduction", by Philippe Kruchten,
Addison-Wesley Publishing Company
5. " Agile Software Develoment Ecosystems", by Jim Highsmith, Addison-Wesley
Publishing Company