SOFTWARE ENGINEERING TECHNIQUES
LESSON 4:
Topics Covered
Software Development Models-Waterfall model, Prototyping
model, Evolutionary model, Spiral model
Objectives
Upon completion of this Lesson, you should be able to:
• Know how to select an appropriate software development
model
• Explain what is water fall model
• Know what is prototyping model
• Know what is evolutionary model
• Know what is spiral model
In our last three lectures we have covered almost all the general
concepts of software engineering which we should know before
going on deep into the subject which each one of us should
know and should be familiar with:
In this lecture let us see what are the various software
development models. We have to choose an appropriate
software development model according to the project. This is a
very important topic and so you have to pay more attention
towards it.
Let us explore the various software development models.
Software Development Model
Over the years, various models have emerged to support the
development of high-quality software products. A few of the
most widely adopted models are presented below
1. Linear Sequential/Classic Life Cycle / Iterative Waterfall
Model
2. Prototyping
3. Evolutionary And Spiral Models
Linear Sequential Model
The waterfall development model encourages the development
team to specify the business functionality of the software prior
© Copy Right: Rai University
3E.253
to developing a system. It then breaks the complex mission of
development into several logical steps, starting with
requirements gathering and ending with release. The waterfall
development model is checked for proper execution and quality
through validation of entry requirements and exit criteria
Every project goes through some kind of systems analysis,
design, implementation and evaluation.
Sometimes called the classic life cycle or the waterfall model, the
linear sequential model suggests a systematic, sequential
approach to software development that begins at the system
level and progresses through analysis, design, coding, testing
and support. Modeled after a conventional engineering cycle, the
linear sequential model encompasses the following activities:
System/Information engineering and modeling: Because
software is always part of a larger system, work begins by
establishing requirements for all system elements and then
allocating some subset of these requirements to software. This
system view is essential when software must interact with other
elements such as hardware, people, and databases. System
engineering and analysis encompass requirements gathering at a
system level with a small amount of top-level design and
analysis. Information engineering encompasses requirements
gathering at the strategic business level and at the business area
level.
Analysis: The study of the processes: the WHAT. The
understanding of what is being done, how it is being done,
what is the frequency, the goals the limits, the requirements, the
problems.
The requirements gathering process is intensified and focused
specifically on software. To understand the nature of the
programs to be built, the software engineer must understand
the information domain for the software as well as required
function, behavior, performance, and interface. Requirements
for both the system and the software are documented and
reviewed with the customer.
Design: The determination of the way in which the
requirements identified in the analysis are translated to an
information system: the HOW. Data, dialogue, and processes in
the way to be implemented are identified. Software design is
actually a multistep process that focuses on four distinct
attributes of a program: data structure, software architecture,
interface representations, and procedural detail. The design
process translates requirements into a representation of the
software that can be accessed for quality before coding begins.
Like requirements, the design is documented and becomes part
of the software configuration.
Code generation: The design must be translated into machine-
readable form. The code generation step performs this task. If
the design is performed in a detailed manner, code generation
can be accomplished mechanistically.
11
 Testing: once code has been generated, program testing begins.
SOFTWARE ENGINEERING TECHNIQUES
The testing process focuses on the logical internals of the
software, ensuring that all statements have been tested, and on
the functional externals; that is, conducting tests to uncover
errors and ensure that defined input will produce actual results
that agree with the required results.
Implementation/Support: The programming of the data,
processes and dialogue defined in the design. Software for
implementation and data management are selected. Databases
are defined and dialogues and processes are programmed.
Software will undoubtedly undergo change after it is delivered
to the customer. Change will occur because errors have been
encountered, because the software must be adapted to
accommodate changes in its external environment or because
the customer requires functional or performance enhancements.
Software support/maintenance reapplies each of the preceding
phases to an existing program rather than a new one.
Additional points on Linear Sequential model: it is the oldest
and most widely used paradigm for software engineering.
Among its limitation are:
• Real projects rarely follow the sequential flow that the model
proposes. Although the linear model can accommodate
iteration, it does so indirectly. As a result changes can cause
confusion as the project team proceeds.
• It is often difficult for the customer to state all requirements
explicitly. The linear sequential model requires this and has
difficulty accommodating the natural uncertainty that exists
at the beginning of many projects.
• The customer must have patience. A working version of the
program will not be available until towards the end of the
project. A major error, if undetected until the working
program is reviewed, can be disastrous.
• The sequential model can lead to a “blocking state” in which
some project members must wait for other members of the
team to complete dependent tasks. Overall productivity
could get reduced in the process.
While each of these problems is real, the classic life cycle
model has a definite and important place in software
engineering work. It provides a template into which methods
for analysis design, coding, testing, and support can be placed.
Where requirements are clearly known, it results in superior
quality products. While it does have weaknesses, it is
significantly better than a haphazard approach to software
development.
Prototyping Model
The Prototyping Model was developed on the assumption that
it is often difficult to know all of your requirements at the
beginning of a project. Typically, users know many of the
objectives that they wish to address with a system, but they do
not know all the nuances of the data, nor do they know the
details of the system features and capabilities. The Prototyping
Model allows for these conditions, and offers a development
approach that yields results without first requiring all
information up-front.
When using the Prototyping Model, the developer builds a
simplified version of the proposed system and presents it to
© Copy Right: Rai University
12
the customer for consideration as part of the development
process. The customer in turn provides feedback to the
developer, who goes back to refine the system requirements to
incorporate the additional information. Often, the prototype
code is thrown away and entirely new programs are developed
once requirements are identified.
There are a few different approaches that may be followed when
using the Prototyping Model:
• Creation of the major user interfaces without any
substantive coding in the background in order to give the
users a “feel” for what the system will look like,
• Development of an abbreviated version of the system that
performs a limited subset of functions; development of a
paper system (depicting proposed screens, reports,
relationships etc.), or
• Use of an existing system or system components to
demonstrate some functions that will be included in the
developed system.
Prototyping is comprised of the following steps:
• Requirements Definition/Collection. Similar to the
Conceptualization phase of the Waterfall Model, but not as
comprehensive. The information collected is usually limited
to a subset of the complete system requirements.
• Design. Once the initial layer of requirements information is
collected, or new information is gathered, it is rapidly
integrated into a new or existing design so that it may be
folded into the prototype.
• Prototype Creation/Modification. The information from the
design is rapidly rolled into a prototype. This may mean the
creation/modification of paper information, new coding, or
modifications to existing coding.
• Assessment. The prototype is presented to the customer for
review. Comments and suggestions are collected from the
customer.
• Prototype Refinement. Information collected from the
customer is digested and the prototype is refined. The
developer revises the prototype to make it more effective and
efficient.
• System Implementation. In most cases, the system is
rewritten once requirements are understood. Sometimes, the
Iterative process eventually produces a working system that
can be the cornserstone for the fully functional system.
Problems/Challenges Associated with the
Prototyping Model
Criticisms of the Prototyping Model generally fall into the
following categories:
• Prototyping can lead to false expectations. Prototyping often
creates a situation where the customer mistakenly believes
that the system is “finished” when in fact it is not. More
specifically, when using the Prototyping Model, the pre-
implementation versions of a system are really nothing more
than one-dimensional structures. The necessary, behind-the-
scenes work such as database normalization, documentation,
testing, and reviews for efficiency have not been done. Thus
the necessary underpinnings for the system are not in place.
3E.253
• Prototyping can lead to poorly designed systems. Because
the primary goal of Prototyping is rapid development, the
design of the system can sometimes suffer because the
system is built in a series of “layers” without a global
consideration of the integration of all other components.
While initial software development is often built to be a
“throwaway, “ attempting to retroactively produce a solid
system design can sometimes be problematic.
Disadvantages of Prototyping
1. Often clients expect that a few minor changes
to the prototype will more than suffice their
needs. They fail to realise that no consideration
was given to the overall quality of the software
in the rush to develop the prototype.
2. The developers may lose focus on the real
purpose of the prototype and compromise the
quality of the product. For example, they may
employ some of the inefficient algorithms or
inappropriate programming languages used in
developing the prototype. This mainly due to laziness and
an over reliance on familiarity with seemingly easier methods.
3. A prototype will hardly be acceptable in court in the event
that the client does not agree that the developer has
discharged his/her obligations. For this reason using the
prototype as the software specification is normally reserved
for software development within an organisation.
To avoid the above problems the developer and the client
should both establish a protocol, which indicates the
deliverables to the client as well as a contractual obligation.
In both versions the prototype is discarded early in the life cycle.
However, one way of ensuring that the product is properly
designed and implemented is to implement the prototype in a
different programming language from that of the product.
Before going onto spiral model we’ll see what is evolutionary
model
Evolutionary Model
This model is also known as successive versions model. In this
model, the system is first broken down into several modules or
© Copy Right: Rai University
3E.253
functional units that can be incrementally implemented and
SOFTWARE ENGINEERING TECHNIQUES
delivered .
The developers first develop the core modules of the system.
This initial product skeleton is refined into increasing levels of
capability by adding new functionalities in successive versions.
In this approach, each successive version of the product is a
functioning system capable of performing some more useful
work. Therefore, as the user gets a chance to experiment with a
partially developed system much before
the fully developed version is released,
the evolutionary model facilitates to elicit
the exact requirements of the used for
incorporating into the fully developed
system.
A, B, C are modules of a software product that are incrementally
developed and delivered.
The figure shows evolutionary development of a software
product.
Also, the core modules get tested thoroughly, thereby reducing
chances of errors in the final product. However, the main
disadvantage of the successive version model is that for most
practical problems, it is difficult to subdivide the problem into
several functional units that can be incrementally implemented
and delivered. Therefore, the evolutionary model is useful only
for very large problems, where it is easier to identify nodules for
incremental implementation, thus obviating the need to
commit large resources in one go for development of the full-
fledged system.
Now let us see what a spiral model is?
Spiral Model
The spiral development model combines the waterfall
development model and the prototype approach, which is a
series of partial implementations of the product. Advantages
13
 of the spiral development model include an early focus on • Here the customer decides when the next phase of planning
SOFTWARE ENGINEERING TECHNIQUES

reusing existing software components, the incorporation of
software quality standards and the integration of hardware and
software development cycles.
• Provides a framework for designing software processes that
incorporate risk assessment and management into each phase
of software development.
• Meta model.
Definitions
Risks: potentially adverse circumstances that may impair the
development process and quality of products.
Risk Management: identify, address and eliminate software risk
items before they become a threat to successful software
operation or a major source of expensive software rework.
and risk analysis occurs. If it is determined that the risks are
to high, the project can be terminated.
• Customer Evaluation
• In this phase, the customer will assess the engineering
results and make changes if necessary.
Strengths and Weaknesses
Strengths
• Good for large and complex projects
• Customer Evaluation allows for any changes deemed
necessary, or would allow for new technological advances to
be used
• Allows customer and developer to determine and to react to
risks at each evolutionary level

Representation of Components, Relationships, and rules • Direct consideration of risks at all levels greatly reduces
The spiral lifecycle model is the combination of the classic problems
waterfall model and an element called risk analysis. This model Weaknesses
is very appropriate for large software projects. The model
• Difficult to convince some customers that the evolutionary
consists of four main parts, or blocks, and the process is shown
by a continuous loop going from the outside towards the approach is controllable
inside. This shows the progress of the project. • Needs considerable risk assessment

• Planning • If a risk is not discovered, problems will surely occur

• This phase is where the objectives, alternatives, and Appropriate or Inappropriate Domains of Application
constraints are determined. Appropriate
• Risk Analysis • Large, complex projects
• What happens here is that alternative solutions and
Inappropriate
constraints are defined, and risks are identified and analyzed.
• Simple, easy projects
If risk analysis indicates uncertainty in the requirements, the
prototyping model might be used to assist the situation. • If a project is simple and easy, then time will be wasted

• Engineering
on risk analysis if the risk could be easily seen or if there
weren’t any risks at all.

© Copy Right: Rai University

14 3E.253
Background Material However, the spiral model is not a panacea. It may be difficult

SOFTWARE ENGINEERING TECHNIQUES

The traditional software engineering models don’t deal with the to convince customers [particularly in contract situations] that
risks involved in the projects. Many projects have failed because the evolutionary approach is controllable. It demands
the risks involved weren’t taken into account at all. Barry Boehm considerable risk assessment expertise and relies on this
tried to fix this by incorporating the strengths of other models expertise for success. If a major risk is not uncovered and
(namely the Waterfall model), and changing the management managed, problems will undoubtedly occur.
emphasis to risk analysis. This model is still new and hasn’t
PPT-1
been widely used; it was introduced in 1988.
Linear Sequential Model
Related Tools and Methodologies (Waterfall Model)
Navigation between each phase is done through data/control
hierarchies, functional decomposition, and requirement
allocation.
Phase products are represented through structure charts, state-
transition diagrams, and stimulus response threads.
Comparison
The Spiral model is actually based in part on the Waterfall
model (the other part is based on the Rapid Prototype model).
The Spiral model is better in the sense that it allows for risk
management where the Waterfall places too much emphasis on PPT-2
project management. It should be kept in mind however, the Contributions
requirements of the project, and which model will suit it the
• Introduces discipline into the software development process
best.
• Implementation of a product should be postponed until
Additional Points on Spiral Model
after the objectives of implementation are well understood
A spiral model is divided into a number of framework
activities, also called task regions. Typically, there are between Drawbacks
three and six regions, some of them are: • Linear
• Customer communication-tasks required to establish • Rigid
effective communication between developer and customer.
• Monolithic
• Planning- tasks required defining resources, timelines, and
PPT-3
other project-related information.
• Risk Analysis- tasks required to assess both technical and The Prototyping Model
management risks. “Do it twice” principle by Brooks
• Engineering - tasks required to build one or more • First version: Throwaway prototype
representations of the application. • Second version: Actual solution using Waterfall model
• Construction and release – tasks required to construct, test, Drawbacks
install, and provide user support [documentation and • Quick fixes may not be evaluated
training].
• Does not eliminate the time gap between the definition of
• Customer evaluation- tasks required obtaining customer
requirements and final delivery of application
feedback based on evaluation of the software representations
created during the engineering stage and implemented • No emphasis on need for anticipating changes
during the installation stage. Ppt-4
The spiral model is a realistic approach to the development of Evolutionary Process Model
large-scale systems and software. Because software evolves as the
• Software evolves
process progresses, the developer and customer better
understand and react to risks at each evolutionary level. The • Requirements may change
spiral model uses prototyping as a risk reduction mechanism, • Market competition
but, more important, enables the developer to apply the Iterative in Nature
prototyping approach at any stage in the evolution of the
• Deliver core product to the real user
product. It maintains the systematic stepwise approach
suggested by the classic life cycle but incorporates it into an • Measure the added value of the user
iterative framework that more realistically reflects the real world. • Develop the next increment of the product
The spiral model demands a direct consideration of technical
PPT-5
risks at all stage of the project and if properly applied, should
reduce risks before they become problematic. • In contrast to Waterfall model
• supports program evolution

© Copy Right: Rai University

3E.253 15
 • Also provides a method for proving program correctness. Definitions
SOFTWARE ENGINEERING TECHNIQUES

• Program correctness proofs represent an analytic Risks: potentially adverse circumstances that may impair the
mathematical approach for analyzing correctness of program development process and quality of products.
after it is developed. Risk Management: identify, address and eliminate software
• Given P and Specification={<Pre,Post>,…..}, verify truth risk items before they become a threat to successful software
of {Pre} P {Post}. operation or a major source of expensive software rework.
• Transformation approach is constructive Ppt-10
• Given specification pairs <Pre,Post> • Cyclic
• Derive P that satisfies all the <Pre,Post> pairs in the • Each cycle of spiral consists of 4-6 stages
specification. • Radius of spiral-cost accumulated so far in the process
• Automatically derives a program that satisfies • Introduces prototyping and risk and cost evaluation in each
specification. phase.
PPT-6 • Couples evolutionary nature of software development with
controlled and systematic aspects of linear sequential model.
Advantages
• Provides potential for rapid development of incremental
• Enable a software engineer to specify, develop, and verify a
software system by applying a rigorous mathematical versions of software.
notation. Ppt-11
• Ambiguity, incompleteness, and inconsistency can be • Allows to restate the issues of robustness vs correctness
discovered/corrected easily by mathematical analysis. • After one cycle, unstated requirements checked as part of
• Use of formal methods serves as a basis of program robustness of application
verification. • May become part of specifications in the next cycle
• Offers promise of defect free software development. • After each cycle, robustness approximates correctness more
• Programmer is constrained to operate within well defined closely.
formal boundaries; can focus on design; complexity kept
Ppt-12
under control.
Spectrum of Models
PPT-7
• Waterfall Life Cycle Model Documentation driven
Recent Research
• Evolutionary Approaches Increment driven
• Use of techniques developed in Artificial Intelligence to
• Transformational Approach Specification driven
support environment for transformational model.
• Spiral Method (meta model) Risk driven
• Automated Assistant mediates and supports activities of
the software process as directed by Software Engineer Summary
• Recording derivation steps and rationale • There is no ideal process model
• Producing necessary information for SE to make • Appropriate is a hybrid solution-“Mix-and-match” lifecycle
decisions model
• Suggesting strategies • Process model should be specified at the beginning of the
project
PPT-8
• Risk analysis and resolution are significant for process
Drawbacks control
• Requires extensive mathematical background and training in
Exercises
applying formal methods.
1. Is there ever a case when the generic phases of the software
• Still a research oriented approach; but promising for software
engineering process don’t apply? If so, describe it?
development for safety critical systems such as aircraft
avionics and medical devices. 2. Which of the software engineering paradigms presented in
this lecture do you think would be most effective? Why?
PPT-9
3. Provide five examples of software development projects that
Spiral Model would be amenable to prototyping. Name two or three
• Provides a framework for designing software processes that applications that would be more difficult to prototype.
incorporate risk assessment and management into each phase 4. Give four differences between engineering of cars and
of software development. software
• Meta model. 5. List the main stages of the Waterfall model
6. What do the arrows going back up the Waterfall model
mean?

© Copy Right: Rai University

16 3E.253
7. What do you have at the end of i) Throwaway Prototyping
ii) Evolutionary Prototyping?
8. Is it acceptable to have a prototype that only has an interface
and nothing behind it?
9. Complete the table, placing a rank 1,2,3 in each cell
Waterfall Prototyping Evolutionary
Models
Coping with
Change
Involving the
user
Good
Documentation
Overcoming
technical
difficulties
along the way
Structured
Code
10. Choose a software process for each of the following:
a. Developing a video compression component for mobile
devices
b. Developing an inventory system to an exact specification
c. Developing an all-encompassing student management
system
Assignment
According to Boehm, however, this model “does not work well
for many classes of software, particularly interactive end-user
applications.” Specifying the requirements for such applications
is notoriously difficult since interface design is highly subjective
and clients rarely ever understand the real needs the software
should meet. As a result, “document-driven standards have
pushed many projects to write elaborate specifications of poorly
understood user interfaces and decision-support functions,
followed by the design and development of large quantities of
unusable code” [Boehm 1988]. The problem is that a contract is
signed before the real requirements of the system are properly
understood.
In addition to this shortcoming, the model provides no means
for risk assessment and management during the life cycle
1. Identify the model Boehm mentioned in above paragraph.
2. Discuss the pitfalls with respect to this model.
Case Study
The Customer
Our client is a multinational bank operating in 50 countries.
The Challenge
The bank had begun building an enterprise data warehouse and
a pilot data mart in early 1998. They had adopted a waterfall
development model. The project suffered a setback because of
quality related issues and delivery schedules could not be met.
We were invited to recommend a road map and process for the
© Copy Right: Rai University
3E.253
development and deployment of the data warehouse and the
SOFTWARE ENGINEERING TECHNIQUES
subsequent roll out over 50 countries.
The Solution
We introduced our incremental/iterative process development
model in place of the waterfall model the bank had selected.
Detailed quality processes were formulated for project
management and monitoring. The project involved evaluation
and tool selection for areas such as Data ETL and Data Model
Management. We also proposed formal processes to strengthen
areas like configuration management, review, metrics collection
and analysis.
The following technologies were used
• Hardware: AS/400 (data warehouse, data marts), Windows
NT server (data marts)
• Data mart and staging database: IBM DB2/400, data marts
replicated in Oracle
• Data modeling:Cool:Biz
• OLAP Analysis: COGNOS tools
The process we recommended has been implemented
successfully. This has provided the client with a well-configured,
standardized system to capture critical business information.
The same solution will now be rolled out to the bank’s location
worldwide.
Further Readings and References
The current state of the art in software engineering can best be
determined from monthly publications such as IEEE
Transactions on Software Engineering. Industry periodicals such
as Application Development Trends, Cutter IT Journal and
Software Development often contain articles on Software
Engineering topics.
A wide variety of information sources on software engineering
and the software process is available on the Internet. The
various sites are as listed below.
BGTCS Spiral Model: http://www.magicnet.net/~jbryson/
SPIRAL.HTML
Classic Waterfall Model: http://osiris.sunderland.ac.uk/rif/
linda_spence/HTML/2.1.1.html
Problems with the Waterfall Model: http://
osiris.sunderland.ac.uk/rif/linda_spence/HTML/2.1.2.html
Software Lifecycles: http://www.seas.gwu.edu/faculty/
shmuel/cs273/presentation/slice/273a-lifecycle.htm
Spiral Model: http://osiris.sunderland.ac.uk/rif/linda_spence/
HTML/2.1.7.html
Spiral Model: http://www.cstp.umkc.edu/~bwalter/spiral.htm
Spiral Model: http://www-isis.ecs.soton.ac.uk/computing/c/
c/node227.htm
Spiral Model SDM: http://www.istis.unomaha.edu/dpeak/
ISQA4350/sdlc/sld011.htm
Summary Review of A Spiral Model of Software Development:
http://www.ags.uci.edu/~jblevins/reviews/HCI/
Boehm.html
Waterfall Model: http://www-isis.ecs.soton.ac.uk/computing/
c/c/node226.htm
17