CONTENTS

1.SOFTWARE PROCESS MODEL.

2.CATEGORIES:
(a)WATERFALL MODEL
(b)V-MODEL
(c)PROTOTYPE MODEL
(d)RAD MODEL
(e)INCREMENTAL MODEL
(f)SPIRAL MODEL
3.CONCLUSION
4.REFERENCE

Software Process Models

Many process models I came across so far have their background in a certain engineering
setup which I call "the happy engineering world". I called it this way, because in this "world"
you design systems where requirements can be set up from the beginning, sub-components
may be even available to a large extend and very often resources are not strictly limited. As
an example may serve an airport traffic control system. They do not need to design their radar
systems and mainframe computers along side the actual airport control system project. They
can rely on existing components and concentrate on the collection and analysis of the
requirements for the actual control software, then go to the design phase, then to the coding.
The tests will be strictly a test of the initial requirements. This all sounds pretty much like
following on of the process models e.g. the V-model I showed below.
However, there is also a quite different world and this is mostly forgotten by the preachers of
process models. Let me give you as an example one of my past projects. I was responsible for
the software development for a new continuous variable transmision for a vehicle. When I
say new I mean new. The transmission itself was a brandnew development using brandnew
technologies and we simply did not know how it would behave. Of course a good number of
requirements were known to us. We knew how the output currents had to look like to control
the transmission, and a few other things. Looking back I could say it was roughly 60% of the
requirements we knew for the first sample. After that the mechanical department changed and
imprroved the transmission several times. Many requirements remained the same, some
where changed, others were added and we had to change the software several times. We had
four or five different samples plus a good number of intermediate changes on existing
samples. You would call it a typical prototyping? No, it wasn't because the samples were not
thrown away and after that the series development started. We simply went into production
with the last sample, its mechanics and its software. This kind of development is quite
common in many industries. The answer of the process engineers was so far to cascade VCycles to express the different sample phases, but this does not give the true picture either. Of
course we did a kind of requirements engineering and we wrote down the most important
design decisions in the early sample phases, but only as much as was necessary to
communicate among the team members. This was far from satifying the ideas of process
assessors. But doing more would have been an absolute waste of time, because everybody
knew that it was most likely superseeded by the next sample. So what is the solution to it? As
I said the process model we used was a cascaded V-cycle model with the possibility to tailor
the completeness and quality of the work products and process steps of the earlier V-cycles,
requiring
a
complete
and
good
last
V-cycle.
The spiral model would have been a solution too, however there are these nasty risk analysis
phases which we did not want to do and which made not much sense in our situation. Quite
frankly there is no ideal process model for some develoment work. What ever you use, it will
always need some adaptation and tailoring. Therefore I just want to give a short overview on
the most common process models. Which ever you may choose for your situation, be aware
that
it
will
never
match
your
situation
completely.

TheWaterfallModel
The waterfall model is believed to have been the first process model which was introduced
and widely followed in software engineering. The innovation was that the first time software
engineering was devided into separate phases. When I did my first programs in PL/1 and
RPG in the early 1970's there was no awareness of splitting up software development into
different phases. Programs were very small, the requirements only a few and after punching a
pile of cards the program was done and could be tested by inserting it into the card reader and
observing
what
it
did.
As programs became bigger the need for a better requirements phase, some more thoughts on
the design, etc. were needed. Programmers found it more and more difficult to keep an
abstract of the program in their mind and transfer it into code. Also the thought of having a
separate testing phase performed by dedicated testers evolved. The different phases of
software engineering were identified and simply cascaded in each other, allowing for loops in
case it was found in a subsequent phase that the previous phase was not done properly.

The

phases

of

"The

Waterfall

Model"

are:

Requirement Analysis & Definition: All requirements of the system which has to be
developed are collected in this step. Like in other process models requirements are split up in
functional requiremetns and constraints which the system has to fulfill. Requirements have to
be collected by analyzing the needs of the end user(s) and checking them for validity and the
possibility to implement them. The aim is to generate a Requirements Specification
Document which is used as an input for the next phase of the model.
System Design: The system has to be properly designed before any implementation is started.
This involves an architectural design which defines and describes the main blocks and
components of the system, their interfaces and interactions. By this the needed hardware is
defined and the software is split up in its components. E.g. this involves the definition or
selection of a computer platform, an operating system, other peripheral hardware, etc. The
software components have to be defined to meet the end user requirements and to meet the
need of possible scalability of the system. The aim of this phase is to generate a System
Architecture Document this serves as an input for the software design phase of the
development, but also as an input for hardware design or selection activities. Usually in this
phase various documents are generated, one for each discipline, so that the software usually
will
receive
a
software
architecture
document.
Software Design: Based on the system architecture which defines the main software blocks
the software design will break them further down into code modules. The interfaces and
interactions of the modules are described, as well as their functional contents. All necessary
system states like startup, shutdown, error conditions and diagnostic modes have to be
considered and the activity and behaviour of the software has to be defined. The output of this
phase is a Software Design Document which is the base of the following implemetnation
work.
Coding: Based on the software design document the work is aiming to set up the defined
modules or units and actual coding is started. The system is first developed in smaller
portions called units. They are able to stand alone from an functional aspect and are
integrated
later
on
to
form
the
complete
software
package.
Software Integration & Verification: Each unit is developed independently and can be tested
for its functionality. This is the so called Unit Testing. It simply verifies if the modules or
units to check if they meet their specifications. This involves functional tests at the interfaces
of the modules, but also more detailed tests which consider the inner structure of the software
modules. During integration the units which are developed and tested for their functionalities
are brought together. The modules are integrated into a complete system and tested to check
if
all
modules
cooperate
as
expected.
System Verification: After successfully integration including the related tests the complete
system has to be tested against its initial requirements. This will include the orignal hardware
and environment, whereas the previous integration and testing phase may still be performed
in
a
different
environment
or
on
a
test
bench.

Operation & Maintenance: The system is handed over to the customer and will be used the
first time by him. Naturally the customer will check if his requirements were implemetned as
expected but he will also validate if the correct requirements have been set up in the
beginning. In case there are changes necessary it has to be fixed to make the system usable or
to make it comply to the customer wishes. In most of the "Waterfall Model" descriptions this
phase is extended to a never ending phase of "Operations & Maintenance". All the problems
which did not arise during the previous phases will be solved in this last phase.
The weekness of the Waterfall Model is at hand:

It is very important to gather all possible requirements during

the first phase of requirements collection and analysis. If not all
requirements are obtained at once the subsequent phases will
suffer from it. Reality is cruel. Usually only a part of the
requirements is known at the beginning and a good deal will be
gathered during the complete development time.

Iterations are only meant to happen within the same phase or at

best from the start of the subsequent phase back to the previous
phase. If the process is kept according to the school book this
tends to shift the solution of problems into later phases which
eventually results in a bad system design. Instead of solving the
root causes the tendency is to patch problems with inadequate
measures.

There may be a very big "Maintenance" phase at the end. The

process only allows for a single run through the waterfall.
Eventually this could be only a first sample phase which means
that the further development is squeezed into the last never
ending maintenance phase and virtually run without a proper
process.

TheVModel
A further development of the waterfall model issued into the so called "V-Model". If you look
at it closely the individual steps of the process are almost the same as in the waterfall model.
Therefore I will not describe the individual steps again, because the description of the
waterfall steps may substitute this. However, there is on big difference. Instead of going
down the waterfall in a linear way the process steps are bent upwards at the coding phase, to
form the typical V shape. The reason for this is that for each of the design phases it was found
that there is a counterpart in the testing phases which correlate to each other.

The time in which the V-model evolved was also the time in which software testing
techniques were defined and various kinds of testing were clearly separated from each other.
This new empasis on software testing (of course along with improvements and new
techniques in requirements engineering and design) led to the evolution of the waterfall
model into the V-model. The tests are derived directly from their design or requirements
counterparts. This made it possible to verify each of the design steps individually due to this
correlation.

Another idea evolved which was the traceability down the left side of the V. This means that
the requirements have to be traced into the design of the system, thus verifying that they are
implemented completely and correctly. Another feature can be observed when you compare
the waterfall model to the V-model. The "Operation & Maintenance" phase was replaced in
later versions of the V-model with the validation of requirements. This means that not only
the correct implementation of requirements has to be checked but also if the requirements are
correct. In case there is the need of an update of the requirements and subsequently the design
and coding, etc. there are two options. Either this has to be treated like in the waterfall model
in a never ending maintenance phase, or in going over to another V-cycle. The earlier
versions of V-models used the first option. For later versions a series of subsequent V-cycles
was
defined,
as
shown
in
the
below
diagram:

This idea also correlated with the established sample phases for products as it is present in
many industries. One of the cascaded V-cycles became the V-cycle of a sample phase. In
addition to this the V-cycles were tailored. This means that in earlier sample phases not all the
intermediate work products and process step were established in their full beauty but it was
simply reduced to what makes sense. By these measures the V-model became a usable
process model. It does not consider every detail and possibility but evaluated over a multitude
of
projects
in
various
industries
it
proved
its
usability.

The

Spiral

Model

The process begins at the center position. From there it moves clockwise in traversals. Each
traversal of the spiral usually results in a deliverable. It is not clearly defined what this
deliverable is. This changes from traversal to traversal. For example, the first traversals may
result in a requirement specification. The second will result in a prototype, and the next one
will result in another prototype or sample of a product, until the last traversal leads to a
product which is suitable to be sold. Consequently the related activities and their
documentation will also mature towards the outer traversals. E.g. a formal design and testing
session
would
be
placed
into
the
last
traversal.

There are different instances of this model so far I saw it with 3 to 6 task regions. The above
picture
shows
4
task
regions.

These regions are:

The planning task - to define resources, responsibilities,

milestones and schedules.

The goal determination task - to define the requirements and

constraints for the product and define possible alternatives.

The risk analysis task - to assess both technical and management

risks.

The engineering task - to design and implement one or more

prototypes or samples of the application.

The most outstanding distinction between the spiral model and other software models is the
explicit risk evaluation task. Although risk management is part of the other processes as well,
it does not have an own representation in the process model. For other models the risk
assessment is a sub-task e.g. of the overall planning and management. Further there are no
fixed phases for requirements specification, design or testing in the spiral model. Prototyping
may be used to find and define requirements. This may then be followed by "normal" phases
as they can be found in other process models to handle design and testing.
ADVANTAGES:
The advantages of the spiral model are that it reflects the development approach in many
industries much better than the other process models do. It uses a stepwise approach which
e.g. goes hand in hand with the habit of maintaining a number of hardware sample phases in
cases where the product to be produced is not only software for a given environment, but also
contains the development of hardware. This way the developers and the customer can
understand and react much better to risks in the evolutionary process. By having an iterative
process which reduces formalisms and omittable activities in the earlier phases the use of
resources is optimized. Further, any risks should be detected much earlier than in other
process
models
and
measures
can
be
taken
to
handle
them.
DISADVANTAGES:
The disadvantages of the spiral model are that the risk assessment is rigidliy anchored in the
process. First of all it demands risk-assessment expertise to perform this task and secondly in
some cases the risk assessment may not be necessary in this detail. For completely new
products the risk assessment makes sense. But I dare to say that the risks for programming
yet another book keeping package are well known and do not need a big assessment phase.
Also if you think of the multitude of carry over projects in many industries i.e. applying an
already developed product to the needs of a new customer by small changes, the risks are not
a subject generating big headaches. Generally speaking the spiral model is not much
esteemed and not much used, although it has many advantaged and could have even more if
the risk assessment phases would be tailored down to the necessary amount.

RAD MODEL:
Rapid application development is a software development methodology, which involves
iterative development and the construction of prototypes. It is a merger of various structured
techniques, especially the data driven Information Engineering with prototyping techniques
to accelerate software systems development
Advantages of the RAD methodology:
1.
2.

3.
4.
5.
6.

Flexible and adaptable to changes.

Prototyping applications gives users a tangible description from which to judge
whether critical system requirements are being met by the system. Report output can be
compared with existing reports. Data entry forms can be reviewed for completeness of all
fields, navigation, data access (drop down lists,checkboxes, radio buttons, etc.).
RAD generally incorporates short development cycles - users see the RAD product
quickly.
RAD involves user participation thereby increasing chances of early user community
acceptance.
RAD realizes an overall reduction in project risk.
Pareto's 80 - 20 Rule usually results in reducing the costs to create a custom system.
Disadvantages of RAD methodology:

1.

Unknown cost of product. As mentioned above, this problem can be alleviated by the
customer agreeing to a limited amount of rework in the RAD process.
2.
It may be difficult for many important users to commit the time required for success
of the RAD process.

PROTOTYPE MODEL:

Overview
The original purpose of a prototype is to allow users of the software to evaluate developers'
proposals for the design of the eventual product by actually trying them out, rather than
having to interpret and evaluate the design based on descriptions. Prototyping can also be
used by end users to describe and prove requirements that developers have not considered,
and that can be a key factor in the commercial relationship between developers and their
clients.[1] Interaction design in particular makes heavy use of prototyping with that goal.
This process is in contrast with the 1960s and 1970s monolithic development cycle of
building the entire program first and then working out any inconsistencies between design
and implementation, which led to higher software costs and poor estimates of time and cost.
[citation needed]
The monolithic approach has been dubbed the "Slaying the (software) Dragon"
technique, since it assumes that the software designer and developer is a single hero who has
to slay the entire dragon alone. Prototyping can also avoid the great expense and difficulty of
changing a finished software product.
Outline of the prototyping process
The process of prototyping involves the following steps
1. Identify basic requirements
Determine basic requirements including the input and output information desired.
Details, such as security, can typically be ignored.

2. Develop Initial Prototype

The initial prototype is developed that includes only user interfaces. (See Horizontal
Prototype, below)
3. Review
The customers, including end-users, examine the prototype and provide feedback on
additions or changes.
4. Revise and Enhance the Prototype
Using the feedback both the specifications and the prototype can be improved.
Negotiation about what is within the scope of the contract/product may be necessary.
If changes are introduced then a repeat of steps #3 and #4 may be needed.
Types of prototyping
Software prototyping has many variants. However, all the methods are in some way based on
two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.
Throwaway prototyping
Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation
of a model that will eventually be discarded rather than becoming part of the final delivered
software. After preliminary requirements gathering is accomplished, a simple working model
of the system is constructed to visually show the users what their requirements may look like
when they are implemented into a finished system.
Rapid Prototyping involved creating a working model of various parts of the system
at a very early stage, after a relatively short investigation. The method used in
building it is usually quite informal, the most important factor being the speed with
which the model is provided. The model then becomes the starting point from which
users can re-examine their expectations and clarify their requirements. When this has
been achieved, the prototype model is 'thrown away', and the system is formally
developed based on the identified requirements.
The most obvious reason for using Throwaway Prototyping is that it can be done quickly.
If the users can get quick feedback on their requirements, they may be able to refine them
early in the development of the software. Making changes early in the development
lifecycle is extremely cost effective since there is nothing at that point to redo. If a project
is changed after a considerable work has been done then small changes could require
large efforts to implement since software systems have many dependencies. Speed is
crucial in implementing a throwaway prototype, since with a limited budget of time and
money little can be expended on a prototype that will be discarded.
Another strength of Throwaway Prototyping is its ability to construct interfaces that the
users can test. The user interface is what the user sees as the system, and by seeing it in
front of them, it is much easier to grasp how the system will work.

1.

Design the prototype

2.

User experiences/uses the prototype, specifies new requirements

3.

Repeat if necessary

4.

Write the final requirements

5.
Develop the real products
Evolutionary prototyping
Evolutionary Prototyping (also known as breadboard prototyping) is quite different
from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is
to build a very robust prototype in a structured manner and constantly refine it. "The
reason for this is that the Evolutionary prototype, when built, forms the heart of the
new system, and the improvements and further requirements will be built.
When developing a system using Evolutionary Prototyping, the system is continually
refined and rebuilt.
"evolutionary prototyping acknowledges that we do not understand all the
requirements and builds only those that are well understood."
This technique allows the development team to add features, or make changes
that couldn't be conceived during the requirements and design phase.
For a system to be useful, it must evolve through use in its intended operational
environment. A product is never "done;" it is always maturing as the usage
environment changeswe often try to define a system using our most familiar frame
of reference---where we are now. We make assumptions about the way business will
be conducted and the technology base on which the business will be implemented. A
plan is enacted to develop the capability, and, sooner or later, something resembling
the envisioned system is delivered.
Evolutionary Prototypes have an advantage over Throwaway Prototypes in
that they are functional systems. Although they may not have all the features
the users have planned, they may be used on an interim basis until the final
system is delivered.

"It is not unusual within a prototyping environment for the user to put an initial
prototype to practical use while waiting for a more developed versionThe user may
decide that a 'flawed' system is better than no system at all."[7]
In Evolutionary Prototyping, developers can focus themselves to develop
parts of the system that they understand instead of working on developing
a whole system.

Incremental prototyping
The final product is built as separate prototypes. At the end the
separate prototypes are merged in an overall design.
Extreme prototyping
Extreme Prototyping as a development process is used especially for
developing web applications. Basically, it breaks down web
development into three phases, each one based on the preceding one.
The first phase is a static prototype that consists mainly of HTML
pages. In the second phase, the screens are programmed and fully
functional using a simulated services layer. In the third phase the
services are implemented. The process is called Extreme Prototyping
to draw attention to the second phase of the process, where a fully
functional UI is developed with very little regard to the services other
than their contract.
Advantages of prototyping
There are many advantages to using prototyping in software
development some tangible, some abstract.
Reduced time and costs: Prototyping can improve the quality of
requirements and specifications provided to developers. Because
changes cost exponentially more to implement as they are detected
later in development, the early determination of what the user really
wants can result in faster and less expensive software.
Improved and increased user involvement: Prototyping requires
user involvement and allows them to see and interact with a
prototype allowing them to provide better and more complete
feedback and specifications.The presence of the prototype being
examined by the user prevents many misunderstandings and
miscommunications that occur when each side believe the other
understands what they said. Since users know the problem
domain better than anyone on the development team does, increased
interaction can result in final product that has greater tangible and

intangible quality. The final product is more likely to satisfy the users
desire for look, feel and performance.
Disadvantages of prototyping
Using, or perhaps misusing, prototyping can also have disadvantages.
Insufficient analysis: The focus on a limited prototype can distract
developers from properly analyzing the complete project. This can
lead to overlooking better solutions, preparation of incomplete
specifications or the conversion of limited prototypes into poorly
engineered final projects that are hard to maintain. Further, since a
prototype is limited in functionality it may not scale well if the
prototype is used as the basis of a final deliverable, which may not be
noticed if developers are too focused on building a prototype as a
model.
User confusion of prototype and finished system: Users can begin
to think that a prototype, intended to be thrown away, is actually a
final system that merely needs to be finished or polished. (They are,
for example, often unaware of the effort needed to add error-checking
and security features which a prototype may not have.) This can lead
them to expect the prototype to accurately model the performance of
the final system when this is not the intent of the developers. Users
can also become attached to features that were included in a
prototype for consideration and then removed from the specification
for a final system. If users are able to require all proposed features be
included in the final system this can lead to conflict.
Developer misunderstanding of user objectives: Developers may
assume that users share their objectives (e.g. to deliver core
functionality on time and within budget), without understanding
wider commercial issues. For example, user representatives
attending Enterprise software(e.g. PeopleSoft) events may have seen
demonstrations of "transaction auditing" (where changes are logged
and displayed in a difference grid view) without being told that this
feature demands additional coding and often requires more hardware
to handle extra database accesses. Users might believe they can
demand auditing on every field, whereas developers might think this
is feature creep because they have made assumptions about the extent
of user requirements. If the developer has committed delivery before
the user requirements were reviewed, developers are between a rock
and a hard place, particularly if user management derives some
advantage from their failure to implement requirements.
Developer attachment to prototype: Developers can also become
attached to prototypes they have spent a great deal of effort
producing; this can lead to problems like attempting to convert a
limited prototype into a final system when it does not have an
appropriate underlying architecture. (This may suggest that

throwaway prototyping, rather than evolutionary prototyping, should

be used.)
Excessive development time of the prototype: A key property to
prototyping is the fact that it is supposed to be done quickly. If the
developers lose sight of this fact, they very well may try to develop a
prototype that is too complex. When the prototype is thrown away the
precisely developed requirements that it provides may not yield a
sufficient increase in productivity to make up for the time spent
developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and
delaying the final product.
Expense of implementing prototyping: the start up costs for
building a development team focused on prototyping may be high.
Many companies have development methodologies in place, and
changing them can mean retraining, retooling, or both. Many
companies tend to just jump into the prototyping without bothering to
retrain their workers as much as they should.

INCREMENTAL MODEL:
The Incremental model combines elements of the linear sequential model with the iterative
philosophy of the prototyping. This model has been explicitly designed to accommodate a
product that evolves over time.
When an incremental model is used, the first increment is often a core product. The
core product is used by the customer or undergoes a detailed review. As a result of use
and/or evaluation a plan is developed for the next increment. The plan addresses the
modification to the core product to better meet the needs of the customer and delivery
of additional features and functionality. Software is constructed in a step-by-step
manner. While a software product is being developed, each step adds to what has
already been completed.
The incremental Model is an evolution of the waterfall model, where the waterfall model is
incrementally applied.
The series of releases is referred to as increments, with each increment providing more
functionality to the customers. After the first increment, a core product is delivered, which
can already be used by the customer. Based on customer feedback, a plan is developed for the
next increments, and modifications are made accordingly. This process continues, with
increments being delivered until the complete product is delivered. The incremental

philosophy is also used in the agile process model.

Incremental model is an evolution of waterfall model. The product is designed, implemented, integrated a
popular
model
software
evolution
used
many
commercial
software
Incremental software development model may be applicable to projects where:
Software Requirements are well defined, but realization may be delayed.

The
basic
software
functionality

Advantages
1.After every iteration any faulty piece software can be identified easily as very few changes
are done after every iteration.
2.It is easier to test and debug as testing and debugging can be performed after each iteration.
3.This model does not affect anyone's business values because they provide core of the
software which customer needs,which will indeed help that person to keep run his business.
4.After establishing an overall architecture,system is developed and delivered in increments.
Disadvantages
1.If the requirements intially were thought to be stable but at later stages are realized to be
unstable then the increments have to be withdrawn and have to be reworked.
2.Resulting cost may exceed the cost of the organization.
3.Problems may arise related to system architecture.

CONCLUSION:
(a)Provides comprehensive overview of s/w process engineering system.

(b)Combine both process and infrastructure element.

(c)Give improvement effort.
(d)Develop the project.