SOFTWARE DEVELOPMENT:

1. Introduction
Computers are becoming a key element in our daily lives. Slowly and surely they
are taking over many of the functions that effect our lives critically. They are now
controlling all forms of monetary transactions, manufacturing, transportation,
communication, defence 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.hen
they are going to play such a crucial role, one small flaw either in the hardware or the
software can lead to catastrophic conse!uences. 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
devlopment as yet. "ut at the same time, it is mandatory that software always behaves in
a predictable manner, even in unforeseen circumstances. #ence 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 e&pected to solve enormously comple& problems. Some of the
aspects of real life software pro'ects are:
Team effort: (ny large development effort re!uires the services of a team of specialists.
)or e&ample the team could consist of domain e&perts, software design e&perts, coding
specialists, testing e&perts, hardware specialists, etc. *ach group could concentrate on a
specific aspect of the problem and design suitable solution. #owever no group can work
in isolation. There will be constant interaction among team members.
Metodo!o"#: "roadly there are two types of methodologies, namely, $procedure oriented
methodolgies$ and $ob'ect 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 pro'ect. +ral
communication and $back of the envelop designs$ are not sufficient. )or e&ample,
documentation is necessary if client signoff is re!uired at various stages of the process.
+nce developed, the software lives for a long time. ,uring its life, it has to undergo lot of
changes. ithout clear design specifications and well documented code, it will be
impossible to make changes.
P!annin": Since the development takes place against a client$s re!uirements it is
imperative that the whole effort is well planned to meet the schedule and cost constraints.
-uality assurance: Clients e&pect value for money. In addition to meeting the client$s
re!uirements, the software also should meet additional !uality constraints. They could be
in terms of performance, security, etc.
La# u$er: .ost of the time, these software packages will be used by non/computer savvy
users. #ence the software has to be highly robust.
Soft%are too!$: ,ocumentation is important for the success of a software pro'ect, but it is
a cumbersome task and many software practitioners balk at the prospect of
documentation. There are tools known as Computer (ided Software *ngineering 0C(S*1
tools which simplify the process of documentation.
&onformance to $tandard$: e need to follow certain standards to ensure clear and
unambiguous documentation. )or e&ample, I*** standards for re!uirements
specifications, design, etc. Sometimes, clients may specify the standards to be used.
2euse: The development effort can be optimised, by reusing well/tested components. )or
e&ample, mathematical libraries, graphical user interface tool kits, *3"s, etc.
4on/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.
&an"e mana"ement: henever 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.
*very function that accesses the variable will be effected. 5nless care is taken to
minimise the impact, the software may not behave as e&pected.
6ersion control: +nce 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.
Su'(ect to ri$)$: (ny large effort is sub'ect to risks. The risks could be in terms of non/
availability of skills, technology, inade!uate resources, etc. It is necessary to constantly
evaluate the risks, and put in place risk mitigation measures.
*. Soft%are +ua!it#
The goal of any software development process is to produce high !uality software. hat
is software !uality7 It has been variously defined as:
)itness for purpose
8ero 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 !uality are:
&orrectne$$: Software should meet the customer$s needs
Ro'u$tne$$: Software must always behave in an e&pected manner, even when
une&pected inputs are given
,$a'i!it#: *ase of use. ( software with a graphical user interface is considered more
user/friendly than one without it
9ortability: The ease with which software can be moved from one platform to another
Efficienc#: +ptimal resource 0memory % e&ecution time1 utili:ation
Maintaina'i!it#: *ase with which software can be modified
Re!ia'i!it#: The probability of the software giving consistent results over a period of time
F!e-i'i!it#: *ase with which software can be adapted for use in different conte&ts
Securit#: 9revention of unauthorised access
Intero.era'i!t#: The abilty of the software to integrate with e&isting 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. *very software must be correct. The other
attributes may be present in varying degrees. )or e&ample, it is an e&pensive proposition
to make a software ;<<= reliable and it is not re!uired in all conte&ts. If the software is
going to be used in life critical situations, then ;<<= reliability is mandatory. "ut, say, in
a weather monitoring system, a little less reliability may be acceptable. #owever, the
final decision lies with the client. +ne should keep in mind that some of the above
attributes conflict with each other. )or e&ample, 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 ,+S 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 re!uire enormous changes. So in practice there
will always be a tradeoff.
/.* Wat i$ a Proce$$0
( 9rocess 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 pro'ect. 6isibility 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 organi:e workflow and outputs to ma&imi:e resource utili:ation
It defines everybody$s roles and responsibilities clearly.
Individual productivity increases due to speciali:ation and at the same time the
team$s productivity increases due to coordination of activities
( 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
.odel the intra and inter phase transitions
5se techni!ues to carry out the tasks
6erify and 6alidate each task and the results
*&ercise process and pro'ect management skills
The words $verify$ and $validate$ need some clarification. 6erify means to check if the task
has been e&ecuted correctly, while validate means to check if the correct task has been
e&ecuted. In the conte&t 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 e&ecution is the solution to the desired problem, is validation.
The generic phases that are normally used in a software development process are:
(nalysis: In this phase user needs are gathered and converted into software re!uirements.
)or e&ample, if the user need is to generate the tra'ectory of a missile, the software
re!uirement is to solve the governing e!uations. This phase should answer the !uestion:
what is to be done to meet user needs7
De$i"n: This phase answers the !uestion: #ow to meet the user needs7 ith respect to
the above e&ample, design consists of deciding the algorithm to be used to solve the
governing e!uations. The choice of the algorithm depends on design ob'ectives like
e&ecution time, accuracy, etc. In this phase we determine organisation of various modules
in the software system
&on$truction: Coding is the main activity in this phase
Te$tin": There are three categories of testing: unit testing, integration testing, and system
testing. There are two types of testing: "lack bo& testing and hite bo& testing. "lack
bo& testing focuses on generating test cases based on re!uirements. hite bo& testing
focuses on generating test cases based on the internal logic of various modules
Implementation
>. Soft%are Life &#!ce Mode!$
In practice, two types of software life cycle models are used / se!uential model and
iterative model.
1.1 Waterfa!! Mode!:
Se!uential model, also known as water fall model, is pictorially shown thus:
It represents the development process as a se!uence of steps 0phases1. It re!uires that a
phase is complete before the ne&t phase is started. "ecause of the e&plicit recognition of
phases and se!uencing, 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 re!uirements. It is often difficult to envisage all the re!uirements a priori. If a
mistake in understanding the re!uirements gets detected during the coding phase, then the
whole process has to be started all over again. ( working version of the software will not
be available until late in the pro'ect life cycle. So, iteration both within a phase and across
phases is a necessity.
1.* Protot#.in"
9rototyping is discussed in the literature as a separate approach to software development.
9rototyping as the name suggests, re!uires that a working version of the software is built
early in the pro'ect life. There are two types of prototyping models, namely:
Throw away prototype and
*volutionary prototype
The ob'ective of the throw away prototyping model is to understand the re!uirements and
solution methodologies better. The essence is speed. #ence, an ad/hoc and !uick
development approach with no thought to !uality, is resorted to. It is akin to $code and
test$. #owever, once the ob'ective is met, the code is discarded and fresh development is
started, ensuring that !uality standards are met. Since the re!uirements are now well
understood, one could use the se!uential approach. This model suffers from wastage of
effort, in the sense that developed code is discarded, because it does not meet the !uality
standards.
*volutionary prototyping takes a different approach. The re!uirements are prioritised and
the code is developed for the most important re!uirements first, always with an eye on
!uality. Software is continuously refined and e&panded with feedback from the client.
The chief advantage of prototyping is that the client gets a feel of the product early in the
pro'ect life cycle.
(s 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.
1./ S.ira! Mode!
"arry "oehm 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 pro'ects. 9ictorially it
can be shown thus:
It allows best mi& of other approaches and focusses on eliminating errors and unattractive
alternatives early. (n important feature of this model is the stress on risk analysis. +nce
the ob'ectives, alternatives, and constraints for a phase are identified, the risks involved in
carrying out the phase are evaluated, which is e&pected to result in a $go, no go$ decision.
)or evaluation purposes, one could use prototyping, simulations, etc. This model is best
suited for pro'ects, which involve new technology development. 2isk analysis e&pertise
is most critical for such pro'ect.
1.1 ETV2 mode!
I". introduced the *T6? model during the @<$s to document their processes. $*$ 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, $6$ stands for the verification % validation process to
ensure that the right tasks are performed, and $?$ stands for the e&it 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. *ach phase in the process
can be considered as an activity and structured using the *T6? model. If re!uired, the
tasks can be further subdivided and each subtask can be further structured using the
*T6? model.
1.3 Rationa! ,nified Proce$$ Mode!
(mong the modern process models, 2ational 5nified 9rocess 02591 developed by
2ational Corporation is noteworthy. It is an iterative model and captures many of the best
practices of modern software development. 259 is e&plained more fully in the module
++(, with 5.L. .ore information on 259 can be obtained here and from here.
1.4 A"i!e Metodo!o"ie$
(ll the methodologies described before are based on the premise that any software
development process should be predictable and repeatable. +ne 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 e&cessive emphasis on structure. There is a movement called
(gile Software .ovement, !uestioning 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 fle&ible enough to handle the variations.
)or e&ample: the entire set of software re!uirements cannot be known at the begining of
the pro'ect 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. #ence the agile methodolgies advocate the principle Abuild short, build oftenA.
That is the given pro'ect is broken up in to subpro'ects and each subpro'ect is developed
and integrated in to the already delivered system. This way the customer gets continuous
delivery of useful and usable systems. The subpro'ects are chosen so that they have short
delivery cycles, usually of the order of B to > weeks. The development team also gets
continuous feedback. ( number of agile methodologies have been proposed. The more
popular among them are SC25., ,C4(.IC SCST*.S ,*6*L+9.*4T .*T#+,
0,S,.1, C2CST(L .*T#+,S, )*(T52*/,2I6*4 ,*6*L+9.*4T, L*(4
,*6*L+9.*4T 0L,1, *?T2*.* 92+D2(..I4D 0?91. ( short description of
each of these methods follows:
SC25.: It is a pro'ect 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. .ore information on SC25. can
be obtained here
D5NAMI& S5STEMS DEVELOPMENT MET6OD 7DSDM8: It is characterised by
nine principles:
(ctive user involvement
Team empowerment
)re!uent delivery of products
)itness for business purpose
Iterative and incremental development
(ll changes during development are reversible
"aselining of re!uirements at a high level
Integrated testing
Collaboration and cooperation between stakeholders
.ore information on ,S,. can be obtained here.
&R5STAL MET6ODOLO9IES: They are a set of configurable methodologies. They
focus on the people aspects of development. The configuration is carried out based on
pro'ect si:e, criticality and ob'ectives. Some of the names used for the methodologies are
Clear, Cellow, +range, +range web, , 2ed , etc. .ore information can be obtained from
here.
FEAT,RE DRIVEN DEVELOPMENT 7FDD8: It is a short iteration framework for
software development. It focuses on building an ob'ect model, build feature list, plan by
feature, design by feature, and build by feature. .ore informtion can be obtained from
here.
LEAN DEVELOPMENT 7LD8: This methodology is derived from the principles of
lean production, the restructuring of the 3apanese automobile manufacturing industry that
occurred in the ;E@<s. It is based on the following principles of lean thinking: *liminate
waste, (mplify learning, ,ecide as late as possible, ,eliver as fast as possible, *mpower
the team, "uild the integrity in, See the whole. .ore informtion can be obtained from
here.
E2TREME PRO9RAMMIN9 72P8: This methodology is probably the most popular
among the agile methodologies. It is based on three important principles, vi:., test first,
continuous refactoring, and pair programming. .ore information can be obtained from
here.
+ne of the important concepts popularised by ?9 is pair programming. Code is always
developed in pairs. hile one person is keying in the code, the other person would be
reviewing. This site is dedicated to pair programming. The paper by Laurie illiams et
al., demonstrates the efficacy of pair programming.
The site agilealliance.com is dedicated to promoting agile software development
methodologies.
3. 6o% to coo$e a .roce$$
(mong the plethora of available processes, how can we choose one7 There is no single
answer to this !uestion. 9robably the best way to attack this problem is to look at the
software re!uirements.
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.
here the re!uirements are changing, evolutionary prototyping is better.
If the re!uirements are coupled with the underlying business processes, which are going
through a process of change, then a model based on "oehm$s spiral model, like the
2ational 5nified 9rocess should be used.
In these days of dynamic business environment, where $time to market$ is critical, and
pro'ect si:e is relatively small, an agile process should be chosen.
These are but guidelines only. .any organisations choose a model and adapt it to their
business re!uirements. )or e&ample, some organisations use waterfall model, modified to
include iterations within phases.
4. &onc!u$ion$
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 re!uirements, completeness of re!uirements, underlying business processes,
organisational structure, and the prevailing business environment