UNIT I SOFTWARE PROCESS MODELS

Introduction to Software Engineering, Software Process, Perspective

and Specialized Process Models –Waterfall model – Spiral Model – V
shaped model – RAD model – Iterative Model – Prototype model.

Introduction to Software Engineering :

Software Engineering provides a standard procedure to design and
develop a software. Our Software Engineering Tutorial contains all
the topics of Software Engineering like Software Engineering Models,
Software Development Life Cycle, Requirement Engineering,
Software Design tools, Software Design Strategies, Software Design
levels, Software Project Management, Software Management
activities, Software Management Tools, Software Testing levels,
Software Testing approaches, Quality Assurance Vs. Quality control,
Manual Testing, Software Maintenance, Software Re-engineering and
Software Development Tool such as CASE Tool.

What is Software Engineering?

T The software is a collection of integrated programs.

Software subsists of carefully-organized instructions and code written

by developers on any of various particular computer languages.

Computer programs and related documentation such as requirements,

design models and user manuals.
Engineering is the application of scientific and practical knowledge
to invent, design, build, maintain, and improve frameworks,
processes, etc.

The term software engineering is the product of two

words, software, and engineering.

Software Engineering is an engineering branch related to the

evolution of software product using well-defined scientific principles,
techniques, and procedures. The result of software engineering is an
effective and reliable software product.

Why is Software Engineering required?

Software Engineering is required due to the following reasons:

o To manage Large software

o For more Scalability
o Cost Management
o To manage the dynamic nature of software
o For better quality Management
Need of Software Engineering

The necessity of software engineering appears because of a higher

rate of progress in user requirements and the environment on which
the program is working.

o Huge Programming: It is simpler to manufacture a wall than to

a house or building, similarly, as the measure of programming
become extensive engineering has to step to give it a scientific
process.
o Adaptability: If the software procedure were not based on
scientific and engineering ideas, it would be simpler to re-create
new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and
huge manufacturing has let down the cost of computer and
electronic hardware. But the cost of programming remains high
if the proper process is not adapted.
o Dynamic Nature: The continually growing and adapting nature
of programming hugely depends upon the environment in which
the client works. If the quality of the software is continually
changing, new upgrades need to be done in the existing one.
o Quality Management: Better procedure of software
development provides a better and quality software product.

Characteristics of a good software engineer

The features that good software engineers should possess are as

follows:

Exposure to systematic methods, i.e., familiarity with software

engineering principles.

Good technical knowledge of the project range (Domain knowledge).

Good programming abilities.

Good communication skills. These skills comprise of oral, written,

and interpersonal skills.
High motivation.

Sound knowledge of fundamentals of computer science.

Intelligence.

Ability to work in a team

Importance of Software Engineering

The importance of Software engineering is as follows:

Reduces complexity: Big software is always complicated and
challenging to progress. Software engineering has a great solution to
reduce the complication of any project. Software engineering divides
big problems into various small issues.
To minimize software cost: Software needs a lot of hardwork and
software engineers are highly paid experts. A lot of manpower is
required to develop software with a large number of codes. But in
software engineering, programmers project everything and decrease
all those things that are not needed.
To decrease time: Anything that is not made according to the project
always wastes time. And if you are making great software, then you
may need to run many codes to get the definitive running code.
Handling big projects: Big projects are not done in a couple of days,
and they need lots of patience, planning, and management. And to
invest six and seven months of any company, it requires heaps of
planning, direction, testing, and maintenance.
Reliable software: Software should be secure, means if you have
delivered the software, then it should work for at least its given time
or subscription. And if any bugs come in the software, the company is
responsible for solving all these bugs.
Effectiveness: Effectiveness comes if anything has made according to
the standards. Software standards are the big target of companies to
make it more effective.
Software Process:

The term software specifies to the set of computer programs,

procedures and associated documents (Flowcharts, manuals, etc.) that
describe the program and how they are to be used.

A software process is the set of activities and associated outcome that

produce a software product. Software engineers mostly carry out
these activities. These are four key process activities, which are
common to all software processes. These activities are:

1. Software specifications: The functionality of the software and

constraints on its operation must be defined.
2. Software development: The software to meet the requirement
must be produced.
3. Software validation: The software must be validated to ensure
that it does what the customer wants.
4. Software evolution: The software must evolve to meet
changing client needs.
The Software Process Model

A software process model is a specified definition of a software

process, which is presented from a particular perspective. Models, by
their nature, are a simplification, so a software process model is an
abstraction of the actual process, which is being described. Process
models may contain activities, which are part of the software process,
software product, and the roles of people involved in software
engineering. Some examples of the types of software process models
that may be produced are:

1. A workflow model: This shows the series of activities in the

process along with their inputs, outputs and dependencies. The
activities in this model perform human actions.
2. 2. A dataflow or activity model: This represents the process as
a set of activities, each of which carries out some data
transformations. It shows how the input to the process, such as a
specification is converted to an output such as a design. The
activities here may be at a lower level than activities in a
workflow model. They may perform transformations carried out
by people or by computers.
3. 3. A role/action model: This means the roles of the people
involved in the software process and the activities for which
they are responsible.

There are several various general models or paradigms of software

development:

1. The waterfall approach: This takes the above activities and

produces them as separate process phases such as requirements
specification, software design, implementation, testing, and so
on. After each stage is defined, it is "signed off" and
development goes onto the following stage.
2. Evolutionary development: This method interleaves the
activities of specification, development, and validation. An
 initial system is rapidly developed from a very abstract
specification.
3. Formal transformation: This method is based on producing a
formal mathematical system specification and transforming this
specification, using mathematical methods to a program. These
transformations are 'correctness preserving.' This means that you
can be sure that the developed programs meet its specification.
4. System assembly from reusable components: This method
assumes the parts of the system already exist. The system
development process target on integrating these parts rather than
developing them from scratch.

Program vs. Software

Software is more than programs. Any program is a subset of software,

and it becomes software only if documentation & operating
procedures manuals are prepared.

There are three components of the software as shown in fig:

Program: Program is a combination of source code & object code.

2. Documentation: Documentation consists of different types of
manuals. Examples of documentation manuals are: Data Flow
Diagram, Flow Charts, ER diagrams, etc.

Software is the set of instructions in the form of programs to govern

the computer system and to process the hardware components. To
produce a software product the set of activities is used. This set is
called a software process.

Software Development :

In this process, designing, programming, documenting, testing, and

bug fixing is done.

Components of Software :

There are three components of the software: These are : Program,

Documentation, and Operating Procedures.

1. Program –
A computer program is a list of instructions that tell a computer
what to do.

2. Documentation –
Source information about the product contained in design
documents, detailed code comments, etc.

3. OperatingProcedures –
Set of step-by-step instructions compiled by an organization to
help workers carry out complex routine operations.

Software Crisis :
1. Size and Cost –
Day to day growing complexity and expectation out of software.
Software are more expensive and more complex.
2. Quality –
Software products must have good quality.

3. DelayedDelivery –
Software takes longer than the estimated time to develop, which
in turn leads to cost shooting up.

Specialized Process Model in Software Engineering:

Component Based Development

The component based development model incorporates many of the
characteristics of the spiral model. It is evolutionary in nature,
Specialized process model demanding an iterative approach to the
creation of software.

However, the component based development model constructs

applications from prepackaged software components.

Modeling and construction activities begin with the identification of

candidate components. These components can be designed as either
conventional software modules or object oriented classes or packages
of classes.

Regardless of the technology that is used to create the components,

the component based development specialized process model
incorporates the following steps.

1. Available component based products are researched and

evaluated for the application
domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the
components.
 4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper
functionality.

The component based development model leads to software reuse,

and reusability provides software engineers with a number of
measurable benefits.

The Formal Methods Model

The formal methods model encompasses a set of activities that leads
to formal mathematical specification of computer software.

Formal methods enable you to specify, develop, and verify a

computer based system by applying a rigorous, mathematical
notation.

A variation on this approach, called clean room software engineering.

When formal methods are used during development, they provide a

mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms.

Ambiguity, incompleteness, and inconsistency can be discovered

and corrected more easily, but through the application of
mathematical analysis.

When formal methods are used during design, they serve as a basis
for program verification and therefore enable you to discover and
correct errors that might otherwise go undetected.

Although not a mainstream approach, the formal methods model

offers the promise of defect free software.

Draw Backs:
  The development of formal models is currently quite time
consuming and expensive.
 Because few software developers have the necessary
background to apply formal methods, extensive training is
required.
 It is difficult to use the models as a communication mechanism
for Technically unsophisticated customers.

Aspect Oriented Software Development

AOSD defines “aspects” that express customer concerns that cut
across multiple system functions, features, and information.

When concerns cut across multiple system functions, features, and

information, they are often referred to as crosscutting concerns.

Aspectual requirements define those crosscutting concerns that have

an impact across the software architecture.

Aspect oriented software development (AOSD), often referred to as

aspect oriented programming (AOP), is a relatively new software
engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing
aspects.”

Grundy provides further discussion of aspects in the context of what

he calls aspect oriented component engineering (AOCE):

AOCE uses a concept of horizontal slices through vertically

decomposed software components, called “aspects,” to characterize
cross-cutting functional and non-functional properties of components.
Software Development Life Cycle (SDLC)

A software life cycle model (also termed process model) is a pictorial

and diagrammatic representation of the software life cycle. A life
cycle model represents all the methods required to make a software
product transit through its life cycle stages. It also captures the
structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities

performed on a software product from its inception to retirement.
Different life cycle models may plan the necessary development
activities to phases in different ways. Thus, no element which life
cycle model is followed, the essential activities are contained in all
life cycle models though the action may be carried out in distinct
orders in different life cycle models. During any life cycle stage, more
than one activity may also be carried out.

Need of SDLC

The development team must determine a suitable life cycle model for
a particular plan and then observe to it.

Without using an exact life cycle model, the development of a

software product would not be in a systematic and disciplined
manner. When a team is developing a software product, there must be
a clear understanding among team representative about when and
what to do. Otherwise, it would point to chaos and project failure.
This problem can be defined by using an example. Suppose a
software development issue is divided into various parts and the parts
are assigned to the team members. From then on, suppose the team
representative is allowed the freedom to develop the roles assigned to
them in whatever way they like. It is possible that one representative
might start writing the code for his part, another might choose to
prepare the test documents first, and some other engineer might begin
with the design phase of the roles assigned to him. This would be one
of the perfect methods for project failure.

A software life cycle model describes entry and exit criteria for each
phase. A phase can begin only if its stage-entry criteria have been
fulfilled. So without a software life cycle model, the entry and exit
criteria for a stage cannot be recognized. Without software life cycle
models, it becomes tough for software project managers to monitor
the progress of the project.

SDLC Cycle

SDLC Cycle represents the process of developing software. SDLC

framework includes the following steps:
The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in

SDLC.

The senior members of the team perform it with inputs from all the
stakeholders and domain experts or SMEs in the industry.

Planning for the quality assurance requirements and identifications of

the risks associated with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client
to gather all the data like what the customer wants to build, who will
be the end user, what is the objective of the product. Before creating a
product, a core understanding or knowledge of the product is very
necessary.

For Example, A client wants to have an application which concerns

money transactions. In this method, the requirement has to be precise
like what kind of operations will be done, how it will be done, in
which currency it will be done, etc.

Once the required function is done, an analysis is complete with

auditing the feasibility of the growth of a product. In case of any
ambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (Software Requirement

Specification) document is created. The developers should thoroughly
follow this document and also should be reviewed by the customer for
future reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly

represent and document the software requirements and get them
accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement

Specification document which contains all the product requirements
to be constructed and developed during the project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of

requirements, analysis, and design of the software project. This phase
is the product of the last two, like inputs from the customer and
requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the

programming is built. The implementation of design begins
concerning writing code. Developers have to follow the coding
guidelines described by their management and programming tools
like compilers, interpreters, debuggers, etc. are used to develop and
implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to

make sure that the products are solving the needs addressed and
gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing,

acceptance testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it
is deployed.

Then based on the assessment, the software may be released as it is or

with suggested enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real
issues come up and requirements to be solved from time to time.

This procedure where the care is taken for the developed product is
known as maintenance.

Prescriptive Process Model in Software Engineering:

Prescriptive process model were originally proposed to bring order to

the chaos of software development. Prescriptive process model define
a prescribed set of process elements and a predictable process work
flow.
“prescriptive” because they prescribe a set of process elements
framework activities, software engineering actions, tasks, work
products, quality assurance, and change control mechanisms for each
project.

SDLC Models:

There are various software development life cycle models defined and
designed which are followed during the software development
process. These models are also referred as Software Development
Process Models". Each process model follows a Series of steps unique
to its type to ensure success in the process of software development.
Following are the most important and popular SDLC models followed
in the industry −
 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Prototype model.
Waterfall Model

 The waterfall is a universally accepted SDLC model. In this

method, the whole process of software development is divided
into various phases.

 The waterfall model is a continuous software development

model in which development is seen as flowing steadily
downwards (like a waterfall) through the steps of requirements
analysis, design, implementation, testing (validation),
integration, and maintenance.

 Linear ordering of activities has some significant consequences.

First, to identify the end of a phase and the beginning of the
next, some certification techniques have to be employed at the
end of each step. Some verification and validation usually do
this mean that will ensure that the output of the stage is
consistent with its input (which is the output of the previous
 step), and that the output of the stage is consistent with the
overall requirements of the system.

 Waterfall approach was first SDLC Model to be used widely in

Software Engineering to ensure success of the project. In "The
Waterfall" approach, the whole process of software development
is divided into separate phases. In this Waterfall model,
typically, the outcome of one phase acts as the input for the next
phase sequentially.
 The following illustration is a representation of the different
phases of the Waterfall Model.

The sequential phases in Waterfall model are −

 Requirement Gathering and analysis − All possible
requirements of the system to be developed are captured in this
phase and documented in a requirement specification document.
  System Design − The requirement specifications from first
phase are studied in this phase and the system design is
prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system
architecture.
 Implementation − With inputs from the system design, the
system is first developed in small programs called units, which
are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the
implementation phase are integrated into a system after testing
of each unit. Post integration the entire system is tested for any
faults and failures.
 Deployment of system − Once the functional and non-
functional testing is done; the product is deployed in the
customer environment or released into the market.
 Maintenance − There are some issues which come up in the
client environment. To fix those issues, patches are released.
Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer
environment.
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". In this model, phases do not overlap.

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.

Waterfall Model - Advantages

The advantages of waterfall development are that it allows for

departmentalization and control. A schedule can be set with deadlines
for each stage of development and a product can proceed through the
development process model phases one by one.
Development moves from concept, through design, implementation,
testing, installation, troubleshooting, and ends up at operation and
maintenance. Each phase of development proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows −
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has
specific deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very
well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow

much reflection or revision. Once an application is in the testing
stage, it is very difficult to go back and change something that was
not well-documented or thought upon in the concept stage.
The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
  Not suitable for the projects where requirements are at a
moderate to high risk of changing. So, risk and uncertainty is
high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 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

Spiral Model:

The spiral model is a risk-driven process model. This SDLC model

helps the group to adopt elements of one or more process models like
a waterfall, incremental, waterfall, etc. The spiral technique is a
combination of rapid prototyping and concurrency in design and
development activities.

Each cycle in the spiral begins with the identification of objectives for
that cycle, the different alternatives that are possible for achieving the
goals, and the constraints that exist. This is the first quadrant of the
cycle (upper-left quadrant).

The next step in the cycle is to evaluate these different alternatives

based on the objectives and constraints. The focus of evaluation in
this step is based on the risk perception for the project.

The next step is to develop strategies that solve uncertainties and

risks. This step may involve activities such as benchmarking,
simulation, and prototyping.

The spiral model has four phases. A software project repeatedly

passes through these phases in iterations called Spirals.
Identification:
This phase starts with gathering the business requirements in the
baseline spiral. In the subsequent spirals as the product matures,
identification of system requirements, subsystem requirements and
unit requirements are all done in this phase.
This phase also includes understanding the system requirements by
continuous communication between the customer and the system
analyst. At the end of the spiral, the product is deployed in the
identified market.
Design:
The Design phase starts with the conceptual design in the baseline
spiral and involves architectural design, logical design of modules,
physical product design and the final design in the subsequent spirals.
Construct or Build:
The Construct phase refers to production of the actual software
product at every spiral. In the baseline spiral, when the product is just
thought of and the design is being developed a POC (Proof of
Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and
design details a working model of the software called build is
produced with a version number. These builds are sent to the
customer for feedback.
Evaluation and Risk Analysis:
Risk Analysis includes identifying, estimating and monitoring the
technical feasibility and management risks, such as schedule slippage
and cost overrun. After testing the build, at the end of first iteration,
the customer evaluates the software and provides feedback.
The following illustration is a representation of the Spiral Model,
listing the activities in each phase.
Based on the customer evaluation, the software development process
enters the next iteration and subsequently follows the linear approach
to implement the feedback suggested by the customer. The process of
iterations along the spiral continues throughout the life of the
software.

Spiral Model Application:

The Spiral Model is widely used in the software industry as it is in

sync with the natural development process of any product, i.e.
learning with maturity which involves minimum risk for the customer
as well as the development firms.
The following pointers explain the typical uses of a Spiral Model −
 When there is a budget constraint and risk evaluation is
important.
 For medium to high-risk projects.
  Long-term project commitment because of potential changes to
economic priorities as the requirements change with time.
 Customer is not sure of their requirements which is usually the
case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get
enough customer feedback.
 Significant changes are expected in the product during the
development cycle.

Spiral Model - Pros and Cons:

The advantage of spiral lifecycle model is that it allows elements of

the product to be added in, when they become available or known.
This assures that there is no conflict with previous requirements and
design.
This method is consistent with approaches that have multiple software
builds and releases which allows making an orderly transition to a
maintenance activity. Another positive aspect of this method is that
the spiral model forces an early user involvement in the system
development effort.
On the other side, it takes a very strict management to complete such
products and there is a risk of running the spiral in an indefinite loop.
So, the discipline of change and the extent of taking change requests
is very important to develop and deploy the product successfully.
The advantages of the Spiral SDLC Model are as follows −
 Changing requirements can be accommodated.
 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky
parts can be developed earlier which helps in better risk
management.
The disadvantages of the Spiral SDLC Model are as follows −
 Management is more complex.
 End of the project may not be known early.
 Not suitable for small or low risk projects and could be
expensive for small projects.
 Process is complex
 Spiral may go on indefinitely.
 Large number of intermediate stages requires excessive
documentation

V shaped model:

In this type of SDLC model testing and the development, the step is
planned in parallel. So, there are verification phases on the side and
the validation phase on the other side. V-Model joins by Coding
phase.

V-Model also referred to as the Verification and Validation Model. In

this, each phase of SDLC must complete before the next phase starts.
It follows a sequential design process same as the waterfall model.
Testing of the device is planned in parallel with a corresponding stage
of development.
Verification: It involves a static analysis method (review) done
without executing code. It is the process of evaluation of the product
development process to find whether specified requirements meet.

Validation: It involves dynamic analysis method (functional, non-

functional), testing is done by executing code. Validation is the
process to classify the software after the completion of the
development process to determine whether the software meets the
customer expectations and requirements.

So V-Model contains Verification phases on one side of the

Validation phases on the other side. Verification and Validation
process is joined by coding phase in V-shape. Thus it is known as V-
Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where

product requirements understood from the customer's side. This
 phase contains detailed communication to understand customer's
expectations and exact requirements.
2. System Design: In this stage system engineers analyze and
interpret the business of the proposed system by studying the
user requirements document.
3. Architecture Design: The baseline in selecting the architecture
is that it should understand all which typically consists of the list
of modules, brief functionality of each module, their interface
relationships, dependencies, database tables, architecture
diagrams, technology detail, etc. The integration testing model
is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks
down into small modules. The detailed design of the modules is
specified, which is known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started.
Based on the requirements, a suitable programming language is
decided. There are some guidelines and standards for coding.
Before checking in the repository, the final build is optimized
for better performance, and the code goes through many code
reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are

developed during the module design phase. These UTPs are
executed to eliminate errors at code level or unit level. A unit is
the smallest entity which can independently exist, e.g., a
program module. Unit testing verifies that the smallest entity
can function correctly when isolated from the rest of the codes/
units.
2. Integration Testing: Integration Test Plans are developed
during the Architectural Design Phase. These tests verify that
groups created and tested independently can coexist and
communicate among themselves.
3. System Testing: System Tests Plans are developed during
System Design Phase. Unlike Unit and Integration Test Plans,
 System Tests Plans are composed by the client?s business team.
System Test ensures that expectations from an application
developer are met.
4. Acceptance Testing: Acceptance testing is related to the
business requirement analysis part. It includes testing the
software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is
available within the user atmosphere. It conjointly discovers the
non-functional problems like load and performance defects
within the real user atmosphere.

When to use V-Model?

o When the requirement is well defined and not ambiguous.

o The V-shaped model should be used for small to medium-sized
projects where requirements are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical
resources are available with essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well
before coding.
3. This saves a lot of time. Hence a higher chance of success over
the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily
understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.

2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no
early prototypes of the software are produced.
 4. If any changes happen in the midway, then the test documents
along with the required documents, has to be updated

RAD model:

RAD (Rapid Application Development) Model:

RAD is a linear sequential software development process model that

emphasizes a concise development cycle using an element based
construction approach. If the requirements are well understood and
described, and the project scope is a constraint, the RAD process
enables a development team to create a fully functional system within
a concise time period.

RAD (Rapid Application Development) is a concept that products can

be developed faster and of higher quality through:

o Gathering requirements using workshops or focus groups

o Prototyping and early, reiterative user testing of designs
o The re-use of software components
o A rigidly paced schedule that refers design improvements to the
next product version
o Less formality in reviews and other team communication
The various phases of RAD are as follows:

1.Business Modelling: The information flow among business

functions is defined by answering questions like what data drives the
business process, what data is generated, who generates it, where does
the information go, who process it and so on.

2. Data Modelling: The data collected from business modeling is

refined into a set of data objects (entities) that are needed to support
the business. The attributes (character of each entity) are identified,
and the relation between these data objects (entities) is defined.
Process Modelling: The information object defined in the data
modeling phase are transformed to achieve the data flow necessary to
implement a business function. Processing descriptions are created for
adding, modifying, deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate

construction of the software; even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have

already been tested since RAD emphasis reuse. This reduces the
overall testing time. But the new part must be tested, and all interfaces
must be fully exercised.

When to use RAD Model?:

o When the system should need to create the project that

modularizes in a short span time (2-3 months).
o When the requirements are well-known.
o When the technical risk is limited.
o When there's a necessity to make a system, which modularized
in 2-3 months of period.
o It should be used only if the budget allows the use of automatic
code generating tools.

Advantage of RAD Model:

o This model is flexible for change.

o In this model, changes are adoptable.
o Each phase in RAD brings highest priority functionality to the
customer.
o It reduced development time.
o It increases the reusability of features.

Disadvantage of RAD Model:

o It required highly skilled designers.

o All application is not compatible with RAD.
 o For smaller projects, we cannot use the RAD model.
o On the high technical risk, it's not suitable.
o Required user involvement.

Iterative Model:

In this Model, you can start with some of the software specifications
and develop the first version of the software. After the first version if
there is a need to change the software, then a new version of the
software is created with a new iteration. Every release of the Iterative
Model finishes in an exact and fixed period that is called iteration.

The Iterative Model allows the accessing earlier phases, in which the
variations made respectively. The final output of the project renewed
at the end of the Software Development Life Cycle (SDLC) process.

The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements
are gathered from customers and check by an analyst whether
requirements will fulfil or not. Analyst checks that need will achieve
within budget or not. After all of this, the software team skips to the
next phase.

2. Design: In the design phase, team design the software by the

different diagrams like Data Flow diagram, activity diagram, class
diagram, state transition diagram, etc.

3. Implementation: In the implementation, requirements are written

in the coding language and transformed into computer programmes
which are called Software.

4. Testing: After completing the coding phase, software testing starts

using different test methods. There are many test methods, but the
most common are white box, black box, and grey box test methods.

5. Deployment: After completing all the phases, software is deployed

to its work environment.

6. Review: In this phase, after the product deployment, review phase

is performed to check the behaviour and validity of the developed
product. And if there are any error found then the process starts again
from the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the

software in the working environment there may be some bugs, some
errors or new updates are required. Maintenance involves debugging
and new addition options.

When to use the Iterative Model?:

1. When requirements are defined clearly and easy to understand.

2. When the software application is large.
3. When there is a requirement of changes in future.

Advantage(Pros) of Iterative Model:

 1. Testing and debugging during smaller iteration is easy.
2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on
designing.

Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.

2. More Resources may be required.
3. Design can be changed again and again because of imperfect
requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing
requirements.

Prototype Model:

The prototype model requires that before carrying out the

development of actual software, a working prototype of the system
should be built. A prototype is a toy implementation of the system. A
prototype usually turns out to be a very crude version of the actual
system, possible exhibiting limited functional capabilities, low
reliability, and inefficient performance as compared to actual
software. In many instances, the client only has a general view of
what is expected from the software product. In such a scenario where
there is an absence of detailed information regarding the input to the
system, the processing needs, and the output requirement, the
prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

 2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side
by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the

final product.
2. Require extensive customer collaboration
o Costs customer money

o Needs committed customer

o Difficult to finish if customer withdraw

o May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper
requirement analysis, design, customer evaluation, and
feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

Evolutionary Process Model

Evolutionary process model resembles the iterative enhancement

model. The same phases are defined for the waterfall model occurs
here in a cyclical fashion. This model differs from the iterative
enhancement model in the sense that this does not require a useful
product at the end of each cycle. In evolutionary development,
requirements are implemented by category rather than by priority.

For example, in a simple database application, one cycle might

implement the graphical user Interface (GUI), another file
manipulation, another queries and another updates. All four cycles
must complete before there is a working product available. GUI
allows the users to interact with the system, file manipulation allow
the data to be saved and retrieved, queries allow user to get out of the
system, and updates allows users to put data into the system.

Benefits of Evolutionary Process Model

Use of EVO brings a significant reduction in risk for software

projects.

EVO allows the marketing department access to early deliveries,

facilitating the development of documentation and demonstration.

Better fit the product to user needs and market requirements.

Manage project risk with the definition of early cycle content.

Uncover key issues early and focus attention appropriately.

Increase the opportunity to hit market windows.

Accelerate sales cycles with early customer exposure.

Increase management visibility of project progress.