Unit 1:

Introduction to Software Engineering

Dr. Rachna Patel

Department of CE and AI&DS

Unit-1: Introduction to Software Engg. 1

 Unit – 1: Introduction to Software Engineering
■ Introduction of software engineering:
■ Changing nature of the software
■ Legacy software
■ Software development myths
■ Generic view of Process:
■ Software engineering - A layered technology
■ Process framework
■ Capability Maturity Model Integration (CMMI)
■ Process technology
■ Product and process
■ Perspective process models:
■ Waterfall model
■ Incremental model
■ Evolutionary process models:
■ Prototyping/ Prototype model
■ Spiral Model
■ Concurrent development model
2
Ariane 5 - One bug, one crash
■ It took the European Space Agency
10 years and $7 billion to produce
Ariane 5, a giant rocket capable of
hurling a pair of three-ton satellites
into orbit with each launch and
intended to give Europe
overwhelming supremacy in the
commercial space business.
■ Issue was a small computer
program trying to stuff a 64-bit
number into a 16-bit space.

One bug, one crash.

Of all the careless lines of code recorded
in the history of computer science

3
Y2K bug (millennium bug)
■ The Y2K bug was a computer
flaw, or bug, that may have
caused problems when
dealing with dates beyond
December 31, 1999.
■ The flaw, faced by computer
programmers and users all
over the world on January 1,
2000, is also known as the
"millennium bug..
As the year 2000 approached,
■ Computer engineers used a
computer programmers
.
Instead of a date reading realized that computers might
1970, it read 70. not interpret
00 as 2000, but as 1900

4
Why to Study Software Engineering?
Software Development Life Cycle without Software Engineering

1 2 3 4
How the How the How the How the
Customer Project System Programme
Explains Leader Analyst r Works
Requirement understand it design it on it

5
Why to Study Software Engineering?
Software Development Life Cycle without Software Engineering

5 6 7 8
How the How the What How the
Business Project Operations Customer
Consultant was Installed was
describe it documented billed
6
Why to Study Software Engineering?
Software Development Life Cycle
without Software Engineering

Software development
Process needs to be
engineered to avoid
the communication gape
& to meet the actual
requirement of customer
9 10 within stipulated budget
How it What the
& time
was customer
supported really needed
7
SDLC without Software Engineering
Customer Requirement Solution

• Have one trunk • Have one trunk

• Have four legs • Have four legs
• Should carry load both • Should carry load both passenger
passenger & cargo & cargo
• Black in color • Black in color
• Should be herbivorous • Should be herbivorous

Our value
added
Also gives
milk

8
Software Engineering
Engineering

Design Build Product

Software Engineering

9
Software Engineering
Software engineering is the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works
efficiently in real machines.

Software Engineering is the science and art of building (designing

and writing programs) a software systems that are:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation

10
Software Engineering Cont.
■ Software Engineering is a layered technology
■ Quality
■ Main principle of Software Engineering is Quality Focus.
■ An engineering approach must have a focus on quality.
■ Total Quality Management (TQM), Six Sigma, ISO 9001, ISO 9000-
3, CAPABILITY MATURITY MODEL (CMM), CMMI & similar
approaches encourages a continuous process improvement
culture
■ Process layer
■ It is a foundation of Software Engineering
■ It is the glue the holds the technology layers
■ It defines a framework with activities for effective delivery of
software engineering technology

11
Software Engineering Cont.
■ Method
■ It provides technical how-to’s for building software
■ It encompasses many tasks including communication,
requirement analysis, design modeling, program construction,
testing and support
■ Tools
■ Computer‐aided software engineering (CASE) is the scientific
application of a set of tools and methods to a software system
which is meant to result in high‐quality, defect‐free, and
maintainable software products.
■ CASE tools automate many of the activities involved in various
life cycle phases.

12
 Changing nature of the software
Characteristics of Software
■ Software is developed or engineered
■ It is not manufactured like hardware
■ Manufacturing phase can introduce quality problem that are nonexistent
(or easily corrected) for software
■ Both requires construction of “product” but approaches are different
■ Software doesn’t “wear-out”

Infant
“Wear out”
mortality
Failure Rate

Time

Fig: Bathtub curve of hardware failure

13
Characteristics of Software cont.
Change
Failure Rate Increate failure rate due to side effect

Actual Curve

Idealized Curve

Time
Fig: Software failure curve
Slowly, the minimum failure rate level begins to rise – Software is
deteriorating due to change.

■ Although the industry is moving toward component based

construction, most software continues to be custom built

14
Software is dead…..!
■ The old School view of
Software
■ You buy it
■ You own it &
■ It’s your job to manage it
■ That is coming to an end

■ Because of web 2.0 & extensive

computing power, there is a
different generation of software
■ It is delivered via Internet
■ It looks exactly like it’s residing
on each user’s computing
device
■ Actually it reside on far away
server
15
What is Software?
■ Software is
1) Computer program that when executed provide desired
features, function & performance
2) Data Structure that enable programs to easily manipulate
information
3) Descriptive information in both hard and soft copy that
describes the operation and use of programs

+ +
Computer Data Documents
Program Structure Soft & Hard
16
Legacy Software
State-of-the art software

Why must it change?

■ Software must be adapted to meet the needs of new

computing environments or technology.
■ Software must be enhanced to implement new business
requirements.
■ Software must be extended to make it interoperable with
other more modern systems or databases.
■ Software must be re-architected to make it viable within a
network environment.

17
Software Development Myths
■ Affect managers, customers (and other non-technical
stakeholders) and practitioners.

■ Are believable because they often have elements of truth, but …

■ Invariably lead to bad decisions,

therefore …

■ Insist on reality as you navigate your way through software

engineering

18
 Software Myths

Management
Myths

Customer
Myths

“Misleading
Attitudes that Practitioner's
(Developer)
cause serious Myths
problem” are
myths.
 Management myth - 1 & 2

We have standards and We have the newest

procedures to build a computers and
system, which is enough. development tools.
Reality Reality
Are software practitioners
It takes much more than the
aware of standard’s existence?
latest model computers to do
Does it reflect modern software high-quality software
engineering practice? development.
Is it complete? Computer-aided software
Is it streamlined to improve time engineering (CASE) tools are
to delivery while still more important than
maintaining a focus on quality? hardware.
In many cases, the answer to all
of these questions is "no.“
 Management myth - 3 & 4
I outsourced the
We can add more
development activity, now
programmers and can
I can relax and can wait
catch up the schedule.
for the final working
product.
Reality Reality
Software development is not a
mechanistic process like If an organization does not
manufacturing. understand how to manage
In the words of Fred Brooks : and control software projects
"adding people to a late software internally, it will invariably
project makes it later." struggle when it outsources
People who were working must software projects.
spend time educating the
newcomers.
People can be added but only in a
planned and well-coordinated
manner.
 Customer myth - 1 & 2
A general statement of Requirement Changes can
objectives (requirements) be easily accommodated
is sufficient to start a because software is very
development. flexible.
Reality Reality

Comprehensive (detailed)
It is true that software
statements of requirements is not
requirements change, but the
always possible, an ambiguous
impact of change varies with
(unclear) “statement of objectives”
can lead to disaster.
the time at which it is
introduced.
Unambiguous (clear) requirements
can be gathered only through When requirements changes
effective and continuous are requested early the cost
communication between customer impact is relatively small.
and developer.
 Practitioner's (Developer) myth – 1 & 2

Once we write the I can’t access quality until

program, our job is done. it is running.

Reality Reality
One of the most effective
Experts say "the sooner you software quality assurance
begin 'writing code', the longer mechanisms can be applied
it will take you to get done." from the beginning of a
Industry data indicates that 60 project - the technical review.
to 80% effort expended on Software reviews are more
software will be after it is effective “quality filter” than
delivered to the customer for testing for finding software
the first time. defects.
 Practitioner's (Developer) myth – 3 & 4
Working program is the Software engineering is
only deliverable work about unnecessary
product. documentation.

Reality Reality

A working program is only one Software engineering is not

part of a software about creating documents. It
configuration. is about creating a quality
product.
A variety of work products (e.g.,
models, documents, plans) Better quality leads to
provide a foundation for reduced rework. And reduced
rework results in faster
successful engineering and, delivery times.
more important, guidance for
software support.
Generic View of Process
The Process , What is it?
■ A series of predictable steps.
■ A roadmap that helps create a timely, high quality.

Who does it?

■ Software Engineers and their managers adopt it their needs.
■ Users play a role in the process of defining, building and
testing.

25
Generic View of Process
Why is it important?
■ It provides stability, control, and organization to an activity
■ Uncontrolled activity becomes quite chaotic
■ Modern software engineering approach must be “agile"
Demand only those activities, controls and documentation that
are appropriate for the project team and the product.
What are the steps?
■ The process that you adopt depends on the software that you’re
building.

26
Software Process
A process is a collection of activities, actions and tasks that are performed
when some work product is to be created
A process is not a rigid prescription for how to build the software, rather it is
adaptable approach that enables the people doing the work to pick and choose
the appropriate set of work actions and tasks
An activity try to achieve a broad objective (e.g., communication with
stakeholders)
An activity is applied regardless of the application domain, size of the project,
complexity of the effort, or degree of accuracy 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 noticeable outcome.
Each of these activities, actions & tasks reside within a framework or model

27
Software Process
Figure in the next slide represents “The Software Process”
Each framework activity is populated by set of software engineering
actions
Each software engineering action is defined by a task set that identifies
work to be completed, product to be produced, quality assurance
points & milestones to indicate progress
The purpose of software process is
■ to deliver software in timely manner and
■ within sufficient quality to satisfy those
■ Who has given proposal for software development and
■ Those who will use software

28
Software Process Framework
Process framework
Umbrella activities
framework activity #1
Software Engineering action #1.1
Task Sets
Software Process

Work tasks
… Work products
… Quality assurance points
Software Engineering action #1.k
Task Sets Work tasks
… Work products
… Quality assurance points

framework activity #n

29
Process Framework Activities
Communication Communication Planning Software Project Plan
with Customers / which defines workflow
stockholders to that is to follow.
understand project It describes technical
requirements for task, risks, resources,
defining software product to be produced
features & work schedule

Modeling Creating models to Constructio Code

understand Generation
requirements and
n (manual or automated)
shows design of &
software to Testing
achieve (to uncover errors in
requirements the code)
Deliver Software to Customer
Collect feedback from customer based on
Deployment evaluation
Software Support

30
Types of Process Flow

31
Umbrella Activities

■ Umbrella activities applied throughout

the software project & help a software It establish a
team to manage and control progress, skeleton
quality, change & risks architecture for
■ Umbrella activities are those which software
keep running in the background engineering
throughout the software development work.

32
Umbrella Activities Cont.

Software project Risk Software quality

Tracking & Control Management assurance

Technical Reviews Measurement

Reusability
Management
Software Configuration Management

Work product preparation and production

33
Umbrella Activities Cont.
■ Software project tracking and control: allows the software
team to assess progress against the project plan and take
any necessary action to maintain the schedule.
■ Risk management: assesses (evaluates) risks that may
affect the outcome of the project or the quality of the product.
■ Software quality assurance: defines and conducts the
activities required to ensure software quality.
■ Technical reviews: assesses software engineering work
products in an effort to uncover and remove errors before
they are propagated to the next activity.
■ Measurement: defines and collects process, project and
product measures that assist the team in delivering software
that meets stakeholders’ needs.

34
Umbrella Activities Cont.
■ Software configuration management: it manages the effects
of change throughout the software process.
■ Reusability management: it defines criteria for work product
reuse (including software components) and establishes
mechanisms to achieve reusable components.
■ Work product preparation and production: it encompasses
(includes) the activities required to create work products such
as models, documents, logs, forms and lists.

35
Software Engineering Layered
Technology
Software Engineering Tools allows automation of activities
which helps to perform systematic activities. A system for the
support of software development, called computer-aided
software engineering (CASE). Examples: Testing Tools,
Bug/Issue Tracking Tools etc…

It provides technical how-to’s for building software, it

encompasses many tasks including communication,
requirement analysis, design modeling, program
construction, testing and support

It is a foundation of Software Engineering, It is the

glue the holds the technology layers, It defines a
framework activities

Defines continuous process improvement principles

36
 Software Engineering Layered Approach Cont.
Quality
Main principle of Software Engineering is Quality Focus.
An engineering approach must have a focus on quality.
Total Quality Management (TQM), Six Sigma, ISO 9001, ISO
9000-3, CAPABILITY MATURITY MODEL (CMM), CMMI & similar
approaches encourages a continuous process improvement
culture
Process Layer
It is a foundation of Software Engineering, It is the glue the holds the
technology layers together and enables logical and timely development
of computer software.
It defines a framework with activities for effective delivery of software
engineering technology
It establish the context in which technical methods are applied, work
products (models, documents, data, reports, forms, etc.) are produced,
milestones are established, quality is ensured, and change is properly
managed.
 Software Engineering Layered Approach Cont.

Method
It provides technical how-to’s for building software
It encompasses many tasks including communication, requirement
analysis, design modeling, program construction, testing and support

Tools
Software engineering tools provide automated or semiautomated
support for the process and the methods
Computer‐aided software engineering (CASE) is the scientific
application of a set of tools and methods to a software system
which is meant to result in high‐quality, defect‐free, and
maintainable software products.
CASE tools automate many of the activities involved in various
life cycle phases.
Capability Maturity Model Integration
■ Capability Maturity Model Integration (CMMI) is a successor
of CMM and is a more evolved model that incorporates best
components of individual disciplines of CMM like Software
CMM, Systems Engineering CMM, People CMM, etc. Since
CMM is a reference model of matured practices in a specific
discipline, so it becomes difficult to integrate these
disciplines as per the requirements. This is why CMMI is used
as it allows the integration of multiple disciplines as and when
needed.

Objectives of CMMI :
■ Fulfilling customer needs and expectations.
■ Value creation for investors/stockholders.
■ Market growth is increased.
■ Improved quality of products and services.
■ Enhanced reputation in Industry.

39
Capability Maturity Model Integration(cont…)
■ CMMI Model – Maturity Levels :
In CMMI with staged representation, there are five maturity levels
described as follows :
■ Maturity level 1 : Initial
■ processes are poorly managed or controlled.
■ unpredictable outcomes of processes involved.
■ ad hoc and chaotic approach used.
■ No KPAs (Key Process Areas) defined.
■ Lowest quality and highest risk.
■ Maturity level 2 : Managed
■ requirements are managed.
■ processes are planned and controlled.
■ projects are managed and implemented according to their
documented plans.
■ This risk involved is lower than Initial level, but still exists.
■ Quality is better than Initial level.
40
Capability Maturity Model Integration(cont…)
■ Maturity level 3 : Defined
■ processes are well characterized and described using
standards, proper procedures, and methods, tools, etc.
■ Medium quality and medium risk involved.
■ Focus is process standardization.
■ Maturity level 4 : Quantitatively managed
■ quantitative objectives for process performance and quality
are set.
■ quantitative objectives are based on customer requirements,
organization needs, etc.
■ process performance measures are analyzed quantitatively.
■ higher quality of processes is achieved.
■ lower risk

41
Capability Maturity Model Integration(cont…)
■ Maturity level 5 : Optimizing
■ continuous improvement in processes and their performance.
■ improvement has to be both incremental and innovative.
■ highest quality of processes.
■ lowest risk in processes and their performance.

42
Process Technology
■ Process technology tools allow a software organization to
build an automated model of the common process framework,
task sets, umbrella activities

■ Once an acceptable process has been created, other process

technology tools can be used to allocate, monitor, and even
control all software engineering tasks.

43
Product and Process
■ Product:
In the context of software engineering, product includes any
software manufactured based on the customer’s request.
This can be a problem solving software or computer based
system. It can also be said that this is the result of a project.

■ Process:
Process is a set of sequence steps that have to be followed to
create a project. The main purpose of a process is to improve
the quality of the project. The process serves as a template
that can be used through the creation of its examples and is
used to direct the project.

44
Software Process Models
■ The process model is the abstract representation of process.
■ Also known as Software development life cycle (SDLC) or
Application development life cycle Models
■ Process models prescribe a distinct set of activities, actions,
tasks and milestones (deliverables) 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 (adjusted) to meet the
needs of software engineers and managers for a specific project.

45
SDLC Phases
Communication

Deployment SDLC Planning

Software
Development
Life
Cycle

Construction Modelling

46
Different Process Models
■ Waterfall Model (Linear Sequential Model)
■ Incremental Process Model
■ Prototyping Model
■ The Spiral Model
■ Rapid Application Development Model

47
The Waterfall Model cont.
Requirement
Gathering and analysis

Design

Coding

Testing

Maintenance

48
The Waterfall Model cont.
■ In requirement gathering and analysis phase the basic
requirement of the system must be understood by software
engineer, who is also called analyst. The information domain ,
function, behavioral requirements of the system are understood.
All these requirements are then well documented and discussed
further with the customer, for reviewing.
■ In design is an intermediate step between requirement analysis
and coding.
■ Data structure
■ Software Architecture
■ Interface representation
■ Algorithmic details
The requirement are translated in some easy to represent from
using which coding can be effectively and efficiently.

49
The Waterfall Model cont.
■ Coding is a step in which design is translated into machine –
readable form. If design is done in sufficient detail then coding
can be done effectively. Programs are crated in this phase
■ Testing begins when coding is done. While performing testing
the major focus is on logical internals of the software. The
testing ensures execution of all the paths, functional behaviors.
The purpose of testing is to uncover errors, fix the bugs and meet
the customer requirements.
■ Maintenance is the longest life cycle phase. When the system is
installed and put in practical use then error may get introduced,
correcting such errors and putting it in use Is the major purpose
of maintenance activity. Similarly, enhancing system services as
new requirements are discovered is again maintenance of the
system.

50
The Waterfall Model cont.
■ When requirements for a problems are well understood then this
model is used in which work flow from communication to
deployment is linear
■ This Model also called as the Classic life cycle or linear
sequential model.
■ When to use ?
■ Requirements are very well known, clear and fixed
■ Product definition is stable
■ Technology is understood
■ There are no ambiguous (unclear) requirements
■ Ample (sufficient) resources with required expertise are available
freely
■ The project is short

51
The Waterfall Model cont.
■ Advantages
■ Simple to implement and manage
■ Drawbacks
■ Unable to accommodate changes at later stages, that is required
in most of the cases.
■ Working version is not available during development. Which can
lead the development with major mistakes.
■ Deadlock can occur due to delay in any step.
■ Not suitable for large projects.

52
Incremental Process Model

53
Incremental Process Model cont.
■ The incremental model combines elements of linear and parallel
process flows.
■ This model applies linear sequence in a iterative manner.
■ Initially core working product is delivered.
■ Each linear sequence produces deliverable “increments” of the
software.
■ For example, word-processing software developed using the
incremental model
■ It might deliver basic file management, editing and document
production functions in the first increment
■ more sophisticated editing in the second increment;
■ spelling and grammar checking in the third increment; and
■ advanced page layout capability in the fourth increment.

54
Incremental Process Model cont.
■ When to Use ?
■ When the requirements of the complete system are clearly
defined and understood but staffing is unavailable for a
complete implementation by the business deadline.
■ Advantages
■ Generates working software quickly and early during the
software life cycle.
■ It is easier to test and debug during a smaller iteration.
■ Customer can respond to each built.
■ Lowers initial delivery cost.
■ Easier to manage risk because risky pieces are identified and
handled during iteration.

55
Rapid Application Development Model
Team - 1
Modeling

Construction
Communicatio Integration
n Delivery
Team - 2 Feedback

Planning Modeling Deploymen

Construction t

Team - 3
Component Reuse
Business Modeling Automatic Code
Modeling Generatio
Data Modeling Construction n
Process Modeling Testing

56
RAD Model Cont.
■ It is also know as RAD Model
■ It is a type of incremental model in which; components or
functions are developed in parallel.
■ Rapid development is achieved by component based
construction
■ This can quickly give the customer something to see and use
and to provide feedback.
■ Communication
■ This phase is used to understand business problem.
■ Planning
■ Multiple software teams work in parallel on different
systems/modules.

57
RAD Model Cont.
■ Modeling
■ Business Modeling: among the business.
■ Ex. What kind of information drives (moves)?
■ Who is going to generate information?
■ From where information comes and goes?
■ Data Modeling: Information refine into set of that
are to support business.
■ Process Modeling: transforms to
necessary to implement business.
■ Construction
■ It highlighting the .
■ Deployment
■ Deliver to customer basis on subsequent iteration.

58
RAD Model Cont.
■ When to Use ?
■ There is a need to create a system that can be modularized in
2-3 months of time.
■ High availability of designers and budget for modeling along
with the cost of automated code generating tools.
■ Resources with high business knowledge are available.
■ Advantages
■ Reduced development time.
■ Increases reusability of components.
■ Quick initial reviews occur.
■ Encourages customer feedback.
■ Integration from very beginning solves a lot of integration issues.

59
RAD Model Cont.
■ 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).

60
Difference Between RAD and Incremental Model
Sr.No. RAD Model Incremental Model
Incremental Model is a software
Rad model is a software development
development model where the product is,
model where by the components or
1. analyzed, designed, implemented and
functions are developed in parallel as if
tested incrementally until the product is
they were mini projects.
finished.

Rad model requirements and early stage In incremental model requirements and
2.
planning is not necessary. early stage planning is necessary.

RAD model is used between large and Incremental model can’t handle large
3.
small project. project.

There is also low amount risk in

4. There is low amount risk in RAD model.
incremental model.

In incremental model large team is not

5. In RAD model small team size is required.
required.

Flexibility to change in incremental

6. Flexibility to change in rad model is Easy.
model is Easy.

In rad model overlapping of phases is In incremental model overlapping of

7.
possible. phases is possible.

Testing is done in rad model after Testing is done in incremental model

8.
completion of coding. after every iteration of phase.

Returning to previous stage/phase in rad Returning to previous stage/phase in

9.
model is possible. incremental model is possible.

10. Cost of rad model is also Low. Cost of incremental model is also Low.

61
Evolutionary Process Models
■ When a set of core product or system requirements is well
understood but the details of product or system extensions have
yet to be defined.
■ In this situation there is a need of process model which specially
designed to accommodate product that evolve with time.
■ Evolutionary Process Models are specially meant for that which
produce an increasingly more complete version of the software
with each iteration.
■ Evolutionary Models are iterative.
■ Evolutionary models are
■ Prototyping Model
■ Spiral Model
■ Concurrent Development Model

62
Prototyping model
■ Prototyping model is appropriate when
■ Customers have general objectives of software but do not have
detailed requirements for functions & features.
■ Developers are not sure about efficiency of an algorithm &
technical feasibilities.
■ It serves as a mechanism for identifying software requirements.
■ Prototype can be serve as “the first system”.
■ Both stakeholders and software engineers like prototyping model
■ Users get feel for the actual system
■ Developers get to build something immediately

63
Prototyping model cont.

64
Prototyping model cont.
■ It works as follow
■ Communicate with stockholders & define objective of Software
■ Identify requirements & design quick plan
■ Model a quick design (focuses on visible part of software)
■ Construct Prototype & deploy
■ Stakeholders evaluate this prototype and provides feedback
■ Iteration occurs and prototype is tuned based on feedback
■ Problem Areas
■ Customer 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.
65
Prototyping model cont.
■ Advantages
■ Users are actively involved in the development
■ Since in this methodology a working model of the system is
provided, the users get a better understanding of the system
being developed
■ Errors can be detected much earlier

66
The Spiral Model

67
The Spiral Model cont.
■ The Spiral model is an evolutionary process model that couples
iterative nature of prototyping with the controlled and
systematic aspects of waterfall model
■ It provides the potential for rapid development.
■ Software is developed in a series of evolutionary releases.
■ Early iteration release might be prototype but later iterations
provides more complete version of software.
■ It is divided into framework activities. Each activity represent one
segment of the spiral
■ Each pass through the planning region results in adjustments to
■ the project plan
■ Cost & schedule based on feedback

68
The Spiral Model cont.
■ Customer communication: it is suggested to establish customer
communication
■ Planning: All planning activities are carried out in order to define
resources time line and other project related activities.
■ Risk Analysis: The tasks required to calculate technical and
management risks are carried out.
■ Engineering: In this task region, tasks required to build one or
more representations of applications are carried out.
■ Construct and release: All necessary tasks required to construct,
test, install the application are conducted. Some tasks that are
required to provide user support are also carried out in this task
region.
■ Customer evaluation: Customer's feedback is obtained and
based on customer evaluation required tasks are performed and
impended at installation stage.

69
The Spiral Model cont.
■ When to use Spiral Model?
■ For development of large scale / high-risk projects.
■ When costs and risk evaluation is important.
■ Users are unsure of their needs.
■ Requirements are complex.
■ New product line.
■ Significant (considerable) changes are expected.
■ Advantages
■ High amount of risk analysis hence, avoidance of Risk is
enhanced.
■ Strong approval and documentation control.
■ Additional functionality can be added at a later date.
■ Software is produced early in the Software Life Cycle.

70
The Spiral Model cont.
■ Disadvantages
■ Can be a costly model to use.
■ Risk analysis requires highly specific expertise.
■ Project’s success is highly dependent on the risk analysis phase.
■ Doesn’t work well for smaller projects.

71
WIN-WIN Spiral Model
■ The spiral model suggests a framework activity that addresses
customer communication. The objective of this activity is to elicit
project requirements from the customer. In an ideal context, the
developer simply asks the customer what is required and the
customer provides sufficient detail to proceed. Unfortunately, this
rarely happens. In reality, the customer and the developer enter
nto a process of negotiation, where the customer may be asked
to balance functionality, performance, and other product or
system characteristics against cost and time to market.
■ The best negotiations strive for a “win-win” result. That is, the
customer wins by getting the system or product that satisfies the
majority of the customer’s needs and the developer wins by
working to realistic and achievable budgets and deadlines.
■ Customer’s WIN means: Obtaining the system that satisfies
most of the needs.
■ Developer’s WIN means: Getting the work done with realistic and
achievable budgets and deadlines.

72
WIN-WIN Spiral Model Cont.

73
WIN-WIN Spiral Model Cont.
Boehm’s WINWIN spiral model defines a set of negotiation
activities at the beginning of each pass around the spiral. Rather
than a single customer communication activity, the following
activities are defined:
■ Identification of the system or subsystem’s key “stakeholders.”
■ Determination of the stakeholders’ “win conditions.”
■ Negotiation of the stakeholders’ striving for win condition. With
the concerned software project team reconcile for WIN-WIN
result then determine next level objectives, constraints and
alternatives.
■ Evaluate process and product. Analyze and resolve the risks
■ Define next level of product and process
■ Validate process and product definitions.
■ Take a review of product and give necessary comments on it.

74
Concurrent Development

75
Concurrent Development Cont.
■ This model is also called as concurrent engineering model. In
this model the framework activities are represented as series of
tasks. For example the modelling activity can performed in
various states. These states contain various activities or task.
■ For instance : modelling activity can be initially in under
development state. Then when certain processes or activities are
going on it might be in awaiting changes state. Some reviews or
revisions might be carried out on the developed or partially
developed software. Hence under review or under revision might
be some states.
■ Finally the software product goes in done state. Sometimes
some inconsistencies in analysis model may trigger some
changes in the existing product. Then for implementing those
changes product has to undergo awaiting changes state.

76
Concurrent Development Cont.
Advantages
■ All types of software development can be done using concurrent
development model.
■ This model provides accurate picture of current state of project.
■ Each activity or task can be carried out concurrently. Hence this
model is an efficient process model.

77
Software Application Domains
System
Software
Point of Sale,
Artificial Customized
Application
intelligence Software
Software
Software

Software
Application Engineerin
Web Domains
Application g /
Scientific
Software

Product line Embedded

Software Software

78