Introduction to Software

Engineering

Ref. book :
Software Engineering by Roger Pressman
Chapter : Topic Covered
 Evolving Role of Software
 Hardware vs. Software
 Software characteristics
 Changing nature of software
 Evolution of Software
 Software Myths
 Evolving Role of Software
 Today, software takes on a dual role. It is a product, and at the same time, the vehicle
for delivering a product.
 As a product,
 it delivers the computing potential embodied(included) by computer hardware or more
broadly, by a network of computers that are accessible by local hardware.
 Whether it resides within a mobile phone or operates inside a mainframe computer, software
is an information transformer—producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as a single bit or as complex as a multimedia
presentation derived from data acquired from dozens of independent sources.
 As the vehicle,
 used to deliver the product,
 software acts as the basis for the control of the computer (operating systems), the
communication of information (networks), and the creation and control of other programs
(software tools and environments).
 What is Software ?
Software can define as:

Instruction – executed provide desire features, function & performance.

Data structure – to adequately manipulate operation.

Documents – operation and use of the program.

Software products may be developed for a particular customer or may be developed for
a general market.

Software products may be

Generic - developed to be sold to a range of different customers e.g. PC
software such as Excel or Word.

Bespoke (custom) - developed for a single customer according to their
specification.
Hardware vs. Software
Hardware Software

 Manufactured  Developed/ engineered

 wear out  deteriorate
 Built using components  Custom built
 Relatively simple  Complex
Manufacturing vs. Development
 Once a hardware product has been
manufactured, it is difficult or impossible to
modify. In contrast, software products are
routinely modified and upgraded.
 In hardware, hiring more people allows you
to accomplish more work, but the same
does not necessarily hold true in software
engineering.
 Unlike hardware, software costs are
concentrated in design rather than
production.
Failure curve for Hardware
Failure curve for Hardware
The relationship, often called the “bathtub curve” indicates that
 hardware exhibits relatively high failure rates early in its life (these failures are
often attributable to design or manufacturing defects);
 defects are corrected and the failure rate drops to a steady-state level (hopefully,
quite low) for some period of time.
 As time passes, however, the failure rate rises again as hardware components
suffer from the cumulative effects of dust, vibration, abuse, temperature
extremes, and many other environmental maladies. Stated simply, the hardware
begins to wear out.
Failure curve for Software
Failure curve for Software
Software is not susceptible to the environmental maladies that cause hardware to wear
out. In theory, therefore, the failure rate curve for software should take the form of the
“idealized curve” shown in Figure
 Undiscovered defects will cause high failure rates early in the life of a program.
However, these are corrected and the curve flattens as shown.
 The idealized curve is a gross oversimplification of actual failure models for
software.
 However, the implication is clear—software doesn’t wear out. But it does
deteriorate!
Failure curve for Software
During its life, software will undergo change. As changes are made, it is likely that
errors will be introduced, causing the failure rate curve to spike as shown in the “actual
curve”.
Before the curve can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again. Slowly, the minimum failure rate level
begins to rise—the software is deteriorating due to change.
When a hardware component wears out, it is replaced by a spare part.
There are no software spare parts.
Every software failure indicates an error in design or in the process through which
design was translated into machine executable code. Therefore, software maintenance
involves considerably more complexity than hardware maintenance.
Component Based vs. Custom Built
 Hardware products typically employ
many standardized design
components.
 Most software continues to be custom
built.
 The software industry does seem to
be moving (slowly) toward
component-based construction.
 Software characteristics

Software is developed or engineered; it is not
manufactured.

Software does not “wear out” but it does
deteriorate.

Software continues to be custom built, as
industry is moving toward component based
construction.
Software Application Domains

System software

Application software

Engineering/scientific software

Embedded software

Product line software

Web applications

Artificial intelligence software
 Software Application Domains
 System software
 a collection of programs written to service other programs.
 Some system software (e.g., compilers, editors, and file management utilities) processes
complex, but determinate, information structures.
 Other systems applications (e.g., operating system components, drivers, networking
software, telecommunications processors) process largely indeterminate data.
 In either case, the systems software area is characterized by heavy interaction with computer
hardware; heavy usage by multiple users; concurrent operation that requires scheduling,
resource sharing, and sophisticated process management; complex data structures; and
multiple external interfaces.
 Application software
 stand-alone programs that solve a specific business need.
 Applications in this area process business or technical data in a way that facilitates business
operations or management/technical decision making.
 In addition to conventional data processing applications, application software is used to
control business functions in real time (e.g., point-of-sale transaction processing, real-time
manufacturing process control).
 Software Application Domains
 Engineering/scientific software
 Characterized by "number crunching" algorithms.
 Applications range from astronomy to volcano logy, from automotive stress analysis to
space shuttle orbital dynamics, and from molecular biology to automated manufacturing.
 Ex. Computer Aided Design (CAD), system stimulation etc.
 Embeded software
 resides within a product or system and is used to implement and control features and
functions for the end user and for the system itself.
 Embedded software can perform limited and esoteric functions (e.g., key pad control for a
microwave oven) or provide significant function and control capability (e.g., digital
functions in an automobile such as fuel control, dashboard displays, and braking systems).
 Product-line software
 designed to provide a specific capability for use by many different customers.
 Product-line software can focus on a limited and esoteric(intended for) marketplace (e.g.,
inventory control products) or address mass consumer markets (e.g., word processing,
spreadsheets, computer graphics, multimedia, entertainment, database management, and
personal and business financial applications).
 Software Application Domains
 Web applications
 called “WebApps,” this network-centric software category spans a wide array of
applications.
 In their simplest form, WebApps can be little more than a set of linked hypertext files that
present information using text and limited graphics. However, as Web 2.0 emerges,
WebApps are evolving into sophisticated computing environments that not only provide
stand-alone features, computing functions, and content to the end user, but also are
integrated with corporate databases and business applications.
 Artificial intelligence software
 makes use of nonnumerical algorithms to solve complex problems that are not amenable to
computation or straightfor ward analysis.
 Applications within this area include robotics, expert systems, pattern recognition (image
and voice), artificial neural networks, theorem proving, and game playing.
Software Process
Chapter - Topic Covered
 Layered Technology
 Software Process Framework
 Generic Process Framework Activities
 Umbrella Activities
 CMMI Level
Overview
 What? A software process – as a framework for
the tasks that are required to build high-quality
software.
 Who? Managers, software engineers, and
customers.
 Why? Provides stability, control, and organization
to an otherwise chaotic activity.
 Steps? A handful of activities are common to all
software processes, details vary.
 Work product? Programs, documents, and data.
What is software engineering?
 Definition :
 (1) The application of 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 (1) above
 Its a discipline that is concerned with all aspects of software
production.

 Software engineers should adopt

 Systematic and organized approach to their work
 Use appropriate tools and techniques depending on the
problem to be solved
 The development constraints and the resources available
 Apply Engineering Concepts to developing Software
 Challenge for Software Engineers is to produce high quality
software with finite amount of resources & within a predicted
schedule
Software Engineering – Layered
Technology

Layered Technology

Tools: CASE preferred

Methods: technical “how to’s”

Process model: the “framework”

A quality focus: the “bedrock”

Layered Technology

A quality Focus
 Every organization is rest on its commitment to quality.
 Total quality management, Six Sigma, or similar continuous
improvement culture and it is this culture ultimately leads to
development of increasingly more effective approaches to software
engineering.
 The bedrock that supports software engineering is a quality focus.

Process:
 It’s a foundation layer for software engineering.
 It’s define framework for a set of key process areas (KRA) for
effectively manage and deliver quality software in a cost effective
manner
 The processes define the tasks to be performed and the order in which
they are to be performed
Layered Technology

Methods:
 It provide the technical how-to's for building software.
 Methods encompass a broad array of tasks that include requirements
analysis, design, program construction, testing, and support.
 There could be more than one technique to perform a task and different
techniques could be used in different situations.
Tools:
 Provide automated or semi-automated support for the process,
methods and quality control.
 When tools are integrated so that information created by one tool can
be used by another, a system for the support of software development,
called computer-aided software engineering (CASE)
 Software Process
 A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created.
 An activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the project,
complexity of the effort, or degree of rigor with which software engineering is to be
applied.
 An action (e.g., architectural design) encompasses a set of tasks that produce a major
work product (e.g., an architectural design model).
 A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.
 In the context of software engineering, a process is not a rigid prescription for how to
build computer software. Rather, it is an adaptable approach that enables the people
doing the work (the software team) to pick and choose the appropriate set of work
actions and tasks. The intent is always to deliver software in a timely manner and with
sufficient quality to satisfy those who have sponsored its creation and those who will
use it.
 Software Process Framework
 A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to
all software projects, regardless of their size or complexity.
 In addition, the process framework encompasses a set of umbrella activities that are
applicable across the entire software process.
Software Process Process Framework
Process framework Umbrella Activities
Umbrella Activities
Framework activities
Framework activity
1
work tasks
work products
milestones & deliverable
QA checkpoints
Framework activity
n
Process Framework

•Each framework activities is

populated by a set for software
engineering actions – a collection
of related tasks.
• Each action has individual work
task.
Software Process Framework
 Software Process Framework
 A generic process framework for software engineering encompasses five activities:
 Communication:
 Heavy communication with customers, stakeholders, team
 Encompasses requirements gathering and related activities
 The intent is to understand stakeholders’ objectives for the project and to gather requirements
that help define software features and functions

 Planning:
 Any complicated journey can be simplified if a map exists. A software project is a
complicated journey, and the planning activity creates a “map” that helps guide the team as it
makes the journey.
 The map—called a software project plan—defines the software engineering work by
describing the technical tasks to be conducted, the risks that are likely, the resources that will
be required, the work products to be produced, and a work schedule.
 Workflow that is to follow
 Describe technical task, likely risk, resources will require, work products to be produced and
a work schedule.

 Modeling:
 Help developer and customer to understand requirements (Analysis of requirements) &
Design of software
 Software Process Framework
 A generic process framework for software engineering encompasses five activities:
 Construction
 Code generation: either manual or automated or both
 Testing – to uncover error in the code.

 Deployment:
 Delivery to the customer for evaluation
 Customer provide feedback
Software Process Framework
Software Process Framework
 Umbrella Activities
 Software engineering process framework activities are complemented by a number of
umbrella activities.
 In general, umbrella activities are applied throughout a software project and help a
software team manage and control progress, quality, change, and risk. Typical
umbrella activities include:
 Software project tracking and control
 Assessing progress against the project plan.
 Take adequate action to maintain schedule.

 Formal technical reviews

 Assessing software work products in an effort to uncover and remove errors
before goes into next action or activity.

 Software quality assurance

 Define and conducts the activities required to ensure software quality.

 Software configuration management

 Manages the effects of change.
 Umbrella Activities
 Document preparation and production
 Help to create work products such as models, documents, logs, form and list.

 Reusability management
 Define criteria for work product reuse
 Mechanisms to achieve reusable components.

 Measurement
 Define and collects process, project, and product measures
 Assist the team in delivering software that meets customer’s needs.

 Risk management
 Assesses risks that may effect that outcome of project or quality of product (i.e.
software)
 Software Evolution
 The Law of Continuing Change (1974): E-type (Real
world implemented) systems must be continually
adapted else they become progressively less
satisfactory.
 The Law of Increasing Complexity (1974): As an E-type
system evolves its complexity increases unless work is
done to maintain or reduce it.
 The Law of Self Regulation (1974): The E-type system
evolution process is self-regulating with distribution of
product and process measures close to normal.
 The Law of Conservation of Organizational Stability
(1980): The average effective global activity rate in an
evolving E-type system is invariant over product lifetime.
 Software Evolution
 The Law of Conservation of Familiarity (1980): As an E-type
system evolves all associated with it, developers, sales
personnel, users, for example, must maintain mastery of its
content and behavior to achieve satisfactory evolution.
 The Law of Continuing Growth (1980): The functional content
of E-type systems must be continually increased to maintain
user satisfaction over their lifetime.
 The Law of Declining Quality (1996): The quality of E-type
systems will appear to be declining unless they are rigorously
maintained and adapted to operational environment changes.
 The Feedback System Law (1996): E-type evolution processes
constitute multi-level, multi-loop, multi-agent feedback systems
and must be treated as such to achieve significant
improvement over any reasonable base.
 Software Myths
Definition: Beliefs about software and the process used to build it. Myths have number
of attributes that have made them insidious (i.e. dangerous).
Misleading Attitudes - caused serious problem for managers and technical people.
Management myths
Managers in most disciplines, are often under pressure to maintain budgets, keep
schedules on time, and improve quality.

Myth1: We already have a book that's full of standards and procedures for building
software, won't that provide my people with everything they need to know?
Reality :
 Are software practitioners aware of existence standards?
Does it reflect modern software engineering practice?
Is it complete? Is it streamlined to improve time to delivery while still maintaining a
focus on quality?
 Software Myths
Myth2: If we get behind schedule, we can add more programmers and catch up
Reality:
Software development is not a mechanistic process like manufacturing. Adding people
to a late software project makes it later.
People can be added but only in a planned and well coordinated manner

Myth3: If I decide to outsource the software project to a third party, I can just relax and
let that firm build it.
Reality:
If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsource software projects
 Software Myths
Customer Myths
Customer may be a person from inside or outside the company that has requested
software under contract.

Myth: A general statement of objectives is sufficient to begin writing programs— we

can fill in the details later.
Reality:
A poor up-front definition is the major cause of failed software efforts.
A formal and detailed description of the information domain, function, behavior,
performance, interfaces, design constraints, and validation criteria is essential. These
characteristics can be determined only after thorough communication between customer
and developer.
Myth: Project requirements continually change, but change can be easily accommodated
because software is flexible.
Reality: Customer can review requirements and recommend modifications with
relatively little impact on cost. When changes are requested during software design, the
cost impact grows rapidly. Below mentioned figure for reference.
 Software Myths
Practitioner's myths
Myth1: Once we write the program and get it to work, our job is done.
Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll
take you to get done." Industry data indicate that between 60 and 80 percent of all
effort expended on software will be expended after it is delivered to the
customer for the first time.

Myth2: Until I get the program "running" I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be
applied from the inception of a project—the formal technical review.

Myth3: The only deliverable work product for a successful project is the working
program.
Reality: A working program is only one part of a software configuration that includes
many elements. Documentation provides a foundation for successful
engineering and, more important, guidance for software support.
 Software Myths
Myth4 : Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating
quality. Better quality leads to reduced rework. And reduced rework results in
faster delivery times.
Capability Maturity Model
Integration (CMMI)
 The Software Engineering Institute (SEI) has
developed process meta-model to measure
organization different level of process
capability and maturity.
 CMMI – developed by SEI
 The CMMI defines each process area in terms
of “specific goals” and the “specific practices”
required to achieve these goals.
 Specific goals establish the characteristics
that must exist if the activities implied by a
process area are to be effective.
 Specific practices refine a goal into a set of
process-related activities.
CMMI Level
Level 0 (Incomplete) –
 Process are not perform or not achieve all the goals and objectives
defined by the CMMI for Level I capability.
Level 1 (Performed) – All specific goals are performed as per defined by
CMMI
Level 2 (Managed) –
 All level 1 criteria have been satisfied
 In addition to Level I;
 People doing work have access to adequate resources to get job
done,
 Stakeholders are actively involved,
 Work tasks and products are monitored, controlled, reviewed,
and evaluated for conformance to process description.
Level 3 (Defined) –
 All level 2 criteria have been achieved.
 In addition;
 management and engineering processes documented
 standardized and integrated into organization-wide software
process
CMMI Level (cont.)
Level 4 (Quantitatively Managed) -
 All level 3 criteria have been satisfied.
 Software process and products are quantitatively understood
 Controlled using detailed measures and assessment.
Level 5 (Optimized) –
 Continuous process improvement is enabled by quantitative
feedback from the process and testing innovative ideas.
Software Process Model
Chapter : Topic Covered
 About software process model
 Build and Fix Model
 Why Models are needed?
 Process as a "black box“ & Problem
 Process as a “white box“ & Advantage
 Prescriptive Model
 Waterfall Model or Linear Sequential
 Incremental Process Models
 Incremental Model
 RAD Model
 Evolutionary Process Models
 Prototyping
 Spiral Model
 Concurrent Development Model
 Fourth Generation Techniques (4GT)
 Component based development (CBD)
Software process model
 Process models prescribe a distinct set of activities,
actions, tasks, milestones, and work products required to
engineer high quality software.
 Process models are not perfect, but provide roadmap for
software engineering work.
 Software models provide stability, control, and
organization to a process that if not managed can easily
get out of control
 Software process models are adapted to meet the needs
of software engineers and managers for a specific
project.
Build and Fix Model
Build and Fix Model
The earlier approach
 Product is constructed without specification or any
attempt at design.
 developers simply build a product that is reworked as
many times as necessary to satisfy the client.
 model may work for small projects but is totally
unsatisfactory for products of any reasonable size.
 Maintenance is high.
 Source of difficulties and deficiencies
 impossible to predict
 impossible to manage
Why Models are needed?
 Symptoms of inadequacy: the software crisis
 scheduled time and cost exceeded
 user expectations not met
 poor quality
Process as a "black box"

Informal
Requirements
Process

Product

Quality?
Uncertain /
Incomplete
requirement
In the beginning
Problems
 The assumption is that requirements can
be fully understood prior to development
 Interaction with the customer occurs
only at the beginning (requirements)
and end (after delivery)
 Unfortunately the assumption almost
never holds
Process as a "white box"

Informal
Requirements
Process

Product

feedback
Advantages
 Reduce risks by improving visibility
 Allow project changes as the project progresses
 based on feedback from the customer
Prescriptive Model
 Prescriptive process models advocate an orderly approach to software
engineering
 Organize framework activities in a certain order
 Process framework activity with set of software engineering actions.
 Each action in terms of a task set that identifies the work to be
accomplished to meet the goals.
 The resultant process model should be adapted to accommodate the
nature of the specific project, people doing the work, and the work
environment.
 Software engineer choose process framework that includes activities
like;
 Communication
 Planning
 Modeling
 Construction
 Deployment
Prescriptive Model
 Calling this model as “Prescribe”
because it recommend a set of
process elements, activities, action
task, work product & quality.
 Each elements are inter related to
one another (called workflow).
Waterfall Model or Classic Life
Cycle
Waterfall Model or Classic Life
Cycle
 Requirement Analysis and Definition: What - The systems services, constraints
and goals are defined by customers with system users.
 Scheduling tracking -
 Assessing progress against the project plan.
 Require action to maintain schedule.
 System and Software Design: How –It establishes and overall system
architecture. Software design involves fundamental system abstractions and
their relationships.
 Integration and system testing: The individual program unit or programs are
integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is delivered to
the customer.
 Operation and Maintenance: Normally this is the longest phase of the software
life cycle. The system is installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of the life-cycle.
 Limitations of the waterfall
model
 The nature of the requirements will not change very much During
development; during evolution
 The model implies that you should attempt to complete a given stage
before moving on to the next stage
 Does not account for the fact that requirements constantly change.
 It also means that customers can not use anything until the entire
system is complete.
 The model implies that once the product is finished, everything else is
maintenance.
 Surprises at the end are very expensive
 Some teams sit ideal for other teams to finish
 Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
Problems:
1. Real projects are rarely follow the sequential model.
2. Difficult for the customer to state all the requirement explicitly.
3. Assumes patience from customer - working version of program will not
available until programs not getting change fully.

62
Incremental Process Model

C-
Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each piece builds

on pieces already delivered
The Incremental Model
 Rather than deliver the system as a single delivery, the development
and delivery is broken down into increments with each increment
delivering part of the required functionality.
 First Increment is often core product
 Includes basic requirement
 Many supplementary features (known & unknown) remain
undelivered
 A plan of next increment is prepared
 Modifications of the first increment
 Additional features of the first increment
 It is particularly useful when enough staffing is not available for the
whole project
 Increment can be planned to manage technical risks.
 Incremental model focus more on delivery of operation product with
each increment.
The Incremental Model
 User requirements are prioritised and the highest priority requirements
are included in early increments.
 Once the development of an increment is started, the requirements are
frozen though requirements for later increments can continue to
evolve.
 Customer value can be delivered with each increment so system
functionality is available earlier.
 Early increments act as a prototype to help elicit requirements for later
increments.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the most testing.
Rapid Application Development
(RAD) Model

Makes heavy use of reusable software

RAD model
 Communication – to understand business problem.
 Planning – multiple s/w teams works in parallel on diff.
system.
 Modeling –
 Business modeling – Information flow among
business is working.
Ex. What kind of information drives?
Who is going to generate information?
From where information comes and goes?
 Data modeling – Information refine into set of data
objects that are needed to support business.
 Process modeling – Data object transforms to
information flow necessary to implement business.
 Construction – it highlighting the use of pre-existing
software component.
 Deployment – Deliver to customer basis for
subsequent iteration.
 RAD model emphasize a short development cycle.
 “High speed” edition of linear sequential model.
 If requirement are well understood and project scope is
constrained then it enable development team to create “
fully functional system” within a very short time period.
RAD Model

 If application is modularized (“Scalable Scope”), each

major function to be completed in less than three
months.
 Each major function can be addressed by a separate
team and then integrated to form a whole.
Drawback:
 For large but scalable projects
 RAD requires sufficient human resources
 Projects fail if developers and customers are not
committed in a much shortened time-frame
 Problematic if system can not be modularized
 Not appropriate when technical risks are high ( heavy
use of new technology)
Evolutionary Process Model
 Produce an increasingly more
complete version of the software with
each iteration.
 Evolutionary Models are iterative.
 Evolutionary models are:
 Prototyping
 Spiral Model
 Concurrent Development Model
 Fourth Generation Techniques (4GT)
Evolutionary Process Models :
Prototyping
Prototyping cohesive
 Best approach when:
 Objectives defines by customer are general but does not have details
like input, processing, or output requirement.
 Developer may be unsure of the efficiency of an algorithm, O.S., or the
form that human machine interaction should take.
 It can be used as standalone process model.
 Model assist software engineer and customer to better understand what is to
be built when requirement are fuzzy.
 Prototyping start with communication, between a customer and software
engineer to define overall objective, identify requirements and make a
boundary.
 Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
 Quick design leads to prototype construction.
 Prototype is deployed and evaluated by the customer/user.
 Feedback from customer/end user will refine requirement and that is how
iteration occurs during prototype to satisfy the needs of the customer.
Prototyping (cont..)
 Prototype can be serve as “the first system”.
 Both customers and developers like the prototyping paradigm.
 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.

Problem Areas:
 Customer cries foul and demand that “a few fixes” be applied to make
the prototype a working product, due to that software quality suffers as
a result.
 Developer often makes implementation in order to get a prototype
working quickly without considering other factors in mind like OS,
Programming language, etc.

Customer and developer both must be agree that the prototype is built to
serve as a mechanism for defining requirement.
Evolutionary Model: Spiral
Model
Spiral Model
 Couples iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model
 It provide potential for rapid development of increasingly more
complete version of the software.
 Using spiral, software developed in as series of evolutionary
release.
 Early iteration, release might be on paper or prototype.
 Later iteration, more complete version of software.
 Divided into framework activities (C,P,M,C,D). Each activity
represent one segment.
 Evolutionary process begins in a clockwise direction, beginning at
the center risk.
 First circuit around the spiral might result in development of a
product specification. Subsequently, develop a prototype and
then progressively more sophisticated version of software.
 Unlike other process models that end when software is delivered.
 It can be adapted to apply throughout the life of software.
Spiral Model
 Spiral Model (cont.)
Concept Development Project:
 Start at the core and continues for multiple iterations until it is
complete.
 If concept is developed into an actual product, the process
proceeds outward on the spiral.
New Product Development Project:
 New product will evolve through a number of iterations around
the spiral.
 Later, a circuit around spiral might be used to represent a
“Product Enhancement Project”
Product Enhancement Project:
 There are times when process is dormant or software team not
developing new things but change is initiated, process start at
appropriate entry point.
 Spiral models uses prototyping as a risk reduction
mechanism but, more important, enables the developer
to apply the prototyping approach at each stage in the
evolution of the product.

 It maintains the systematic stepwise approach

suggested by the classic life cycle but also incorporates
it into an iterative framework activity.
 If risks cannot be resolved, project is immediately
terminated
Problem Area:
 It may be difficult to convince customers (particularly in
contract situations) that the evolutionary approach is
controllable.
 If a major risk is not uncovered and managed, problems
will undoubtedly occur.