OBJECT ORIENTED SOFTWARE

ENGINEERING

D.Sudhagar/Associate Professor
 UNIT - I
SOFTWARE DEVELOPMENT LIFE CYCLE

Introduction – Object Orientation - Object Oriented Methodologies –

Terminologies - Software Development Life Cycle – Conventional
Software Life Cycle Models – Build and Fix Model – Waterfall Model
– Prototyping Model – Iterative Enhancement Model – Spiral Model
– Extreme Programming - Object Oriented Software Life Cycle
Models – Selection of Software Development Life Cycle Models.

Reference:
1. Yogesh Singh, Ruchika Malhotra, “ Object – Oriented Software
Engineering”, PHI Learning Private Limited ,First edition,2012
Introduction
 Object oriented concepts
 T h e s i z e and co m p le x it y o f s o f t w a r e i s in c r e a s in g day b y day.
Conventional approaches of software design and implementation may not
be effectively applicable.
 We want to simplify the development process and to produce high quality
maintainable software.
 As we all know, development may take few years and same may have to
be maintained for many years.
 A maintainable software may reduce the maintenance cost and high
quality may enhance the sustainability of the software.
 Object oriented concepts
 It is becoming popular to design, develop and maintain large size, complex
and critical software systems using object oriented paradigm.
 Due to its popularity and acceptability in customers, companies are also
releasing the object oriented versions of their existing software products.
 Many of the customers expect object oriented software solutions and
request the same for their forthcoming projects.
Software Development
Software Development
Benefits of Object Orientation
 What is Software Engineering?
o There are two words ‘software’ and
‘engineering’.
o Engineering forces us to focus on
systematic, scientific and well defined
processes to produce a good quality
product.
O “The establishment and use of sound
engineering principles in order to obtain
economically developed software that is
reliable and works efficiently on real machines.”
(First conference on Software engineering
1968)
 What is Software Engineering?

o “The application of a systematic,

disciplined, quantifiable approach to the
development, operation and maintenance
of software, and the study of these
approaches, that is, the application of
engineering to software.”
(IEEE Computer Society’s Software
engineering body of knowledge)
 What is Software Engineering?
o "It is a profession dedicated to
designing, implementing, and
modifying software so that it is of
h i g h e r quality, m o r e a f f o r d a b l e ,
maintainable, and faster to build."
(Wikipedia 2010)
 What is Software Engineering?
Program vs. Software
o Program is set of instructions written for
a specific purpose.
o Software is the combination of
program(s), documentation (documents
produced during development) and
operating procedure manuals (delivered
with programs to customer at the time of
release).
 What is Software Engineering?
o Program vs. Software

Software

Program(s) Documentation Operating

procedure manuals

Parts of Software
 What is Software Engineering?
Some of the documents produced
during software development. Some
of them are:
o Software Requirements and
Specification document
o Software Design Document
o Test plan document
o Test suite document
o Source code
 What is Software Engineering?
Some of the operating procedure
manuals are:
o Installation manual
o System administration manual
o Beginner’s guide tutorial
o System overview
o Reference guide
 Software Characteristics

 Flexibility of Software
 Reusability of Software
Object Orientation
 What is Object Orientation?
o Why is object oriented software
development taking centre stage in
software industry?
o Why object oriented version of
existing software products are
coming in the market?
 What is Object Orientation?
o We f e e l t h a t r e a l s t r e n g t h o f o b j e c t
oriented approach is its modeling ability
to represent real world situations.
o A model helps us to visualize and
understand a real situation along with its
behavior.
o Architects use models to demonstrate
their conceptual constructs which may
also increase the confidence of their
clients in terms of design, aesthetics and
feel of the proposed project.
What is Object Orientation?
 Classes & Objects
o All book types may be combined to form a group called class.
o All objects are instances of a class.
o The class describes the structure of the instance which include
behaviour and information.
Class
Book

Software Software Software

Engineering Testing Quality
Object1
Object2 Object3
 Classes & Objects
o Suppose there are 10 books in a
library of same subject, language,
publisher and author; but these
books are distinguishable due to
their own title and accession
number.
o All objects have unique
identification like accession
number in case of a book in the
library. In a library, book, student,
faculty, employee are the example
of objects.
 Classes & Objects
o A set of objects with similar behaviour & information may constitute
a class.
o Hence, an object has a state (information) and it offers number of
operations (behaviour) depending upon its class.
 Classes & Objects
o A class represents a template for several objects and describes how
these objects are structured internally. Objects of the same class
have the same definition both for their operations and for their
information structures.
o An instance is an object created from a class. The class describes
the (behaviour & information) structure of the instance, which the
current state of the instance is defined by the operations performed
on the instance.
o An attribute (or information / state) is a data value held by the object
of a class.
o Operations (or behaviour) are the functions which may be applied on
a class.
Classes & Objects

Book Class name

accessiono : Integer
subjectdescriptor : String
ISBN : Long
booktitle : String
language : String Attributes
authorfname : String
authorlname : String
publisher : String
Book Class
addbook()
deletebook()
updatebook()
Operations
viewbook()
Classes & Objects
 Messages
o Objects communicate through passing
messages.
o A message is a request for performing an
operation by some object in the system.
o A message may consist of the identification of
the target object, name of the requested
operation and other relevant information for
processing the request.
o An object which originates a message is called
the sender and the object which receives a
message is called the receiver.
Message Exchange in Classes
 Encapsulation
 Encapsulation is also known as
information hiding concept.
 The data and operations are
combined into a single unit.
 The only way to access data is
through operations which are
designed to operate on the data.
 The data is not available to
external world.
 This concept may make the data
safe and secure from external
interventions.
Encapsulation
 Inheritance
o We may organize our knowledge
in terms of hierarchy of
categories.
o All classes inherit information
from the upper classes.
o Each derived class inherits the
attributes of its base class and
this process is known as
inheritance. In general, low level
classes (known as subclasses
or derived classes) inherit state
and behaviour from their high
level class (known as a super
class or base class).
 Member
memberID : Long
photograph : Variant
name : string
fname : String
DOB : Date
phone : Long
email : String
memberdate : Date
validupto : Date

addmember()
deletemember()
updatemember()
viewmember()

student faculty employee

rollno facultyID employeeID
school school branch
programme
Inheritance
class Member
{
private:
long int memberID;
char photograph [300];
char name[50];
char fname [50];
Date DOB;
long int phone;
char email [60];
Date memberdate;
Date validupto;

public:
addmember();
deletemember();
updatemember();
viewmember();
};
Inheritance
class employee : public Member //publicly derived
class
{
long int employeeID;
char branch[60];
};

class faculty : public Member //public inheritance

{
long int facultyID;
char school[100];
};

class student : public Member //public inheritance

{
long int rollno;
char school[100];
char programme[100];
};
 Method
o A ‘method’ is the sequence of steps (or set of operations) to be
performed to fulfill the assigned task.
o For example, four methods ‘addMember ’, ‘deleteMember ’,
‘updateMember’, and ‘viewMember’ are implemented in Member class.
o There may be many methods available for any task. It is the
responsibility of receiver of the message to choose an appropriate
method to complete task effectively & efficiently.
Polymorphism
Polymorphism
 The dictionary meaning of polymorphism is “many
forms”.
 In the real world, the same operations may have
different meanings in different situations.
 S a m e m e s s a g e i s s e n t t o d i ff e r e n t o b j e c t s
irrespective of their class, but the responses of
objects may be different.
Polymorphism
 Polymorphism is considered to be an
important concept of any object oriented
programming languages.
 As we all know, arithmetic operators such as +, =,
- are used to operate on primary data types such as int,
float etc.
 We may overload these operators so that they may
operate in the same way on objects (user defined data
types) as they operate on primary data types.
 Thus, the same operators will have multiple forms.
Data Abstraction
 Data abstraction is to collect essential elements
composing to a compound data.
Object Composition
 The use of objects as data members in another class is
referred to as object composition.
 The object is a collection of set of objects represented
through has-a relationship.
 In object oriented systems, has-a relationship depicts that an
object is declared as an attribute in another class.
Object Composition

Class A
{
………
A B };

……… Oa: A Class B

{
A Oa;
};
Object Oriented
Methodologies
 Object Oriented Methodologies

 Object oriented analysis by Coad and

Yourdon
 Object oriented design by Booch
 Object modeling technique by Rumbaugh et
al.
 Object oriented software engineering by
Jacobson
 Object Oriented Methodologies

Coad and Yourdon Methodology

 Identification of classes and
objects
 Identification of structures
 Definition of subjects
 Definition of attributes
 Definition of services (methods)
 Object Oriented Methodologies
Coad and Yourdon Methodology
 Identification of classes and objects involves
investigating the application domain and the system’s
environment.
 The behavior of each objects are found and this information is
documented. Identification of structures involve identification of is-
a and whole-part relationships.
 The is-a relationship captures class inheritance (known
as Gen-Spec structure) and whole-part relationship
captures the information that how an object is part of
another object.
 Object Oriented Methodologies

Coad and Yourdon Methodology

 Each structure is classified into a subject.
 Attributes are the data members of the class.
 The attributes for each object are defined and kept at the
appropriate level in the inheritance hierarchy.
 Defining services involve identification of operations
in a class. This also involves identification of
interfaces amongst the objects through messages.
Object Oriented Methodologies

Booch Methodology
 Grady Booch proposed object oriented methodology in
his book Object-Oriented Design (OOD) in 1991.
 The primary aim of OOD was to establish a base for
implementation of object oriented systems.
 The Booch methodology can be broadly divided into two
processes: macro process and micro process.
 Object Oriented Methodologies

Booch Methodology
Establishment Construction
of requirements of analysis
model

Design of
architecture

Maintenance of Evolution in
delivered the form of
functionality refinements
 Object Oriented Methodologies

Booch Methodology
 In first phase the requirements are established using
context diagrams and prototypes.
 The outcomes of this phase are core requirements of
the system.
 Analysis process involves requirement capturing and
understanding. It involves “what of the system”. This
phase consists of construction of use cases,
identification and prioritization of risks.
Object Oriented Methodologies

Booch Methodology
 Design phase focuses on construction of architecture of
the system and involves:
 Identification of horizontal layers
 Mapping classes to subsystems
 Release planning
 Attaching risks identified in analysis phase to releases
 Evolutionary phase involves implementation of the
system and each release adds to the functionality of the
system.
 Maintenance phase consists of post deployment
activities.
Object Oriented Methodologies

Booch Methodology
 It is the lower level process. The following recursive
steps are followed in OOD micro process
Identification of classes and objects
Identification of semantics of classes and objects
Identification of relationship amongst classes and objects
Specification of interfaces and implementation of classes and
objects
 Object Oriented Methodologies

Rumbaugh Methodology
 Rumbaugh developed a technique
that focuses on analysis, design
and implementation of the system.
This technique is popularly known
as Object Technique (OMT).
 The OMT consists of four phases:
analysis, system design, object
design and implementation.
 Object Oriented Methodologies

Rumbaugh Methodology
 Analysis phase: Analysis phase is composed of three
submodels given below:
Object model: It captures the static aspect of the system.
Dynamic model: It captures the behavioral aspects of the
object models and describes state of the objects.
Functional model: It represents the functional aspects of the
system in terms of operations defined in the classes.
 Object Oriented Methodologies
Rum Baugh Methodology
 System design phase: In this phase high level design is
developed taking the implementation environment including
DBMS and communication protocols into account.
 Object design phase: The goal of this phase is to define the
objects in details. The algorithms and operations of the
objects are defined in this phase. New objects may be
identified to represent the intermediate functionality.
 Implementation phase: Finally the objects are implemented
following coding standards and guidelines.
 Object Oriented Methodologies

Jacobson Methodology
 All the methodologies described above still lack of a
comprehensive architecture to develop a software
project.
 The Jacobson’s methodology known as “Object
Oriented Software Engineering (OOSE)” consists of
five models:
The requirement model: The aim of the model is to gather
software requirements.
The analysis model: The goal of this model is to produce
ideal, robust and modifiable structure of an object.
Object Oriented Methodologies

Jacobson Methodology
The design model: It refines the objects keeping the
implementation environment in mind.
The implementation model: It implements the objects.
The test model: The goal of the test model is to validate
and verify the functionality of the system.
 Object Oriented Modeling
 Object oriented modeling is a way of constructing visual
models based on real world objects.
 Modeling helps in understanding the probl ems,
developing proper documents and producing well
designed programs.
 Modeling produces well understood requirements,
robust designs, high quality and maintainable systems.
 Object Oriented Modeling
 UML represents the combination of the notations used
by Booch, Rumbaugh and Jacobson.
 The best concepts and processes were extracted from
all the methodologies till date and combined into UML.
 UML was adopted by Object Management Group
(OMG) in November, 1997.
 UML is defined as language for visual modeling that
allows to specify, visualize, construct, understand and
document the various artifacts of the system.
Terminologies
 Some Terminologies
 Customers, Developers and Users
Customers are persons who request the system,
approve the system and pay for the system.
Developers are the persons at the supplier side
who are responsible for the development of the
system. Users are the persons who will actually
use the system.
For example in the library management system
developed for a university, the customer is the
university, developer is the one at the supplier side
who develops the system and the users are the
persons in the library staff who will actually work
on the system.
 Some Terminologies
 Product and process
Product is what is delivered to the customer. It may include Software
Requirement Specification (SRS) document, source code, test reports, user
manuals and system guide.
Process is the way in which the software is produced. A process is like a
tunnel through which the project goes in order to produce a product

product

process
 Some Terminologies
 Actor, Use Case, Use Case Model and Use Case Scenario
An actor represents the role of a user that interacts
with the system. Some of the examples of the actors
used in “Library Management System” are
administrator, data entry operator, student, library
staff and faculty.
A use case describes who (any user) does what
(interaction) with the system, for what goal, without
considering the internal details of the system. The
use case model depicts actors, use cases and the
relationship between them.
A use case scenario is an instance of a use case or
a complete path through the use case.
 Some Terminologies
 System and Subsystems
System is an organized and arranged structure as a whole that consists of
interrelated and well defined procedures, processes and methods. All systems
consist of inputs, outputs, feedback mechanisms and boundaries.

A system may consist of several subsystems. Subsystems are a way of

reducing complexity of system.

For example, in a company, accounts, sales, marketing are different

subsystems. In object oriented analysis, objects may be grouped together to
form a subsystem.
 Some Terminologies
 Class, Responsibility and Collaboration
Class is template that consists of attributes and operations. Responsibilities
are attributes and operations included in a class.

Collaborations are the other classes that a class calls in order to achieve the
functionality.

The class, responsibility and collaboration are often combined together in

object oriented analysis to depict the functionality of a class and relationship
between classes.
 Some Terminologies
 Measures, Metrics and Measurement

A measure provides a quantitative indication of the extent, dimension, size,

capacity, efficiency, productivity or reliability of some attributes of a
product or process.

Measurement is the act of evaluating a measure.

A metric is a quantitative measure of the degree to which a system,

component or process possesses a given attribute.
 Some Terminologies
 Quality and Reliability
Software reliability is one of the important factor of software quality.
Software reliability is defined as:

“the probability of failure free operation for the specified time in a specified
environment”

Software Quality measures how well software is designed (quality of design),

and how well the software conforms to that design (quality of conformance).

Software Reliability is one of the part of software quality.

To produce good quality product, a software tester must verify and validate
throughout the software development process.
 Some Terminologies
 Quality Assurance and Quality Control
The purpose of quality assurance activities is to enforce standards and
techniques to improve the development process and prevent bugs from ever
occurring.
Quality assurance group monitors and guides throughput the software
development life cycle. Examples are reviews, audits, etc.

Quality control attempts to build a software and test it thoroughly. It concentrates

on specific products rather than processes as in the case of quality assurance.
This is a defect detection and correction activity which is usually done after the
completion of the software development,. Example is software testing at various
levels.
 Some Terminologies
 Verification and Validation
Verification: (as defined by IEEE/ANSI)
It is a process of evaluating a system or component to determine whether the
products of a given development phase satisfy the conditions imposed at the start
of that phase.
Verification is the process of evaluating, reviewing, inspecting and doing desk
checks of work products such as requirement specifications, design specification
and code.
It can be applied to all those things that can be reviewed in the early phases to
make sure that what comes out of that phase is what we expected to get.
 It is a ‘human testing’ as it involves looking at the documents on paper.
 Some Terminologies
Validation: (as defined by IEEE/ANSI)

It is a process of evaluating a system or component during or at

the end of development process to determine whether it satisfies
the specified requirements.

 It involves executing the actual software.

It is a computer based testing process. It usually exposes
symptoms of errors.
 Definition: Testing = Verification + Validation
 Some Terminologies
 Error, Mistake, Bug, Fault and Failure
People make errors. A good synonym
is mistake. This may be a syntax error
or misunderstanding of specifications.
Sometimes, there are logical errors.

When developers make mistakes

while coding, we call these mistakes
“bugs”.
 Some Terminologies
A fault is the representation of an error, where representation is the
mode of expression, such as narrative text, data flow diagrams, ER
diagrams, source code etc. Defect is a good synonym for fault.

A failure occurs when a fault executes. A particular fault may cause

different failures, depending on how it has been exercised.
 Some Terminologies
 States and Events
A state is an abstract situation in the life cycle of
an entity that occurs in response to occurrence of
some event.

An event is an input (a message or method call).

Due to occurrence of some event, the system
transits from one state to other.
 Some Terminologies
S. No Traditional approach Object oriented approach
1 The system is viewed as collection of The system is viewed as collection of
processes. objects.
2 Data flow diagrams, ER diagrams, UML models including use case diagram,
data dictionary and structured charts c l a s s d i a g r a m , s e q u e n c e d i a g r a m s ,
are used to describe the system. component diagrams etc are used to
describe the system.
3 Reusable source code may not be The aim is to produce reusable source
produced. code.
4 Data flow diagrams depicts the Classes are used to describe attributes and
processes and attributes functions that operate on these attributes.
5 It follows top-down approach for It follows bottom-up approach for
modeling the system. modeling the system.
6 Non iterative Highly iterative
Software Development
Life Cycle
Software Development Life Cycle

The essence of the software development

process that consists of :
Analysis
Design
Implementation
Testing
Refinement
is to transform users’ needs into a software
solution that satisfies those needs.
Software Development Life Cycle
We need not see code until after 25 to 30 % of the
development time. Because ?
We need to spend more time in:
Gathering REQUREMENTS,
Developing a requirement model
Developing an analysis model (It consists of class diagrams and
sequence diagrams that describe the logical implementation of the
functional requirements.)
Developing a design model(In the design model, packages contain the
design elements of the system, such as design classes, interfaces, and
design subsystems, that evolve from the analysis classes.)
Finally code can be developed quickly.
Emphasize is on building high quality software.
i.e (Meeting specifications & being adaptable for change.)
Software Development Life Cycle

The goal of Software Engineering is to provide

models and processes that lead to the production
of well-documented maintainable software in a
manner that is predictable.
 Software Life Cycle Models

“The period of time that starts when a software product

is conceived and ends when the product is no longer
available for use. The software life cycle typically
includes a requirement phase, design phase,
implementation phase, test phase, installation and check
out phase, operation and maintenance phase, and
sometimes retirement phase”.
Conventional Software Life Cycle Models

 Build and Fix Model

 Waterfall Model
 Prototyping Model
 Iterative Enhancement Model
 Spiral Model
 Extreme Programming
 Build & Fix Model
• In the build and fix model (also referred to as an ad
hoc model), the software is developed without any
specification or design.
• An initial product is built, which is then repeatedly
modified until it (software) satisfies the user.
• That is, the software is developed and delivered to the
user. The user checks whether the desired functions
‘are present.
• If not, then the software is changed according to the
needs by adding, modifying or deleting functions.
• This process goes on until the user feels that the
software can be used productively.
Build & Fix Model
 Build & Fix Model

This model includes the following two phases.

• Build: In this phase, the software code is developed

and passed on to the next phase.
• Fix: In this phase, the code developed in the build
phase is made error free. Also, in addition to the
corrections to the code, the code is modified
according to the user’s requirements.
 Build & Fix Model

❖ Suitable for small programming exercises of

100 or 200 lines
❖ Unsatisfactory for software for any
reasonable size
❖ Code soon becomes unfixable &
unenhanceable
❖ Maintenance is practically not possible
 Build & Fix Model

Advantages Disadvantages
1.Requires less experience to 1.No real means is available of
execute or manage other than assessing the progress, quality,
the ability to program. and risks.
2.Suitable for smaller software. 2.Cost of using this process
3.R e q u i r e s l e s s p r o j e c t model is high as it requires
planning. rework until user’s requirements
are accomplished.
3.I n f o r m a l d e s i g n o f t h e
software as it involves
unplanned procedure.
4.Maintenance of these models
is problematic.
 Waterfall Model

This model is easy to understand and reinforces

the notion of “define before design” and “design
before code”.

T h e m o d e l expects complete & accurate

requirements early in the process, which is
unrealistic
Waterfall Model
 Waterfall Model
The sequential phases in Waterfall model are:

• Requirement Gathering and analysis − All possible requirements of the system

to be developed are captured in this phase and documented in a requirement
specification document.

• System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.

• Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
 Waterfall Model

• Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.

• Deployment of system − Once the functional and non-functional testing is

done; the product is deployed in the customer environment or released into the
market.

• Maintenance − There are some issues which come up in the client

environment. To fix those issues, patches are released. Also to enhance the
product some better versions are released. Maintenance is done to deliver these
changes in the customer environment.
 Waterfall Model
Advantages
• System is well documented.
• Phases correspond with project management phases.
• Cost and schedule estimates may be lower and more accurate.
• Details can be addressed with more engineering effort if software is large or
complex.

Disadvantages
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
 Waterfall Model

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall
model is most suited are:
• When the requirements are constant and not changed
regularly.
• A project is short
• Where the tools and technology used is consistent and
is not changing
• When resources are well prepared and are available to
use.
 Incremental Models

They are effective in the situations where requirements are

defined precisely and there is no confusion about the
functionality of the final product.

After every cycle a useable product is given to the customer.

Popular particularly when we have to quickly deliver a

limited functionality system.
 Incremental Models

• Incremental Model is a process of software

development where requirements divided into
multiple standalone modules of the software
development cycle.
• In this model, each module goes through the
requirements, design, implementation and
testing phases.
• Every subsequent release of the module adds
function to the previous release. The process
continues until the complete system achieved.
Incremental Models
 Incremental Models

Advantage of Incremental Model

• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its
iteration.
• The Client gets important functionality early.
Disadvantage of Incremental Model
• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.
 Incremental Models

When we use the Incremental Model?

• When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or
trained.
• When the customer demands a quick release of the
product.
• You can develop prioritized requirements first.
 Prototyping Model

➢ The prototype may be a usable program but is not

suitable as the final software product.

➢ The code for the prototype is thrown away. However

experience gathered helps in developing the actual
system.

➢ The development of a prototype might involve extra

cost, but overall cost might turnout to be lower than
that of an equivalent system developed using the
waterfall model.
Prototyping Model

l
 Prototyping Model

Steps of Prototype Model:

1.Requirement Gathering and Analyst
2.Quick Decision
3.Build a Prototype
4.Assessment or User Evaluation
5.Prototype Refinement
6.Engineer Product
 Prototyping Model

Advantage:
• Reduce the risk of incorrect user requirement
• Support early product marketing
• Reduce Maintenance cost.
• Errors can be detected much earlier as the system is made side
by side.
Disadvantages:
• An unstable/badly implemented prototype often becomes the final
product.
• Prototyping tools are expensive.
• Special tools & techniques are required to build a prototype.
• It is a time-consuming process.
 Prototyping Model

When we use the Prototype model

Generally, we go for this model because of the following
reasons:
• Whenever the customer is new to the software
industry or when he doesn't know how to give the
requirements to the company.
• When the developers are new to the domain.
 Iterative Enhancement Model

This model has the same phases as the waterfall model, but with
fewer restrictions. Generally the phases occur in the same order as
in the waterfall model, but they may be conducted in several cycles.
Useable product is released at the end of the each cycle, with each
release providing additional functionality.

✓ Customers and developers specify as many requirements as

possible and prepare a SRS document.
✓ Developers and customers then prioritize these requirements
✓ Developers implement the specified requirements in one or
more cycles of design, implementation and test based on the
defined priorities.
 Iterative Enhancement Model

• The basic idea of this model is to start the process

with requirements and iteratively enhance the
requirements until the final software is implemented.
• In addition, as in prototyping, the increment provides
feedback from the user specifying the requirements of
the software.
• This approach is useful as it simplifies the software
development process as implementation of smaller
increments is easier than implementing the entire
system.
Iterative Enhancement Model
 Iterative Enhancement Model

Advantages:
1.Testing and debugging during smaller iteration is easy.
2.A Parallel development can plan.
3.It is easily acceptable to ever-changing needs of the project.
4.Risks are identified and resolved during iteration.
5.Limited time spent on documentation and extra time on designing.

Disadvantages:
1.It is not suitable for smaller projects.
2.More Resources may be required.
3.Design can be changed again and again because of imperfect
requirements.
4.Requirement changes can cause over budget.
5.Project completion date not confirmed because of changing
requirements.
 Iterative Enhancement Model

When to use the Iterative Model?

1.When requirements are defined clearly and easy to
understand.
2.When the software application is large.
3.When there is a requirement of changes in future.
 Spiral Model

Models do not deal with uncertainly which is inherent to

software projects.
Important software projects have failed because project
risks were neglected & nobody was prepared when
something unforeseen happened.

Barry Boehm recognized this and tired to incorporate the

“project risk” factor into a life cycle model.
The result is the spiral model, which was presented in 1986.
Spiral Model
 Spiral Model

The radial dimension of the model represents the cumulative costs.

Each path around the spiral is indicative of increased costs. The
angular dimension represents the progress made in completing
each cycle. Each loop of the spiral from X-axis clockwise
through 360o represents one phase. One phase is split roughly into
four sectors of major activities.
▪ Planning: Determination of objectives, alternatives &
constraints.
▪ Risk Analysis: Analyze alternatives and
attempts to identify and resolve the risks involved.
▪ Development: Product development and testing product.
▪ Assessment: Customer evaluation
 Spiral Model
▪ An important feature of the spiral model is that each phase is completed
with a review by the people concerned with the project (designers and
programmers)
▪ The advantage of this model is the wide range of options to
accommodate the good features of other life cycle models.
▪ It becomes equivalent to another life cycle model in
appropriate situations.
• The spiral model has some difficulties that need to be resolved before it
can be a universally applied life cycle model. These difficulties include
lack of explicit process guidance in determining objectives, constraints,
alternatives; relying on risk assessment expertise; and provides more
flexibility than required for many applications.
 Spiral Model

Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.

Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.
 Spiral Model

When to use Spiral Model?

• When deliverance is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
 Extreme Programming

• Extreme Programming (XP) is an agile software

development framework that aims to produce
higher quality software, and higher quality of
life for the development team. XP is the most
specific of the agile frameworks regarding
appropriate engineering practices for software
development.
• The general characteristics where XP is
appropriate were described by Don Wells:
qDynamically changing software requirements
qRisks caused by fixed time projects using new
technology
 Extreme Programming

Extreme Programming takes the effective principles and practices

to extreme levels.
• Code reviews are effective as the code is reviewed all the time.
• Testing is effective as there is continuous regression and testing.
• Design is effective as everybody needs to do refactoring daily.
• Integration testing is important as integrate and test several
times a day.
• Short iterations are effective as the planning game for release
planning and iteration planning.
 Extreme Programming

Extreme Programming involves :

• Writing unit tests before programming and keeping all of the tests
running at all times. The unit tests are automated and eliminates defects
early, thus reducing the costs.
• Starting with a simple design just enough to code the features at hand
and redesigning when required.
• Programming in pairs (called pair programming), with two programmers
at one screen, taking turns to use the keyboard. While one of them is at
the keyboard, the other constantly reviews and provides inputs.
• Integrating and testing the whole system several times a day.
• Putting a minimal working system into the production quickly and
upgrading it whenever required.
• Keeping the customer involved all the time and obtaining constant
feedback.
 Extreme Programming

Advantages Disadvantages
No unnecessary Customer must participate
programming work in the process
Stable software through Relatively large time
continuous testing investment
Error avoidance through
Relatively high costs
pair programming
 Object Oriented Software Life Cycle
Models
OBJECT ORIENTED SYSTEMS DEVELOPMENT: A USE CASE
DRIVEN APPROACH
The O-O software development life cycle
(SDLC) consists of three macro processes:
Object-Oriented Analysis (focuses on what the
system does)
Object-Oriented Design(OOD on how the system does
it)
Object-Oriented Implementation
The use case model can be employed
throughout most activities.
Object Oriented Software Life Cycle
Models
 The Unified Process

• Developed by I.Jacobson, G.Booch and J.Rumbaugh.

• Software engineering process with the goal of producing good

quality maintainable software within specified time and budget.

• Developed through a series of fixed length mini projects called

iterations.

• Maintained and enhanced by Rational Software Corporation and thus

referred to as Rational Unified Process (RUP).
Phases of the Unified Process

Inception Elaboration Construction

Constructio Transition
Transition
n
Time

Definition of Planning & Initial Release of

objectives architecture operational the Software
of the project for the project capability product
Phases of the Unified Process

• Inception: defines scope of the project.

• Elaboration
- How do we plan & design the project?
- What resources are required?
- What type of architecture may be suitable?

• Construction: the objectives are translated in design &

architecture documents.
• Transition : involves many activities like delivering, training,
supporting, and maintaining the product.
 Inception Phase

The inception phase has the following objectives:

▪ Gathering and analyzing the requirements.

▪ Planning and preparing a business case and evaluating
alternatives for risk management, scheduling resources etc.
▪ Estimating the overall cost and schedule for the project.
▪ Studying the feasibility and calculating profitability of the
project.
Outcomes of Inception Phase

Prototypes Project plan

Business Initial risk

Inception
model assessment
Initial business
Vision
Initial use Initial case
document
case model project
Glossary
 Elaboration Phase
The elaboration phase has the following objectives:

▪ Establishing architectural foundations.

▪ Design of use case model.
▪ Elaborating the process, infrastructure & development
environment.
▪ Selecting component.
▪ Demonstrating that architecture support the vision at
reasonable cost & within specified time.
Outcomes of Elaboration
Phase
Development plan Revised risk
document
Preliminary An executable
Elaboration architectural
User manual
prototype
Architecture
Use case Description
model Supplementary
document
Requirements
with non functional
requirement
 Construction Phase

The construction phase has the following objectives:

▪ Implementing the project.

▪ Minimizing development cost.
▪ Management and optimizing resources.
▪ Testing the product
▪ Assessing the product releases against acceptance criteria
Outcomes of Construction
Phase
Test Operational
Outline manuals
Documentation
Construction Test Suite
manuals
A description
Software of the
product User manuals current release
 Transition Phase

The transition phase has the following objectives:

▪ Starting of beta testing

▪ Analysis of user’s views.
▪ Training of users.
▪ Tuning activities including bug fixing and
enhancements for performance & usability
▪ Assessing the customer satisfaction.
Outcomes of Transition
Phase

Transition

Product User feedback

release Beta test reports
Selection of a Life Cycle Model

Selection of a model is based on:

a) Requirements

b) Development team
c) Users
d) Project type and associated risk
 Based On Characteristics Of Requirements

Requirements Waterfall Prototype Iterative Build & Fix Spiral

enhancement
Are requirements
easily understandable Yes No No No No
and defined?
Do we change
requirements quite No Yes No No Yes
often?
Can we define
requirements early Yes No Yes No No
in the cycle?

Requirements are
indicating a complex No Yes Yes No Yes
system to be built
 Based On Status Of Development Team

Development Waterfall Prototype Iterative Build & Fix Spiral

team enhancement

Less experience on
No Yes No Yes Yes
similar projects?

Less domain
knowledge (new to Yes No Yes Yes Yes
the technology)
Less experience on
tools to be used Yes No No Yes Yes

Availability of
training if required No No Yes No No
 Based On User’s Participation

Involvement Waterfall Prototype Iterative Build & Fix Spiral

of Users enhancement

User involvement
in all phases No Yes No No No

Limited user
participation Yes No Yes Yes Yes

User have no
previous experience No Yes Yes Yes Yes
of participation in
similar projects

Users are experts of

problem domain No Yes Yes No No
Based On Type Of Project With Associated Risk

Project type Waterfall Prototype Iterative Build & Fix Spiral

and risk enhancement
Project is the
enhancement of the No No Yes No No
existing system
Funding is stable
for the project Yes Yes No No No
High reliability
requirements No No Yes No Yes
Tight project
schedule No Yes Yes No Yes
Use of reusable
components No Yes No No Yes
Are resources (time,
money, people etc.) No Yes No No Yes
scare?
 Multiple Choice Questions

1 Spiral Model was developed by

(a) Bev Littlewood (b) Berry Boehm
(c) Roger Pressman (d) Victor Basili
2 Which model is most popular for student’s small projects?
(a) Waterfall model (b) Spiral model
(c) Quick and fix model (d) Prototyping model
3. Which is not a software life cycle model?
(a) Waterfall model (b) Spiral model
(c) Prototyping model (d) Capability maturity model
4. Project risk factor is considered in
(a) Waterfall model (b) Prototyping model
(c) Spiral model (d) Iterative enhancement model
5. SDLC stands for
(a) Software design life cycle (b) Software development life cycle
(c) System development life cycle (d) System design life cycle
 Multiple Choice Questions

6 Build and fix model has

(a) 3 phases (b) 1 phase
(c) 2 phases (d) 4 phases
7. SRS stands for
(a) Software requirements specification (b) Software requirements solution
(c) System requirements specification (d) none of the above
8. Waterfall model is not suitable for
(a) small projects (b) accommodating change
(c) complex projects (d) none of the above
9 RAD stands for
(a) Rapid application development (b) Relative application development
(c) Ready application development (d) Repeated application development
10 RAD model was proposed by
(a) Lucent Technologies (b) Motorola
(c) IBM (d) Microsoft
 Multiple Choice Questions

11 If requirements are easily understandable and defined,which model is best suited?

(a) Waterfall model (b) Prototyping model
(c) Spiral model (d) None of the above
12 If requirements are frequently changing, which model is to be selected?
(a) Waterfall model (b) Prototyping model
(c) RAD model (d) Iterative enhancement model
13 If user participation is available, which model is to be chosen?
(a) Waterfall model (b) Iterative enhancement model
(c) Spiral model (d) RAD model
14 If limited user participation is available, which model is to be selected?
(a) Waterfall model (b) Spiral model
(c) Iterative enhancement model (d) RAD model
15 If project is the enhancement of existing system, which model is best suited?
(a) Waterfall model (b) Prototyping model
(c) Iterative enhancement model (d) Spiral model
 Multiple Choice Questions

16 Which one is the most important feature of spiral model?

(a) Quality management (b) Risk management
(c) Performance management (d) Efficiency management
17 Most suitable model for new technology that is not well understood is:
(a) Waterfall model (b) RAD model
(c) Iterative enhancement model (d) Evolutionary development model
18 Statistically, the maximum percentage of errors belong to the following phase of
SDLC
(a) Coding (b) Design
(c) Specifications (d) Installation and maintenance
19 Which phase is not available in software life cycle?
(a) Coding (b) Testing
(c) Maintenance (d) Abstraction
20 The development is supposed to proceed linearly through the phase in
(a) Spiral model (b) Waterfall model
(c) Prototyping model (d) None of the above
 Multiple Choice Questions

21 Unified process is maintained by

(a) Infosys (b) Rational software corporation
(c) SUN Microsystems (d) None of the above
22 Unified process is
(a) Iterative (b) Incremental
(c) Evolutionary (d) All of the above
23 Who is not in the team of Unified process development?
(a) I.Jacobson (b) G.Booch
(c) B.Boehm (d) J.Rumbaugh
24 How many phases are in the unified process?
(a) 4 (b) 5
(c) 2 (d) None of the above
25 The outcome of construction phased can be treated as:
(a) Product release (b) Beta release
(c) Alpha release (d) All of the above
 Exercises

1.What do you understand by the term Software Development Life Cycle

(SDLC)? Why is it important to adhere to a life cycle model while
developing a large software product?
2. What is software life cycle? Discuss the generic waterfall model.
3.List the advantages of using waterfall model instead of adhoc build and fix
model.
4.Discuss the prototyping model. What is the effect of designing a prototype
on the overall cost of the project?
5. What are the advantages of developing the prototype of a system?
6.Describe the type of situations where iterative enhancement model might
lead to difficulties.
7. Compare iterative enhancement model and evolutionary process model.
 Exercises

8. Sketch a neat diagram of spiral model of software life cycle.

9.Compare the waterfall model and the spiral model of software
development.
10.As we move outward along with process flow path of the spiral model,
what can we say about software that is being developed or maintained.
11.How does “project risk” factor effect the spiral model of software
development.
12.List the advantages and disadvantages of involving a software engineer
throughout the software development planning process.
13.Explain the spiral model of software development. What are the
limitations of such a model?
14.Describe the rapid application development (RAD) model.Discuss each
phase in detail.
15.What are the characteristics to be considered for the selection of the life
cycle model?
 Exercises

16.What is the role of user participation in the selection of a life cycle

model?.
17. Why do we feel that characteristics of requirements play a very
significant role in the selection of a life cycle model?
18.Write short note on “status of development team” for the selection of a
life cycle model?.
19. Discuss the selection process parameters for a life cycle model.
20.What is unified process? Explain various phases along with the outcome
of each phase.
21.Describe the unified process work products after each phase of unified
process.
22.What are the advantages of iterative approach over sequential approach?
Why is unified process called as iterative or incremental?
Thank You