OVERVIEW OF SOFTWARE

ENGINEERING
VIT Chennai

1
 OVERVIEW OF SOFTWARE
ENGINEERING
• 5 hours SLO: 1
• Nature of Software, Software Engineering,
Software – process, project, product, Process
Models – Classical & Evolutionary models,
Overview of System Engineering

2
 What is software?
• Computer programs and associated documentation

• Software is: (1) instructions (computer programs)

that when executed provide desired features,
function, and performance; (2) data structures that
enable the programs to adequately manipulate
information and (3) documentation that describes
the operation and use of the programs.
 Software products
• Software products may be developed for a particular
customer or may be developed for a general market

• Generic products
– Stand-alone systems that are marketed and sold to any customer
who wishes to buy them.
– Examples – PC software such as graphics programs, project
management tools; CAD software; software for specific markets
such as appointments systems for dentists.
• Customized products
– Software that is commissioned by a specific customer to meet
their own needs.
– Examples – embedded control systems, air traffic control
software, traffic monitoring systems.

Chapter 1 Introduction 4
 Product specification
• Generic products
– The specification of what the software should do
is owned by the software developer and decisions
on software change are made by the developer.
• Customized products
– The specification of what the software should do
is owned by the customer for the software and
they make decisions on software changes that are
required.

Chapter 1 Introduction 5
 Application types
• Stand-alone applications
– These are application systems that run on a local
computer, such as a PC. They include all necessary
functionality and do not need to be connected to a
network.
• Interactive transaction-based applications
– Applications that execute on a remote computer and are
accessed by users from their own PCs or terminals. These
include web applications such as e-commerce applications.
• Embedded control systems
– These are software control systems that control and
manage hardware devices. Numerically, there are probably
more embedded systems than any other type of system.

Chapter 1 Introduction 6
 Application types
• Batch processing systems
– These are business systems that are designed to process
data in large batches. They process large numbers of
individual inputs to create corresponding outputs.
• Entertainment systems
– These are systems that are primarily for personal use and
which are intended to entertain the user.
• Systems for modeling and simulation
– These are systems that are developed by scientists and
engineers to model physical processes or situations, which
include many, separate, interacting objects.

Chapter 1 Introduction 7
 Application types
• Data collection systems
– These are systems that collect data from their
environment using a set of sensors and send that
data to other systems for processing.
• Systems of systems
– These are systems that are composed of a number
of other software systems.

Chapter 1 Introduction 8
Essential attributes of good software

Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to

meet the changing needs of customers. This is a critical attribute
because software change is an inevitable requirement of a
changing business environment.
Dependability and Software dependability includes a range of characteristics
security including reliability, security and safety. Dependable software
should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.
Efficiency Software should not make wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is

designed. This means that it must be understandable, usable and
compatible with other systems that they use.

Chapter 1 Introduction 9
 Software characteristics
• Software is developed or engineered, it
is not manufactured in the classical
sense.
• Software doesn't "wear out."
• Although the industry is moving toward
component-based construction, most
software continues to be custom-built.

10
Software doesn’t “wear out”:

11
Wear vs. Deterioration

12
 How Programs Are Usually Written …

This is how the

The requirements The developers problem is
understood it in This is how the solved now
specification was
that way problem was
defined like this
solved before.

This is how the program is This, in fact, is what the

described by marketing customer wanted … ;-)
That is the program after
department
debugging
 What is software engineering?

• Software engineering is an engineering discipline whose focus is the

cost effective development of the high quality software system.

• Software engineering is an engineering discipline which is concerned

with all aspects of software production.

• Software engineers should adopt a systematic and organised approach

to their work and use appropriate tools and techniques depending on
the problem to be solved, the development constraints and the
resources available.
 Software Engineering
• Some realities:
– a concerted effort should be made to understand
the problem before a software solution is
developed
– design becomes a pivotal activity
– software should exhibit high quality
– software should be maintainable
• The seminal definition:
– [Software engineering is] the establishment and
use of sound engineering principles in order to
obtain economically software that is reliable and
works efficiently on real machines.
15
 Software Engineering Definition

• IEEE defines software engineering as:

• (1) The application of a Systematic,
disciplined, quantifiable approach to the
development, operation and maintenance of
software; that is, the application of
engineering to software.
• (2) The study of approaches as in the above
statement.

16
 Software Engineering Definition
• Fritz Bauer, a German computer scientist,
defines software engineering as:
Software engineering is the establishment and
use of sound engineering principles in order to
obtain economically software that is reliable
and work efficiently on real machines.

17
 What is the difference between software
engineering and computer science?

Computer Science Software Engineering

is concerned with
 theory  the practicalities of developing
 fundamentals  delivering useful software

Computer science theories are currently

insufficient to act as a complete
underpinning for software engineering, BUT
it is a foundation for practical aspects of
software engineering
 What are the key challenges facing software
engineering?
• Coping with legacy systems, coping with
increasing diversity and coping with demands for
reduced delivery times.
– Legacy systems – old, valuable systems must be
maintained and updated.
– Heterogeneity – systems are distributed and include a
mix of hardware and software.
– Delivery – there is increasing pressure for faster
delivery of software.
 The changing nature of software

• There are seven broad categories of computer

software present continuing challenges for
software engineers.
– System software
– Application software
– Engineering/scientific software
– Embedded software
– Product line software
– Web application
– AI software
Software—New Categories
• Open world computing—pervasive, distributed computing
• Ubiquitous computing—wireless networks
• Netsourcing—the Web as a computing engine
• Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
• Also …
– Data mining
– Grid computing
– Cognitive machines
– Software for nanotechnologies

21
 What is the difference between software
engineering and system engineering?
• Software engineering is part of System
engineering
• System engineering is concerned with all
aspects of computer-based systems
development including
– hardware,
– software and
– process engineering
• System engineers are involved in
system specification,
architectural design,
integration and deployment
 Frequently asked questions about
software engineering
Question Answer

What is software? Computer programs and associated documentation.

Software products may be developed for a particular
customer or may be developed for a general market.
What are the attributes of good software? Good software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What are the fundamental software Software specification, software development, software
engineering activities? validation and software evolution.
What is the difference between software Computer science focuses on theory and fundamentals;
engineering and computer science? software engineering is concerned with the practicalities
of developing and delivering useful software.
What is the difference between software System engineering is concerned with all aspects of
engineering and system engineering? computer-based systems development including
hardware, software and process engineering. Software
engineering is part of this more general process.

Chapter 1 Introduction 23
 Frequently asked questions about
software engineering
Question Answer
What are the key challenges facing Coping with increasing diversity, demands for reduced
software engineering? delivery times and developing trustworthy software.
What are the costs of software Roughly 60% of software costs are development costs,
engineering? 40% are testing costs. For custom software, evolution
costs often exceed development costs.
What are the best software engineering While all software projects have to be professionally
techniques and methods? managed and developed, different techniques are
appropriate for different types of system. For example,
games should always be developed using a series of
prototypes whereas safety critical control systems require
a complete and analyzable specification to be developed.
You can’t, therefore, say that one method is better than
another.
What differences has the web made to The web has led to the availability of software services
software engineering? and the possibility of developing highly distributed service-
based systems. Web-based systems development has led
to important advances in programming languages and
software reuse.

Chapter 1 Introduction 24
 Software Process

• A software process (also knows as software

methodology) is a set of related activities that
leads to the production of the software. These
activities may involve the development of the
software from the scratch, or, modifying an
existing system.

25
 Software Process…
• Any software process must include the following four
activities:
• Software specification (or requirements engineering):
Define the main functionalities of the software and the
constrains around them.
• Software design and implementation: The software is to
be designed and programmed.
• Software verification and validation: The software must
conforms to it’s specification and meets the customer
needs.
• Software evolution (software maintenance): The software
is being modified to meet customer and market
requirements changes.

26
 Software process..
• In practice, they include sub-activities such as
requirements validation, architectural design,
unit testing, …etc.
• There are also supporting activities such as
configuration and change management,
quality assurance, project management, user
experience.

27
 Software process..
• When we talk about a process, we usually talk about the activities
in it. However, a process also includes the process description,
which includes:
• Products: The outcomes of the an activity. For example, the
outcome of architectural design maybe a model for the software
architecture.
• Roles: The responsibilities of the people involved in the process. For
example, the project manager, programmer, etc.
• Pre and post conditions: The conditions that must be true before
and after an activity. For example, the pre condition of the
architectural design is the requirements have been approved by the
customer, while the post condition is the diagrams describing the
architectural have been reviewed.

28
 Software process..
• Software process is complex, it relies on
making decisions. There’s no ideal process and
most organizations have developed their own
software process.
• For example, an organization works on critical
systems has a very structured process, while
with business systems, with rapidly changing
requirements, a less formal, flexible process is
likely to be more effective.

29
A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering

30
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints

Umbrella Activities

31
Framework Activities
• Communication
• Planning
• Modeling
– Analysis of requirements
– Design
• Construction
– Code generation
– Testing
• Deployment

32
Umbrella Activities
• Software project management
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Work product preparation and
production
• Reusability management
• Measurement
• Risk management

33
Adapting a Process Model
– the overall flow of activities, actions, and tasks and the
interdependencies among them
– the degree to which actions and tasks are defined within
each framework activity
– the degree to which work products are identified and
required
– the manner which quality assurance activities are applied
– the manner in which project tracking and control activities
are applied
– the overall degree of detail and rigor with which the
process is described
– the degree to which the customer and other stakeholders
are involved with the project
– the level of autonomy given to the software team
– the degree to which team organization and roles are
prescribed

34
 The Essence of Practice
• Polya suggests:
1. Understand the problem (communication and
analysis).
2. Plan a solution (modeling and software
design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and
quality assurance).

35
 Understand the Problem
• Who has a stake in the solution to the
problem? That is, who are the stakeholders?
• What are the unknowns? What data,
functions, and features are required to
properly solve the problem?
• Can the problem be compartmentalized? Is it
possible to represent smaller problems that
may be easier to understand?
• Can the problem be represented graphically?
Can an analysis model be created?
36
 Plan the Solution
• Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that
implements the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements of the
solution reusable?
• Can subproblems be defined? If so, are solutions readily apparent
for the subproblems?
• Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?

37
 Carry Out the Plan
• Does the solution conform to the plan? Is
source code traceable to the design
model?
• Is each component part of the solution
provably correct? Has the design and
code been reviewed, or better, have
correctness proofs been applied to
algorithm?

38
 Examine the Result
• Is it possible to test each component part
of the solution? Has a reasonable testing
strategy been implemented?
• Does the solution produce results that
conform to the data, functions, and
features that are required? Has the
software been validated against all
stakeholder requirements?

39
Hooker’s General Principles

• 1: The Reason It All Exists

• 2: KISS (Keep It Simple, Stupid!)
• 3: Maintain the Vision
• 4: What You Produce, Others Will
Consume
• 5: Be Open to the Future
• 6: Plan Ahead for Reuse
• 7: Think!

40
The Four Ps: People, Project,
Product, and Process
in Software Development
VIT Chennai
 The Four Ps: People, Project,
Product, and Process
in Software Development
• People: The architects, developers, testers,
and their supporting management, plus users,
customers, and other stakeholders are the
prime movers in a software project
• Project: The organizational element through
which software development is managed. The
outcome of a project is a released product.
• Product: Artifacts that are created during the
life of the project, such as models source
code, exécutables, and documentation
• Process: A software engineering process is a
definition of the complete set of activities
needed to transform users’ requirements into
a product. A process is a template for creating
projects
 Tools
• Tools: Software that is used to automate the
activities defined in the process.
The 4 Ps in software development.
 People Are Crucial

• People are involved in the development of a

software product throughout its entire life
cycle.
• They finance the product, schedule it, develop
it, manage it, test it, use it,and benefit from it.
• Therefore, the process that guides this
development must be people oriented, that is,
one that works well for the people using it.
Development Processes Affect People
• The way in which a software project is
organized and managed profoundly affects the
people involved in the project
• Concepts such as feasibility, risk management,
team organization, project scheduling, and
project understandability all play important
• Project feasibility: Most people do not enjoy
working on projects that are deemed
infeasible—nobody wants to go down with
the ship.
• Infeasible projects can then be terminated at
an early stage, thus alleviating morale
problems.
• Risk management: Similarly, when people
sense that risks have not been analyzed and
reduced, they become uneasy.
• Team structure: People work most effectively
in small groups of six to eight members.
• A good architecture with well defined
interfaces between subsystems and
components makes such a division of effort
possible.
• Project schedule: When people believe that a
schedule is unrealistic, morale will plummet—
people don’t like to go to work knowing that
no matter how hard they try, they will never
be able to produce the expected results
• Project understandability: People like to know
what they are doing; they want to understand
the whole picture. The architecture
description provides an overview for everyone
involved in a project
• .
• Sense of accomplishment: In an iterative life
cycle, people receive frequent feedback,
which in turn, provides closure.
• Frequent feedback and the resulting closure
increases the work tempo. A fast work pace
combined with frequent closure heightens
people’s sense of accomplishment
 Projects Make the Product

• A development project results in a new

release of a product.
• The first project in the life cycle develops and
releases the initial system, or product.
• Successive project cycles extend the life of the
system over many releases.
• Throughout its life cycle, a project team has to
be concerned with change, iterations, and the
organizational pattern within which the
project is conducted:
• A sequence of change:
• Every cycle, every phase, and, yes, every iteration
changes the system from one thing to something
else.
• The first development cycle is a special case that
changes the system from nothing into something.
• Each cycle leads to a release, and beyond a
sequence of cycles, change continues for
generations
• series of iterations:Within each phase of a cycle,
workers carry out the activities of the phase
through a series of iterations.
• Each iteration implements a set of related use
cases or mitigates some risks.
• In an iteration developers proceed through a
series of workflows: requirements, design,
implementation, and test.
• Since each iteration goes through each of these
workflows, we can think of an iteration as a
miniproject.
• An organizational pattern: A project involves a team of
people assigned to accomplish a result within business
constraints, that is, time, cost, and quality.
• The people work as different workers. The idea of
“process” is to provide a pattern within which people
as workers execute a project.
• This pattern or template indicates the types of workers
the project needs and the artifacts with which it is to
work.
• The process also offers a lot of guidelines, heuristics,
and documentation practices that help the assigned
people do their job.
 Product Is More Than Code
• The product developed is a software system.
• The term product here refers not just to the code that is
delivered but to the whole system
• A system is all the artifacts that it takes to represent it in
machine or human readable form to the machines, the
workers, and the stakeholders.
• The machines are tools, compilers, or target computers.
• Workers include management, architects, developers,
testers, marketers, administrators, and others.
• Stakeholders are the funding authorities, users,
salespeople, project managers, line managers, production
people, regulatory agencies, and so on.
 Artifacts

• Artifact is a general term for any kind of

information created, produced,changed, or
used by workers in developing the system.
• Some sample artifacts are UML diagrams and
their associated text, user-interface sketches
prototypes and components, test plans and
test procedures etc..
 The Software Process
• A structured set of activities required to
develop a software system
– Specification
– Design
– Validation
– Evolution
• A software process model is an abstract
representation of a process
– It presents a description of a process from some particular
perspective
 Software Life Cycle
• The phases necessary to develop and maintain a
software system. These phases include:
– Requirements (Specification)
– Design
– Implementation (Coding)
– Testing (Validation)
– Maintenance (Evolution)
• A software process model is an abstract
representation of how these phases can be
addressed.

64
Process Flow

65
 Process Flow
 Linear process flow executes each of the five activities
in sequence.
 An iterative process flow repeats one or more of the
activities before proceeding to the next.
 An evolutionary process flow executes the activities in a
circular manner. Each circuit leads to a more complete
version of the software.
 A parallel process flow executes one or more activities
in parallel with other activities ( modeling for one aspect
of the software in parallel with construction of another
aspect of the software.

66
 Process Assessment and Improvement
• SP cannot guarantee that software will be delivered on time, meet the needs, or has the desired
technical characteristics. However, the process can be assessed to ensure that it meets a set of
basic process criteria that have been shown to be essential for a successful software engineering.

• Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step
process assessment model that incorporates five phases: initiating, diagnosing, establishing,
acting and learning.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a
diagnostic technique for assessing the relative maturity of a software organization; uses
the SEI CMM as the basis for the assessment [Dun01]
• SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in developing
an objective evaluation of the efficacy of any defined software process. [ISO08]

• ISO 9001:2000 for Software—a generic standard that applies to any organization that
wants to improve the overall quality of the products, systems, or services that it provides.
Therefore, the standard is directly applicable to software organizations and companies.
[Ant06]

67
 The Waterfall Model

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.

The classic life cycle suggests a systematic, sequential approach

to software development.

68
 Advantages
• Relatively simple to understand
• Each phase of development proceeds
sequentially
• Allows managerial control where a schedule
with deadlines is set for each stage of
development
• Helps in controlling schedules, budgets, and
documentation

69
 Disadvantages
• * Requirements need to be specified before
the development proceeds.
• The changes of requirements in later phases
of the waterfall model cannot be done.
• No user involvement and working version of
the software is available when the software is
being developed
• Assumes that requirements are stable and are
frozen across the project span

70
 When to use the waterfall model:

• This model is used only when the requirements

are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are
available freely
• The project is short.

71
V Model
• It is always better to
introduce testing in the early
phase of SDLC
• Before starting the actual
testing, testing team has to
work on various activities
like preparation of Test
Strategy, Test Planning,
Creation of Test cases & Test
Scripts which is work parallel
with the development
activity which help to get the
test deliverable on time.

72
The V-Model
A variation of waterfall model
depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.

Team first moves down the left

side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.

73
 Advantages of V-model:
• Simple and easy to use.
• Testing activities like planning, test designing
happens well before coding. This saves a lot of
time. Hence higher chance of success over the
waterfall model.
• Proactive defect tracking – that is defects are
found at early stage.
• Avoids the downward flow of the defects.
• Works well for small projects where
requirements are easily understood.

74
 Disadvantages of V-model:

• Very rigid and least flexible.

• Software is developed during the
implementation phase, so no early prototypes
of the software are produced.
• If any changes happen in midway, then the
test documents along with requirement
documents has to be updated.

75
• When to use the V-model:
• The V-shaped model should be used for small
to medium sized projects where requirements
are clearly defined and fixed.
• The V-Shaped model should be chosen when
ample technical resources are available with
needed technical expertise.

76
The Incremental Model

77
 The Incremental Model
• When initial requirements are reasonably well
defined, but the overall scope of the development
effort precludes a purely linear process. A
compelling need to expand a limited set of new
functions to a later system release.
• It combines elements of linear and parallel process
flows. Each linear sequence produces deliverable
increments of the software.
• The first increment is often a core product with
many supplementary features. Users use it and
evaluate it with more modifications to better meet
the needs.

78
 advantages
• Avoids the problems resulting in risk driven approach
in the software
• Understanding increases through successive
refinements
• performs cost-benefit analysis before enhancing
software with capabilities.
• Incrementally grows in effective solution after every
iteration
• Does not involve high complexity rate
• Early feedback is generated because implementation
occurs rapidly for a small subset of the software

79
 Disadvantages
• Required planning at the management and
technical level
• Becomes invalid when there is time constraint
on the project schedule or when the users
cannot accept the phased deliverables

80
• When to use the Incremental model:
• This model can be used when the requirements
of the complete system are clearly defined and
understood.
• Major requirements must be defined; however,
some details can evolve with time.
• There is a need to get a product to the market
early.
• A new technology is being used
• Resources with needed skill set are not
available
• There are some high risk features and goals. 81
 Evolutionary Models
• Software system evolves over time as requirements often
change as development proceeds. Thus, a straight line to a
complete end product is not possible. However, a limited
version must be delivered to meet competitive pressure.
• Usually a set of core product or system requirements is well
understood, but the details and extension have yet to be
defined.
• You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
• It is iterative that enables you to develop increasingly more
complete version of the software.
• Two types are introduced, namely Prototyping and Spiral
models.

82
 Evolutionary Models: Prototyping

• When to use: Customer defines a set of general objectives but does not identify
detailed requirements for functions and features. Or Developer may be unsure of the
efficiency of an algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the
objective, identify whatever requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and modeling (quick design) occur.
Quick design focuses on a representation of those aspects the software that will be
visible to end users. ( interface and output). Design leads to the construction of a
prototype which will be deployed and evaluated. Stakeholder’s comments will be used
to refine requirements .
• Both stakeholders and software engineers like the prototyping paradigm. Users get a
feel for the actual system, and developers get to build something immediately.
However, engineers may make compromises in order to get a prototype working
quickly. The less-than-ideal choice may be adopted forever after you get used to it.

83
Evolutionary Models: Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

84
 Advantages
• Provides a working model to the user early in the process,
enabling early assessment and increasing user’s confidence
• The developer gains experience and insight by developing
a prototype thereby resulting in better implementation of
requirements
• The prototyping model serves to clarify requirements,
which are not clear, hence reducing ambiguity and
improving communication between the developers and
users
• There is a great involvement of users in software
development. Hence the requirements of the users are met
to the greatest extent
• Helps in reducing risks associated with the software

85
 DISADVANTAGES
• If the user is not satisfied by the developed prototype , then a new
prototype is developed. This process goes on until a perfect
prototype is developed. Thus, this model is time consuming and
expensive
• The developer loses focus of the real purpose of prototype and
hece, may compromises with the quality of the software. For
example, developers may use some inefficient algorithms or
inappropriate programming languages while developing prototype
• Prototyping can lead to false expectations.
• The primary goal of prototyping is speedy development, thus, the
system design can suffer as it is developed in series without
considering integration of all other components

86
 Evolutionary Models: The Spiral
• It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall
model and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems.
• Two main distinguishing features: one is cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk. The other is a set of anchor point
milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
• A series of evolutionary releases are delivered. During the early iterations, the release might be a model
or prototype. During later iterations, increasingly more complete version of the engineered system are
produced.
• The first circuit in the clockwise direction might result in the product specification; subsequent passes
around the spiral might be used to develop a prototype and then progressively more sophisticated
versions of the software. Each pass results in adjustments to the project plan. Cost and schedule are
adjusted based on feedback. Also, the number of iterations will be adjusted by project manager.
• Good to develop large-scale system as software evolves as the process progresses and risk should be
understood and properly reacted to. Prototyping is used to reduce risk.
• However, it may be difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise.

87
Evolutionary Models: The Spiral

88
 What is it?
• The Spiral Development ( or Lifecycle) Model
is a systems development method used in
information technology.
• It combines the features of the prototyping
model and the waterfall model.
• It is favored for large, expensive, and
complicated models.

89
 Steps of the Spiral Model
1. Define the problem with as much detail as
possible by interviewing the client and
potential users of the system, as well as,
studying any existing system.
2. A preliminary design is created for the new
system.
3. A first prototype of the new system is
constructed from the preliminary design and
is a scaled down version of the final product.

90
 Steps of the Spiral Model
4. A second prototype is derived by the
following procedure
– Evaluate the first prototype for strengths,
weaknesses and risks
– Define the requirements of the 2nd prototype
– Plan and design the 2nd prototype
– Construct and test the 2nd prototype

91
 Steps of the Spiral Model
5. At this point the customer may decide to
scrap the whole project if the risk is too high.
– Development cost overruns
– Operating-cost miscalculation
– Other factors that might result in a substandard
product

92
 Steps of the Spiral Model
6. Evaluate the current prototype in the same
way as the previous prototype and create
another one if needed
7. Iterate the proceeding steps until the
customer is satisfied that the current
prototype represents the final product.
8. Construct the final system

93
 Steps of the Spiral Model
9. The final system is thoroughly evaluated and
tested and routine maintenance is carried
out for the life of the product.

94
 Advantages
• Estimates of the budget and schedule become more
realistic as work progresses because of the questions that
have been raised
• Easier to cope with the changes inherent to software
development
• Software engineers can start working on the project earlier
rather than wading through a lengthy early design process.
• Re-evaluation after each step allows changes in user
perspectives, technology advances, or financial
perspectives
• Estimation of budget and schedule gets realistic as the
work progressses

95
 Disadvantages
• Estimates of budget and time are harder to
judge at the beginning of the project since the
requirements evolve through the process

96
 When to use Spiral model:
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise
because of potential changes to economic
priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research 97
 Three Concerns on Evolutionary Processes

• First concern is that prototyping poses a problem to project planning

because of the uncertain number of cycles required to construct the
product.
• Second, it does not establish the maximum speed of the evolution. If
the evolution occur too fast, without a period of relaxation, it is certain
that the process will fall into chaos. On the other hand if the speed is
too slow then productivity could be affected.
• Third, software processes should be focused on flexibility and
extensibility rather than on high quality. We should prioritize the speed
of the development over zero defects. Extending the development in
order to reach high quality could result in a late delivery of the product
when the opportunity niche has disappeared.

98
 Problem 1
• Suppose you have to develop software for a
client with minimum risk involved in
development. But the client is not in a
position to define the detailed input and
output requirements. In this situation which
software process model would you use?
Justify your answer

99
 Problem 2
• Expert solutions Inc. is a company engaged in
software consultancy and wants to set up a
specialized software development
environment to support system software
activities. There are no guidelines available
with the management for setting up such a
centre as they have so far only worked in
application areas. Suggest a process model
which can help the company set up its
operations and develop software
100