Software Engineering is the application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software.

What is software engineering?

• A popular definition of software engineering is: “A systematic collection of good program
development practices and techniques”.
• Good program development techniques have resulted from research innovations as well as from
the lessons learnt by programmers through years of programming experiences.
• An alternative definition of software engineering is: “An engineering approach to develop software”.

Is software engineering a science or an art?

• Several people hold the opinion that writing a good quality programs is an art.
• let us examine whether the software engineering is really a form of art or is it similar to other
engineering disciplines.
• Just as any other engineering discipline, software engineering makes heavy use of the knowledge
that occurred from the experiences of a large number of practitioners.
• These past experiences have been systematically organised and used wherever possible.
• As usual in all engineering disciplines, in software engineering several conflicting goals are
encountered while solving a problem.
• In such situations, several alternate solutions are first proposed. Then an appropriate solution is
chosen out of them, based on various conditions such as cost, maintainability, and usability.
Therefore, while arriving at the final solution, several iterations and back tracking are usually
needed.
• In science, only unique solutions are possible. Engineering disciplines such as software engineering
make use of only well understood and well-documented principles.
• Art is often based on making subjective judgement based on qualitative attributes and using
ill-understood principles.
• From the above discussions, we can easily infer that software engineering is like other engineering
disciplines such as civil engineering or electronics engineering.

1.1 EVOLUTION—FROM AN ART FORM TO AN ENGINEERING DISCIPLINE

In this section, we review how starting from an esoteric(ambiguous/confused) art form, the software
engineering discipline has evolved over the years.

1.1.1 Evolution of an Art into an Engineering Discipline

• Software engineering principles have evolved over the last sixty years with contributions from
numerous researchers and software professionals. Over the years, it has emerged from a pure art to
a craft, and finally to an engineering discipline.
• The early programmers used an ad hoc programming style. This style of program development is
being referred 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 of rules or
recommendations that a programmer has to follow.
• In a build and fix or code and fix style, a program is quickly developed without making any plan,
design and specifications. The different imperfections that are subsequently noticed are fixed later.
• Every programmer himself evolves his own software development techniques solely guided by his
own intuition, experience, whims, and fancies.
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.
• 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 been shown in below Figure 1.1. It can be seen from the
Figure 1.1, that every technology in the initial years starts as a form of art. Over time, it graduates
to a craft and finally emerges as an engineering discipline.

• In the early days of programming, there were good programmers and bad programmers. The good
programmers knew certain principles (or tricks) that helped them to write good programs, which
they seldom shared with the bad programmers.
• Program writing in later years was similar 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
emerging at a very rapid rate, making this discipline highly dynamic.
• Software engineering practices have proven to be indispensable (very essential/very necessary) to
the development of large software products, though exploratory styles are often used successfully to
develop small programs such as programs written by students as classroom assignments.
1.1.3 A Solution to the Software Crisis
• software engineering appears to be one of the option available to tackle the present software crisis.
• organisations are spending increasingly larger portions of their budget on software compared to
hardware. Among all the symptoms of the present software crisis, the trend of increasing software
costs is probably the most vexing.

• In early days, when you bought any hardware product, the essential software that ran on it can
came free with it.
• At present, many organisations are spending much more on software than on hardware. If this trend
continues, we might soon have an amusing scenario, like in future when you buy any software
product the hardware on which the software runs would come free with the software!!!
• There are many factors, which causes the software crisis, the important factors are
i) rapidly increasing problem size
ii) lack of adequate training in software engineering techniques
iii) increasing skill shortage, and low productivity improvements.
• What is the remedy? It is believed that a satisfactory solution to the present software crisis is to
spread the software engineering practices among the developers, coupled with further
advancements to the software engineering discipline itself.
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

Programs:
• Many toy software’s 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. Further, the author of a program
is usually the sole user of the software and himself maintains the code.
• These toy software’s therefore usually lack good user-interface and proper documentation. Besides
these may have poor maintainability, efficiency, and reliability.
• These toy softwares do not have any supporting documents such as users’ manual, maintenance
manual, design document, test documents, etc.,
• we call these toy softwares as programs.

Products:
• professional software usually have multiple users and, therefore, have good user-interface, proper
users’ manuals, and good documentation support.
• A software product has a large number of users, so it is systematically designed, carefully
implemented, and thoroughly tested.
• A professionally written software usually consists not only the program code but also all the
associated documents such as requirements specification document, design document, test
document, users’ manuals, etc.
• A further difference is that professional software is often too large and complex to be developed by
any single individual. It is usually developed by a group of developers working in a team.

Even though software engineering principles are primarily intended for use in development of professional
software, many results of software engineering can effectively be used for development of small programs
as well. However, when developing small programs for personal use, rigid adherence to software
engineering principles is often not worthwhile.
1.2.2 Types of Software Development Projects
A software development company 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

Software product development projects:

Generic software product development projects:

• When a software development company wishes to develop a generic product, it first determines the
features or functionalities that would be useful to the large number of users.
• The development team draws up the product specification on its own, based on the feedback
collected from a large number of users.
• Typically, each software product is developed to target some 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.
• For example, Microsoft targets desktops and laptops through its Windows 8 operating system,
while it targets high-end mobile handsets through its Windows mobile operating system, and
targets servers through its Windows server operating system.

Domain specific software product development projects:

• 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.
• Examples of domain specific software products are FINACLE from Infosys in the banking domain and
AspenPlus from Aspen Corporation in the chemical process simulation.
Software services projects:
• Software services cover a large number of software projects such as customization, outsourcing,
maintenance of the software.
• At present, there is a rapid growth in these type of software projects

Customization projects:
• In this type of service projects, already existed software programs can be modified to quickly fulfil
the specific requirements of any customer.
• At present, hardly no one is developing the software project from scratch by writing the program
code, and mostly they are developing the softwares by customizing some existing softwares.
• For example, to develop a software to automate the payroll generation activities of an educational
institute, the vendor may customize an existing software that might been developed earlier for a
different client or educational institute.
• Due to heavy reuse of code, now it has become possible to develop the large software systems in a
short period of time.

Maintenance projects:
• In this type of service projects, the tech support is provided to the deployed projects.
• Software Maintenance refers to the process of modifying and updating a software system after it
has been delivered to the customer.
• This involves fixing bugs, adding new features, and adapting to new hardware or software
environments.
• Effective maintenance is crucial for extending the software’s lifespan and aligning it with evolving
user needs.

Outsourced projects:
• 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. For example, a company might consider the
outsourcing option, if it feels that it does not have sufficient experts to develop some specific parts
of the software; or it may determine that some parts can be developed cost-effectively by another
company.
• Since an outsourced project is a small part of some larger project, outsourced projects are usually
small in size and need to be completed within a few months or a few weeks of time.

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.
• Generic product development entails certain amount of business risk. A company needs to invest
upfront and there is a substantial risk concerning whether the investments would turn profitable are
not. Possibly, the Indian companies were risk averse.
• Of late, the Indian companies have slowly started to focus on product development as well.
1.3 EXPLORATORY STYLE OF SOFTWARE DEVELOPMENT
• We have already discussed that the 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.
• 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?

• No software team can remain competitive if it uses the exploratory style of software development.
• Let us examine how do the effort and time required to develop a professional software increases
with the increase in program size.
• The increase in development effort and time with problem size has been indicated in Figure 1.5.
 • Observe the thick solid line plot in Figure 1.5 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 much
time and cost 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.
• For example, using the exploratory style, you may easily solve a problem that requires writing only
1000 or 2000 lines of source code. But, if you are asked to solve a problem that would require
writing one million lines of source code, you may never be able to complete it using the exploratory
style.
• 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, observe the dotted line plot in Figure 1.5 if programs could be written
automatically by machines, then the increase in effort and time with size would be even closer to a
linear increase with size.
• Now let us try to understand why does the effort required to develop a program grow exponentially
with program size and why does the program is completely break down when the program size
becomes large? To get an insight into the answer to this question, we need to have some knowledge
of the human cognitive limitations.

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 needs more time and effort to develop a large programming
solution.
• Psychologists say that the human memory can be thought to consist of two distinct parts 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

• The block labelled sensory organs represents the five human senses sight, hearing, touch, smell, and
taste.
• The block labelled neuromotor organs represents the hands, fingers, feet, etc.
 We now elaborate this human cognition model as
1) Short-term memory
2) Long-term memory
3) Item
4) Evidence of short-term memory
5) The magical number 7
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).
• It should be clear that the short-term memory plays a very crucial part in the human cognition
mechanism. All information collected through the sensory organs are first stored in the short-term
memory and used by the brain to drive the neuromotor organs.
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?
• Items present in the short-term memory can get stored in the long-term memory either through
large number of refreshments (repetitions) or by forming links with already existing items in the
long-term memory.
• For example, you possibly remember your own telephone number because you might have repeated
(refreshed) it for a large number of times in your short-term memory.
Item:
• An item is any set of related information. According to this definition, a character such as ‘a’ or a
digit such as ‘5’ can each be considered as an item. A word, a sentence, a story, or even a picture can
each be a single item. Each item normally occupies one place in memory.
• The phenomenon of forming one item from several items is referred to as chunking by psychologists.
For example, if you are given the binary number 110010101001—it may prove very hard for you to
understand and remember.
• But, the octal form of the number 6251 (i.e., the representation (110)(010)(101)(001)) may be much
easier to understand and remember since we have managed to create chunks of three items each.
Evidence of short-term memory:
• Evidences of short-term memory manifest themselves in many of our day-to-day experiences. As an
example of the short-term memory, consider the following situation. Suppose, you look up a number
from the telephone directory and start dialling it. If you find the number to be busy, you would dial
the number again after a few seconds—in this case, you would be able to do so almost effortlessly
without having to look up the directory. But, after several hours or days since you dialled the number
last, you may not remember the number at all, and would need to consult the directory again.
The magical number 7:
• Miller called the number seven as the magical number, 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.
So, he can easily understand it. As the number of items that one has to deal with increases beyond
seven, it becomes exceedingly difficult to understand it.
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:

1) abstraction
2) decomposition

Abstraction:
• Abstraction is a technique to solve the complexity of the computer systems.
• Abstraction means displaying only the essential information and hiding the details. It works by
establishing a level of simplicity on which a person interacts with the system, suppressing the more
complex details below the current level.
• Data abstraction refers to providing only essential information about the data to the outside world,
hiding the background details or implementation. Consider a real-life example of a man driving a car
only knows how to drive the car, not about working mechanism of the car.

Decomposition:
• It is another important principle that is available in software engineer to handle the 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.
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 and documentation would result in highly unstructured and poor-
quality code, so if there is any changes, maintenance of the code becomes very difficult.
• It becomes very difficult to use the exploratory style in a team development environment. Most
softwares mandate huge development efforts, necessitating team effort for developing large
softwares. Team development is indispensable (very essential/ very necessary) for developing
modern software.
• It becomes very difficult to partition the work among a set of developers who can work concurrently.

1.4 EMERGENCE OF SOFTWARE ENGINEERING (Evolution of software design techniques)

• We have already pointed out that software engineering techniques have evolved over many years in
the past.
• This evolution is the result of a series of innovations and accumulation of experience about writing
good quality programs.
• let us briefly examine a few of these innovations and programming experiences which have
contributed to the development of the software engineering discipline.
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. Program lengths were typically limited to
about a few hundreds of lines of monolithic assembly code. Every programmer developed his own
individualistic style of writing programs according to his intuition and used ad hoc style.

2. High-level Language Programming: Computers became faster with the introduction of 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. This considerably reduced the effort required to develop software and helped programmers to
write larger programs. Writing each high-level programming construct in effect enables the programmer to
write several machine instructions. However, the programmers were still using the exploratory style of
software development.

3. Control Flow-based Design: 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 flowcharting technique was developed. Even today, the flowcharting technique is
being used to represent and design algorithms.

4. Data Structure-oriented Design: Computers became even more powerful with the advent of Integrated
Circuits (ICs) in the early 1970s. These could now be used to solve more complex problems. Software
developers were tasked to develop larger and more complicated software. Which often required writing in
excess of several tens of thousands of lines of source code. 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.
Example: Jackson’s Structured Programming (JSP) technique developed by Michael Jackson (1975). In
JSP methodology, a program’s data structure is first designed using the notations for sequence, selection,
and iteration. The JSP methodology provides an interesting technique to derive the program structure from
its data structure representation.

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, 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 Data Flow-Oriented Design techniques
were proposed. The functions are also called as processes and the data items that are exchanged between
the different functions are represented in a diagram is known as a Data Flow Diagram (DFD).

6. Object-oriented Design: Object-oriented design technique is an intuitively appealing approach, where the
natural objects (such as employees, 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 is also known as data abstraction. Object-oriented techniques have gained widespread
acceptance because of their simplicity, the scope for code and design reuse, promise of lower development
time, lower development cost, more robust code, and easier maintenance. let us examine what are the
current challenges in designing software.1) program sizes are further increasing as compared to what was
being developed a decade back.2) many of the present day software are required to work in a client-server
environment through a web browser-based access(called web-based software).
1.5 NOTABLE CHANGES IN SOFTWARE DEVELOPMENT PRACTICES
• Before we discuss the details of various software engineering principles, it is worthwhile to examine
the differences between an exploratory style of software development and modern software
engineering practices.
exploratory style of software development modern software engineering practices
the exploratory software development style software engineering techniques are based
is based on error correction (build and fix) on the principles of error prevention.
software engineering principles
is the realisation that it is much more cost-effective to
prevent errors from occurring
than to correct them as and when they are detected.
In the exploratory style, coding was In the modern software development style, coding is
considered synonymous with software regarded as only a small part of
development. For instance, this naive way the overall software development activities. There are
of developing a software believed in several development activities
developing a working system as quickly as such as design and testing which may demand much
possible and then successively modifying more effort than coding.
it until it performed satisfactorily
No requirements phase 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.
No design phase there is a distinct design phase where standard design
techniques are employed
to yield coherent and complete design models
No Periodic reviews 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.
No testing phase software testing has become very systematic and
standard testing techniques
are available. Testing activity has also become all
encompassing, as test cases are
being developed right from the requirements
specification stage.
No phase activities There is better visibility of the software through various
developmental activities.
No planning phase projects are being thoroughly planned. The primary
objective of project
planning is to ensure that the various development
activities take place at the
correct time and no activity is halted due to the want
of some resource.
No metrics are used Several metrics of the products and the product
development activities are being collected to help in
software project management
and software quality assurance.
1.6 COMPUTER SYSTEMS ENGINEERING: different stages of computer system engineering are:
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 contains several activities such as collection of basic information relating to the
software such as data to be input, how the input data processed, outputs produced from the
processed data, as well as various constraints on the development.
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.
Hardware software partitioning:
• 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.

Hardware and software development:

• After the hardware-software partitioning stage, development of hardware and software are carried
out concurrently (shown as concurrent branches in Figure 1.14).
Integration and testing:
• In system engineering, testing the software during development becomes a tricky issue, To test the
software during development, it usually becomes necessary to develop simulators that mimic the
features of the hardware being developed. The software is tested using these simulators. Once both
hardware and software development are complete, these are integrated and tested.
Maintenance:
• Software Maintenance refers to the process of modifying and updating a software system after it
has been delivered to the customer. This involves fixing bugs, adding new features, and adapting to
new hardware or software environments.
The project management activity is required throughout the duration of system development as shown in
Figure 1.14.
1.7 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).
• The stage where the customer feels a need for the software and forms rough ideas about the
required features is known as the inception stage.
• Starting with the inception stage, a software evolves through a series of identifiable stages (also
called phases) on account of the development activities carried out by the developers, until it is fully
developed and released to the customers.
• Once installed and made available for use, the users start to use the software. This signals the start
of the operation (also called maintenance) phase.
• As the users use the software, they request for fixing any failures that they might be encountered
and suggest several improvements and modifications to the software.
• Thus, the maintenance phase usually involves continually making changes to the software to
accommodate the bug-fix and change requests from the user.
• Finally, the software is retired, when the users do not find it any longer useful due to reasons such as
availability of some new software with improved features and more efficient working
Software development life cycle (SDLC) model

• A software development life cycle (SDLC) model (also called software life cycle model (SLCM) and
software development process model (SDPM)) describes the different activities that need to be
carried out for the software to evolve in its life cycle.
• A development process may not only describe various activities that are carried out over the life
cycle but also prescribe a specific methodology to carry out the activities and also recommends the
specific documents and other artifacts(tasks) that should be produced at the end of each phase.
Process versus methodology

Activity Process Methodology

The software process is a set of steps or a set of activities that are It is a way to solve a particular problem
Definition
used during the development of software. in a structured way.

A Process consists of all the steps from the start to the completion Its focus is more on the particular
Focus
of the project that are needed during the development. phase during the development.

The methodology is predefined, so it

There are different types of processes available and can be used
Flexibility has low scope for changes in the
according to the requirements of the user.
predefined methodology.

An example of a software process is SDLC(Software Development examples of methodology are agile,

Example
Life cycle). waterfall, spiral
Why use a development process?

• The primary advantage of using a development process is that it encourages development of

software in a systematic and disciplined manner.
• When software is developed by a team rather than by an individual programmer, life cycle model
must be used for the successful completion of the project.
• Software development organisations have realised that selection of suitable life cycle model helps to
produce good quality software and helps to minimise the chances of time and cost overruns.
• Programming-in-the-small refers to the 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.
Why document a development process?

• It is not enough for an organisation to just have a well-defined development process, but the
development process needs to be properly documented.
• We have identified a few important problems that may crop up when a development process is not
adequately documented.
• Those problems are as follows:
1. A documented process model ensures that every activity in the life cycle is accurately
defined. Without proper documentation, the activities and their ordering tend to be loosely
defined, this may lead to confusion and misinterpretation.
2. It is easier to tailor a documented process model, when it is required to modify certain
activities or phases of the life cycle.
3. A documented process model, as we discuss later, is a mandatory requirement of the modern
quality assurance standards such as ISO 9000 and SEI CMM, otherwise it would not qualify
for accreditation by any of the quality certifying agencies.
4. In the absence of a quality certification for the organisation, the customers would be
suspicious of its capability of developing a quality software and the organisation might find
it difficult to win tenders for software development.
Phase entry and exit criteria

• A good SDLC besides clearly identifying the different phases in the life cycle.
• A good SDLC model should unambiguously define the entry and exit criteria for each phase.
• The phase entry or exit criteria is usually expressed as a set of conditions that needs to be satisfied
for the phase to start (or) phase to complete).
• When the phase entry and exit criteria are not well-defined, it becomes very difficult for the project
manager to determine the exact status of the development and track the progress of the project.
• This usually leads to a problem that is usually identified as the 99 per cent complete syndrome.
1.8 WATERFALL MODEL AND ITS EXTENSIONS
1. Classical Waterfall Model
2. Iterative Waterfall Model
3. V-Model
4. Prototyping Model
5. Incremental Development Model
6. Evolutionary Model

1.8.1. Classical Waterfall Model

• The waterfall model is possibly the most obvious and intuitive way in which software can be
developed through team effort.
• We can think of the waterfall model as a generic model that has been extended in many ways for
catering to specific software development situations.
• The classical waterfall model divides the life cycle into six phases as shown in Figure 2.1

Phases of the classical waterfall model

The different phases of the classical waterfall model are:
1. feasibility study,
2. requirements analysis and specification,
3. design,
4. coding and unit testing,
5. integration and system testing,
6. maintenance
 • The phases starting from the feasibility study to the integration and system testing phase are known
as the development phases.
• The last phase is known as the maintenance phase.
• In the waterfall model, different life cycle phases typically require relatively different amounts of
efforts to be put in by the development team.
• The relative amounts of effort spent on different phases for a typical software has been shown in
Figure 2.2.

• Observe the Figure that among all the life cycle phases, the maintenance phase normally requires
the maximum effort, on average 60 percent of the total effort is spent on the maintenance phase.
• Next, 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 contains several activities such as collection of basic information relating to the
software such as data to be input, how the input data processed, outputs produced from the
processed data, as well as various constraints on the development.
• These collected data are analysed to perform the following:
1. Development of an overall understanding of the problem: we need to understand the details of
various requirements of the customer, such as the screen layouts, graphical user interface (GUI),
and algorithm’s
2. Formulation of various possible strategies for solving the problem: In this activity, various
possible high-level solution schemes to the problem are determined.
3. Evaluation of the different solution strategies: The different identified solution schemes are
analysed to evaluate their benefits and shortcomings. Such evaluation often requires making
approximate estimates of the resources required, cost of development, and development time
required. The different solutions are compared, and the best solution is finalised. Once the best
solution is identified, all activities in the later phases are carried out as per this solution.
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:
1. requirements gathering and analysis.
2. requirements specification.
Requirements gathering and analysis:

• The goal of the requirement’s 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.
• The goal of the requirements analysis activity is to weed out the incompleteness and
inconsistencies in these gathered requirements.
Requirements specification:
• After the requirement gathering and analysis activities are complete, the identified
requirements are documented. This document is called as a software requirements
specification (SRS) document.
• The SRS document is written using end-user terminology. This makes the SRS document
understandable to the customer. Therefore, understandability of the SRS document is an
important issue.
• The SRS document normally serves as a contract between the development team and the
customer. Any future dispute between the customer and the developers can be settled by
examining the SRS document.
• The SRS document is an important document which must be thoroughly understood by the
development team and reviewed jointly with the customer.
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 different design approaches are popularly being used, they are
1. procedural design approach.
2. object-oriented design approach.
Procedural design approach:

• The traditional procedural design approach is in use in many software development projects
at the present time.
• This traditional design technique is based on data flow modelling.
• It consists of two important activities:
1. Structured analysis: During structured analysis, the functional requirements specified in
the SRS document are decomposed into subfunctions and the dataflow among these
subfunctions is analysed and represented diagrammatically in the form of DFDs.
2. Structured design: Structured design consists of two main activities: architectural design
(also called high-level design) and detailed design (also called Low-level design). High-
level design involves decomposing the system into modules and representing the
 interfaces and the invocation relationships among the modules. During the detailed
design activity, internals of the individual modules such as the data structures and
algorithms of the modules are designed and documented.
Object-oriented design approach:

• First identify various objects (real world entities) occurring in the problem.
• Identify the relationships among the objects. For example, the objects in a pay-roll software
may be employees, managers, pay-roll register, Departments, etc.
• 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 called as the implementation phase, since the design is implemented into a
workable solution in this phase.
• Each component of the design is implemented as a program module.
• The main object of this phase is a set of program modules that have been developed are individually
unit tested and determined that they are working correctly and the modules must be documented.
Integration and system testing
• Integration of different modules is undertaken soon after they have been coded and unit tested.
• During the integration and system testing phase, the different modules are integrated in a planned
manner. Various modules making up a software are almost never integrated in one shot.
• Integration of various modules are normally carried out incrementally over a number of steps.
During each integration step, previously planned modules are added to the partially integrated
system and the resultant system is tested.
• Finally, after all the modules have been successfully integrated and tested, the full working system is
obtained. System testing is carried out on this fully working system.
• System testing usually consists of three different kinds of testing activities:
1. a-testing: a testing is the system testing performed by the development team.
2. b-testing: This is the system testing performed by a friendly set of customers.
3. 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
• The total effort spent on maintenance of a typical software during its operation phase is usually far
greater than that required for developing the software itself. Many studies confirm this and indicate
that the ratio of the total effort spent on its maintenance is roughly 40:60.
• 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.
Disadvantages (Shortcomings) of the classical waterfall model: The classical waterfall model is a very
simple and intuitive model. However, it suffers from several shortcomings. Let us identify some of the
important shortcomings of the classical waterfall model.

• No feedback paths: In classical waterfall model, the evolution of a software from one phase to the
next is analogous to a waterfall. Just as water in a waterfall after having flowed down cannot flow
back, once a phase is complete, the activities carried out in it and any artifacts produced in this
phase are final and are closed for any rework.
• Difficult to accommodate change requests: The customers’ requirements may keep on changing
with time. But, in this model it becomes difficult to accommodate any requirement change requests
made by the customer after the requirements specification phase is completed.
• Inefficient error corrections: This model defers integration of code and testing tasks until it is very
late when the problems are harder to resolve.
• No overlapping of phases: This model recommends that the phases must be carried out sequentially
new phase can start only after the completion of previous phase.
Is the classical waterfall model useful at all?

• We have already pointed out that it is hard to use the classical waterfall model in real projects.
• In any practical development environment, as the software takes shape, several iterations through
the different waterfall stages become necessary for correction of errors committed during various
phases.
• Therefore, the classical waterfall model is hardly usable for software development. But, as
suggested by Parnas [1972] the final documents for the product should be written as if the product
was developed using a pure classical waterfall.

1.8.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 feedback paths allow for correcting errors committed by a programmer during some phase, as
and when these are detected in a later phase.
• Please notice that there is no feedback path to the feasibility stage. This is because once a team
accepts to take up a project, it does not give up the project easily due to legal and moral reasons.
Shortcomings of the iterative waterfall model
Difficult to accommodate change requests
Incremental delivery not supported
Phase overlap not supported
Error correction unduly expensive
Limited customer interactions
Heavy documentation
No support for risk handling and reuse

Concepts of phase containment and phase overlap:

Phase containment of errors

• No matter how careful a programmer may be, he might end up committing some mistake or other
while carrying out a life cycle activity. These mistakes result in errors (also called faults or bugs) in
the work product.
• It is advantageous to detect the errors in the same phase in which they take place, since early
detection of bugs reduces the effort and time required for correcting those errors.
Phase overlap

• 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. Some members may complete their part of the work earlier
than other members. If strict phase transitions are maintained, then the team members who
complete their work early would idle waiting for the phase to be complete and are said to be in a
blocking state. Thus, the developers who complete early would idle while waiting for their team
mates to complete their assigned work. Clearly this is a cause for wastage of resources and a source
of cost escalation and inefficiency. As a result, in real projects, the phases are allowed to overlap.
That is, once a developer completes his work assignment for a phase, proceeds to start the work for
the next phase, without waiting for all his team members to complete their respective work
allocations.
1.8.3 V-Model

The V-model can basically be divided into three phases.

1)verification phase: the requirements are recorded and converted into a system analysis. These
requirements become increasingly specific according to the top-down principle and represent the left-hand
side of the V-model.

• The verification phase comprises several levels. These levels are interdependent, i.e. if a change is
made at a higher level, something will also change at the levels below.
• An important step in the verification phase is gathering the requirements. requirements must be
analysed in detail and clearly defined.
• In the system analysis step, it is clarified whether it is possible to achieve all these requirements.
• A design is developed for the entire system and, depending on the type of project, possible graphic
designs are also developed.
• The verification phase ends with the module design. This is the lowest level at which it is determined
how the functions will be implemented in your product.
2)the coding phase: In the coding phase, the product is programmed, and the software is created.
3)validation phase: the bottom-up principle is applied and tested. This is the right-hand side of the V. You
start with the tests at unit level and work your way up to the tests at acceptance level.

• We are now on the right-hand side of the V. The tests found on this side always correspond to the
level on the left-hand side of the V. therefore They are opposite each other in the diagram.
• The unit test is at the lowest level. This is where the individual components are analysed.
• This is followed by the integration test. This checks that the modules work together and that the
data exchange between the components works smoothly.
• The system test is the latest point at which the customer is also involved, and several test runs of the
entire system are carried out.
• Last phase is known as acceptance, Users should be invited to take part in the test in order to obtain
a test result that is as realistic as possible. With the last phase, the software development is finished
according to the V-model.
Advantages of V-model
The important advantages of the V-model over the iterative waterfall model are as following:

• In the V-model, much of the testing activities (test case design, test planning, etc.) are carried out in
parallel with the development activities.
• 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. This leads to more
efficient manpower utilisation.
• In the V-model, the test team is associated with the project from the beginning. Therefore they build
up a good understanding of the development artifacts, and this in turn, helps them to carry out
effective testing of the software.
Disadvantages of V-model

• Being a derivative of the classical waterfall model, this model inherits most of the weaknesses of the
waterfall model.

Difference between V-model and Waterfall model

Aspect Waterfall model V-model

Waterfall model is a sequential execution It is also a sequential execution

Execution Process process. process.

Testing Activities In Waterfall model testing activities start In V-model testing activities start
Start after the development activities are over. with the first stage.

Guarantee of success through Waterfall Guarantee of success through V-

Success Guarantee model is low. model is high.

Testing during It is not possible to test a software during its There is possibility to test a
Development development. software during its development.

Identification of Identification of defects is done in the Identification of defects can be

Defects testing phase. done from the beginning.

Debugging can be done in

Debugging is done after the last phase.
Debugging between phases.

Waterfall model is less used now-a-days in V-model is widely used in software

Usage software engineering. engineering.
1.8.4 Prototyping Model
• The prototyping model can be considered as an extension of the waterfall model.
• This model suggests building a working prototype of the system, before development of the actual
software. 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.
Life cycle activities of prototyping model
The prototyping model of software development is graphically shown in Figure 2.6. As shown in Figure 2.6,
software is developed through two major activities—prototype development 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.
Advantages of prototype 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.
• The prototyping model is especially useful when the exact technical solutions are unclear to the
development team.
• An important reason for developing a prototype is that it is impossible to “get it right” the first time.
• 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.
Disadvantages of the prototype model:

• The prototype model can increase the cost of the project development.
• The prototyping model is ineffective for risks identified later during the development cycle.

1.8.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 the incremental 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 develop the core features of the system.
• Once the initial core features are developed, these are refined into increasing levels of capability by
adding new functionalities in successive versions.
• Each incremental version is usually developed using an iterative waterfall model of development.
The incremental model is schematically shown in Figure 2.8.
• 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
• 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 of incremental model

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.
Incremental resource deployment: This model saves the developing organisation from deploying large
resources and manpower for a project in one go.
1.8.6 Evolutionary Model
• This model has many features of the incremental model and iterative model.
• In simple words, “Iterative model” + “Incremental model” = Evolutionary model.
• 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 is prepared.
• But, in evolutionary model, the requirements, plan, estimates, and solution evolve over the
iterations, rather than fully defined.
• Due to obvious reasons, 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.
• When the new version of the product is released, it includes the new functionality and some changes
in the existing product, which are also released with the latest version.
• This model also permits the developer to change the requirements, and the developer can divide the
process into different manageable work modules.
• The development team must have to respond to customer feedback throughout the development
process by frequently altering the product, strategy, or process.
• A schematic representation of the evolutionary model of development has been shown in Figure 2.9.
Advantages of the evolutionary model:
Effective elicitation of actual customer requirements: In this model, the user gets a chance to experiment
with a partially developed software. Therefore, the evolutionary model helps to accurately elicit user
requirements with the help of feedback obtained on the delivery of different versions of the software.
Easy handling of change requests: In this model, the change requests of the customer is handled easily.

Disadvantages of the evolutionary model:

Feature division into incremental parts can be non-trivial: For many development projects, especially for
small-sized projects, it is difficult to divide the requirements into several parts.
Requirement of Constant Feedback: The continuous user feedback can be a double-edged sword. It requires
the constant engagement with users or stakeholders, which can be challenging if they are not available.

Differences between the Evolutionary model and incremental model.

Feature Incremental Model Evolutionary Model

Focus Delivering a complete system by adding features Delivering a core version and
incrementally evolving it based on user
feedback

Requirements Defined upfront, it means that, the development Evolve based on feedback
activities start only after the completion of
requirements specification.

Scope Fixed, with minor deviations possible Flexible and evolves based on
feedback

Deliverables Each increment is a working version of the system Each stage builds upon the
previous one
1.9 RAPID APPLICATION DEVELOPMENT (RAD)
The major goals of the RAD model are as follows:
1) To decrease the time taken and the cost incurred to develop software systems.
2) To limit the costs of accommodating change requests.
3) To reduce the communication gap between the customer and the developers.

• The critical feature of this model is the use of powerful development tools and techniques.
• A software project is broken down into small modules wherein each module can be assigned
independently to separate teams.
• The development team always includes a customer representative to clarify the requirements and to
reduce the communication gap between the customer and the developers.
• Multiple teams work parallelly on developing the software system using the RAD model.
• These modules can finally be combined to form the final product.
• Development of each module involves the various basic steps as in the waterfall model i.e.
requirements analysing, designing, coding, and then testing, etc. as shown in the above figure.
• Another striking feature of this model is a short period i.e. the time frame for delivery(time-box) is
generally 60-90 days.
• This process involves building a rapid prototype, delivering it to the customer, and take the feedback
from the customer. After validation by the customer, the SRS document is developed, and the design
is finalized.
• This model has the features of both prototyping and evolutionary models.
• It deploys an evolutionary 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 customers usually suggest changes to a specific feature, only after they have used it. Since the
features are delivered in small increments.
• The decrease in development time and cost, and at the same time an increased flexibility to
incorporate changes are achieved in the RAD model in two ways—minimal use of planning and
heavy reuse of any existing code through rapid prototyping.
• RAD model emphasises code reuse as an important mechanism for completing a project faster and
to reduce the development cost.

Advantages of RAD:
Customised software: As already pointed out a customised software is developed for the customers 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. Naturally, for projects with
very aggressive time schedules, RAD model should be preferred.
Large software: Only for software supporting many features (large software) can incremental development
and delivery be meaningfully carried out.

Disadvantages of RAD:
Generic products (wide distribution): software products are generic in nature and usually have wide
distribution. For such systems, optimal performance and reliability are more important in a competitive
market. The RAD model of development may not yield systems having optimal performance and reliability.

Requirement of optimal performance and/or reliability: For certain categories of products, optimal
performance or reliability is required. Examples of such systems include an operating system (high reliability
required) and a flight simulator software (high performance required). If such systems are to be developed
using the RAD model, the desired product performance and reliability may not be realised.
Lack of similar products: If a company has not developed similar software, then it is not possible to reuse
the existing artifacts, and the use of RAD model becomes meaningless.
Monolithic entity: For certain software, especially small-sized software, it may be hard to divide the
required features into small parts that can be incrementally developed and delivered. In this case, it
becomes difficult to develop a software incrementally.
1.10 AGILE DEVELOPMENT MODELS
• The agile model could help a project to adapt to change requests quickly.
• Thus, a major aim of the agile model is to facilitate quick project completion. It gaves the required
flexibility so that the activities that may not be necessary for a specific project could be easily
removed. Also, anything that wastes time and effort is avoided.
• Please note that agile model is being used as an umbrella term to refer to a group of development
processes. While these processes share certain common characteristics, yet they do have certain
subtle differences among themselves.
• A few popular agile SDLC models are the following:
1) Crystal
2) Atern (formerly DSDM)
3) Feature-driven development
4) Scrum
5) Extreme programming (XP)
6) Lean software development
7) Unified process
• In an agile model, the requirements are decomposed into many small parts that can be
incrementally developed.
• The agile models adopt an incremental and iterative approach. Each incremental part is developed
over an iteration. Each iteration is intended to be small and easily manageable and lasts for a couple
of weeks only. At a time, only one increment is planned, developed, and then deployed.
• The time to complete an iteration is called a time box. The implication of the term time box is that
the end date for an iteration does not change. Does not exceed the scheduled time. central principle
of the agile model is, delivery of an increment to the customer after each time box.
• 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.
• Agile models emphasise use of face-to-face communication in preference over written documents. It
is recommended that the development team size be kept small (5-9 people). This would help the
team members to meaningfully engage in face-to-face communication and lead to a collaborative
work environment.
1.11 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. The number
of loops shown in Figure 2.12 is just an example.
• 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.
• A prominent feature of the spiral model is handling unforeseen risks that can show up after the
project has started.
Phases of the Spiral Model
In this model each phase is splited 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. With each iteration around the spiral (beginning at
the center and moving outwards), progressively more complete versions of the software get built.
Quadrant 1: The objectives are investigated, elaborated, and analysed. Based on this, the risks involved in
meeting the phase objectives are identified.
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: 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 (i.e. the developed version of the software) with the customer and plan the next iteration of the spiral.

Advantage: For projects having many unknown risks that might show up after the development proceeds,
the spiral model would be the most appropriate development model to follow.
Disadvantage: It is very difficult to use, unless there are knowledgeable and experienced staff in the project.
Also, it is not suitable for the development of outsourced projects.
Difference between various SDLC Models

Aspect Waterfall Iterative Spiral Agile V-Models Incremental

Developmen
Sequential Iterative Iterative Iterative Iterative Iterative
t Approach

Planning,
Planning, Planning, Planning, Divided into
Design,
Risk Sprint, Design, increments,
Coding,
Analysis, Review, Implementation each with
Linear Testing,
Engineering Retrospectiv , Testing, Planning,
Evaluation
, Testing e (Iterative Deployment Implementation
(Repeated
(Cyclical) Cycles) (Parallel) , Testing
Phases Iteratively)

Flexibility Low High High High Moderate High

Risk
Continuous Continuous
Late Proactive risk management Proactive risk
risk risk
mitigation, management aligned with management,
assessment, assessment,
Risk Limited , Adaptability phases, Adaptability to
Proactive Adaptability
Managemen adaptability to changes Moderate changes
mitigation to changes
t adaptability

Time-to-
Longer Faster Variable Faster Moderate Faster
Market

User
Limited Continuous Periodic Continuous Periodic Continuous
Involvement

After Continuous Integrated Continuous

Continuous After
Implementatio throughout throughout throughout
and c Implementation
Testing n iterations the spiral increments

Adaptability Low High High High Moderate High

Linear Easier to
Cyclical Adaptive Adaptive
Complexity approach, manage, Traceability
approach, approach to approach to
Managemen Limited Adaptability helps manage c
Risk-d changes changes
t adaptability to changes
Explain When to use which SDLC models?

Consideration Waterfall Iterative Spiral Agile V-Models Incremental

Small to Medium to Small to Medium to

Large Small to Large
Project Size Medium Large Medium Large

Project Low to Medium to Medium to Medium to

High Low to High
Complexity Medium High High High

Likely to Stable to
Moderate
Requirements Stable Can evolve Can evolve change Moderate
stability
Stability frequently Stability

Client High and

Limited Continuous Periodic Periodic Continuous
Involvement Continuous

Moderate Variable, Moderate

High Moderate
Predictability, Some Suitable for Predictability,
Predictability, Predictability,
Budget Some Flexibility Changing Some
Fixed Budget Fixed Budget
Constraints Flexibility Budgets Flexibility

Moderate to
Low Moderate High Moderate Moderate
Risk Tolerance High

Time-to-
Moderate Faster Variable Faster Moderate Faster
Market

Extensive Moderate Detailed Minimal Moderate Moderate

Documentatio Documentatio Documentatio Documentatio Documentatio Documentatio Documentatio
n Emphasis n n n n n n

Testing
Sequential Continuous Continuous Continuous Continuous
Conducted
Testing after Testing Testing and Testing
After the
Development Throughout Throughout Collaborative Throughout
Testing Completion of
Phases Iterations the Spiral Testing Increments
Approach Phases

Highly
Limited High Adaptive to Moderate High
Change Adaptive to
Flexibility Flexibility Changes Flexibility Flexibility
Management Changes