UNIT I:

Introduction: Evolution, Software development projects, Exploratory style of

software developments, Emergence of software engineering, Notable changes in
software development practices, Computer system engineering.

Software Life Cycle Models: Basic concepts, Waterfall model and its extensions,
Rapid application development, Agile development model, Spiral model

Introduction: software engineering is: “A systematic collection of good program

development practices and techniques”.

1.1.1 Evolution of an Art into an Engineering Discipline

The early programmers used an ad hoc programming style. This style of program
development is now variously being referred to as exploratory, build and fix, and
code and fix styles.

The exploratory programming style is an informal style in the sense that there are
no set rules or recommendations that a programmer has to adhere to—every
programmer himself evolves his own software development techniques solely
guided by his own intuition, experience, whims, and fancies.

the exploratory style usually yields poor quality and unmaintainable code and also
makes program development very expensive as well as time-consuming.

1.1.2 Evolution Pattern for Engineering Disciplines

If we analyse the evolution of the software development styles over the last sixty
years, we can easily notice that it has evolved from an esoteric art form to a craft
form and then has slowly emerged as an engineering discipline.this pattern of
evolution is not very different from that seen in other engineering disciplines.

Irrespective of whether it is iron making, paper making, software development, or

building construction; evolution of technology has followed strikingly similar
patterns. This pattern of technology development has schematically been shown in
Figure 1.1. It can be seen from Figure 1.1 that every technology in the initial years
starts as a form of art.

The story of the evolution of the software engineering discipline is not much
different. As we have already pointed out, in the early days of programming,there
were good programmers and bad programmers.

The good programmers knew certain principles (or tricks) that helped them write
good programs, which they seldom shared with the bad programmers. Program
writing in later years was akin to a craft.

Over the next several years, all good principles (or tricks) that were discovered by
programmers along with research innovations have systematically been organised
into a body of knowledge that forms the discipline of software engineering.
Software engineering principles are now being widely used in industry, and new

principles are still continuing to emerge at a very rapid rate—making this discipline

highly dynamic.

1.1.3 A Solution to the Software Crisis

what exactly is the present software crisis? What are its symptoms, causes, and
possible solutions? To understand the present software crisis,consider the following
facts.

The expenses that organisations all over the world are incurring on software
purchases as compared to the expenses incurred on hardware purchases have been
showing an worrying trend over the years (see Figure 1.2).

As can be seen in the figure, organisations are spending increasingly larger portions
of their budget on software as compared to that on hardware. Among all the
symptoms of the present software crisis, the trend of increasing software costs is
probably the most vexing.
1.2 SOFTWARE DEVELOPMENT PROJECTS

Before discussing about the various types of development projects that are being
undertaken by software development companies, let us first understand the
important ways in which professional software differs from toy software such as
those written by a student in his first programming assignment.
1.2.1 Programs versus Products

Many toy software are being developed by individuals such as students for their
classroom assignments and hobbyists for their personal use. These are usually
small in size and support limited functionalities.

The author of a program is usually the sole user of the software and himself
maintains the code. These toy software therefore usually lack good user-interface
and proper documentation. Besides these may have poor maintainability, efficiency,
and reliability. Since these toy software do not have any supporting documents such
as users’ manual, maintenance manual, design document, test documents, etc.,we
call these toy software as programs.

professional software usually have multiple users and, therefore, have good user-
interface, proper users’ manuals, and good documentation support. Since, a
software product has a large number of users, it is systematically designed,
carefully implemented,and thoroughly tested.

1.2.2 Types of Software Development Projects

A software development company typically has a large number of on-going projects.

Each of these projects may be classified into software product development projects
or services type of projects. These two broad classes of software projects can be
further classified into subclasses as shown in Figure 1.3
A generic software product development project concerns about developing a
software that would be sold to a large number of customers,it is said to have a
horizontal market.the services projects may either involve customizing some
existing software, maintaining or developing some outsourced software. Since a
specific segment of customers are targeted, these software products are said to
have a vertical market. In the following, we distinguish between these two major
types of software projects.

Software products

We all know of a variety of software such as Microsoft’s Windows operating system

and Office suite, and Oracle Corporation’s Oracle 8i database management
software. These software are available off-the-shelf for purchase and are used by a
diverse range of customers.
These are called generic software products since many users essentially use the
same software. These can be purchased off-the-shelf by the customers.
When a software development company wishes to develop a generic product, it first
determines the features or functionalities that would be useful to a large cross
section of users. Based on these, the development team draws up the product
specification on its own. Of course, it may base its design discretion on feedbacks
collected from a large number of users. Typically, each software product is
targetted to some market segment (set of users). Many companies find it
advantageous to develop product lines that target slightly different market
segments based on variations of essentially the same software.
domain specific software products are sold to specific categories of customers and
are said to have a vertical market. Domain specific software products target specific
segments of customers (called verticals) such as banking,telecommunication,
finance and accounts, and medical.

Software services
Software services covers a large gamut of software projects such as
customization,outsourcing, maintenance, testing, and consultancy.
Over the past few decades, a large number of programs have already been
developed. Available programs can therefore be modified to quickly fulfil the
specific requirements of any customer.
At present, there is hardly any software project in which the program code
is written from scratch, and software is being mostly developed by customizing
some existing software.
Development of outsourced software is a type of software service. Outsourced
software projects may arise for many reasons. Sometimes, it can make good
commercial sense for a company developing a large project to outsource some
parts of its development work to other companies. The reasons behind such a
decision may be many.
1.2.3 Software Projects Being Undertaken by Indian Companies
Indian software companies have excelled in executing software services projects
and have made a name for themselves all over the world. the Indian companies
have slowly started to focus on product development as well. Can you recall the
names of a few software products developed by Indian software companies? Let us
try to hypothesise the reason for this situation. Generic product development
entails certain amount of business risk. A company needs to invest upfront and
there is substantial risks concerning whether
the investments would turn profitable. Possibly, the Indian companies were risk
averse.Till recently, the world-wide sales revenue of software products and services
were evenly matched.

1.3 EXPLORATORY STYLE OF SOFTWARE DEVELOPMENT

exploratory program development style refers to an informal development style

where the programmer makes use of his own intuition to develop a program rather
than making use of the systematic body of knowledge categorized under the
software engineering discipline.
The exploratory development style gives complete freedom to the programmer to
choose the activities using which to develop software.Though the exploratory style
imposes no rules a typical development starts after an initial briefing from the
customer. Based on this briefing, the developers start coding to develop a working
program.
The software is tested and the bugs found are fixed. This cycle of testing and bug
fixing continues till the software works satisfactorily for the customer. A schematic
of this work sequence in a build and fix style has been shown graphically in Figure
1.4. Observe that coding starts after an initial customer briefing

about what is required. After the program development is complete, a test and fix
cycle continues till the program becomes acceptable to the customer.
An exploratory development style can be successful when used for developing very
small programs, and not for professional software.
What is wrong with the exploratory style of software development?
Let us first consider that exploratory style is being used to develop a professional
software.
The increase in development effort and time with problem size has been indicated
in Figure 1.5.
Observe the thick line plot that represents the case in which the exploratory style is
used to develop a program. It can be seen that as the program size increases, the
required effort and time increases almost exponentially.
For large problems, it would take too long and cost too much to be practically
meaningful to develop the program using the exploratory style of development. The
exploratory development approach is said to break down after the size of the
program to be developed increases beyond certain value.

Now observe the thin solid line plot in Figure 1.5 which represents the case when
development is carried out using software engineering principles. In this case, it
becomes possible to solve a problem with effort and time that is almost linear in
program size. On the other hand, if programs could be written automatically by
machines, then the increase in effort and time with size would be even closer to a
linear (dotted line plot) increase with size.
Summary of the shortcomings of the exploratory style of software
development:
We briefly summarise the important shortcomings of using the exploratory
development style to develop a professional software:
  The foremost difficulty is the exponential growth of development time and
effort with problem size and large-sized software becomes almost impossible
using this style of development.
 The exploratory style usually results in unmaintainable code. The reason for
this is that any code developed without proper design would result in highly
unstructured and poor quality code.
 It becomes very difficult to use the exploratory style in a team development
environment. In the exploratory style, the development work is undertaken
without any proper design and documentation. Therefore it becomes very
difficult to meaningfully partition the work among a set of developers who
can work concurrently. On the other hand, team development is
indispensable for developing modern software—most software mandate huge
development efforts, necessitating team effort for developing these. Besides
poor quality code, lack of proper documentation makes any later
maintenance of the code very difficult.
1.3.1 Perceived Problem Complexity: An Interpretation Based on Human
Cognition Mechanism
A simple understanding of the human cognitive mechanism would also give us an
insight into why the exploratory style of development leads to an undue increase in
the time and effort required to develop a programming solution. It can also explain
why it becomes practically infeasible to solve problems larger than a certain size
while using an exploratory style.
Psychologists say that the human memory can be thought to consist of two distinct
parts [Miller, 1956]: short-term and long-term memories. A schematic
representation of these two types of memories and their roles in human cognition
mechanism has been shown in Figure 1.6. In Figure 1.6, the block labelled sensory
organs represents the five human senses sight, hearing, touch, smell, and taste.
The block labelled actuator represents neuromotor organs such as hand, finger,
feet, etc.
Short-term memory: The short-term memory, as the name itself suggests, can
store information for a short while—usually up to a few seconds, and at most for a
few minutes. The short-term memory is also sometimes referred to as the working
memory. The information stored in the short-term memory is immediately
accessible for processing by the brain. The short-term memory of an average
person can store up to seven items;
but in extreme cases it can vary anywhere from five to nine items (7 ± 2). As shown
in Figure 1.6, the short-term memory participates in all interactions of the human
mind with its environment.
All information collected through the sensory organs are first stored in the short-
term memory. The short-term memory is also used by the brain to drive the
neuromotor organs. The mental manipulation unit also gets its inputs from the
short-term memory and stores back any output it produces.
Long-term memory: Unlike the short-term memory, the size of the long-term
memory is not known to have a definite upper bound. The size of the long-term
memory can vary from several million items to several billion items, largely
depending on how actively a person exercises his mental faculty. An item once
stored in the long-term memory, is usually retained for several years. But, how do
items get stored in the long-term memory?
Item: We have so far only mentioned the number of items that the long-term and
the short-term memories can store.An item is any set of related information.A word,
a sentence, a story, or even a picture can each be a single item. Each item normally
occupies one place in memory. This phenomenon of forming one item from several
items is referred to as chunking by psychologists.
Evidence of short-term memory: Evidences of short-term memory manifest
themselves in many of our day-to-day experiences.
The magical number 7:Miller called the number seven as the magical number
[Miller,1956] since if a person deals with seven or less number of unrelated
information at a time these would be easily accommodated in the short-term
memory.
When the number of details (or variables) that one has to track to solve a problem
increases beyond seven, it exceeds the capacity of the short-term memory and it
becomes exceedingly more difficult for a human mind to grasp the problem.
1.3.2 Principles Deployed by Software Engineering to Overcome Human
Cognitive Limitations
Two important principles that are deployed by software engineering to overcome the
problems arising due to human cognitive limitations are—abstraction and
decomposition.
Abstraction
Abstraction refers to construction of a simpler version of a problem by ignoring the
details. The principle of constructing an abstraction is popularly known as modelling
(or model construction).

Abstraction is the simplification of a problem by focusing on only one aspect of the

problem while omitting all other aspects.
„ Suppose you are asked to develop an overall understanding of some country.
A physical map shows the physical features of an area; such as mountains, lakes,
rivers, coastlines, and so on. On the other hand, the political map shows states,
capitals, and national boundaries, etc. The physical map is an abstract model of the
country and ignores the state and district boundaries.
„. Consider the following situation. Suppose you are asked to develop an
understanding of all the living beings inhabiting the earth.
Decomposition
Decomposition is another important principle that is available in the repertoire of a
software engineer to handle problem complexity. This principle is profusely made
use by several software engineering techniques to contain the
exponential growth of the perceived problem complexity.
The decomposition principle is popularly known as the divide and conquer
principle.The decomposition principle advocates decomposing the problem into
many small independent parts. The small parts are then taken up one by one and
solved separately.
The idea is that each small part would be easy to grasp and understand and can be
easily solved. The full problem is solved when all the parts are solved.
Why study software engineering:
 The skill to participate in development of large software. You can
meaningfully
participate in a team effort to develop a large software only after learning the
systematic techniques that are being used in the industry.
 You would learn how to effectively handle complexity in a software
development
problem. In particular, you would learn how to apply the principles of abstraction
and decomposition to handle complexity during various stages in software
development such as specification, design, construction, and testing.
1.4 EMERGENCE OF SOFTWARE ENGINEERING
This evolution is the result of a series of innovations and accumulation of
experience about writing good quality programs. Since these innovations and
programming experiences are too numerous, let us briefly examine only a few of
these innovations and programming experiences which have contributed to the
development of the software engineering discipline.
1.4.1 Early Computer Programming
Early commercial computers were very slow and too elementary as compared to
today’s
standards. Even simple processing tasks took considerable computation time on
those
computers. No wonder that programs at that time were very small in size and
lacked
sophistication. Those programs were usually written in assembly languages.
They then went on fixing any problems that they observed until they
had a program that worked reasonably well. We have already designated this style
of
programming as the build and fix (or the exploratory programming) style.
1.4.2 High-level Language Programming
Computers became faster with the introduction of the semiconductor technology in
the
early 1960s. Faster semiconductor transistors replaced the prevalent vacuum tube-
based circuits in a computer. With the availability of more powerful computers, it
became possible to solve larger and more complex problems. At this time, high-
level languages such as FORTRAN, ALGOL, and COBOL were introduced.
1.4.3 Control Flow-based Design
As the size and complexity of programs kept on increasing, the exploratory
programming
style proved to be insufficient. Programmers found it increasingly difficult not only
to
write cost-effective and correct programs, but also to understand and maintain
programs written by others. To cope up with this problem, experienced
programmers advised other programmers to pay particular attention to the design
of a program’s control flow structure.
A program’s control flow structure indicates the sequence in which the program’s
instructions are executed.
In order to help develop programs having good control flow structures, the
flow charting technique was developed.

A programmer trying to understand a program would have to mentally trace and

understand the processing that take place along all the paths of
the program making program understanding and debugging extremely complicated.
Are GO TO statements the culprits?
In a landmark paper, Dijkstra [1968] published his (now famous) article “GO TO
Statements Considered Harmful”.
He pointed out that unbridled use of GO TO statements is the main culprit in making
the control structure of a program messy.
Structured programming—a logical extension
Structured programming is facilitated, if the programming language being used
supports single-entry, single-exit program constructs such as if-then-else, do-while,
etc.
Research experiences have shown that programmers commit less number of errors
while using structured if-then-else and do-while statements than when using test-
and-branch code constructs. Besides being less error-prone, structured programs
are normally more readable, easier to maintain, and require less effort to develop
compared to unstructured programs.
Very soon several languages such as PASCAL, MODULA, C, etc., became available
which were specifically designed to support structured programming.
1.4.4 Data Structure-oriented Design
Computers became even more powerful with the advent of integrated circuits (ICs)
in the early seventies. These could now be used to solve more complex problems.
Software developers were tasked to develop larger and more complicated software.
This often required writing in excess of several tens of thousands of lines of source
code. The control flow-based program development techniques could not be used
satisfactorily any more to write those programs, and more effective program
development techniques were needed.
It was soon discovered that while developing a program, it is much more important
to pay attention to the design of the important data structures of the program than
to the design of its control structure. Design techniques based on this principle are
called data structure-oriented design techniques.
1.4.5 Data Flow-oriented Design
As computers became still faster and more powerful with the introduction of very
large scale integrated (VLSI) Circuits and some new architectural concepts,The data
flow-oriented techniques advocate that the major data items handled by a system
must be identified and the processing required on these data items to produce the
desired outputs should be determined. More complex and sophisticated software
were needed to solve further challenging problems. Therefore, software developers
looked out for more effective techniques for designing software and soon data flow-
oriented techniques were proposed.
The functions (also called as processes) and the data items that are exchanged
between
the different functions are represented in a diagram known as a data flow diagram
(DFD).
The program structure can be designed from the DFD representation of the
problem.
1.4.6 Object-oriented Design
Data flow-oriented techniques evolved into object-oriented design (OOD) techniques
in the late seventies. Object-oriented design technique is an intuitively appealing
approach, where the natural objects (such as employees, pay-roll-register, etc.)
relevant to a problem are first identified and then the relationships among the
objects such as composition, reference, and inheritance are determined. Each
object essentially acts as a data hiding (also known as data abstraction) entity.
Object-oriented techniques have gained wide spread acceptance because of their
simplicity, the scope for code and design reuse, promise of lower development time.
1.4.7 What Next?
we have so far discussed how software design techniques have evolved since
the early days of programming. We pictorially summarise this evolution of the
software
design techniques in Figure 1.13. It can be observed that in almost every passing
decade,revolutionary ideas were put forward to design larger and more
sophisticated programs,and at the same time the quality of the design solutions
improved.
1.4.8 Other Developments
It can be seen that remarkable improvements to the prevalent software design
technique
occurred almost every passing decade. In addition to the advancements made to
the software design techniques, several other new concepts and techniques for
effective software development were also introduced. These new techniques include
life cycle models, specification techniques, project management techniques, testing
techniques, debugging techniques, quality assurance techniques, software
measurement techniques, computer aided software engineering (CASE) tools, etc.
The development of these techniques accelerated the growth of software
engineering as a discipline.

1.5 NOTABLE CHANGES IN SOFTWARE DEVELOPMENT PRACTICES

  An important difference is that the exploratory software development style is
based on error correction (build and fix) while the software engineering
techniques are based on the principles of error prevention.
 In the exploratory style, coding was considered synonymous with software
development.
 A lot of attention is now being paid to requirements specification. Significant
effort is being devoted to develop a clear and correct specification of the
problem
before any development activity starts.
 Now there is a distinct design phase where standard design techniques are
employed to yield coherent and complete design models.
 Periodic reviews are being carried out during all stages of the development
process.
 The main objective of carrying out reviews is phase containment of errors,
i.e. detect and correct errors as soon as possible.
 By visibility we mean production of good quality, consistent and peer
reviewed documents at the end of every software development activity.Now,
projects are being thoroughly planned.

1.6 COMPUTER SYSTEMS ENGINEERING

In all the discussions so far, we assumed that the software being developed
would run on some general-purpose hardware platform such as a desktop
computer or a server. But, in several situations it may be necessary to
develop special hardware on which the software would run.
Computer systems engineering addresses development of such systems
requiring development of both software and specific hardware to run the
software. Thus, systems engineering encompasses software engineering.
 The general model of systems engineering is shown schematically in Figure
1.14. One of the important stages in systems engineering is the stage in
which decision is made regarding the parts of the problems that are to be
implemented in hardware and the ones that would be implemented in software.
This has been represented by the box captioned hardware-software partitioning
in Figure 1.14. While partitioning the functions between hardware and software,
several trade-offs such as flexibility, cost, speed of operation, etc., need to be
considered. The functionality implemented in hardware run faster. On the other
hand, functionalities implemented in software is easier to extend. Further, it is
difficult to implement complex functions in hardware.
SOFTWARE LIFE CYCLE MODELS
software engineering approaches emphasise software development through a well-
defined and ordered set of activities. These activities when graphically modelled
(represented) and textually described are variously called as software life cycle
model, software development life cycle (SDLC) model, and software development
process model. Several life cycle models have so far been proposed.
2.1 A FEW BASIC CONCEPTS
Software life cycle
It is well known that all living organisms undergo a life cycle. For example when a
seed is planted, it germinates, grows into a full tree, and finally dies. Based on this
concept of a biological life cycle, the term software life cycle has been defined to
imply the different stages (or phases) over which a software evolves from the initial
customer request for it,to a fully developed software, and finally to a stage where it
is no longer useful to any user, and is discarded.
This stage where the customer feels a need for the software and forms rough ideas
about the required features is known as the inception stage.
The life cycle of a software represents the series of identifiable stages through
which it evolves during its life time.
Software development life cycle (SDLC) model
A software development life cycle (SDLC) model (also called software life cycle
model and software development process model) describes the different activities
that need to be carried out for the software to evolve in its life cycle. Throughout
our discussion, we shall use the terms software development life cycle (SDLC) and
software development process interchangeably
An SDLC is represented graphically by drawing various stages of the life cycle and
showing on it the transitions among the stages.
An SDLC graphically depicts the different phases through which a software
evolves.It is usually accompanied by a textual description of the different activities
that need to be carried out during each phase.
Process versus methodology
A software development process has a much broader scope as compared to
a software development methodology. A process usually describes all the activities
starting from the inception of a software to its maintenance and retirement stages,
or at least a chunk of activities in the life cycle. It also recommends specific
methodologies for carrying out each activity. A methodology in contrast,describes
the steps to carry out only a single or at best a few individual activities.
Why use a development process?
Software development organisations have realised that adherence to a suitable life
cycle model helps to produce good quality software and also helps to minimise the
chances of time and cost overruns.
Programming-in-the-small refers to development of a toy program by a single
programmer.On the other hand,programming-in-the-large refers to development of
professional software through team effort. While development of software of the
former type could succeed even when an individual programmer uses a
build and fix style of development,use of a suitable SDLC is essential for a
professional software development project involving team effort to succeed.
Why document a development process?
A documented development process forms a common understanding of the
activities to be carried out among the software developers and helps them to
develop software in a systematic and disciplined manner. A documented
development process model,besides preventing the misinterpretations that might
occur when the development process is not adequately documented, also helps to
identify inconsistencies,redundancies, and omissions in the development process.
Phase entry and exit criteria
The phase exit criteria for the software requirements specification phase, can be
that the software requirements specification (SRS) document is ready, has been
reviewed internally, and also has been reviewed and approved by the customer.
Only after these criteria are satisfied, the next phase can start.
2.2 WATERFALL MODEL AND ITS EXTENSIONS
The waterfall model and its derivatives were extremely popular in the 1970s and
still are heavily being used across many development projects.
2.2.1 Classical Waterfall Model
Classical waterfall model is intuitively the most obvious way to develop software. It
is simple but idealistic. The Waterfall Model was the first Process Model to be
introduced. It is also referred to as a linear-sequential life cycle model. It is very
simple to understand and use. In a waterfall model, each phase must be completed
before the next phase can begin and there is no overlapping in the phases.
This means that any phase in the development process begins only if the previous
phase is complete. In this waterfall model, the phases do not overlap.
Phases of the classical waterfall model
The phases starting from the feasibility study to the integration and system
testing phase are known as the development phases.
The different phases of the classical waterfall model have been shown in Figure 2.1.

Figure 2.1, the different phases are—feasibility study, requirements analysis and
specification, design, coding and unit testing, integration and system testing, and
maintenance. The phases starting from the feasibility study to the integration and
system testing phase are known as the development phases.The relative amounts
of effort spent on different phases for a typical software has been shown in Figure
2.2. Observe from Figure 2.2 that among all the life cycle phases, the maintenance
phase normally requires the maximum effort. On the average, about 60 per cent of
the total effort put in by the development team in the entire life cycle is spent on
the maintenance activitiesalone. However, among the development phases, the
integration and system testing phase requires the maximum effort in a typical
development project.
Feasibility study
The main focus of the feasibility study stage is to determine whether it would be
financially and technically feasible to develop the software. The feasibility study
involves carrying out several activities such as collection of basic information
relating to the software such as the different data items that would be input to the
system, the processing required to be carried out on these data, the output data
required to be produced by the system, as well as various constraints on the
development. These collected data are analysed to perform the following:
Development of an overall understanding of the problem
Formulation of various possible strategies for solving the problem
Evaluation of the different solution strategies
Requirements analysis and specification
The aim of the requirements analysis and specification phase is to understand the
exact
requirements of the customer and to document them properly. This phase consists
of
two distinct activities, namely requirements gathering and analysis, and
requirements
specification. In the following, we give an overview of these two activities:
Requirements gathering and analysis: The goal of the requirements gathering
activity is to collect all relevant information regarding the software to be developed
from the customer with a view to clearly understand the requirements.
Requirements specification: After the requirement gathering and analysis
activities
are complete, the identified requirements are documented. This document is called
a software requirements specification (SRS) document.
Design
The goal of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some programming
language. In technical terms, during the design phase the software architecture is
derived from the SRS document. Two distinctly different design approaches are
popularly being used at present—the procedural and object-oriented design
approaches.
Procedural design approach:
It consists of two important activities;first structured analysis of the requirements
specification is carried out where thedata flow structure of the problem is examined
and modelled. This is followed bya structured design step where the results of
structured analysis are transformed into the software design.
Object-oriented design approach: The OOD approach is credited
to have several benefits such as lower development time and effort, and better
maintainability of the software.
Coding and unit testing
The purpose of the coding and unit testing phase is to translate a software design
into
source code and to ensure that individually each function is working correctly. The
coding phase is also sometimes called the implementation phase
The main objective of unit testing is to determine the correct working of the
individual modules.
Integration and system testing
Integration testing is carried out to verify that the interfaces among different units
are working satisfactorily. On the other hand, the goal of system
testing is to ensure that the developed system conforms to the requirements that
have been laid out in the SRS document.
System testing usually consists of three different kinds of testing activities:
 a-testing: a testing is the system testing performed by the development
team.
 b-testing: This is the system testing performed by a friendly set of
customers.
 Acceptance testing: After the software has been delivered, the customer
performs system testing to determine whether to accept the delivered
software or to reject it.
Maintenance
Maintenance is required in the following three types of situations:
 Corrective maintenance: This type of maintenance is carried out to correct
errors that were not discovered during the product development phase.
 Perfective maintenance: This type of maintenance is carried out to
improve the
performance of the system, or to enhance the functionalities of the system based
on
customer’s requests.
  Adaptive maintenance: Adaptive maintenance is usually required for
porting the software to work in a new environment. For example, porting may
be required to get the software to work on a new computer platform or with a
new operating system.
Shortcomings of the classical waterfall model
The classical waterfall model is a very simple and intuitive model. However, it
suffers from several shortcomings.
No feedback paths: In classical waterfall model, the evolution of a software from
one phase to the next is analogous to a waterfall.
The classical waterfall model is idealistic in the sense that it assumes that no error
is ever committed by the developers during any of the life cycle phases, and
therefore,incorporates no mechanism for error correction.
Difficult to accommodate change requests
Inefficient error corrections
No overlapping of phases
Is the classical waterfall model useful at all?
Irrespective of the life cycle model that is actually followed for a product
development,the final documents are always written to reflect a classical waterfall
model of development,so that comprehension of the documents becomes easier for
any one reading the document.
2.2.2 Iterative Waterfall Model
The main change brought about by the iterative waterfall model to the classical
waterfall model is in the form of providing feedback paths from every phase to its
preceding phases.
The Iterative Waterfall Model is a software development approach that combines
the sequential steps of the traditional Waterfall Model with the flexibility of iterative
design. It allows for improvements and changes to be made at each stage of the
development process, instead of waiting until the end of the project. The iterative
waterfall model provides feedback paths from every phase to its preceding phases,
which is the main difference from the classical waterfall model.
1. When errors are detected at some later phase, these feedback paths allow
for correcting errors committed by programmers during some phase.
2. The feedback paths allow the phase to be reworked in which errors are
committed and these changes are reflected in the later phases.
3. But, there is no feedback path to the stage – feasibility study, because once a
project has been taken, does not give up the project easily.
4. It is good to detect errors in the same phase in which they are committed.
5. It reduces the effort and time required to correct the errors.
6. A real-life example could be building a new website for a small business.
Following are the phases of Iterative Waterfall Model:
1. Requirements Gathering: This is the first stage where the business owners
and developers meet to discuss the goals and requirements of the website.
2. Design: In this stage, the developers create a preliminary design of the
website based on the requirements gathered in stage 1.
3. Implementation: In this stage, the developers begin to build the website
based on the design created in stage 2.
4. Testing: Once the website has been built, it is tested to ensure that it meets
the requirements and functions properly.
5. Deployment: The website is then deployed and made live to the public.
6. Review and Improvement: After the website has been live for a while, the
business owners and developers review its performance and make any
necessary improvements.
Advantages of Iterative Waterfall Model
Phase Containment of Errors
Flexibility
Testing and feedback
Scalability
Maintenance
Easy to Manage
Improved Customer Satisfaction
Quality Assurance
Risk Reduction
Feedback Path
Phase overlap
 In spite of the best effort to detect errors in the same phase in which they are
committed, some errors escape detection and are detected in a later phase. These
subsequently detected errors cause the activities of some already completed
phases
to be reworked. If we consider such rework after a phase is complete, we can say
that the activities pertaining to a phase do not end at the completion of the phase,
but overlap with other phases as shown in Figure 2.4.

 An important reason for phase overlap is that usually the work required to be
carried out in a phase is divided among the team members.
Shortcomings of the iterative waterfall model
The iterative waterfall model is a simple and intuitive software development model.
It
was used satisfactorily during 1970s and 1980s. In the 1970s and 1960s, software
development projects spanned several years and mostly involved generic software
product development. The projects are now shorter, and involve Customised
software development.
Once requirements have been frozen, the waterfall model provides no scope for any
modifications to the requirements. The basic assumption made in the iterative
waterfall model that methodical requirements gathering and analysis alone is
sufficient to comprehensively and correctly identify all the requirements by the end
of the requirements phase is flawed.
Difficult to accommodate change requests
Incremental delivery not supported
Phase overlap not supported
Error correction unduly expensive
Limited customer interactions
Heavy weight
No support for risk handling and reuse
2.2.3 V-Model
this model gets its name from its visual appearance (see Figure 2.5). In this model
verification and validation activities are carried out throughout the development life
cycle, and therefore the chances bugs in the work products considerably reduce.
This model is therefore generally considered to be suitable for use in projects
concerned with development of safety-critical software that are required to have
high reliability.
As shown in Figure 2.5, there are two main phases—development and validation
phases. The left half of the model comprises the development phases and the right
half
comprises the validation phases.
 In each development phase, along with the development of a work product,
test case design and the plan for testing the work product are carried out,
whereas the actual testing is carried out in the validation phase. This
validation plan created during the development phases is carried out in the
corresponding validation phase which have been shown by dotted arcs in
Figure 2.5.

 In the validation phase, testing is carried out in three steps—unit, integration,

and system testing. The purpose of these three different steps of testing
during
the validation phase is to detect defects that arise in the corresponding
phases of software development— requirements analysis and specification,
design, and coding respectively.
V-model versus waterfall model
As already mentioned, in contrast to the iterative waterfall model where
testing activities are confined to the testing phase only, in the V-model
testing activities are spread over the entire life cycle. As shown in Figure 2.5,
during the requirements specification phase, the system test suite design
activity takes place. During the design phase, the integration test cases are
 designed. During coding, the unit test cases are designed. Thus, we can say
that in this model, development and validation activities proceed hand in
hand.
Advantages of V-model
 In the V-model, much of the testing activities (test case design, test planning,
etc.) are carried out in parallel with the development activities.
 Since test cases are designed when the schedule pressure has not built up,
the quality of the test cases are usually better.
 The test team is reasonably kept occupied throughout the development cycle
in contrast to the waterfall model where the testers are active only during the
testing phase.
 In the V-model, the test team is associated with the project from the
beginning.
Disadvantages of V-model
 High risk and uncertainty.
 It is not good for complex and object-oriented projects.
 It is not suitable for projects where requirements are not clear and contain a
high risk of changing.
 This model does not support iteration of phases.
 It does not easily handle concurrent events.
 Time-Consuming: The V-Model can be time-consuming, as it requires a lot of
documentation and testing.
 Overreliance on Documentation: The V-Model places a strong emphasis on
documentation, which can lead to an overreliance on documentation at the
expense of actual development work.

2.2.4 Prototyping Model

The prototype model is also a popular life cycle model. The prototyping model can
be
considered to be an extension of the waterfall model. This model suggests building
a
working prototype of the system, before development of the actual software. A
prototype
is a toy and crude implementation of a system. It has limited functional capabilities,
low
reliability, or inefficient performance as compared to the actual software. A
prototype can be built very quickly by using several shortcuts.
Necessity of the prototyping model
The prototyping model is advantageous to use for specific types of projects. The GUI
part of a software system is almost always developed using the prototyping model.

 It is advantageous to use the prototyping model for development of the

graphical user interface (GUI) part of an application. Through the use of a
prototype, it becomes easier to illustrate the input data formats, messages,
 reports, and the interactive dialogs to the customer.This is a valuable
mechanism for gaining better understanding of the customers needs.
 The prototyping model is especially useful when the exact technical solutions
are unclear to the development team. A prototype can help them to critically
examine the technical issues associated with product development.
 An important reason for developing a prototype is that it is impossible to “get
it right” the first time. The prototyping model is considered to be useful for
the development of not only the GUI parts of a software,but also for a
software project for which certain technical issues are not clear to the
development team.
Life cycle activities of prototyping model
The prototyping model of software development is graphically shown in
Figure 2.6.software is developed through two major activities—prototype
construction and iterative waterfall-based software development.
 Prototype development: Prototype development starts with an initial
requirements gathering phase. A quick design is carried out and a prototype
is built. The developed prototype is submitted to the customer for evaluation.
Based on the customer feedback, the requirements are refined and the
prototype is suitably modified. This cycle of obtaining customer feedback and
modifying the prototype continues till the customer approves the prototype.
Iterative development: Once the customer approves the prototype, the
actual software is developed using the iterative waterfall approach. In spite of
the availability of a working prototype, the SRS document is usually needed
to be developed since the SRS document
is invaluable for carrying out traceability analysis, verification, and test case
design during
later phases.
prototype helps a great deal in developing the actual system.By constructing
the prototype and submitting it for user evaluation, many customer
requirements get properly
defined and technical issues get resolved by experimenting with the
prototype. This minimises later change requests from the customer and the
associated redesign costs.
Strengths of the prototyping model
This model is the most appropriate for projects that suffer from risks arising
from technical uncertainties and unclear requirements. A constructed
prototype helps overcome these risks. Even though the construction of a
throwaway prototype might involve incurring additional cost, for systems with
unclear customer requirements and for systems with unresolved technical
issues, the overall development cost usually turns out to be lower compared
to an equivalent system developed using the iterative waterfall model.
Weaknesses of the prototyping model
The prototype model can increase the cost of development for projects that
are routine development work and do not suffer from any significant risks.
Since the prototype is constructed only at the start of the project, the
prototyping model is ineffective for risks identified later during the
development cycle. The prototyping model would not be appropriate for
projects for which the risks can only be identified after the development is
underway.
2.2.5 Incremental Development Model

In the incremental life cycle model, the software is developed in increment. In this
life cycle model, first the requirements are split into a set of increments. The first
increment is a simple working system implementing only a few basic features. Over
successive iterations, successive increments are implemented and delivered to the
customer until the desired system is realised. The incremental development model
has been shown in Figure 2.7.
Life cycle activities of incremental development model
In the incremental life cycle model, the requirements of the software are first
broken down into several modules or features that can be incrementally
constructed and delivered. This has been pictorially depicted in Figure 2.7. At any
time, plan is made only for the next increment and no long-term plans are made.
Therefore, it becomes easier to accommodate change requests from the customers.
The development team first undertakes to develop the core features of the system.
Each incremental version is usually developed using an iterative waterfall model of
development. The incremental model is schematically shown in Figure 2.8. As each
successive version of the software is constructed and delivered to the customer, the
customer feedback is obtained on the delivered version and these feedbacks are
incorporated in the next version. Each delivered version of the
software incorporates additional features over the previous version and also refines
the
features that were already delivered to the customer.
The incremental model has schematically been shown in Figure 2.8. After the
requirements gathering and specification, the requirements are split into several
increments.
Starting with the core (increment 1), in each successive iteration, the next
increment is
constructed using a waterfall model of development and deployed at the customer
site.
After the last (shown as increment n) has been developed and deployed at the
client site,
the full software is developed and deployed.
Advantages
Two important ones are the following:
 Error reduction: The core modules are used by the customer from the
beginning and therefore these get tested thoroughly. This reduces chances of
errors in the core modules of the final product, leading to greater reliability of
the software.
  Incremental resource deployment: This model obviates the need for the
customer to commit large resources at one go for development of the
system. It also saves the developing organisation from deploying large
resources and manpower for a project in one go.

2.2.6 Evolutionary Model

This model has many of the features of the incremental model. As in case of the
incremental model, the software is developed over a number of increments. At each
increment, a concept (feature) is implemented and is deployed at the client site.
The software is successively refined and feature-enriched until the full software is
realised.
The principal idea behind the evolutionary life cycle model is conveyed by its name.
In the incremental development model, complete requirements are first developed
and the SRS document prepared.
In the evolutionary model, the requirements, plan, estimates, and solution evolve
over the iterations, rather than fully defined and frozen in a major up-front
specification effort before the development iterations begin. Such evolution is
consistent with the pattern of unpredictable feature discovery and feature changes
that take place in new product development.
the evolutionary software development process is sometimes referred to as design
a little, build a little, test a little, deploy a little model.This means that after the
requirements have been specified, the design, build, test, and deployment activities
are iterated. A schematic representation of the evolutionary model of development
has been shown in Figure 2.9.
Advantages
The evolutionary model of development has several advantages.
 Effective elicitation of actual customer requirements: The user gets
a chance to experiment with a partially developed software much before the
complete requirements are developed.
 Easy handling change requests: Handling change requests is
easier as no long-term plans are made.
Disadvantages
The main disadvantages of the successive versions model are as follows:
 Feature division into incremental parts can be non-trivial: For many
development projects, especially for small-sized projects, it is difficult to
divide the required features into several parts that can be incrementally
implemented and delivered.
  Ad hoc design: Since at a time design for only the current increment is
done, the
design can become ad hoc without specific attention being paid to
maintainability
and optimality.
Evolutionary versus incremental model of developments
The evolutionary and incremental have several things in common, incremental
development and deployment at the client site. However, in a purely incremental
model,
the requirement specification is completed before any development activities start.
Once
the requirement specification is completed, the requirements are split into
requirements.
In a purely evolutionary development, the development of the first version starts off
after
obtaining a rough understanding of what is required. As the development proceeds,
more and more requirements emerge.
2.3 RAPID APPLICATION DEVELOPMENT (RAD)
The rapid application development (RAD) model was proposed in the early nineties
in an
attempt to overcome the rigidity of the waterfall model that makes it difficult to
accommodate any change requests from the customer. This model has the features
of both prototyping and evolutionary models. It deploys an evolutionary delivery
model to obtain and incorporate the customer feedbacks on incrementally delivered
versions.In this model prototypes are constructed, and incrementally the features
are developed and delivered to the customer. But unlike the prototyping model, the
prototypes are not thrown away but are enhanced and used in the software
construction.
The major goals of the RAD model are as follows:
 To decrease the time taken and the cost incurred to develop software
systems.
 To limit the costs of accommodating change requests.
 To reduce the communication gap between the customer and the developers.
2.3.1 Working of RAD
In the RAD model, development takes place in a series of short cycles or iterations.
At any time, the development team focuses on the present iteration only, and
therefore plans are made for one increment at a time. The time planned for each
iteration is called a time box.
Each iteration is planned to enhance the implemented functionality of the application
by
only a small amount.The development team almost always includes a customer
representative to clarify the requirements. This is intended to make the system
tuned to the exact customer requirements and also to bridge the communication
gap between the customer and the development team.
2.3.2 Applicability of RAD Model
 Customised software: As already pointed out a customised software is
developed for one or two customers only by adapting an existing software. In
customised software development projects, substantial reuse is usually made
of code from pre-existing software.
 Non-critical software: The RAD model suggests that a quick and dirty
software
should first be developed and later this should be refined into the final
software
for delivery.
 Highly constrained project schedule: RAD aims to reduce development
time at the expense of good documentation, performance, and reliability.
 Large software: Only for software supporting many features (large
software) can
incremental development and delivery be meaningfully carried out.
Application characteristics that render RAD unsuitable
 Generic products (wide distribution): Software products are generic in
nature and usually have wide distribution. For such systems, optimal
performance and reliability are imperative in a competitive market.
 Requirement of optimal performance and/or reliability: For certain
categories of products, optimal performance or reliability is required.
 Lack of similar products: If a company has not developed similar
software,then it would hardly be able to reuse much of the existing artifacts.
 Monolithic entity: For certain software, especially small-sized software, it
may
be hard to divide the required features into parts that can be incrementally
developed and delivered.
2.3.3 Comparison of RAD with Other Models
Though RAD is expected to lead to faster software development compared to the
traditional models (such as the prototyping model), the quality and reliability would
be inferior.
RAD versus prototyping model
In the prototyping model, the developed prototype is primarily used by the
development
team to gain insights into the problem, choose between alternatives, and elicit
customer
feedback.
RAD versus iterative waterfall model
In the iterative waterfall model, all the functionalities of a software are developed
together. On the other hand, in the RAD model the product functionalities are
developed incrementally through heavy code and design reuse.
RAD versus evolutionary model
Incremental development is the hallmark of both evolutionary and RAD models.
However,in RAD each increment results in essentially a quick and dirty prototype,
whereas in the evolutionary model each increment is systematically developed
using the iterative
waterfall model.
2.4 AGILE DEVELOPMENT MODELS
The iterative waterfall model has been very popular during the 1970s and 1980s,
developers face several problems while using it on present-day software projects.
The main difficulties include handling change requests from customers during
product development, and the unreasonably high cost and time that is incurred
while developing customised applications.
Over the last two decades or so, projects using iterative waterfall-based life cycle
models
are becoming increasingly rare due to the rapid shift in the characteristics of the
software development projects that are being undertaken. Two changes that are
becoming noticeable are rapid shift from development of software products to
development of customised software and the increased emphasis and scope for
reuse.
we identify a few reasons why the waterfall-based development was becoming
difficult to use in project in recent times:
 In the traditional iterative waterfall-based software development models, the
requirements for the system are determined at the start of a development
project
and are assumed to be fixed from that point on. Later changes to the
requirements After the SRS document has been completed are discouraged.
 Waterfall model is called a heavy weight model, since there is too much
emphasis on producing documentation and usage of tools.
 Waterfall model prescribes almost no customer interactions after the
requirements have been specified.
2.4.1 Essential Idea behind Agile Models
For establishing close interactions with the customer during development and to
gain
a clear understanding of domain-specific issues, each agile project usually includes
a
customer representative in the team. At the end of each iteration, stakeholders and
the
customer representative review the progress made and re-evaluate the
requirements. The developed increment is installed at the customer site. A
distinguishing characteristics of the agile models is frequent delivery of software
increments to the customer.
Agile models emphasise use of face-to-face communication in preference over
written
documents.
The agile model emphasizes incremental release of working software as the primary
measure of progress.
In pair programming, two programmers work together at one work station. One
types in
code while the other reviews the code as it is typed in. The two programmers switch
their roles every hour or so.
Advantages and disadvantages of agile methods
 Lack of formal documents leaves scope for confusion and important decisions
taken during different phases can be misinterpreted at later points of time by
different team members.
 In the absence of any formal documents, it becomes difficult to get important
project decisions such as design decisions to be reviewed by external
experts.
 When a project completes and the developers disperse, maintenance can
become a problem.
2.4.2 Agile versus Other Models
Agile model versus iterative waterfall model
The waterfall model is highly structured and makes a project to systematically step
through requirements-capture, analysis, specification, design, coding, and testing
stages in a planned sequence. Progress is generally measured in terms of the
number of completed and reviewed artifacts such as requirements specification
document, design documents, test plans, code reviews, etc.
Agile versus exploratory programming
Though a few similarities do exist between the agile and exploratory program
development styles, there are vast differences between the two as well. Agile
development model’s frequent re-evaluation of plans, emphasis on face-to-face
communication, and relatively sparse use of documentation are similar to that of
the exploratory style.
Agile model versus RAD model
„Agile model does not recommend developing prototypes, but emphasises
systematic
development of each incremental feature.
„ Agile projects logically break down the solution into features that are
incrementally
developed and delivered.
„ Agile teams only demonstrate completed work to the customer.
2.4.3 Extreme Programming Model
Extreme programming (XP) is an important process model under the agile umbrella
and was proposed by Kent Beck in 1999. The name of this model reflects the fact
that it recommends taking the best practices that have worked well in the past in
projects to extreme levels.
Good practices that need to be carried on to the extreme
We mention some of the good practices that have been recognized in the extreme
programming model and the ways that have been suggested to maximize their use.
Code review: Code review is good since it helps to detect and correct problems
most
efficiently. XP suggests pair programming as the way to achieve continuous review.
Testing: Testing code helps to remove bugs and improves its reliability. XP
suggests
Test-Driven Development (TDD) to continually write and execute test cases.
Incremental development: Incremental development is good, since it helps to
get customer
feedback, and extent of features delivered is a reliable indicator of progress.
Simplicity: Simplicity leads to good quality code. It also makes it easier to test and
debug the code.
Design: Since having a good quality design is important to develop a good quality
solution,every team member should perform some design on a daily basis.
Integration testing: Integration testing is important since it helps to identify the
bugs at the interfaces of different functionalities.
Basic idea of extreme programming model
XP is based on frequent releases (called iterations), during which the developers
implement “user stories”. User stories are similar to use cases, but are more
informal and are simpler.
XP is in favour of making the solution to a problem as simple as possible. In
contrast, the traditional system development methods recommend planning for
reusability and future extensibility of code and design at the expense of higher code
and design complexity.
We discuss these activities in the following subsections:
Coding: XP argues that code is the crucial part of any system development
process, since
without code it is not possible to have a working system.
Testing: XP places high importance on testing and considers it be the primary
means for developing a fault-free software.
Listening: The developers need to carefully listen to the customers if they have to
develop a good quality software. Programmers may not necessarily have an in-
depth knowledge of the specific domain of the system under development.
Designing: Without a proper design, a system implementation becomes too
complex and the dependencies within the system become too numerous and it
becomes very difficult to comprehend the solution.
Feedback: It espouses the wisdom: “A system staying isolated from the scrutiny of
the
users is trouble waiting to happen”. It recognizes the importance of user feedback
in
understanding the exact customer requirements.
Simplicity: A corner-stone of XP is the principle: “build something simple that will
work today, rather than trying to build something that would take time and yet may
never be used”.
Applicability of extreme programming model
Project for development using extreme programming model:
Projects involving new technology or research projects: In this case, the
requirements
change rapidly and unforeseen technical problems are often needed to be resolved.
Small projects: Extreme programming was proposed in the context of small
teams, as
face-to-face communication is easier to achieve in this situation.
Project characteristics not suited to development using agile models
The following are some of the project characteristics that indicate unsuitability of
agile
development model for use in a development project:
 Stable requirements: Conventional development models are more suited
to use in
projects characterised by stable requirements. For such projects, it is known that
almost no changes to the gathered requirements will occur.
 Mission critical or safety critical systems: In the development of such
systems, the
traditional SDLC models are usually preferred to ensure the required reliability.
2.4.4 Scrum
Scrum is one of the agile development models. In the scrum model, the entire
project work
is divided into small work parts that can incrementally be developed and delivered
over
time boxes. These time boxes are called sprints.
At the end of each sprint, the stakeholders and the team members meet to assess
the developed software increment. The stakeholders may suggest any changes and
improvements to the developed software that they might feel necessary.
Key roles and responsibilities
In the scrum model, the team members assume three basic roles: product owner,
scrum master, and team member.
 Product owner: The product owner represents the customer’s perspective
and guides
the team toward building the right software.
 Scrum master: The scrum master acts as the project manager for the
project. The
responsibilities of the scrum master include removing any impediments that the
project may face, and ensuring that the team is fully productive by fostering close
cooperation among the team members.
 Team member: A scrum team usually consists of cross-functional team
members with
expertise in areas such as quality assurance, programming, user interface design,
and
testing.
Artifacts
Three main artifacts form an important part of the scrum methodology. These are:
product
backlog, sprint backlog, and sprint burndown chart.
 Product backlog: This document at any time during development contains
a
prioritized listing of all the features that are yet to be developed. In this document,
the features of the software are usually written in the form of user stories.
 Sprint backlog: Before every sprint, a sprint planning meeting takes place.
During a
sprint planning meeting, the team identifies one or more features (user stories)
from
the product backlog and decides on the tasks that would be needed to be
undertaken
for the development of the identified features and this forms the sprint backlog.
 Sprint burndown chart: During a sprint, the sprint burndown chart is used
as a tool
to visualize the progress made and the work remaining to be undertaken on a daily
basis. At the end of a team meeting called the daily stand-up meeting, the scrum
master determines the work completed in the previous day and the list of work that
remains to be completed and represents these in the sprint burndown chart.

Scrum ceremonies
The term scrum ceremonies is used to denote the meetings that are mandatorily
held during
the duration of a project. The scrum ceremonies include three different types of
meetings:
sprint planning, daily scrum, and sprint review meeting.
  Sprint planning: During the sprint planning meeting, the team members
commit
to develop and deliver certain features in the ensuing sprint, out of those listed in
the product backlog.
 Daily scrum: The daily scrum is a short stand-up meeting conducted during
every
day morning to review the status of the progress achieved so far and the major
issues
being faced on a day-to-day basis. The daily scrum meeting is not a problem-solving
meeting, rather each member updates the teammates about what he/she has
achieved
in the previous day.
 Sprint review meeting: At the end of each sprint, a sprint review is
conducted.
In this meeting, the team demonstrates the new functionality developed during
the sprint that was just completed to the product owner and to the stakeholders.
2.4.5 Lean Software Development
The origin of the Lean software development process can be traced to the Lean
process
that was developed in a car manufacturing industry (Toyota production system). It
was
soon found to be an effective product development process that holds significant
benefits. It
soon became widely accepted and found use in many other types of product
manufacturing
industries. The central theme of Lean is to achieve overall process efficiency
through
elimination of various things that cause waste of work and introduce delays. Kanban
methodology was developed as a part of the Lean approach to visualize the work fl
ow.
Lean methodology in software development
Lean methodology was adopted for use in the software development projects and
has since gained significant popularity. In software development projects, it has
been found effective in reducing delays and bottlenecks by minimizing waste.
Kanban
Kanban is a Japanese word meaning a sign board. The main objective of Kanban is
to
provide visibility to the workflow. This in turn is expected to help debottleneck
congestions
in the process and minimize delays.
Kanban board and Kanban card
A principal artifact of the Kanban approach is the Kanban board. A Kanban board is
typically a white board on which sticky notes called Kanban cards are attached.
Kanban
cards represent the work items that are waiting for completion at different
development
stages.

The Kanban board provides visibility to the software process. It shows work
assigned to each developer at any time and the work fl ow. It, therefore, becomes
possible to define and communicate the priorities and the bottlenecks get
highlighted. The average time it takes to complete
a work item (sometimes called the cycle time) is tracked and optimized so that the
process becomes efficient and predictable. The Kanban system, therefore, helps to
limit the amount of work in process so that the work flowing through the system
matches its full capacity.
2.5 SPIRAL MODEL
This model gets its name from the appearance of its diagrammatic representation
that looks like a spiral with many loops (see Figure 2.12). The exact number of loops
of the spiral is not fixed and can vary from project to project.Each loop of the spiral
is called a phase of the software process. The exact number of phases through
which the product is developed can be varied by the project manager depending
upon the project risks.
2.5.1 Phases of the Spiral Model
Each phase in this model is split into four sectors (or quadrants) as shown in Figure
2.12. In
the first quadrant, a few features of the software are identified to be taken up for
immediate
development based on how crucial it is to the overall software development
Quadrant 1: The objectives are investigated, elaborated, and analysed. Based on
this, the
risks involved in meeting the phase objectives are identified. In this quadrant,
alternative
solutions possible for the phase under consideration are proposed.
Quadrant 2: During the second quadrant, the alternative solutions are evaluated
to select
the best possible solution. To be able to do this, the solutions are evaluated by
developing
an appropriate prototype.
Quadrant 3: Activities during the third quadrant consist of developing and
verifying the
next level of the software. At the end of the third quadrant, the identified features
have
been implemented and the next version of the software is available.
Quadrant 4: Activities during the fourth quadrant concern reviewing the results of
the stages traversed so far with the customer and planning the next iteration of the
spiral.
Advantages/pros and disadvantages/cons of the spiral model
Advantages of the Spiral Model
Below are some advantages of the Spiral Model.
1. Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development
model to follow due to the risk analysis and risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large
and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at a
later phase can be incorporated accurately by using this model.
4. Customer Satisfaction: Customers can see the development of the product
at the early phase of the software development and thus, they habituated
with the system by using it before completion of the total product.
5. Iterative and Incremental Approach: The Spiral Model provides an
iterative and incremental approach to software development, allowing for
flexibility and adaptability in response to changing requirements or
unexpected events.
6. Emphasis on Risk Management: The Spiral Model places a strong
emphasis on risk management, which helps to minimize the impact of
uncertainty and risk on the software development process.
7. Improved Communication: The Spiral Model provides for regular
evaluations and reviews, which can improve communication between the
customer and the development team.
8. Improved Quality: The Spiral Model allows for multiple iterations of the
software development process, which can result in improved software quality
and reliability.
Disadvantages of the Spiral Model
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of
the project is very much dependent on Risk Analysis. Without very highly
experienced experts, it is going to be a failure to develop a project using this
model.
4. Difficulty in time management: As the number of phases is unknown at
the start of the project, time estimation is very difficult.
5. Complexity: The Spiral Model can be complex, as it involves multiple
iterations of the software development process.
6. Time-Consuming: The Spiral Model can be time-consuming, as it requires
multiple evaluations and reviews.
7. Resource Intensive: The Spiral Model can be resource-intensive, as it
requires a significant investment in planning, risk analysis, and evaluations.