Software Process Models

Chapter 2 Software Process Models
Chapter 2 Software Processes
Software process models

The waterfall model
Prototype models
Incremental development
Reuse-oriented software engineering
In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
The waterfall model
Waterfall model phases

There are separate identified phases in the waterfall
model:
Requirements analysis and definition

System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
The main drawback of the waterfall model is the difficulty

of accommodating change after the process is
underway. In principle, a phase has to be complete
before moving onto the next phase.
Waterfall model problems

Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
Therefore, this model is only appropriate when the requirements
are well-understood and changes will be fairly limited during the
design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems

engineering projects where a system is developed at
several sites.
In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.
IS The Classical WATERFALL MODEL USEFUL

AT ALL?
ITERATIVE WATERFALL MODEL
ITERATIVE WATER FALL MODEL

NECESSARY CHANGES(FEEDBACK PATH) FROM
EVERY PHASE TO PRECEEDING FACE IS INTRODUC
ED
CORRECTION OF EROORS COMMITTED DURING THE
PHASE WHEN THESE ARE DETECTED AT LATER
STAGE.
EXAMPLE : DESIGN ERROR
DESIGN IS TO BE REWORK AND CHANGES
TO BE REFLECTED BACK In DESIGN DOCUMENTS
SHORT COMING OF WATERFALL MODEL

CAN NOT HANDLE DIFFERENT TYPE OF RISKS
SCHEDULE SLIPPAGE
TECHNOLOGY OBSELENCE
MAN POWER SHORTAGE

To Achieve better efficiency & Better Productivity
REAL PROJECT FIND IT DIFFICULT TO FOLLOW
RIGID PHASE SEQUANCE

IT WILL CREATE BLOCKING STATES IN THE
SYSTEM
Increment Delivery not supported

Phase overlap not supported
Limited Customer Interaction
Heavy Weight
No support for risk Handling and Code Reuse
10
V SHAPE SDLC
MODEL
11
V SHAPE SDLC MODEL

EXTENSION OF WATERFALL MODEL
FOCUSES ON ENHANCING THE QUALITY OF THE
SOFTWATE BY EXTENDING TESTING PROCEDURE
IN THE SDLC
INSTEAD OF MOVING IN A LINEAR WAY. V SAHPE
MODEL BENDS UPWARDS AFTER THE CODING
PHASE.
DEVELOPMENT & TESTING PHASES CAN BE
CONDUCTED In PARALLEL
12
DEVELOPMENT PHASES ARE CALLED VERIFICATION

TESTING PHASES ARE CALLED VALIDATION,.
V SHAPE MODEL PRODUCES EXCELLENT WORK PODUCT DELIVERY
IN THE FORM OF DETAILED DOCUMENTS and QULAITY S/W
PRODUCTS.
13
The V-Model
These slides are

designed to accompany
Software Engineering: A
Practitioners Approach,
7/e (McGraw-Hill, 2009).
14
Coping with changes In S/W DEVELOPMENT

Change is inevitable in all large software projects.
Business changes lead to new and changed system
requirements
New technologies open up new possibilities for improving
implementations
Changing platforms require application changes
Change leads to rework so the costs of change include

both rework (e.g. re- analysing requirements) as well as
the costs of implementing new functionality
15
Reducing the costs of rework

Change avoidance, where the software process includes
activities that can anticipate possible changes before
significant rework is required.
For example, a prototype system may be developed to show
some key features of the system to customers.
Change tolerance, where the process is designed so that

changes can be accommodated at relatively low cost.
This normally involves some form of incremental development.
Proposed changes may be implemented in increments that have
not yet been developed. If this is impossible, then only a single
increment (a small part of the system) may have be altered to
incorporate the change.
16
Software prototyping
A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
A prototype can be used in:
The requirements engineering process to help with requirements
elicitation and validation;
In design processes to explore options and develop a UI design;
In the testing process to run back-to-back tests.
17
PROTOTYPING
A prototype is an initial version of a software system that
is used to demonstrate concepts, try out design options,
and find out more about the problem and its possible
solutions.
Rapid iterative development of the prototype is
essential so that costs are controlled and system
stakeholders can experiment with the prototype
early in the software process.
18
Benefits of prototyping
Improved system usability.
A closer match to users real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.
19
The process of prototype development
20
Throw-away prototypes
Prototypes should be discarded after development as
they are not a good basis for a production system:
It may be impossible to tune the system to meet non-functional
requirements;
Prototypes are normally undocumented;
The prototype structure is usually degraded through rapid
change;
The prototype probably will not meet normal organisational
quality standards.
21
THROWAWAY PROTOPTYPE
22
EXPLORATORY PROTOPTYPE
23
THROW AWAY PROTOYPE ONLY PROVIDE RICH

SET OF REQUIREMENTS
A BETTER APPROACH WOULD BE TO PRODUCE
PROTOYPE WITH SOMEWHAT BETTER DESIGN AND
QUALITY MEASUUES SO THAT FINALLY AGREED
PROTOYPE MAY BE AMENDED INTO DELIVERABLE
SOFTWARE THROUGH MINIMAL MODIFICATION
RATHER THAN BEING DISCARDRD
24
PROTYPE IS CREATED WITH APPROPRATE

QUALITY MEASURES in THE EXPLORATORY
MODEL.
PROTOTYPES ARE DESIGNED IN EXTENDABE
MANNER SO THAT NEXT VERSION OF PROTOTYPE
IS IMPLEMENTED ON THE TOP OF THE PREVIOUS
ITSELF.
FINAL PRODUCT IS DELIVERED SOON AFTER THE
FINALIZATION OF SPECIFICATION
25
26
Incremental delivery
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.
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.
27
Incremental development and delivery

Develop the system in increments and evaluate each increment
before proceeding to the development of the next increment;
Normal approach used in agile methods;
Evaluation done by user/customer proxy.
Deploy an increment for use by end-users;
More realistic evaluation about practical use of software;
Difficult to implement for replacement systems as increments
have less functionality than the system being replaced.
28
29
Incremental delivery advantages

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.
30
Incremental development benefits

The cost of accommodating changing customer
requirements is reduced.
The amount of analysis and documentation that has to be
redone is much less than is required with the waterfall model.
It is easier to get customer feedback on the development

work that has been done.
Customers can comment on demonstrations of the software and
see how much has been implemented.
More rapid delivery and deployment of useful software to

the customer is possible.
Customers are able to use and gain value from the software
earlier than is possible with a waterfall process.
31
Incremental development problems

The process is not visible.
Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
System structure tends to degrade as new increments

are added.
Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.
32
Incremental delivery problems

Most systems require a set of basic facilities that are
used by different parts of the system.
As requirements are not defined in detail until an increment is to
be implemented, it can be hard to identify common facilities that
are needed by all increments.
The essence of iterative processes is that the

specification is developed in conjunction with the
software.
However, this conflicts with the procurement model of many
organizations, where the complete system specification is part of
the system development contract.
33

Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems.
Commercial-off-the-shelf (COTS) software and services are built and delivered usually
from a third party vendor. COTS can be purchased, leased or even licensed to the general
.
Process stages
public
Component analysis;
Requirements modification;
System design with reuse;
Development and integration.
Reuse is now the standard approach for building many

types of business system
34
35
Component analysis given the requirements specification , a search is made

for components to implement that specification.
Requirement modification during this stage the requirement are analyzed
using information about the component that have been discovered. They are
then modified to reflect the available component.
System design with reuse during this phase the framework of the system is
designed or an existing framework is reused. The designer take into account
the component that are used and organized the framework to cater for this.
Development and integration software that can not be externally procured is
developed and the components and COTS systems are integrated to create
a new system.
36
Types of software component that May be used

Web services that are developed according to service
standards and which are available for remote invocation.
Collections of objects that are developed as a package
to be integrated with a component framework such as
.NET or J2EE.
Stand-alone software systems (COTS) that are
configured for use in a particular environment.
37
Boehms spiral model

Process is represented as a spiral rather than as a
sequence of activities with backtracking.
Each loop in the spiral represents a phase in the
process.
No fixed phases such as specification or design - loops
in the spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout
the process.
38
Boehms spiral model of the software process
39
Spiral model sectors

Objective setting
Specific objectives for the phase are identified.
Risk assessment and reduction

Risks are assessed and activities put in place to reduce the key
risks.
Development and validation

A development model for the system is chosen which can be
any of the generic models.
Planning
The project is reviewed and the next phase of the spiral is
planned.
40
Software Development Life Cycle Models
Strengths ,Weakness
&
Applicability
Waterfall Model
Strengths
It provides structure to technically weak or
inexperienced staff .
When correctly applied, defects may be found early,
when they are relatively inexpensive to fix.
It is easy to use as development proceeds one phase
after another.
Strengths
It allows staff who have completed their phase activities
to be freed up for other projects.
It is easy to track the progress of the project using a
timeline or Gantt chart.
It provides a template into which methods for analysis
,design,code,test,and support can be placed.
Weakness
It has an inherently linear sequential nature any
attempt to go back two or more phases to correct a
problem results in major increases in cost and schedule.
Users cant see quality until the end .They cant
appreciate quality if the finished product cant be seen.
Weakness
It doesnt reflect the problem solving nature of software
development .Phases are tied rigidly to activities , not
how people or teams really work.
It isnt possible for the user to get used to the system
gradually .All training must occur at the end of the life
cycle ,when the software is running .
Weakness
Tight management and control is needed because
there is no provision for revising the requirement .
Each phase is a prerequisite for the succeeding activities
, making this method a risky choice for unprecedented
systems because it inhibits flexibility.
V-shaped Model
Strengths
The model encourages verification and validation of all
internal and external deliverables, not just the software
product.
The model encourages definition of the requirement
before designing the system , and it encourages
designing the software before building the components.
Strengths
It defines the product that the development process
should generate ; each deliverable must be testable.
It enables project management to track progress
accurately ; the progress of the project follows a timeline
, and the completion of each phase is a milestone.
Model is easy to use .
Weakness
It does not handle concurrent events .
It does not handle iterations of the phases .
The model is not equipped to handle dynamic changes
in the requirement throughout the life cycle.
The requirement are tested too late in the cycle to make
changes without affecting the schedule for the project.
Structured Evolutionary rapid prototyping model

Strengths
The end user can see the system requirements as they
are being gathered by the project team customer gets
early interaction with the system .
The model allows for flexible design and development
,including multiple iterations through life cycle phases .
Strengths
Steady , visible signs of progress are produced , making
customer secure.
Communication issues between customers and
developers are minimized.
Users tend to be more satisfied when involved
throughout the life cycle.
Risk control is provided.
Weakness
The model may not be accepted due to a reputation
among the conservatives as a quick and dirty
method.
Sometimes a system with poor performances is
produced ,especially if the tuning stage is skipped.
If the user cannot be involved during the prototype
iteration phase of the life cycle , the final product may
suffer adverse effects .
Weakness
Prototyping is habit forming and may go on too long
.Undisciplined developers may fall into a code-and fix
cycle, leading to expensive , unplanned prototype
iterations .
There may be tendency for difficult problems to be
pushed to the future , causing the initial promise of the
prototype to not be met by subsequent products.
Rapid Application Development model

Strength
Cycle time for the full product can be reduced due to the
use of powerful development tools
Fewer developers are required because the system is
developed by a project team familiar with the problem
domain .
The time box approach mitigates cost and schedule
risk.
Strengths
Constant integrations isolate problems and encourages
customer feedback.
The focus moves from documentation to code what you
see is what you get(WYSIWYG)
It reuses existing program components.
It makes effective use off the-shelf tools and
framework.
Weakness
If the users cannot be involved consistently throughout
the life cycle, the final product will be adversely affected.
Highly skilled and well-trained developers are required.
It requires a system that can be properly modularized.
Hard to use with legacy system.
Weakness
Risk of never achieving closure
It can fail if reusable components are not available.
Incremental Model
Strength
Operational product is delivered first.
The divide and conquer rule allows the problem to be
broken down into manageable pieces.
Initial delivery cost is lowered.
Risk of failure and changing requirements is reduced.
Strengths
Customer can see the most important, most useful
function early.
Risk is spread across several smaller increments instead
of concentrating in one large development.
Project momentum can be maintained
Weakness
The model does not allow for iteration within each

increment.
The definition of complete and fully functional system
must be done early in the life cycle to allow for the
definition of the increments.
Since some modules will be completed before others,
well defined interfaces are required.
Weakness
Formal reviews and audits are difficult to implement on
increments than on a complete system.
Use of general objectives, rather than complete
requirements, in the analysis phase can be
uncomfortable for managemnet.
Spiral Model
Strengths
The spiral model allows users to see the system early,
through the use of rapid prototyping in the development
life cycle.
It provides early indications of risk without much cost.
It splits a potentially large development effort into small
chunks.
Strengths
It provides early and frequent feedback from user to
developers, ensuring a correct product with high quality.
All the money needed for the project need not be
allocated up-front when the spiral model is adopted.
It provides productivity improvement through reuse
capabilities.
Strengths
It does not rely on the impossible task of getting the
design perfect.
Management control of quality, correctness, cost,
schedule and staffing is improved through reviews at
conclusion of each iteration.
Weakness
The time spent evaluating the risk after each spiral is
costly.
The model is complex to use.
Considerable risk assessment expertise is required.
The spiral may continue indefinitely, generated by each
of the customers response to the build initiating a new
cycle; closure may be difficult to achieve.
Weakness
The large number of intermediate stages can create
additional internal and external documentation to
process.
Use of model may be expensive and even unaffordable.
It can be hard to define objective, verifiable milestones
that include readiness to proceed through the next
iteration.
The industry has not had as much experience with the
spiral model as it has with others.
Spiral model usage

Spiral model has been very influential in helping people
think about iteration in software processes and
introducing the risk-driven approach to development.
In practice, however, the model is rarely used as
published for practical software development.
67
The Rational Unified Process

A modern generic process derived from the work on the
UML and associated process.
Brings together aspects of the 3 generic process models
discussed previously.
Normally described from 3 perspectives
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practive perspective that suggests good practice.
68
Phases in the Rational Unified Process
69
RUP phases
Inception
Establish the business case for the system.
Elaboration
Develop an understanding of the problem domain and the
system architecture.
Construction
System design, programming and testing.
Transition
Deploy the system in its operating environment.
70
RUP iteration
In-phase iteration
Each phase is iterative with results developed incrementally.
Cross-phase iteration
As shown by the loop in the RUP model, the whole set of phases
may be enacted incrementally.
71
Static workflows in the Rational Unified Process
Workflow
Description
Business modelling
The business processes are modelled using business

use cases.
Requirements
Actors who interact with the system are identified and

use cases are developed to model the system
requirements.
Analysis and design
A design model is created and documented using

architectural models, component models, object
models and sequence models.
Implementation
The components in the system are implemented and

structured
into
implementation
sub-systems.
Automatic code generation from design models helps
accelerate this process.
72
Static workflows in the Rational Unified Process
Workflow
Description
Testing
Testing is an iterative process that is carried out in conjunction

with implementation. System testing follows the completion of
the implementation.
Deployment
A product release is created, distributed to users and installed in

their workplace.
Configuration
and This supporting workflow managed changes to the system (see
change management
Chapter 25).
Project management
This supporting workflow manages the system development (see

Chapters 22 and 23).
Environment
This workflow is concerned with making appropriate software

tools available to the software development team.
73
RUP good practice

Develop software iteratively
Plan increments based on customer priorities and deliver highest
priority increments first.
Manage requirements
Explicitly document customer requirements and keep track of
changes to these requirements.
Use component-based architectures

Organize the system architecture as a set of reusable
components.
74
Chapter 3 Agile Software Development
Chapter 3 Agile software

development
75
Rapid software development

Rapid development and delivery is now often the most
important requirement for software systems
Businesses operate in a fast changing requirement and it is
practically impossible to produce a set of stable software
requirements
Software has to evolve quickly to reflect changing business needs.
Rapid software development

Specification, design and implementation are inter-leaved
System is developed as a series of versions with stakeholders
involved in version evaluation
User interfaces are often developed using an IDE and graphical
toolset.
development
76
Agile methods
Dissatisfaction with the overheads involved in software
design methods of the 1980s and 1990s led to the
creation of agile methods. These methods:
Focus on the code rather than the design
Are based on an iterative approach to software development
Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
The aim of agile methods is to reduce overheads in the

software process (e.g. by limiting documentation) and to
be able to respond quickly to changing requirements
without excessive rework.
development
77
Agile manifesto
We are uncovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we

value the items on the left more.

development
78
The principles of agile methods

Principle
Description
Customer involvement
Customers should be closely involved throughout the

development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
The software is developed in increments with the customer

specifying the requirements to be included in each increment.
People not process
The skills of the development team should be recognized and

exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change
Expect the system requirements to change and so design the

system to accommodate these changes.
Maintain simplicity
Focus on simplicity in both the software being developed and

in the development process. Wherever possible, actively work
to eliminate complexity from the system.
development
79
Agile method applicability

Product development where a software company is
developing a small or medium-sized product for sale.
Custom system development within an organization,
where there is a clear commitment from the customer to
become involved in the development process and where
there are not a lot of external rules and regulations that
affect the software.
Because of their focus on small, tightly-integrated teams,
there are problems in scaling agile methods to large
systems.

development
80
Problems with agile methods

It can be difficult to keep the interest of customers who
are involved in the process.
Team members may be unsuited to the intense
involvement that characterises agile methods.
Prioritising changes can be difficult where there are
multiple stakeholders.
Maintaining simplicity requires extra work.
Contracts may be a problem as with other approaches to
iterative development.

development
81
Agile methods and software maintenance

Most organizations spend more on maintaining existing
software than they do on new software development. So,
if agile methods are to be successful, they have to
support maintenance as well as original development.
Two key issues:
Are systems that are developed using an agile approach
maintainable, given the emphasis in the development process of
minimizing formal documentation?
Can agile methods be used effectively for evolving a system in
response to customer change requests?
Problems may arise if original development team cannot

be maintained.
development
82
Plan-driven and agile development

Plan-driven development
A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced at
each of these stages planned in advance.
Not necessarily waterfall model plan-driven, incremental
development is possible
Iteration occurs within activities.
Agile development
Specification, design, implementation and testing are interleaved and the outputs from the development process are
decided through a process of negotiation during the software
development process.
development
83
Plan-driven and agile specification

development
84
Most S/W Projects include practices From Plan Driven and Agile Approaches.
To Decide on the Balance between Plan Driven and agile Approach
We have to Answer
following technical, human and organization Questions
Is it important to have a very detailed specification and design

before moving to implementation? If so, you probably need to use
a plan-driven approach.
Is an incremental delivery strategy, where you deliver the software
to customers and get rapid feedback from them, realistic? If so,
consider using agile methods.
How large is the system that is being developed? Agile methods
are most effective when the system can be developed with a small
co-located team who can communicate informally. This may not be
possible for large systems that require larger development teams
so a plan-driven approach may have to be used.

development
85
Technical, human, organizational issues

What type of system is being developed?
Plan-driven approaches may be required for systems that require a lot
of analysis before implementation (e.g. real-time system with complex
timing requirements).
What is the expected system lifetime?

Long-lifetime systems may require more design documentation to
communicate the original intentions of the system developers to the
support team.
What technologies are available to support system development?

Agile methods rely on good tools to keep track of an evolving design
How is the development team organized?

If the development team is distributed or if part of the development is
being outsourced, then you may need to develop design documents to
communicate across the development teams.
development
86
Are there cultural or organizational issues that may affect the

system development?
Traditional engineering organizations have a culture of plan-based
development, as this is the norm in engineering.
How good are the designers and programmers in the

development team?
It is sometimes argued that agile methods require higher skill levels
than plan-based approaches in which programmers simply translate
a detailed design into code
Is the system subject to external regulation?

If a system has to be approved by an external regulator (e.g. the
FAA approve software that is critical to the operation of an aircraft)
then you will probably be required to produce detailed
documentation as part of the system safety case.
development
87
AGILE DEVELOPMENT MODELS

Waterfall Model was not suitable for Present Day
Software Projects
Requirement Request During Development Satge
Caper jones Carried out resarch 800 Real time
Software Projects and concluded
40% of the Requirements arrives after the Development
Begins
Several Models have been Proposed in Last two
Decades to overcome the short comings of WF Model
88
TWO Changes have been Noticed last two Decades

Development of Customized software
Increased Emphasis and Scope for Reuse.
89
Reasons WHY WF Model is Unsuitable as PER

Modern Software Pracices
Dynamic Reuirements
Cutomised Applications becomes POPULAR
W.F IS Heavy Weight Model
(two much emphasis on producing documentation &
usage of tools)
Customer Interaction is almost Nill
90
AGILE SOFTWARE DEVELOPMENT MODEL

Proposed in 1995 to overcome the Shortcoming of W.F
Model
Designed to adapt the Dynamic Requirements
To Facilitate quick Project completion.
Agility is achieved ( Removing activities that may not be
necessary for a Specific Project) also anything that
wastes time and effort is avoided.
Agile model is being used as an umbrella term to refer
to a group of development Processes
91
AGILE SDLC MODELS

Crystal
Atern
Scrum
Extreme Programming(XP)
Lean Development
Unified Process
92
Methodology OF Agile Models

Requirements are Decomposed into small Parts that can
be Incremented
Adopts iterative approach( Each Increment Part is
Developed over an Iteration)
Each iteration is Intended to be small and easily
Manageable and lasting couple of Days.
At a time only one increment is planned , Developedand
then Deployed at customer site.
No Long TERm Plan are Made.
The time to complete an iteration is called time box
93
The End Date Does not change ( Delivery Date is

considered Sacrosanct.
Delivery of an increment is done after each time Box
94
Essential Idea Behind Agile Models

To connect with customer during Development and to
gain a clear Understanding of domain Specific Issues.
Each Agile Project usually includes Customer
representative in its team
After each Iteration Progress is Monitored
Distinguished Characteristic of Agile Models is frequent
Delivery of software increments to Customer
Agile Models Emphasis on Face to Face Communication
Development Team is kept Small (5-9)
95
Suited for Small Projects

Agile Models Emphasizes incremental Release of
working software as the Primary measure of Progress
Deploy Pair Programming
96
Limitations of Agile Method

Lack Of formal documents leaves Scope for Confusion
and Important Decision Taken during different phases
can be misinterpreted. At later point of time by team
members.
In the Absence of formal Documents it becomes difficult
To get important Project Decision such Desgin to be
reviewed by External Team experts
Maintenance is difficult.
97
SPIRAL MODEL
98
Spiral Model
Proposed by Boehm in 1988.

Each loop of the spiral represents a phase
of the software process:
the innermost loop might be concerned with
system feasibility,
the next loop with system requirements
definition,
the next one with system design, and so on.
There are no fixed phases in this model,

the phases shown in the figure are just
examples.
99
Spiral Model (CONT.)

The team must decide:
how to structure the project into phases.
Start work using some generic model:

add extra phases
for specific projects or when problems are identified during a
project.
Each loop in the spiral is split into four sectors

(quadrants).
100
Determine
Objectives
Customer
Evaluationof
Prototype
Identify&
ResolveRisks
DevelopNext
LevelofProduct
101
Objective Setting (First Quadrant)

Identify objectives of the phase,
Examine the risks associated with these objectives.
Risk:
any adverse circumstance that
might hamper
successful completion of a software project
Find alternate solutions possible.
102
Risk Assessment and Reduction (Second Quadrant)

For each identified project risk,
a detailed analysis is carried out.
Steps are taken to reduce the risk.

For example, if there is a risk that the requirements
are inappropriate:
a prototype system may be developed.
103
Development and Validation (Third quadrant):

develop and validate the next level of the product.
Review and Planning (Fourth quadrant):

review the results achieved so far with the
customer and plan the next iteration around the
spiral.
With each iteration around the spiral:

progressively more complete version of the
software gets built.
104
Spiral Model as a meta model
Subsumes all discussed models:

a single loop spiral represents waterfall model.
uses an evolutionary approach - iterations through the spiral are evolutionary levels.
enables understanding and reacting to risks during each

iteration along the spiral.
uses:
prototyping as a risk reduction mechanism
retains the step-wise approach of the waterfall model.
105
Comparison of Different Life Cycle

Models
Iterative waterfall model
most widely used model.
But, suitable only for well-understood problems.
Prototype model is suitable for projects not well

understood:
user requirements
technical aspects
106
Comparison of Different Life Cycle

Models
(CONT.)
Evolutionary model is suitable for large problems:

can be decomposed into a set of modules that can be
incrementally implemented,
incremental delivery of the system is acceptable to the customer.
The spiral model:

suitable for development of technically challenging software
products that are subject to several kinds of risks.
107
Selecting An Appropriate Life cycle Model

for A Project
A suitable Life cycle Model Can possibly be Selected
based on an analysis of issues such as following
1. Characteristics of the software to be Developed
2. Charecteristics of the Development Team
3. Charactetristcs of Development team
108
REFERNCES
1. Fundamental of software Engineering fourth Edition
Rajib Mall
PHI 2014 Edition
2. Software Engineering : Ninth Edition 2014
Ian sommerville
Pearson Education
109

Software Process Models

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Process Models

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 2 Software Process Models

Chapter 2 Software Processes