Software Engineering

Unit 1
Evolving Role of Software and
vulnerability
• Failures and over budget rates are High
• Success
• Cost of hardware and software is decreased by the time
• Manager and Technical Persons asked:
• Why are costs so high?
• Why can not we find all errors before release?
• Why do we have difficulty in measuring progress of software development?
Software Crisis
1. Early software development was ‘personalized’.
2. As sophistication of application grew, programs grew in size and
complexity.
3. Maintenance became difficult.
4. Software projects were taking a lot longer than originally calculated.
5. Software was costing a lot more to develop than initially estimated.
6. Software was being delivered to the customer only to fail.
7. Error found by the customer were extremely difficult to trace and fix.
Software Failure Examples

• OLD Days
• Y2K Problem
• Windows XP in October 25, 2001
• Any countless modern day problems we come across….
Pfizer vaccine rollout delays
In 2023, the rollout of the Pfizer COVID-19 vaccine was delayed in several countries due to a
software glitch. The glitch prevented the company from properly tracking the distribution of the
vaccine, which led to concerns about the safety and efficacy of the vaccine.
Tesla Autopilot crashes
In 2023, there have been a number of high-profile crashes involving Tesla vehicles that were
using the Autopilot feature. In some of these crashes, the Autopilot feature failed to detect
obstacles and crashed into other vehicles or pedestrians.
Southwest Airlines Flight cancellations
In December 2022, Southwest Airlines experienced a series of flight cancellations that
affected thousands of passengers. The cancellations were caused by a software glitch that
prevented the airline from properly scheduling flights. The glitch was not discovered until after
the cancellations had already begun.
• https://www.linkedin.com/pulse/most-recent-major-qa-failures-qaiser-abbas/
 Software
• It consists of programs, set of documentations and the procedures used to setup and
operate the software system
• Software = Programs + Documentation + Operating Procedures.

Programs

Documentation Operating
Procedures

Program is a subset of software.

Program = Source Code + Object Code
Documentation Manuals
Operating Procedures
 Engineering
• Engineering is the process of designing and building something that serves a
particular purpose and finds a cost-effective solution to problems.

• Engineering is the science, skill, and profession of acquiring and applying

scientific, economic, social, and practical knowledge, in order to design and
also build structures, machines, devices, systems, materials and processes.

• Manufacturing is the production of goods for use or sale using labor and
machines, tools, chemical and biological processing, or formulation.
 Software Engineering

• Software engineering is an engineering discipline which is concerned with all aspects

of software production

• Software engineers should

• adopt a systematic and organized approach to their work

• use appropriate tools and techniques depending on

• the problem to be solved,

• the development constraints and

• use the resources available

 Software Engineering

According to IEEE -
The application of systematic, disciplined and quantifiable approach to
the development, operation, and maintenance of software; that is, the
application of engineering to software.
According to Boehm -
The practical application of scientific knowledge in the design and
construction of computer programs and the associated documentation
required to develop, operate, and maintain them.
 Software Engineering
- Engineering uses methods, procedures, tools, and standards
- Methods give the different steps you have to take project planning and
estimation, Requirements analysis, Design, Algorithm development,
Coding, Testing, Maintenance.
- Tools provide automated support for the methods – CASE Tools, Coding
Tools, Testing Tools
- Procedure defines the sequence in which the methods are to be executed
Software Engineering Today
Software Characteristics

1. Software does not wear out – Like hardware

Burn-In Wear Out Phase

Phase Useful Life Phase

Failure
Intensity

Time

Bathtub Curve
Software Characteristics

Software may be retired due to

environmental changes , new
requirements, new expectations

Failure
Intensity

Time

Software curve
 Software Characteristics

2. Software is not manufactured –

The life of a software is from concept exploration to the retirement of
the software product.
It is one time development effort and continues maintenance effort in
order to keep it operational.
Making 1000 copies is not an issue and it does not involve any cost.
In case of hardware products, every product costs us due to raw
material and other processing expenses.

Hence it is not manufactured in the classical sense.

 Software Characteristics

3. Software is logical rather than physical.

4. Reusability of components.
5. Software is flexible.
6. Most software is custom built, rather than being assembled from
existing components.
 Software Myths
Management Myths-
Myth – We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they need to
know?
Reality – The BOOK very well exists,
• but is it used?
• Are the practitioners aware of its existence?
• Is it complete?
• Is it adaptable?

In many cases the answer to all is no.

 Software Myths

Myth – If we get behind schedule, we can add more programmers and catch up.
Reality – S/W development is not a mechanistic process like manufacturing.
• Adding people to a late s/w project makes it later .
• spend time educating the newcomers, there by reducing the amount of time spent on
productive development effort.
• People can be added but only in a planned and well coordinated manner.
 Software Myths
Myth – If I decide to outsource the s/w project to a 3rd party, I can just relax
and let that firm build it.
Reality If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it outsource s/w
projects.
 Software Myths
Customer myths –
Myth – A general statement of objectives is sufficient to begin writing
programs – we can fill in the details later.
• A formal and detailed description of the information domain, function,
behaviour, performance, interfaces, design constraints, and validation
criteria is essential.
• These characteristics can be determined only after thorough
communication between customer and developer.
Software Myths
Myth: Project requirements continually change, but change can be easily accommodated
because software is flexible.
• Reality:
• Impact of change varies with the time at which it is introduced.
• Early requests for change can be accommodated easily.
• The sooner changes are requested by the customer, the cheaper
they are to make.
• The later it becomes , more is the impact on budget,time and
resources.
 Software Myths
Practitioner’s Myth –
Myth – Once we write the program and get it to work, our job is done.
Reality – Someone once said that the sooner you begin writing code, the
longer it will take to get done.

Industry data indicate that between 60 to 80% of all effort expended

on s/w will be expanded after it is delivered to the customer for the
first time.
 Software Myths
Myth – Until I get the program running, I have no way of accessing its
quality
Reality - One of the most effective software quality assurance mechanisms
can be applied from the inception of a project— the formal technical review
Myth – The only deliverable work product for a successful project is the
working program.
Reality - working program is only one part of a software configuration that
includes many elements. Documentation provides a foundation for
successful engineering and, more important, guidance for software support.
 Software Myths
Myth – SE will make us create voluminous and unnecessary documentation
and will invariably slows us down.
Reality –
SE is not about creating documents.
It is about crating quality.
Better quality leads to reduced rework.
And reduced rework results in faster delivery times.
Software Process
 (Webster) A system of operations in producing something; a series of actions, changes, or functions
that achieve an end or a result
 (IEEE) A sequence of steps performed for a given purpose

According to Pressman
 Software engineering process is the glue that holds the technology layers
together and enables rational and timely development of computer software.
 Process defines a framework for a set of key process areas that must be
established for effective delivery of software engineering technology.
 The key process areas form the basis for management control of software
projects and establish the context in which technical methods are applied, work
product (models, documents, data, reports, forms, etc.) are produced,
milestones are established, quality is ensured, and change is properly managed.
Software Process
• A common process framework is established by defining a small number of framework
activities that are applicable to all software projects, regardless of their size or complexity.
• Several task sets—each a collection of software engineering
• work tasks,
• project milestones,
• work products, and
• quality assurance points—
• Enable the framework activities to be adapted to the characteristics of the software
project and the requirements of the project team.
• Umbrella activities—such as software quality assurance, software configuration
management, and measurement—overlap the process model. Umbrella activities are
independent of any one framework activity and occur throughout the process.
 Difference between Software
Engineering and Traditional

Engineering
Software is intangible
 Software doesn’t degrade with time as hardware does. Software failures are
caused by design and implementation error, not by degradation over time
• In classical engineering disciplines, the engineer is equipped with tools and the
mathematical maturity to specify the properties of the product separately from
those of design. The typical software engineering relies much more on
experience and judgment rather than mathematical formula.
Difference between Software
Engineering and Traditional
Engineering
 Software quality
• Conformance to
• explicitly stated functional and

• performance requirements,

• explicitly documented development standards, and

• implicit characteristics

• that are expected of all professionally developed software.

McCall’s quality factors
• Two levels of software quality factors:
• Factors that can be directly measured (bugs or defects)
• Factors that can be measured only indirectly (usability or maintainability)
• Both sets can (and should) be measured
McCall’s quality factors
• McCall, Richards, and Walters group these factors into three
categories, focused on three aspects of a software product:
• Its operational characteristics
(PRODUCT OPERATION)
• Its ability to undergo change
(PRODUCT REVISION)
• Its adaptability to new environments
(PRODUCT TRANSITION)
McCall’s quality factors
 Product Operation
• It includes five software quality factors, which are related with the
requirements that directly affect the operation of the software such as
operational performance, convenience, ease of usage and its correctness.
These factors help in providing a better user experience.
• Correctness:
• the extent to which a program satisfies its specifications and fulfills the customer’s
mission objectives
• Reliability:
• The extent to which a software performs its intended functions without failure.
• Usability:
• The extent of effort required to learn, operate and understand the functions of the
software.
Product Operation (cont.)
• Integrity:
• the extent to which access to software or data by unauthorized persons can
be controlled
• Efficiency:
• The amount of hardware resources and code the software, needs to perform
a function.
 Product Revision
It includes three software quality factors, which are required for testing and
maintenance of the software. They provide ease of maintenance, flexibility and
testing effort to support the software to be functional according to the needs
and requirements of the user in the future.
• Maintainability:
• The effort required to detect and correct an error during maintenance phase.
• Flexibility:
• the effort required to modify an operational program
• Testability:

• The effort required to verify a software to ensure that it meets the specified
requirements.
 Software Development Life Cycle

• SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) is a systematic process

for building software that ensures the quality and correctness of the
software built.
• Life Cycle model take care of the order of activities performed on a
software product from its inception to retirement.
• Different life cycle models may map the basic development activities
to phases in different ways.
• Basic activities are included in all life cycle models though the activities
may be carried out in different orders in different life cycle models.
• During any life cycle phase, more than one activity may also be carried
out.
 Need of SDLC
• Development of software product in a systematic and disciplined
manner

• Clear understanding among team members about when and what to

do

• Each phase defines entry and exit criteria for every phase.
Phases of SDLC
Requirement
Analysis

Maintenance Design

Deployment Coding

Testing
Software Development Life Cycle (SDLC):Requirement Analysis

• Relevant information is collected from the customer to

develop a product
• Any ambiguities must be resolved in this phase only.
• Business analyst and Project Manager lookout
What the customer wants to build
Who will be the end-user
What is the purpose of the product
• Analysis is done to check the feasibility of the
development of a product.
• Once the requirement is clearly understood, the SRS
(Software Requirement Specification) document is
created.
Software Development Life Cycle
(SDLC): Design
• This stage involves the design of the entire system and its elements.
• There are two kinds of design
• High-level design
• Low-level design
• According to their definitions,
• A high-level design (HLD) is the overall plan of the system
• A Low-level design (LLD) is a design of its components.
• Failure at this phase certainly result cost overruns and total collapse at
worst.
• The system and software design documents (SDD) are prepared as per the
requirement specification document.
• There are two kinds of design documents developed in this phase
Software Development Life Cycle (SDLC):Design
 High-Level Design (HLD)
o Brief description and name of each module
o An outline about the functionality of every module
o Interface relationship and dependencies between modules
o Database tables identified along with their key elements
o Complete architecture diagrams along with technology details
 Low-Level Design(LLD)
o Functional logic of the modules
o Database tables, which include type and size
o Complete detail of the interface
o Addresses all types of dependency issues
o Listing of error messages
o Complete input and outputs for every module
Software Development Life Cycle
(SDLC):Coding
• Once the system design phase is over, the next phase is coding.
• In this stage of SDLC the actual development starts, and the product is
built.
• In the coding phase, tasks are divided into units or modules and assigned
to the various developers for writing codes as per the chosen
programming language.
• It is one of the longest phase of the Software Development Life Cycle
process.
 Software Development Life Cycle (SDLC): Testing

• Testing starts once the coding is complete and the modules are released
for testing.
• In this phase, the developed software is tested thoroughly, and any defects
found are assigned to developers to get them fixed.
• During this phase, QA and testing team may find some bugs/defects which
they communicate to developers.
• The development team fixes the bug and send back to QA for a re-test.
• This process continues until the software is bug-free, stable, and working
according to the business needs of that system.
Software Development Life Cycle (SDLC):
Deployment
• At this stage, the goal is to DEPLOY THE SOFTWARE.
• When the software is completed and has no bugs, it is shipped to the
market for beta testing.
• The support team collects feedback of the first users, and if any bugs
come up, the development team fixes them. After that, the final version
is rolled out.
Software Development Life Cycle
(SDLC):Maintenance
• Once the software system is deployed, and customers start using the
developed system, following 3 activities occur:
 Bug fixing - bugs are reported because of some scenarios which are
not tested at all
 Upgrade - Upgrading the application to the newer versions of the
Software
 Enhancement - Adding some new features into the existing software
Importance of SDLC

• It provides visibility for the engaged parties

• It allows to control the project
• Predictable deliveries throughout an entire development
process
• Eliminating risks like going over budget or deadline breach
• The process goes on until all the requirements are met
 SDLC Models
• There are various software development life cycle models defined and
designed which are followed during software development process.
• Each process model follows a Series of steps unique to its type, in order to
ensure success in process of software development.

• Following are the popular conventional SDLC models

1. SDLC: Waterfall Model
2. SDLC: Prototype Model
3. SDLC: Spiral Model
4. SDLC: Evolutionary Development Models
5. SDLC: Iterative Enhancement Models.
 Waterfall Model
• The classical waterfall model is intuitively the most obvious
way to develop software.
• Though the classical waterfall model is elegant and
intuitively obvious, it is not a practical model in the sense
that it cannot be used in actual software development
projects.
Theoretical way of developing software.
• But all other life cycle models are essentially derived from
the classical waterfall model.
• To be able to appreciate other life cycle models it is
necessary to learn the classical waterfall model.
Waterfall Model
• Classical waterfall model divides the life cycle into a set of phases.
• One phase can be started after completion of the previous phase.
• Output of one phase will be the input to the next phase.
• Development process can be considered as a sequential flow in the
waterfall.
• Phases do not overlap with each other.
• All these phases are
cascaded to each other in
which progress is seen as
flowing steadily
downwards (like a
waterfall) through the
phases.
• The next phase is started
only after the defined set of
goals are achieved for
previous phase and it is
signed off, so the name
"Waterfall Model".
 Activities undertaken during Feasibility Study

• At the time of feasibility study PROJECT MANAGERS OR TEAM LEADERS have a rough
understanding that what is to be done.
• This is done based on different input and output data to be produced by the system.
• It is studied and processing is needed to be done on these data.
• After overall understanding, different possible solutions are
investigated in terms of resources required, cost of development,
development time.
• Based on this analysis they pick the best solution and determine whether the solution is
feasible financially and technically.
• VERIFIES whether the customer budget would meet the cost of the product and whether
they have sufficient technical expertise in the area of development.
Activities undertaken during Requirement 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
i. Requirements gathering and analysis
ii. Requirements specification

• The goal of the requirements gathering activity is to collect all relevant

information from the customer regarding the product to be developed.

• This is done to clearly understand the customer requirements so that

incompleteness and inconsistencies are removed.
Activities undertaken during Requirement Analysis
and specification
• The requirements analysis activity is begun by collecting all relevant
data regarding the product to be developed from the users of the
product and from the customer through interviews and
discussions.
• After all ambiguities, inconsistencies, and incompleteness have been
resolved and all the requirements properly understood, the
requirements specification activity can start.
• During this activity, the user requirements are systematically
organized into a Software Requirements Specification (SRS)
document.
 Activities undertaken during 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 approaches are available: the traditional design
approach and the object-oriented design approach.
Activities undertaken during Coding and Unit Testing

• The purpose of the coding and unit testing phase (sometimes called the
implementation phase) of software development is to translate the
software design into source code.
• Each component of the design is implemented as a program module.
• The end-product of this phase is a set of program modules that have
been individually tested.
• During this phase, each module is unit tested to determine the correct
working of all the individual modules.
• It involves testing each module in isolation as this is the most efficient
way to debug the errors identified at this stage.
 Activities undertaken during Integration And System Testing

• Integration of different modules is undertaken once they have been

coded and unit tested.
• During the integration and system testing phase, the modules are
integrated in a planned manner.
• The different modules making up a software product are almost never
integrated in one shot.
• Finally, when all the modules have been successfully integrated and
tested, SYSTEM TESTING is carried out.
• The goal of system testing is to ensure that the Developed System
Conforms To Its Requirements Laid Out In The SRS Document.
• System testing usually consists of three different kinds of testing
activities:
• α – testing: It is the system testing performed by the development
team.
• β – testing: It is the system testing performed by a friendly set of
customers.
 Activities undertaken during Maintenance

• Maintenance involves performing any one or more of the following three

kinds of activities:
• Correcting errors that were not discovered during the product
development phase. This is called corrective maintenance.
• Improving the implementation of the system and enhancing the
functionalities of the system according to the customer’s
requirements. This is called perfective maintenance.
• 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. This is called
adaptive maintenance.
 Waterfall Model Application
• Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are:

 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
 Pros & Cons of Waterfall Model

Pros Cons

Simple and easy to understand and use No working software is produced until late during the life cycle.

Easy to manage due to the rigidity of the model. Each phase has
High amounts of risk and uncertainty.
specific deliverables and a review process.

Phases are processed and completed one at a time. Not a good model for complex and object-oriented projects.

Works well for smaller projects where requirements are very well
Poor model for long and ongoing projects.
understood.

Not suitable for the projects where requirements are at a moderate

Clearly defined stages. to high risk of changing. So risk and uncertainty is high with this
process model.

Well understood milestones. It is difficult to measure progress within stages.

Easy to arrange tasks. Cannot accommodate changing requirements.

Process and results are well documented. Adjusting scope during the life cycle can end a project.

Integration is done as a "big-bang. at the very end, which doesn't

allow identifying any technological or business bottleneck or
challenges early.
 Prototype Model
• The Prototyping model is suitable for projects, which either the customer
requirements or the technical solutions are not well understood.
• This risks must be identified before the project starts. This model is especially
popular for the development of the user interface part of the project.
• In this process model, the system is partially implemented before or during the
analysis phase thereby giving the customers an opportunity to see the product early
in the life cycle.
• The process starts by interviewing the customers and developing the incomplete
high-level paper model.
• This document is used to build the initial prototype supporting only the basic
functionality as desired by the customer.
• Once the customer figures out the problems, the prototype is further refined to
eliminate them.
• The process continues till the user approves the prototype and finds the working
model to be satisfactory.
Prototype Model
• This is a valuable mechanism for gaining better understanding of the
customer’s needs:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs
• The developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, the form that the human-
machine interaction should take etc.
 Build Prototype

Requirements Customer Evaluation ofCustomer satisfied

Gathering Prototype
Quick Design Design

Refine Requirements Implement

Test

Maintain
 Prototype Model
 Basic Requirement Identification: This step involves understanding the very basics
product requirements especially in terms of user interface. The more intricate details of
the internal design and external aspects like performance and security can be ignored
at this stage.
 Developing the initial Prototype: Initial Prototype is developed, very basic requirements
are show cased and user interfaces are provided. Features may not exactly work in the
same manner internally in the actual software developed and the workarounds are
used to give the same look and feel to the customer in the prototype developed.
 Review of the Prototype: The prototype developed is then presented to the customer and
the other important stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in the product under
development.
Prototype Model
 Revise and enhance the Prototype:
 The feedback and the review comments are discussed during this stage and some
negotiations happen with the customer based on factors like, time and budget constraints
and technical feasibility of actual implementation.
 The changes accepted are again incorporated in the new Prototype developed and the cycle
repeats until customer expectations are met.
Prototype Model: Advantages
• The customers get to see the partial product early in the
life cycle. This ensures a greater level of customer
satisfaction and comfort.
• New requirements can be easily accommodated as
there is scope for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot
of effort and cost, besides enhancing the quality of the
software.
• The developed prototype can be reused by the
developer for more complicated projects in the future.
• Flexibility in design.
 Prototype Model: Disadvantages

• Costly w.r.t time as well as money.

• There may be too much variation in requirements each time the
prototype is evaluated by the customer.
• Poor Documentation due to continuously changing customer
requirements.
• It is very difficult for the developers to accommodate all the
changes demanded by the customer.
• There is uncertainty in determining the number of iterations that
would be required before the prototype is finally accepted by the
customer.
• After seeing an early prototype, the customers sometimes demand
the actual product to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-
optimal solutions.
• The customer might lose interest in the product if he/she is not
 Spiral Model
• Spiral model is one of the most important Software
Development Life Cycle models, which provides support for Risk
Handling.
• In its diagrammatic representation, it looks like a spiral with
many loops. The exact number of loops of the spiral is unknown
and can vary from project to project.
• Each loop of the spiral is called a PHASE of the software
development process.
• The exact number of phases needed to develop the product can
be varied by the project manager depending upon the project
risks.
• As the project manager dynamically determines the number of
phases, so the project manager has an important role to
develop a product using spiral model.
• The Radius of the spiral at any point represents the
 Spiral Model

Each phase of Spiral Model is divided into four quadrants as shown in the above
figure. The functions of these four quadrants are discussed below-
1.Objectives determination and identify alternative solutions: Requirements are
gathered from the customers and the objectives are identified, elaborated and
analyzed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.
2.Identify and resolve Risks: During the second quadrant all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that
solution is identified and the risks are resolved using the best possible strategy. At
the end of this quadrant, Prototype is built for the best possible solution.
3.Develop next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third
quadrant, the next version of the software is available.
4.Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate
the so far developed version of the software. In the end, planning for the next phase
is started.
 Spiral Model

• The most important feature of the spiral model is handling these

unknown risks after the project has started.
• Provides the scope to build a prototype at every phase of the software
development.
• Prototyping Model also support risk handling, but the risks must be
identified completely before the start of the development work of the
project.
• In each phase of the Spiral Model, the features of the product are worked
out and analyzed and the risks at that point of time are identified and are
resolved through prototyping.
• This model is much more flexible compared to other SDLC models.
 Spiral Model as Meta Model

• The Spiral model is called as a Meta Model because it

subsumes all the other SDLC models. For example, a
single loop spiral represents the Iterative Waterfall Model.
• The spiral model incorporates the stepwise approach of
the Classical Waterfall Model.
• The spiral model uses the approach of Prototyping
Model by building a prototype at the start of each phase
as a risk handling technique.
 Spiral Model: Advantages
• 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.
• Good for large projects: It is recommended to use the
Spiral Model in large and complex projects.
• Flexibility in Requirements: Change requests in the
Requirements at later phase can be incorporated
accurately by using this model.
• Customer Satisfaction: Customer 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.
 Spiral Model: Disadvantages
• Complex: The Spiral Model is much more complex than other SDLC
models.
• Expensive: Spiral Model is not suitable for small projects as it is
expensive.
• Too much dependable on Risk Analysis: The successful completion of
the project is very much dependent on Risk Analysis. Without very
highly experienced expertise, it is going to be a failure to develop a
project using this model.
• Difficulty in time management: As the number of phases is unknown at
the start of the project, so time estimation is very difficult.
 Iterative Enhancement Model

•In Iterative model, iterative process starts with a simple implementation of

a small set of the software requirements and iteratively enhances the
evolving versions until the complete system is implemented and ready to
be deployed.
• An iterative life cycle model does not attempt to start with a full
specification of requirements.
•Instead, development begins by specifying and implementing just part of
the software, which is then reviewed in order to identify further
requirements.
•This process is then repeated, producing a new version of the software at
the end of each iteration of the model.
 Iterative Model design
• The basic idea behind this method is to develop a
system through repeated cycles (iterative) and in
smaller portions at a time (incremental).
 Advantages of Iterative Enhancement Model

• Adaptation to changing requirements is made possible by its flexibility in

accomodating modifications and improvement during each iteration.
• Early software iterations provide clients with functional portions of the
product, facilitating prompt feedback and validation.
• Problems and risks can be identified and addressed early in the
developement process, reduces chances of issue for future stages.
• Feedback and constant client involvement are encouraged to make sure the
finished product lives up to user expectations.
• Every iteration is put through testing and improvement, leading to higher
quality product.
 Iterative Model Application

• Requirements of the complete system are clearly defined and understood.

 Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team while
working on the project.
 Resources with needed skill set are not available and are planned to be used on
contract basis for specific iterations.
 There are some high-risk features and goals which may change in the future.
Disadvantages of Iterative Enhancement Model

• Especially in larger projects, managing several iterations at once can

add complexity.
• Higher cost
• Due to constant changes, there may be delays in documentation,
making it more difficult to maintain comprehensive documentation.
• Continuous customer engagement may not be possible in all
scenarios, which impacts the effectiveness of the model.
 Evolutionary Model

• Evolutionary model is Delivering your system in a big bang release, delivering it in

incremental process over time is the action done in this model.
• Starts with Some initial requirements and architecture.
• It is better for software products that have their feature sets redefined during
development because of user feedback and other factors.
• Divides the development cycle into smaller, incremental waterfall models in which users
are able to get access to the product at the end of each cycle.
• Feedback is provided by the users on the product for the planning stage of the next cycle
and the development team responds, often by changing the product, plan or process.
• SOFTWARE PRODUCT EVOLVES WITH TIME.

• All the models have the disadvantage that the duration of time from start of the project
to the delivery time of a solution is very high. Evolutionary model solves this problem in a
different approach.
Evolutionary Model
• Evolutionary model suggests breaking down of work into smaller chunks, prioritizing
them and then delivering those chunks to the customer one by one.
• The number of chunks is huge and is the number of deliveries made to the
customer.
• The main advantage is that the customer’s confidence increases as he constantly
gets quantifiable goods or services from the beginning of the project to verify and
validate his requirements.
• The model allows for changing requirements as well as all work in broken down into
maintainable work chunks.

Specification Initial version

Outline
description Intermediate
Development
versions

Validation Final version

Application of Evolutionary
Model:
• It is used in large projects where you can easily find modules for
incremental implementation.
• Evolutionary model is commonly used when the customer wants to
start using the core features instead of waiting for the full software.
• Evolutionary model is also used in object-oriented software
development because the system can be easily portioned into units in
terms of objects.
Advantages and Disadvantages
• Advantages:
• In evolutionary model, a user gets a chance to experiment
partially developed system.
• It reduces the error because the core modules get tested
thoroughly.
• Disadvantages:
• Sometimes it is hard to divide the problem into several
versions that would be acceptable to the customer which
can be incrementally implemented and delivered.