SOFTWARE ENGINEERING TECHNIQUES

LESSON 4:

Topics Covered to developing a system. It then breaks the complex mission of

Software Development Models-Waterfall model, Prototyping development into several logical steps, starting with
model, Evolutionary model, Spiral model requirements gathering and ending with release. The waterfall
development model is checked for proper execution and quality
Objectives
through validation of entry requirements and exit criteria
Upon completion of this Lesson, you should be able to:
Every project goes through some kind of systems analysis,
• Know how to select an appropriate software development
design, implementation and evaluation.
model
• Explain what is water fall model
Sometimes called the classic life cycle or the waterfall model, the
linear sequential model suggests a systematic, sequential
• Know what is prototyping model
approach to software development that begins at the system
• Know what is evolutionary model level and progresses through analysis, design, coding, testing
• Know what is spiral model and support. Modeled after a conventional engineering cycle, the
In our last three lectures we have covered almost all the general linear sequential model encompasses the following activities:
concepts of software engineering which we should know before System/Information engineering and modeling: Because
going on deep into the subject which each one of us should software is always part of a larger system, work begins by
know and should be familiar with: establishing requirements for all system elements and then
In this lecture let us see what are the various software allocating some subset of these requirements to software. This
development models. We have to choose an appropriate system view is essential when software must interact with other
software development model according to the project. This is a elements such as hardware, people, and databases. System
very important topic and so you have to pay more attention engineering and analysis encompass requirements gathering at a
towards it. system level with a small amount of top-level design and
analysis. Information engineering encompasses requirements
Let us explore the various software development models. gathering at the strategic business level and at the business area
Software Development Model level.
Over the years, various models have emerged to support the Analysis: The study of the processes: the WHAT. The
development of high-quality software products. A few of the understanding of what is being done, how it is being done,
most widely adopted models are presented below what is the frequency, the goals the limits, the requirements, the
1. Linear Sequential/Classic Life Cycle / Iterative Waterfall problems.
Model The requirements gathering process is intensified and focused
2. Prototyping specifically on software. To understand the nature of the
3. Evolutionary And Spiral Models programs to be built, the software engineer must understand
the information domain for the software as well as required
Linear Sequential Model 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 waterfall development model encourages the development the design is performed in a detailed manner, code generation
team to specify the business functionality of the software prior can be accomplished mechanistically.

© Copy Right: Rai University

3E.253 11
 Testing: once code has been generated, program testing begins. the customer for consideration as part of the development
SOFTWARE ENGINEERING TECHNIQUES

The testing process focuses on the logical internals of the process. The customer in turn provides feedback to the
software, ensuring that all statements have been tested, and on developer, who goes back to refine the system requirements to
the functional externals; that is, conducting tests to uncover incorporate the additional information. Often, the prototype
errors and ensure that defined input will produce actual results code is thrown away and entirely new programs are developed
that agree with the required results. once requirements are identified.
Implementation/Support: The programming of the data, There are a few different approaches that may be followed when
processes and dialogue defined in the design. Software for using the Prototyping Model:
implementation and data management are selected. Databases • Creation of the major user interfaces without any
are defined and dialogues and processes are programmed. substantive coding in the background in order to give the
Software will undoubtedly undergo change after it is delivered users a “feel” for what the system will look like,
to the customer. Change will occur because errors have been
• Development of an abbreviated version of the system that
encountered, because the software must be adapted to
performs a limited subset of functions; development of a
accommodate changes in its external environment or because
paper system (depicting proposed screens, reports,
the customer requires functional or performance enhancements.
relationships etc.), or
Software support/maintenance reapplies each of the preceding
phases to an existing program rather than a new one. • Use of an existing system or system components to
demonstrate some functions that will be included in the
Additional points on Linear Sequential model: it is the oldest
developed system.
and most widely used paradigm for software engineering.
Among its limitation are: Prototyping is comprised of the following steps:
• Real projects rarely follow the sequential flow that the model • Requirements Definition/Collection. Similar to the
proposes. Although the linear model can accommodate Conceptualization phase of the Waterfall Model, but not as
iteration, it does so indirectly. As a result changes can cause comprehensive. The information collected is usually limited
confusion as the project team proceeds. to a subset of the complete system requirements.
• It is often difficult for the customer to state all requirements • Design. Once the initial layer of requirements information is
explicitly. The linear sequential model requires this and has collected, or new information is gathered, it is rapidly
difficulty accommodating the natural uncertainty that exists integrated into a new or existing design so that it may be
at the beginning of many projects. folded into the prototype.
• The customer must have patience. A working version of the • Prototype Creation/Modification. The information from the
program will not be available until towards the end of the design is rapidly rolled into a prototype. This may mean the
project. A major error, if undetected until the working creation/modification of paper information, new coding, or
program is reviewed, can be disastrous. modifications to existing coding.
• The sequential model can lead to a “blocking state” in which • Assessment. The prototype is presented to the customer for
some project members must wait for other members of the review. Comments and suggestions are collected from the
team to complete dependent tasks. Overall productivity customer.
could get reduced in the process. • Prototype Refinement. Information collected from the
While each of these problems is real, the classic life cycle customer is digested and the prototype is refined. The
model has a definite and important place in software developer revises the prototype to make it more effective and
engineering work. It provides a template into which methods efficient.
for analysis design, coding, testing, and support can be placed. • System Implementation. In most cases, the system is
Where requirements are clearly known, it results in superior rewritten once requirements are understood. Sometimes, the
quality products. While it does have weaknesses, it is Iterative process eventually produces a working system that
significantly better than a haphazard approach to software can be the cornserstone for the fully functional system.
development. Problems/Challenges Associated with the
Prototyping Model
Prototyping Model
Criticisms of the Prototyping Model generally fall into the
The Prototyping Model was developed on the assumption that
following categories:
it is often difficult to know all of your requirements at the
beginning of a project. Typically, users know many of the • Prototyping can lead to false expectations. Prototyping often
objectives that they wish to address with a system, but they do creates a situation where the customer mistakenly believes
not know all the nuances of the data, nor do they know the that the system is “finished” when in fact it is not. More
details of the system features and capabilities. The Prototyping specifically, when using the Prototyping Model, the pre-
Model allows for these conditions, and offers a development implementation versions of a system are really nothing more
approach that yields results without first requiring all than one-dimensional structures. The necessary, behind-the-
information up-front. scenes work such as database normalization, documentation,
testing, and reviews for efficiency have not been done. Thus
When using the Prototyping Model, the developer builds a
the necessary underpinnings for the system are not in place.
simplified version of the proposed system and presents it to

© Copy Right: Rai University

12 3E.253
• Prototyping can lead to poorly designed systems. Because functional units that can be incrementally implemented and

SOFTWARE ENGINEERING TECHNIQUES

the primary goal of Prototyping is rapid development, the delivered .
design of the system can sometimes suffer because the The developers first develop the core modules of the system.
system is built in a series of “layers” without a global This initial product skeleton is refined into increasing levels of
consideration of the integration of all other components. capability by adding new functionalities in successive versions.
While initial software development is often built to be a In this approach, each successive version of the product is a
“throwaway, “ attempting to retroactively produce a solid functioning system capable of performing some more useful
system design can sometimes be problematic. 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.

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. A, B, C are modules of a software product that are incrementally
developed and delivered.
3. A prototype will hardly be acceptable in court in the event
that the client does not agree that the developer has The figure shows evolutionary development of a software
discharged his/her obligations. For this reason using the product.
prototype as the software specification is normally reserved Also, the core modules get tested thoroughly, thereby reducing
for software development within an organisation. chances of errors in the final product. However, the main
To avoid the above problems the developer and the client disadvantage of the successive version model is that for most
should both establish a protocol, which indicates the practical problems, it is difficult to subdivide the problem into
deliverables to the client as well as a contractual obligation. several functional units that can be incrementally implemented
and delivered. Therefore, the evolutionary model is useful only
In both versions the prototype is discarded early in the life cycle. for very large problems, where it is easier to identify nodules for
However, one way of ensuring that the product is properly incremental implementation, thus obviating the need to
designed and implemented is to implement the prototype in a commit large resources in one go for development of the full-
different programming language from that of the product. fledged system.
Before going onto spiral model we’ll see what is evolutionary Now let us see what a spiral model is?
model
Spiral Model
Evolutionary Model The spiral development model combines the waterfall
This model is also known as successive versions model. In this development model and the prototype approach, which is a
model, the system is first broken down into several modules or series of partial implementations of the product. Advantages

© Copy Right: Rai University

3E.253 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 and risk analysis occurs. If it is determined that the risks are
software quality standards and the integration of hardware and to high, the project can be terminated.
software development cycles. • Customer Evaluation
• Provides a framework for designing software processes that • In this phase, the customer will assess the engineering
incorporate risk assessment and management into each phase results and make changes if necessary.
of software development.
Strengths and Weaknesses
• Meta model.
Strengths
Definitions
Risks: potentially adverse circumstances that may impair the • Good for large and complex projects
development process and quality of products. • Customer Evaluation allows for any changes deemed
Risk Management: identify, address and eliminate software risk necessary, or would allow for new technological advances to
items before they become a threat to successful software be used
operation or a major source of expensive software rework. • 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 development and deployment of the data warehouse and the

SOFTWARE ENGINEERING TECHNIQUES

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

© Copy Right: Rai University

3E.253 17