UNIT – I

Difference between Program and Product

Aspect Program Product

Program
contains a
set of
Nature and Product is the final manufacture
instructions
Purpose and production of the project.
designed to
complete a
specific task.

It is a passive
entity as it It is an active entity as it is made
Entity Type resides in the again and again for the purpose
secondary of distribution to users.
memory.

It exists at a A product can exist for a long

single place period of time as long as it is
and tested for better performance
Existence
continues to and durability. A specific software
exist until it product would stop existing if it is
is deleted. destroyed or uninstalled.

Developme It can be It needs a lot of time to be made.

nt Time made in There are several stages (design,
Aspect Program Product

relatively
shorter coding, testing, maintenance etc.
period of ) to form a product.
time.

It is handled
Managemen by the It is handled by product
t program managers.
managers.

It does not
have any
resource
requirement,
Resource
it only It needs human, technology and
Requiremen
requires time resources to be functional.
ts
memory
space for
storing the
instructions.

The main
focus of the
program is
The main focus of a product is its
whether it is
Focus capability to solve the problem
giving a
that it was made for.
specific
desired
output or not.
Aspect Program Product

There are no
concrete
In case of product, the firm
Guidelines guidelines in
guidelines are followed.
writing a
program.

It may or
It needs to worry about the cost
may not
Efficiency and efficiency as it would affect
focus on
and Cost the profitability of the enterprise
efficiency
launching the product.
and cost.

Iterative Waterfall Model

The Iterative Waterfall Model is a software development approach that
combines the sequential steps of the traditional Waterfall Model with the
flexibility of iterative design.

It allows for improvements and changes to be made at each stage of

the development process, instead of waiting until the end of the project.

The Iterative Waterfall Model provides feedback paths from every

phase to its preceding phases, which is the main difference from the
classical Waterfall Model.

1. When errors are detected at some later phase, these feedback paths
allow for correcting errors committed by programmers during some
phase.

2. The feedback paths allow the phase to be reworked in which errors are
committed and these changes are reflected in the later phases.
 3. Although the feasibility study phase doesn’t usually get frequent
feedback, the iterative nature of this model allows for revisiting and
updating it if new requirements or changes in technology come up
later. This helps keep the project aligned with its goals throughout
development.

4. It is good to detect errors in the same phase in which they are

committed.

5. It reduces the effort and time required to correct the errors.

6. A real-life example could be building a new website for a small

business.

Process of Iterative Waterfall Model

Following are the phases of Iterative Waterfall Model:

Iterative Waterfall Model

 1. Requirements Gathering: This is the first stage where the business
owners and developers meet to discuss the goals and requirements of
the website.

2. Design: In this stage, the developers create a preliminary design of

the website based on the requirements gathered in stage 1.

3. Implementation: In this stage, the developers begin to build the

website based on the design created in stage 2.

4. Testing: Once the website has been built, it is tested to ensure that it
meets the requirements and functions properly.

5. Deployment: The website is then deployed and made live to the

public.

6. Review and Improvement: After the website has been live for a
while, the business owners and developers review its performance and
make any necessary improvements.

This process is repeated until the website meets the needs and goals of the
business. Each iteration builds upon the previous one, allowing for
continuous improvement and iteration until the final product is complete.

When to use Iterative Waterfall Model?

1. The prerequisite of being well-defined and comprehended.

2. The development team is gaining knowledge about new technologies.

3. Certain characteristics and objectives carry a significant chance of

failure in the future.

Application of Iterative Waterfall Model

Below are some applications of Iterative Waterfall Model:

1. The essential needs are established, but as time passes, the finer
points may become relevant.

2. Programmers have a learning curve to climb when they utilize new

technology.

3. The resources needed to complete a large project are constrained,

hence on a smaller scale, the automation is more temporary.

4. Very high risk as the project's objective may occasionally alter.

Why is iterative waterfall model used?

The main reason behind using iterative waterfall model is feedback path.
While the feedback loop in the iterative waterfall model primarily focuses on
later phases, it’s still possible to revisit the feasibility study if changes in
requirements or technology emerge, ensuring the project stays aligned with
its goals.

Advantages of Iterative Waterfall Model

Following is the advantage of Iterative Waterfall Model:

1. Phase Containment of Errors: Errors are detected and fixed as close

to their source as possible, reducing costly rework and delays.

2. Collaboration: Continuous collaboration between business owners

and developers ensures the product meets business needs and
improves with feedback at each iteration.

3. Flexibility: The model allows for easy incorporation of new

requirements or features in subsequent iterations, ensuring the
product evolves with the business.

4. Testing and Feedback: Regular testing and feedback cycles help

identify and fix issues early, improving the product's quality and
relevance.

5. Faster Time to Market: Incremental development allows parts of the

product to be delivered sooner, enabling user feedback while further
improvements are made.

6. Risk Reduction: Continuous feedback and testing help identify risks

early, reducing the likelihood of costly errors and delays.

Drawbacks of Iterative Waterfall Model

Following is the disadvantage of Iterative Waterfall Model:

1. Difficult to incorporate change requests: The major drawback of

the iterative waterfall model is that all the requirements must be
clearly stated before starting the development phase. Customers may
change requirements after some time but the iterative waterfall model
does not leave any scope to incorporate change requests that are
made after the development phase starts.
 2. Incremental delivery not supported: In the iterative waterfall
model, the full software is completely developed and tested before
delivery to the customer. There is no scope for any intermediate
delivery. So, customers have to wait a long for getting the software.

3. Overlapping of phases not supported: Iterative waterfall model

assumes that one phase can start after completion of the previous
phase, But in real projects, phases may overlap to reduce the effort
and time needed to complete the project.

4. Risk handling not supported: Projects may suffer from various

types of risks. But, the Iterative waterfall model has no mechanism for
risk handling.

5. Limited customer interactions: Customer interaction occurs at the

start of the project at the time of requirement gathering and at project
completion at the time of software delivery. These fewer interactions
with the customers may lead to many problems as the finally
developed software may differ from the customers' actual
requirements.

Prototyping Model
 The prototype model is also a popular life cycle model.
 The prototyping model can be considered to be an extension of the
waterfall model.
 This model suggests building a working prototype of the system,
before development of the actual software.
  A prototype is a toy and crude implementation of a system. It has
limited functional capabilities, low reliability, or inefficient performance
as compared to the actual software.
 A prototype can be built very quickly by using several shortcuts.
 The shortcuts usually involve developing inefficient, inaccurate, or
dummy functions.
 Normally the term rapid prototyping is used when software tools are
used for prototype construction.

When to Use the Prototype Model

✅ Ideal Scenarios

 Unclear or evolving requirements

When clients aren’t sure what they need, a prototype helps them
visualize and refine their expectations.

 High user interaction systems

For UI-heavy applications like websites, mobile apps, or dashboards,
prototyping helps test usability early.

 Innovative or experimental projects

If you're building something novel, prototypes help validate feasibility
before committing to full development.

 Frequent feedback loops are possible

When stakeholders are available to review and give input regularly, the
iterative nature of prototyping shines.
Phases of Prototyping Model

Prototyping Model has six phases as follows:

1. Requirements gathering and analysis

Requirement analysis is the first step in developing a prototyping

model.

During this phase, the system’s desires are precisely defined.

During the method, system users are interviewed to determine what

they expect from the system.
2. Quick design

The second phase could consist of a preliminary design or a quick

design.

During this stage, the system’s basic design is formed.

However, it is not a complete design.

It provides the user with a quick overview of the system.

The rapid design aids in the development of the prototype.

3. Build a Prototype

During this stage, an actual prototype is intended to support the

knowledge gained from quick design.

It is a small low-level working model of the desired system.

4. Initial user evaluation

The proposed system is presented to the client for preliminary testing

at this stage.

It is beneficial to investigate the performance model’s strengths and

weaknesses.

Customer feedback and suggestions are gathered and forwarded to the

developer.

5. Refining prototype

If the user is dissatisfied with the current model, you may want to
improve the type that responds to user feedback and suggestions.

When the user is satisfied with the upgraded model, a final system
based on the approved final type is created.

6. Implement Product and Maintain

The final system was fully tested and distributed to production after it
was developed to support the original version.

To reduce downtime and prevent major failures, the programmer is run

on a regular basis.

Prototype development:
  Prototype development starts with an initial requirements gathering
phase.
 A quick design is carried out and a prototype is built.
 The developed prototype is submitted to the customer for evaluation.
 Based on the customer feedback, the requirements are refined and the
prototype is suitably modified.
 This cycle of obtaining customer feedback and modifying the prototype
continues till the customer approves the prototype.

Iterative development:

 Once the customer approves the prototype, the actual software is

developed using the iterative waterfall approach.
 In spite of the availability of a working prototype, the SRS document is
usually needed to be developed since the SRS document is invaluable
for carrying out traceability analysis, verification, and test case design
during later phases.
 However, for GUI parts, the requirements analysis and specification
phase becomes redundant since the working prototype that has been
approved by the customer serves as an animated requirements
specification.
 The code for the prototype is usually thrown away.
 However, the experience gathered from developing the prototype
helps a great deal in developing the actual system.

Advantages of Prototyping Model

 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.

 Early feedback from customers and stakeholders can help guide the
development process and ensure that the final product meets their
needs and expectations.

 Prototyping can be used to test and validate design decisions, allowing

for adjustments to be made before significant resources are invested in
development.

 Prototyping can help reduce the risk of project failure by identifying

potential issues and addressing them early in the process.

 Prototyping can facilitate communication and collaboration among

team members and stakeholders, improving overall project efficiency
and effectiveness.

 Prototyping can help bridge the gap between technical and non-
technical stakeholders by providing a tangible representation of the
product.

Disadvantages of the Prototyping Model

 Costly concerning 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 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

satisfied with the initial prototype.

 The prototype may not be scalable to meet the future needs of the
customer.

 The prototype may not accurately represent the final product due to
limited functionality or incomplete features.

 The focus on prototype development may shift away from the final
product, leading to delays in the development process.

 The prototype may give a false sense of completion, leading to the

premature release of the product.

 The prototype may not consider technical feasibility and scalability

issues that can arise during the final product development.

 The prototype may be developed using different tools and

technologies, leading to additional training and maintenance costs.

 The prototype may not reflect the actual business requirements of the
customer, leading to dissatisfaction with the final product.

Applications of Prototyping Model

  The Prototyping Model should be used when the requirements of the
product are not clearly understood or are unstable.

 The prototyping model can also be used if requirements are changing

quickly.

 This model can be successfully used for developing user interfaces,

high-technology software-intensive systems, and systems with
complex algorithms and interfaces.

 The prototyping Model is also a very good choice to demonstrate the

technical feasibility of the product.

Evolutionary Model:

The Evolutionary Prototyping Model is a type of software

development life cycle (SDLC) model where the system is
developed incrementally through continuous refinement of a
working prototype. Unlike throwaway prototyping, the
prototype in this model is not discarded—it evolves into the final
product

1. 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.

2. Therefore, the software product evolves with time.

3. All the models have the disadvantage that the duration of
time from the start of the project to the delivery time of a
solution is very high.

4. The evolutionary model solves this problem with a different

approach.

5. The evolutionary model suggests breaking down work into

smaller chunks, prioritizing them, and then delivering those
chunks to the customer one by one.

6. The number of chunks is huge and is the number of

deliveries made to the customer.

7. 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.

8. The model allows for changing requirements as well as all

work is broken down into maintainable work chunks.
Application of Evolutionary Model

1. 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.
 2. Evolutionary model is also used in object oriented software
development because the system can be easily portioned
into units in terms of objects.

Necessary Conditions for Implementing this Model

1. Customer needs are clear and been explained in deep to the

developer team.

2. There might be small changes required in separate parts but

not a major change.

3. As it requires time, so there must be some time left for the

market constraints.

4. Risk is high and continuous targets to achieve and report to

customer repeatedly.

5. It is used when working on a technology is new and requires

time to learn.

Advantages Evolutionary Model

1. Adaptability to Changing Requirements: Evolutionary

models work effectively in projects when the requirements
are ambiguous or change often. They support adjustments
and flexibility along the course of development.

2. Early and Gradual Distribution: Functional components

or prototypes can be delivered early thanks to incremental
development. Faster user satisfaction and feedback may
result from this.
 3. User Commentary and Involvement: Evolutionary
models place a strong emphasis on ongoing user input and
participation. This guarantees that the software offered
closely matches the needs and expectations of the user.

4. Improved Handling of Difficult Projects: Big, complex

tasks can be effectively managed with the help of
evolutionary models. The development process is made
simpler by segmenting the project into smaller, easier-to-
manage portions.

Disadvantages Evolutionary Model

1. Communication Difficulties: Evolutionary models require

constant cooperation and communication. The strategy may
be less effective if there are gaps in communication or if
team members are spread out geographically.

2. Dependence on an Expert Group: A knowledgeable and

experienced group that can quickly adjust to changes is
needed for evolutionary models. Teams lacking experience
may find it difficult to handle these model's dynamic nature.

3. Increasing Management Complexity: Complexity can be

introduced by organizing and managing several increments
or iterations, particularly in large projects. In order to
guarantee integration and synchronization, good project
management is needed.
 4. Greater Initial Expenditure: As evolutionary models
necessitate continual testing, user feedback and prototyping,
they may come with a greater starting cost. This may be a
problem for projects that have limited funding.

Spiral Model:

The Spiral Model is a Software Development Life Cycle

(SDLC) model that provides a systematic and iterative approach
to software development. In its diagrammatic representation,
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.

Some Key Points regarding the Stages of a Spiral Model:

1. The exact number of phases needed to develop the product

can be varied by the project manager depending upon the
project risks.

2. As the project manager dynamically determines the number

of phases, the project manager has an important role in
developing a product using the spiral model.

3. It is based on the idea of a spiral, with each iteration of the

spiral representing a complete software development cycle,
from requirements gathering and analysis to design,
implementation, testing, and maintenance.
Phases of the Spiral Model

The Spiral Model is a risk-driven model, meaning that the focus is

on managing risk through multiple iterations of the software
development process. Each phase of the Spiral Model is
divided into four Quadrants:

1. Objectives Defined

In first phase of the spiral model we clarify what the project aims
to achieve, including functional and non-functional requirements.
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. Risk Analysis and Resolving

In the risk analysis phase, the risks associated with the project are
identified and evaluated.

During the second quadrant, all the possible solutions are

evaluated to select the best possible solution. Then the risks
associated with that solution are identified and the risks are
resolved using the best possible strategy. At the end of this
quadrant, the Prototype is built for the best possible solution.

3. Develop the 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.

In the evaluation phase, the software is evaluated to determine if

it meets the customer's requirements and if it is of high quality.

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.
The next iteration of the spiral begins with a new planning phase,
based on the results of the evaluation.

The Spiral Model is often used for complex and large software
development projects, as it allows for a more flexible and
adaptable approach to Software development. It is also well-
suited to projects with significant uncertainty or high levels of
risk.

The Radius of the spiral at any point represents the expenses

(cost) of the project so far, and the angular dimension represents
the progress made so far in the current phase.

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful

completion of a software project. The most important feature of
the spiral model is handling these unknown risks after the project
has started. Such risk resolutions are easier done by developing a
prototype.

1. The spiral model supports coping with risks by providing the

scope to build a prototype at every phase of software
development.

2. The Prototyping Model also supports risk handling, but the

risks must be identified completely before the start of the
development work of the project.
 3. But in real life, project risk may occur after the development
work starts, in that case, we cannot use the Prototyping
Model.

4. In each phase of the Spiral Model, the features of the product

dated and analyzed, and the risks at that point in time are
identified and are resolved through prototyping.

5. Thus, this model is much more flexible compared to other

SDLC models.

Why Spiral Model is called Meta Model?

The Spiral model is called a Meta-Model because it subsumes all

the other SDLC models. For example, a single loop spiral actually
represents the Iterative Waterfall Model.

1. The spiral model incorporates the stepwise approach of

the Classical Waterfall Model.

2. The spiral model uses the approach of the Prototyping

Model by building a prototype at the start of each phase as
a risk-handling technique.

3. Also, the spiral model can be considered as supporting

the Evolutionary model - the iterations along the spiral can
be considered as evolutionary levels through which the
complete system is built.

When To Use the Spiral Model?

Here are the reasons where the Spiral Model is used:

 1. When a project is vast in Software Engineering, a spiral
model is utilized.

2. A spiral approach is utilized when frequent releases are

necessary.

3. When it is appropriate to create a prototype

4. When evaluating risks and costs is crucial

5. The spiral approach is beneficial for projects with moderate

to high risk.

6. The SDLC's spiral model is helpful when requirements are

complicated and ambiguous.

7. If modifications are possible at any moment

8. When committing to a long-term project is impractical owing

to shifting economic priorities.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.

1. Risk Handling: The projects with many unknown risks that

occur as the development proceeds, in that case, Spiral
Model is the best development model to follow due to the
risk analysis and risk handling at every phase.

2. Good for large projects: It is recommended to use the

Spiral Model in large and complex projects.
 3. Flexibility in Requirements: Change requests in the
Requirements at a later phase can be incorporated
accurately by using this model.

4. Customer Satisfaction: Customers can see the

development of the product at the early phase of the
software development and thus, they habituated with the
system by using it before completion of the total product.

5. Iterative and Incremental Approach: The Spiral Model

provides an iterative and incremental approach to software
development, allowing for flexibility and adaptability in
response to changing requirements or unexpected events.

6. Emphasis on Risk Management: The Spiral Model places

a strong emphasis on risk management, which helps to
minimize the impact of uncertainty and risk on the software
development process.

7. Improved Communication: The Spiral Model provides for

regular evaluations and reviews, which can improve
communication between the customer and the development
team.

8. Improved Quality: The Spiral Model allows for multiple

iterations of the software development process, which can
result in improved software quality and reliability.

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.

 1. Complex: The Spiral Model is much more complex than
other SDLC models.

2. Expensive: Spiral Model is not suitable for small projects as

it is expensive.

3. Too much dependability on Risk Analysis: The

successful completion of the project is very much dependent
on Risk Analysis. Without very highly experienced experts, it
is going to be a failure to develop a project using this model.

4. Difficulty in time management: As the number of phases

is unknown at the start of the project, time estimation is very
difficult.

5. Complexity: The Spiral Model can be complex, as it involves

multiple iterations of the software development process.

6. Time-Consuming: The Spiral Model can be time-

consuming, as it requires multiple evaluations and reviews.

7. Resource Intensive: The Spiral Model can be resource-

intensive, as it requires a significant investment in planning,
risk analysis, and evaluations.

Comparison between different Life Cycle Models:

The classical waterfall model can be

considered as the basic model and all other life cycle models as
embellishments of this model. However, the classical waterfall
model cannot be used in practical development projects, since
this model supports no mechanism to correct the errors that are
committed during any of the phases but detected at a later
phase. This problem is overcome by the iterative waterfall model
through the provision of feedback paths.

The iterative waterfall model is probably the

most widely used software development model so far. This model
is simple to understand and use. However, this model is suitable
only for well-understood problems, and is not suitable for
development of very large projects and projects that suffer from
large number of risks.

The prototyping model is suitable for projects

for which either the user requirements or the underlying technical
aspects are not well understood, however all the risks can be
identified before the project starts. This model is especially
popular for development of the user interface part of projects.

The evolutionary approach is suitable for

large problems which can be decomposed into a set of modules
for incremental development and delivery. This model is also used
widely for object-oriented development projects. Of course, this
model can only be used if incremental delivery of the system is
acceptable to the customer.

The spiral model is considered a meta model

and encompasses all other life cycle models. Flexibility and risk
handling are inherently built into this model. The spiral model is
suitable for development of technically challenging and large
software that are prone to several kinds of risks that are difficult
to anticipate at the start of the project. However, this model is
much more complex than the other models—this is probably a
factor deterring its use in ordinary projects.

Let us now compare the prototyping model

with the spiral model. The prototyping model can be used if the
risks are few and can be determined at the start of the project.
The spiral model, on the other hand, is useful when the risks are
difficult to anticipate at the beginning of the project, but are likely
to crop up as the development proceeds.

Let us compare the different life cycle

models from the viewpoint of the customer. Initially, customer
confidence is usually high on the development team irrespective
of the development model followed. During the lengthy
development process, customer confidence normally drops off, as
no working software is yet visible. Developers answer customer
queries using technical slang, and delays are announced. This
gives rise to customer resentment. On the other hand, an
evolutionary approach lets the customer experiment with a
working software much earlier than the monolithic approaches.
Another important advantage of the incremental model is that it
reduces the customer’s trauma of getting used to an entirely new
system. The gradual introduction of the software via incremental
phases provides time to the customer to adjust to the new
software. Also, from the customer’s financial viewpoint,
incremental development does not require a large upfront capital
outlay. The customer can order the incremental versions as and
when he can afford them.