SOFTWARE ENGINEERING

ROGER S. PRESSMAN

FIFTH EDITION
 UNIT-I
The Evolving role of software
Software
Software crisis and Myths
Software Engineering a Layered Technology
The software Process models
Component Based development
The Formal Methods Model
4GT
Software Project Planning : Project planning Activities
Software Scope ,Resources
Software project Estimation,Decomposition Techniques

 1.SOFTWARE
Computer Software is the product that software engineers
design and build. It encompasses programs that execute within
a computer of any size and architecture.
 1.1 THE EVOLVING ROLE OF SOFTWARE
Software takes on a dual role
I)A product
ii) The Vehicle for delivering a product
As a Product, it delivers the computing potential embodied by
computer hardware. It resides within a cellular phone or
operates inside a mainframe computer.
Software is an information transformer Producing,
managing, acquiring, modifying, displaying, or transmitting
information.
 As a vehicle ,it is used to deliver the product
The role of computer software has undergone significant
change in more than 50 years.
Popular books published during the 1970s and 1980s gives the
change perception of computer software.
1) Osborne Characterized a New industrial Revolution
2)Toffler called the advent of microelectronics part of The
third wave of change .
3)Naisbitt Information society- About transformation in an
industrial society.
4)Feigenbaum and Mccorduck suggested that information
and knowledge would be the focal point in the 21st century.
5) Stoll argued that Electronic Communityis created by the
network and the software was the key knowledge to
interchange information.
6)Toffler described a Power Shift in which a software lead
to a Democratization of Knowledge
7)Yourdon predicted The decline and fall of the American
programmer.
8) Hammer and Champy argues that information technology
is the pivotal role in Reengineering of the corporation .
9)During the later 1990s ,Yourdon suggested that the rise and
resurrectionof the American programmer.
10)As twentieth century closed, the focus shifted to the impact
on Y2K Time bomp.
1.2 SOFTWARE
Definition
Software is
1)Instructions ( Computer programs) that when
executed provide desired function and performance.
2) data structures that enable the programs to adequately
manipulate information.
3) Documents that describe the operation and use of the
programs.
Software is a logical rather than a physical element.
 1.2.1 SOFTWARE CHARACTERISTICS

Software has characteristics that are different from hardware

1)Software is developed or engineered , it is not manufactured.

2)Software does not wear out.

3)The industry is moving toward Component-Based

Assembly,most software continues to be custom
built.
1.2.2 Software applications
Some generic categories of software applications are
1.System software
-it is a collection of programs written to service
other programs.
Ex:
OS,Compilers,editors, loader,linker,assembler etc.
2.Real-time software
Software that monitors/analyzes/controls real world
events as they occur is called real-time.

Ex:Temperature monitoring system

3.Business software
Business information processing is the largest single software
application area.
Eg: Payroll,Inventory,Accounts payable/Receivable etc.
4.Engineering and scientific software
It have been characterized by Number crunching
algorithms.
Eg:Astronomy,Automated manufacturing ,molecular
biology etc.
5.Embedded software
It Resides in Rom and is used to control products for the
customer and the industrial markets.
Eg; Keypad control for a microwave oven
digital functions in automobile such as fuel control.
6) Personal Computer software
The software commonly used in personal computers.
Eg: Word processing,spread sheets, Multimedia,
database management, etc.
7) Web Based software
The web pages retrieved by the browser are
Software.
These software's are developed using HTML,PEARL
or JAVA
8) Artificial Intelligence Software
AI software's make use of non-numerical algorithms
to solve complex problems.
Application area in this category are
Game playing, Theorem proving,pattern recognition etc.
 1.3 Software :A Crisis on the horizon?
The Word crisis is defined in Websters Dictionary as
A Turning point in the course of anything;decisive or
crucial time, stage or event
The word crisis has another definition
The turning point in the course of disease,when it becomes
clear whether the patient will live or die.
-This definition will gives a clue about the nature of the
problems.
 1.4 SOFTWARE MYTHS

Management myths
Managers are responsible to maintain the budgets, Keep
schedules from slipping, and improve quality.
Myth :
We already have a book thats full of standards and procedures for
building software.wont that provide my people everything they
need to know?
Reality : The book of standards is well exists.
But are the s/w Engineers aware of its existence?
Does it reflects the modern s/w engineering Practices?
Is it complete?
- In many cases the the answer to this questions is no.
Myth : Many people have state-of the art s/w development
tools, we buy them the newest computers.
Reality : To produce the high quality s/w it takes much more time
and cost
CASE tools are more important to achieve good quality
and productivity.
Myth :If we get behind the schedule we can add more programmers
and catch up.
Reality: Brooks state the Adding people to a late s/w project makes
it later.
If new people are added ,people who were working must
spend time for educating new comers.
Myth : if i decide to outsource the s/w project to a third party, I can
just relax.
Reality: If an organization does not understand how to manage and
control s/w it will Struggle to when it outsource the s/w
project.
Customer myths : A Customer who requests the computer s/w .

Myth : A general stmt of objectives is sufficient to begin writing

programs, we can fill the details later.
Reality : A formal and detailed description of Function
performance ,behavior, interfaces, design constraints ,validation can
be obtained only through the discussion to the customer.

Myth :Project Requirements continually change, but change can be

easily accommodated because the s/w is flexible.
Reality:Early requests for change can be accommodate easily.
If the changes will occur during design, the cost impact
grows rapidly.
Changes in function,interface, or other characteristics during
implementation have a severe cost impact.
changes when requested after the s/w is in production,it is
more expensive to make the changes
Practitioners myth : Those who develop the s/w.
Myth : Once we write the program and get it to work ,our job is done.
Reality : Industry data indicate that between 60-80 percent of all
effort
expanded on s/w is that it is delivered to the customer
for the first time
Myth : Until I get the programming I have no way of accessing
its quality.
 Reality : The most effective s/w quality assurance activity is
FTR (Formal Technical Review).FTR is more effective than
testing to find certain classes of s/w defects.
Myth: The only deliverable work product for a successful project
is the working program.
Reality:A working program is only one part of s/w configuration.
but Documentation provides a foundation for successful
engineering.
Myth: s/w Engg. Will make us to create voluminous &
unnecessary
documentation and will invariably slow us down.
Reality: s/w engg. is not about creating documents.it is about
creating quality.better quality leads to reduced work.
2.1 Software Engineering A Layered Technology
Definition for 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 on real machines
- Proposed by Fritz Bauer
IEEE Definition for SE : Software engineering:
1) The application of a systematic, disciplined, Quantifiable
approach to the development, operation and maintenance of
software; ie, the application of engineering to software.
2) The study of approaches as in (1)
 2.1.1 Process, Methods, and Tools
Software engineering is a layered Technology.
The Layers are
TOOLS
METHODS
PROCESS
A QUALITY FOCUS
1)A Quality Focus :
SE is the organizational commitment to the QUALITY.
Total Quality Management promote a continues process improvement
culture and leads to the development of more mature approaches to SE.
The bedrock that supports SE is a quality Focus
2)Process :
The Foundation for SE is the process layer.
Process defines the a framework for a set of Key process areas ( KPA)
for effective delivery of SE Technology.
The key process areas are
Which Technical methods are applied.
Work products(Models, Documents, data, Report, forms etc.)
Milestones are established
A Change is properly managed.
3) Methods:
-Methods provide the technical HOW_TOS for building the
software
-Methods encompasses array of tasks such as
Analysis, Design, Program construction, testing and support.
4)Tools:
It provides the automated and semi-automated support for the
process and methods.
For this COMPUTER AIDED SOFTWARE ENGINEERING is established.
CASE combines software, hardware and SE database.
2.1.2 A Generic view of software Engineering
The work associated with SE can be categorized in to THREE
generic Phases.
1) Definition phase
2) Development phase
3)Support phase
1) Definition Phase :
It focuses on WHAT. During definition phase the S/W engineers
attempts to identify
1)What information should be processed
2)What system behavior can be expected
3)What interface are to be established
4)What design constrain exist
5)What validation criteria are required.
2) Development Phase:
It focuses on HOW. During this phase the S/W engineers attempts t
identify
How data are to be structured
How the function is implemented within the Architecture.
How interfaces are to be characterized.
How the design will be translated in to a programming language
How the testing will be performed.
3)Support phase :
It focuses on change associated with error correction.
Four types of change are encountered during the support
phase.
Correction:
Sometimes the customer will uncover defects in the s/w.
CORRECTIVE MAINTANANCE changes the s/w to correct defects.
Adaptation:
The original environment (eg: CPU,OS,Business rules) for
which the s/w was developed is likely to change. ADAPTIVE
MAINTANANCE results in modification to the s/w.
 Enhancement:
As s/w is used, the customer/user will recognize
additional functions that will provide benefit. For that
PERFECTIVE MAINTANANCE is used.
Prevention:
Computer S/W get worse due to change, because of this
reason PREVENTIVE MAINTENANCE is used, often
called Software engineering.
Software Process
 Software process can be characterized as in
the figure.
A common process framework is
established by small number of framework
activities.
Number of task sets each is a collection of
SE work task, project milestones, work
products and quality assurance points.
Umbrella activities SQA, SCM
2.3 SOFTWARE PROCESS MODELS :
To solve actual problems, a software engineer must incorporate
a development strategy that includes Process, Methods, tools and
the generic phases.
This strategy often referred to as process model or software
engineering paradigm. Based on the nature of the problem the
process model is chosen.
Software development is a problem solving loop with four
distinct stages
Status Quo
Problem definition
Technical development
 Problem
definition

Technical
Status Quo development

Solution
Integration

Fig : The Phases of a problem solving loop

1)Status Quo Represents the current state of affairs.

2)Problem definition-identifies the specific problem to be solved.

3)Technical development Solves the problem through the

application of some technology.

4)Solution integration-delivers the results to those who requested

the solution.
The problem solving loop applies to S/W engineering work at
many different levels. ( ie Macro level, mid level and even at the
LOC).
2.4 THE LINEAR SEQUENTIAL MODEL
- some times called CLASSIC LIFE CYCLE or the WATERFALL
model

System/information Engineering

Analysis Design code Test

Fig : The Linear sequential

model.
System/information Engineering and Modeling
System engineering and analysis encompasses Require
gathering at the system level.
Information engineering encompasses requirements gathering
at the strategic business level.
Software requirement analysis
The requirements gathering process is focused specifically on
S/W. To understand the nature of the program to be built, the S/W
engineer Must understand
The information domain of the software.
Required function
Behavior
Performance &Interface.
Requirement for both the system and the S/W are documented,
and reviewed with the customer
.
Design :
It focuses four distinct attributes of a program
I) Data structure
ii)Software architecture
iii)Interface representations &
iv) Procedural(Algorithmic) Detail.
This process translates the requirements in to representation,
and the design is documented.
Code generation:
The design is translated in to machine readable form in
code generation
Testing : Once code has been generated, program begins
testing. The testing process focuses
1)The logical internals of the software.
2)Ensuring all the statements have been tested
3)on the Functional Externals.
4)Ensure that the Defined input will produce the actual
Results.
Support:
Software will undergo a change after it is delivered to
the customer.
Change will occur because
1)Errors have been encountered.
2)S/W must be adapted to accommodate to new
environment
3)The customer requires functional or performance
Requirements.
Software support/maintenance reapplies each of these phases.
Problems in Linear sequential model :
1) Real Projects rarely follow sequential flow.-ie, changes can
cause confusion as the project team proceeds.
2) It is often difficult for the customer to state all the
requirements explicitly.
3) The customer must have a patience.- A working version of
the programs will not be available until the project is
completed.
The Prototyping model :
A customer defines a set of general objectives for the
S/W but does not identify the detailed I/P , Processing, O/P
requirements.
The Developer may be unsure of the efficiency of an
algorithm, or the form that human/machine interaction should
take.
--- In these situations PROTOTYPRNG PARADIGM is the
best approach.

This paradigm begins with Requirements gathering.-

Developers and customers meet and define the objective of the
S/W
 - A Quick Design then Occurs- It focuses input approaches
and output formats.
The quick design leads to the construction of a
prototype.
The prototype is evaluated by the customer.iteration occurs

as the prototype is tuned to satisfy the customer needs.

The prototype can serve as The First System.-Brooks.

Prototype can also problematic for the following reasons.

1.The customer unaware of the S/W quality and

Maintainability.
Listen
Listentoto Build/revise
Build/revise
customer
customer mock-up
mock-up

Customer
Customer
test
testdrives
drives
mock-up
mock-up
2) The developer often make implementation compromises
in order to get a prototype working quickly.
-An inappropriate OS or Programming language may be used
- An inefficient algorithm may be used to demonstration.
2.6 The RAD model :
Rapid Application Development

RAD is an incremental process S/W development process model

It Emphasizes a short development cycle.

It enables the a development team to create fully functional system

with very short period of time.

The RAD approach encompasses the following phases.

Business modeling: The information flow among business function is modeled
in
such a way that answers the following questions
What information is to processed?
What information is generated?
Who generates it?
Where does the information go?
Who process it?
Data Modeling :
The information flow in business modeling is refined into a set of data
objects that are need to be support the business.
The characteristics of each object are identified and the relationship
between these objects are defined.
Process modeling : The data objects defined in the data modeling phase are
Transformed to implement a business function.
Process descriptions are created for adding, modifying, deleting, or
retrieving a data object

Application generation : RAD assumes the use of 4GT, rather than creating
S/W using III generation languages.

Automated tools are used to facilitate construction of software.

Testing and turnover :

RAD process emphasizes the REUSE, many programming

components have already been tested. this reduce the overall testing time. But
the new components must be tested.
 Business
Business
Team # 1 Team # 2 modeling
modeling

Business
Business Data
Business
Business modeling
modeling
Data
modeling
modeling
modeling
modeling
Data Process
Process
Data
modeling modeling
modeling
modeling
Data
Data Application
Application
modeling
modeling Process
Process generation
generation
modeling
modeling
Testing
Testing&&
Process
Process Application
Application turnover
turnover
generation
generation
modeling
modeling
Testing
Testing&&
turnover
Team #3
turnover
Application
Application
generation
generation

Testing
Testing &&
RAD turnover
turnover
model With in 60 to 90 days
The Drawbacks of RAD Approach:
1)For large projects, RAD requires sufficient human resources

2)RAD requires developers and customers who committed to the rapid-fire

activities necessary to get a system complete in a particular time. If
commitment is lacking RAD project will fail.

3) Not all types of applications are appropriate for RAD.

4) RAD is not appropriate when technical risks are high. Ie,heavy use of new
technology, high degree of interoperability etc.
2.7 Evolutionary software process models :
1) The Incremental model :
It combines the elements of the linear sequential model with the
iterative philosophy of prototyping.
The incremental model applies linear sequences as calendar progress
Each linear sequence produces a deliverable Increment of the
software.
For Example :
Word processing S/W developed using incremental paradigm may deliver
1. Basic file management, Editing, and Document production function
in the first increment
2. More sophisticated editing and document production capabilities in
the second increment
3. Spelling and grammar checking in the third increment
4. Advanced page layout in the fourth increment.
 When an incremental model is used the first increment is often a core

product.
The core product is used by the customer for detailed review
Evaluation a plan is developed for the next increment.
The plan addresses the modification of the core product.
This process is repeated following the delivery of each increment until
a the complete product is produced.
Incremental development is particularly useful when staffing is
unavailable.
 Figure: The increment model

Increment 1
Delivery of
Analysis
Analysis Design
Design Code
Code Test
Test 1st increment

Delivery of
Increment 2 Analysis
Analysis Design
Design Code
Code Test
Test 2 increment
nd

Delivery of
Increment 3 Analysis
Analysis Design
Design Code
Code Test
Test 3 increment
rd

Increment 4 Analysis
Analysis Design
Design Code
Code Test
Test

Delivery of
4th increment

Calendar time
2.7.2 THE SPIRAL MODEL :It includes the features of both the classic life
cycle and prototyping.
A spiral model is divided in to number of framework activities also called Task
region.
There are six task region in spiral model. They are
1.Customer communication : Tasks required to establish effective
communication between developer and customer.
2.Planning : Tasks required to define resources, timelines, and other project
related information.
3)Risk analysis : Tasks required to assess both technical and management
risks

4)Engineering : Tasks required to build one or more representations of the

application.
5) Construction and release : Tasks required to construct, test, install,
and provide user support.
6) Customer evaluation : Tasks required to obtain customer feedback based
on evaluation
Each of these regions is populated by a set of work tasks called a TASK SET.

As the evolutionary begins, the S/W engineering team moves around the spiral
in clockwise direction.
Cost and schedule are adjusted based on the feed back derived from the
customer evaluation
Advantages :
Spiral model is the most realistic approach now. It uses prototyping as
a risk reduction mechanism and maintains systematic stepwise approach
suggested by the water fall model
Problems :
It may be difficult to convince customers.

It demands considerable risk assessment expertise.

Problems will occur if risks are not identified.

2.7.3 The WINWIN spiral model :

Boehm's win win 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
1)Identification of the system or subsystems key stakeholders.
2)Determination of stakeholders Win conditions
3)Negotiation of the stakeholders with a set of WINWIN conditions.
In this model the stress placed on early negotiation.
It introduces three process milestones, called anchor points that
helps to the completion one cycle.
The First anchor Point is Life cycle objectives (LCO)

- defines a set of objectives for each major S/W engineering

activity.
The second anchor point , Life cycle Architecture (LCA)

- Establish objectives that must be met as the system and S/W

architecture is defined.
The Third anchor point , Initial operational capability (IOC).
-it represents a set of objectives associated with the preparation
of the S/W for installation/distribution.
 2. Identify stakeholders
win conditions
3a. Reconcile win conditions

1. Identify 3b. Establish next-level objectives,

next-level Constraints and alternatives
stakeholders

4. Evaluate process and

Product alternatives and
Resolve risks
7. Review and comment

6. Validate product and

Process definitions
5. Define next level of
Figure : The WINWIN spiral model product and process,
including partitions
2.7.4 The concurrent development model :
-Some times called concurrent engineering
The concurrent process model can be represented as a series of major
technical activities, tasks, and with associated states.

Figure illustrates the activity analysis may be in any one of the states.
All activities exists concurrently but in different states.
In a project the customer communication activity has completed its first iteration
and exists in AWAITING CHANGES state.

The analysis activity now makes a transition to the under development state
Again if the customer indicates the changes in the requirements the analysis
activity moves from the under development state to Awaiting changes.
The concurrent process model often used as a paradigm for the
development of Client/Server applications.

This model is applicable to all types of S/W development and provides

accurate picture of the current state of the project.
 None
None

Figure:
Under
One element of Under
development
The concurrent development
Process model

Awaiting
Awaiting
changes
changes

Under
Underreview
review
Under
Under
revision
revision

Base
Baselined
lined

Done
Done

Represents a state of a
Software engineered activity
2.8 Component Based development :
Object oriented technologies provide the technical frame work for component-
based process model.

Figure illustrates Component Based Development (CBD) Incorporates many of

the activities from spiral model.

The CBD model composes applications from packaged S/W components

(called Classes).

The Engineering activity begins with identification of candidate components.

Classes created in the past S/W Engineering projects are stored in a class
library or repository.

.
If the classes need is exists in the library, then it is extracted from the library
and reused.

If, it is not in the library it is engineered using Object-oriented methods.

The CBD model leads to S/W reuse.

Reuse will leads to reduction in project cost and time.

The Unified software development process is a component based

development model that have been proposed in the industry, Using unified
modeling language (UML).
 Identify
Risk candidate
Planning analysis components

Customer
communication Construct Look up
nth iteration components
Of system in library

Put new Extract

Components components
In library if available
Customer
evaluation
Engineering
Construction & release
Build
Components
if unavailable

Figure : Component based development

2.9 THE FORMAL METHODS MODEL:
Formal methods enable the S/W engineer to specify, develop and to
verify a computer based system by applying rigorous mathematical notations.

A Variation of this approach is called Clean Room Software Engineering.

When formal methods are used during development, they provide a
mechanism for eliminating
Ambiguity
Incompleteness
Inconsistency
When formal methods are used during design, they serves as the basis for program
verification and enables the S/W engineer to discover and correct the errors easily.
The formal methods model offers the promise of defect-free S/W.

Some of the difficulties in formal methods are

1. The development of formal methods is quite time consuming process and

expensive.
2.Few S/W developers have the necessary background to apply formal
methods.
3.It is difficult to use the model as a communication mechanism with the
customers.
2.10 Fourth Generation Techniques :
The term fourth generation techniques(4GT) encompasses a broad array
of S/W tools.
The 4GT paradigm for S/W engineering focuses on the ability to
specify S/W using specialized language forms or a graphic notation that the
customer can easily understand.
Currently, the 4GT includes all of the following tools.
i) Report generation
ii) Data manipulation
iii) Code generation
iv) High-level graphics capability
v) Automated generation of HTML and similar language used
for web-site creation.
The 4GT begins with a Requirements gathering

The customer would describe requirements and these would directly

translated in to operational prototype.

For small applications it is possible to move directly from the requirements

gathering step to implementation step using 4GT.

For large projects it is necessary to develop the design.

Implementation using a 4GL will leads to the automatic generation of code.

MERITS OF 4GT:
1) The use of 4GT is a viable approach for many different application
areas.- that is 4GT tools are coupled with CASE and code generators.

2)Time required to produce the S/W is greatly reduced.

3)The use of 4GT demands much more analysis and design, but we
can save the time in coding.
DEMERITS :

4GT tools are not at all easy to use than programming languages, the
resultant source code produced by such tools is Inefficient
SOFTWARE PROJECT PLANNING
Planning involves Estimation- that is an attempt to determine how
much money, how much effort, how many resources, how much time
needed to build a project.
Projective planning objectives :
The objective of S/W project planning is to provide a framework that
enables the manager to make reasonable estimates of resources, cost,
schedule.
The objective is achieved through a process of information discovery
that leads to reasonable estimates.
SOFTWARE SCOPE:
The first activity in S/W project planning is the determination of S/W
Scope.
Obtaining information necessary for scope:
The most commonly used technique to bridge the communication gap
is to conduct a meeting or interview.
To avoid the problems in requirement gathering, a team oriented
approach is developed to gather the requirements called FAST ( Facilitated
Application Specification Technique).
This approach encourages the creation of the team of customers and
developers who work together to identify
The problem
Propose elements of the solution
Negotiate different approaches
Specify a preliminary set of requirements
Software scope describes
Data and control to be progressed
Function
Performance
Constraints
Interfaces
Reliability

The Function describes the scope.

Performance describes the response time requirements.

Constraints identify the limits placed by H/W and S/W.

Feasibility : (Possibility)
Putnam and Myers suggest that scoping is not enough to
develop the S/W. Once the Scope is understood the S/W team must work to
determine if it can be done within a given dimension.

Resources:
The second S/W planning task is estimation of Resources
required to develop a S/W. consider the following figure.
Fig :Resources

People

Reusable software
components

Hardware / software tools

1) Human Resources :
The planner begins by evaluating scope and selecting skills
(Managers ,senior S/W engineers, Data base, client/server etc.) required
to complete development are specified.
The number of people required for a S/W project can be determined only
after the estimate of development effort (Person-months) is made.
2) Reusable S/W resources :
Component based engineering (CBSE) emphasizes Reusability.

Software resources categories

i) Off-the-shelf components :
COTS components are purchased from a third party, are ready for
reuse on the current project, and have been fully validated.
ii) Full-experience components :
Existing specifications, designs, code, or test data developed
for past projects that are similar to the S/W to be build for the current project.
Modifications required for full-experience components will be
relatively low risk.

iii) Partial-experience components :

Existing specifications, designs, code, or test data developed for past
projects that are similar to the S/W to be build for the current project but will require a
substantial amount of risk.

iv) New components :

S/W components that must be build by the S/W team specifically for
the needs of the current project.
The following guidelines should be considered When reusable components are
specified as a resource:
1.The off-the-shelf components meet project requirements, acquire them.
2.If Full-experience components are available, the associated with modification
and integration are acceptable.
3.If partial-experience components are available, their use for current project
must be analyzed
3) Environmental resources :
The environment that support the S/W project often called SEE( S/W engineering
environment) incorporates H/W and S/W.
Hardware provides a platform that that supports the tools require to produce
work products.
When computer based system is be engineered , the S/W team may require access to H/W
elements being developed by other engineering teams.
For example : A S/W project for advanced page layout facilities may need a digital
typesetting system at some point during development.
 Software Project Estimation
Software cost and effort estimation will never be an exact one. Because too many
variables like Human, Environmental, Political can affect the cost of a S/W.
S/W project estimation is a series of steps to achieve reliable cost and effort estimates.
i) Delay estimation until late in the project(100% accurate estimates can be
achieved after the project is completed.)

ii) Base estimates on similar projects that have been already completed.

iii) Use relatively simple decomposition techniques to generate cost & effort.

iv) Use or more empirical models for S/W cost and effort estimation.

.
 The first option indicates the longer wait leads to an effective estimation of cost and
effort
The second option indicates that if the current project is quite similar to past efforts

and other project influences (eg. The customer, business conditions, dead lines)
are equivalent.
Decomposition techniques take a divide and conquer approach to S/W project
estimation. That is decomposing the project in to major functions ,S/E engineering
activities, the cost and effort can be calculated.

Empirical estimation models is based on experience ( historical data ) and

takes the form
d=f(Vi)
Where d is one of a number of estimated values ( ex: Effort, Cost, Project duration )
And Vi are selected independent parameters (ex: estimated LOC or FP).

Automated estimations tools implement one or more decomposition

techniques or empirical models. When combined with GUI, it provides an attractive option
for estimation
DECOMPOSITION TECHNIQUES
The decomposition technique was discussed from two different points of view.
i) Decomposition of the problem
ii) Decomposition of the process
Project planner understand and generate an estimate of its size.
Software sizing :
The accuracy of the software project estimate is predicted on a number of things.
1)The degree to which the planner has properly estimated the size of the product to be
build
2) The ability to translate the size estimate into human effort, calendar time, and dollars.
3) The degree to which the project plan reflects the abilities of the software team.
4) The stability of the product requirements and the environment that supports the
S/W engineering effort
Putnam and Myers suggest Four different approaches for S/W sizing problem.
Fuzzy logic sizing : To apply this approach the planner must identify
i) The Type of application
ii) Establish the magnitude on a qualitative scale
Although personal experience can be used, the planner should also have access
to a historical database of project.
ii) Function point sizing : The planner develops the estimates of the information
domain characteristics.
iii) Standard component sizing : S/W is composed of different components that
are Generic to a particular application area.
For ex: The standard components of an information system are
Subsystems
Modules
 Screens
Reports
Interactive programs
Files
LOC.
iv) Change sizing : This approach is used when a project includes the use of
existing S/W that must be modified in some way.
The planner estimates the number and type (ex: Reuse, adding code,
changing code, deleting code ) of modifications that must be accomplished.
Problem-based estimation :
LOC and FC data are used in two ways during S/W project estimation.
1) As an estimation variable to size each element of the S/W.
2) As baseline metrics collected from past projects.
LOC and FP are distinct estimation techniques . Yet both have a number of
characteristics in common.
Using a S/W scope the project planner decompose a problem in to identify the
functions. LOC and FP is then estimated later.
LOC and FP averages should be computed by project domain.
LOC and FP estimation techniques differ in the level of detail required for
decomposition and the target of partitioning.
When LOP is used as a estimation variable decomposition is essential. This
decomposition approach assumes that all functions can be decomposed in to
sub functions.
That is the greater degree of partitioning , the more accurate estimates of LOC
can be developed.
For FP estimates decomposition works differently. Rather than focusing on
function
Each of the information domain characteristics are estimated.
They are inputs, Outputs, Data files, External interfaces
Regardless of the estimation variable that is used, the project planner estimating
the
range of values for each function . using historical data, the planner
estimates
an Optimistic, Most likely, Pessimistic size value for each function .
The Expected value for the estimation variable (size), S , can be computed as
a weighted average of the optimistic (Sopt), most likely ( Sm), and
Pessimistic ( S pess) estimates.
S=(Sopt + 4Sm + S pess) / 6
An Example of LOC based estimation
Let us consider a S/W package to be developed for a Computer-aided
design application for mechanical components.
A Review of the system specification that the S/W is to execute on
engineering
work station and must interface with various computer graphics peripherals
such as
a mouse , digitizer, high resolution color display, and laser printer.
Using the system specification , the software scope can be developed.
In the CAD S/W the following major S/W functions are identified.
Use interface and control facilities (UICF)
Two-Dimensional geometric analysis(2DGA)
Three-Dimensional geometric analysis(3DGA)
 Database management(DBM)
Computer graphics display facilities(CGDF)
Peripheral control functions(PCF)
Design analysis modules(DAM)

Using the decomposition for LOC an estimation table is developed.

The Estimation table is shown below.
Function Estimated LOC
User interface and control facilities (UICF) 2,300
Two-dimensional geometric analysis (2DGA) 5,300
Three-dimensional geometric analysis (3DGA) 6,800
Database management (DBM) 3,350
Computer graphics display facilities (CGDF) 4,950
Peripheral control function (PCF) 2,100
Design analysis modules (DAM) 8,400

Estimated lines of code 33,200

Figure: Estimation table for the LOC method

A range of LOC estimates is developed for each function.
For ex: The range of LOC estimates for 3DGA is
Optimistic-4600
Most likely-6900
pessimistic-8600
Applying these values to the equation s=(Sopt +4Sm+Spess)/6
The expected value for 3DGA is 6800.
A review of historical data , the average organizational productivity for systems
of this type is 620LOC/pm.
Based on the labor rate of $8000 per month
Cost per line of code is $13.
The total estimated project cost is $431,000 and
Estimated effort is 54 persons-month.
EXAMPLE OF FP BASED ESTIMATION
Decomposition for FP-based estimation focuses on
information domain values rather than software functions.
Refer the function point table calculation.

The project planner estimates inputs, outputs, inquires, files, External

interfaces for the CAD S/W.

In this estimate the complexity weight factor is assumed to be an

average . Complexity weight factors are Listed below.
Information domain value Opt. Likel Pess. Est. Weight FP
y Count count

Number of inputs 20 24 30 24 4 97

Number of outputs 12 15 22 16 5 78

Number of inquiries 16 22 28 22 5 88

Number of files 4 4 5 4 10 42

Number of external interfaces 2 2 3 2 7 15

Count total 320

Figure: Estimating information domain values
Factor Value
Backup and recovery 4
Data communications 2
Distributed processing 0
Performance critical 4
Existing operating environment 3
On-line data entry 4
Input transaction over multiple screens 5
Master file updated on-line 3
Information domain value complex 5
Internal processing complex 5
Code designed for reuse 4
Conversion/Installation in design 3
Multiple installations 5
Application designed for change 5
Complexity adjustment factor 1.17
Finally,the estimated number of FP is Derived.

FP estimated=Count-total x [0.65+0.01 x E(Fi)]

FP estimated=375.

The organizational average productivity for system of this type is 6.5FP/pm.

Based on the labor rate of $8000.
The cost per FP is approximately $1230.
Total estimated project cost is $461, 000
Estimated effort is 58 persons-month.
ii) Process-based estimation
This is the most common technique for estimating a project.
The Process is decomposed in to a set of tasks and effort required to each
task is estimated.
Process based estimation begins with a delineation of S/W functions
obtained form the project scope.
A series of S/W process activities must be performed for each function.
Once problem functions and process activities are melded, the planner
estimates the effort required to accomplish each S/W process activities.
The labor rate will vary for each task. Because the senior staff heavily
involved in early activities and are more expensive than junior staff who
involved in later design tasks, code generation and early testing.
An example of process-based estimation :

Again consider the example of CAD S/W.

Estimated effort for each S/w engineering activity are provided for each CAD
S/W function.

estimated efforts required for analysis, design, code, and test are then
calculated.

It should be noted the 53% of all effort is expanded on front-end engineering

tasks that is analysis and design.

Based on an average labor rate of $8000, the total estimated project cost is
$368,000 , and the estimated effort is 46 persons-months .
5.7 EMPIRICAL ESTIMATION MODELS
An estimation model for computer S/W uses empirically derived formulas to
predict effort as a function of LOC or FP.
The empirical data that supports most estimation models are derived form a
limited sample projects.
The structure of estimation models
A typical estimation model is derived using regression analysis on data collected
from past S/W projects .
The over structure of such models takes the form
E=A+B x (ev)C

Where A, B and C are Empirically derived constants.

E is a effort in person-month.
ev is the estimation variable. (either LOC or FP).
Among many LOC oriented estimation models proposed in the literature are

E=5.2 x (KLOC) 0.91 Walston-Felix model

E=5.5 +0.73 x (KLOC) 1.16 Bailey-Basili model
E=3.2 x(KLOC) 1.05 Boehm simple model
E=5.288 x (KLOC) 1.047 Doty model for KLOC>9

FP oriented models have also been proposed.

E= -13.39 + 0.0545 FP Albrecht and gaffney model
E=60.62 x 7.728 x 10 -8 FP3 Kemerer model
E=585.7 + 15.12 FP Maston, Barnett, and Mellichamp model
These models implies that it can be used for local needs.
The COCOMO model:

COCOMO stands for Constructive COst MOdel. Introduced by Boehm.

This model is one of the widely used S/W cost estimation model.

It has evolved into a more comprehensive estimation model called COCOMO II.

COCOMO II address the following areas.

Application composition model : Used during the early stages of S/W
engineering like,
Prototyping of user interfaces
Consideration of S/W and system interaction
Assessment of performance
Evaluation of technology
Early design stage model : Used once requirements have been stabilized and
basic S/W architecture has been established.
Post-architecture model : Used during the construction of the S/W.
The COCOMO II model requires sizing information.
Three different sizing options are available.
i) Object points
ii) Function Points
iii) Lines of source code.
The COCOMO II application composition model uses object points
Object point is an indirect S/W measure that is computed using
1) Screens 2) Reports 3) Components required to build the application.
Each object instance is classified in to THREE complexity levels.
i) Simple ii) Medium iii) Difficult

Once Complexity is deter mind, the number of screens, reports, and

components are weighted .This is illustrated in the following Table.
 Complexity weight
Object type
Simple Medium Difficult

Screen 1 2 3
Report 2 5 8
3 GL Component 10
Figure: Complexity weighting for object types
When component-based development or general S/W reuse is applied, the
percentage Of reuse is
estimated and the object point count is adjusted.

NOP=(object points) x [(100-%reuse)/100]

Where NOP is defined as new object points.

To derive an estimate of effort based on the computed NOP value, a productivity
rate must be derived.
The following table presents the productivity rate.
PROD=NOP/person-month

Developers experience/capability Very Low Nominal High Very

low high

Environment maturity/capability Very Low Nominal High Very

low high

PROD 4 7 13 25 50

Once the productivity rate has been determined, an estimate of project

effort can be derived as

estimated effort = NOP / PROD

The Software equation
The S/W equation is a dynamic multivariable model.
This model has been derived from productivity data collected for over 4000
Contemporary S/W projects.
Based on those data an estimation model of the form
E=[LOC x B 0.333 / P]3 x (1/t4)
Where E=effort in person months or person years
t=Project duration in months or years.
B=Special skills factor
P=Productivity parameter
This model mainly focused on
Overall process maturity and management practices
The extent to which good S/W engineering practices are used.
The level of programming languages used.
The state of the software environment
The skills end experience of the S/W team.
The complexity of the application.

The S/W equation has two independent parameters.

1) An estimate of size( in LOC)

2) An indication of project duration in months or years.

Putnam and Myers suggest a set of equations derived from the S/W
equation
Minimum development time is defined as
t min=8.14(LOC/P)0.43 in months for t min>6 months
E= 180 Bt3 in person-months for E>= 20 person-months

Using these two equations, the productivity parameter for the CAD
S/W is
P=12,000.
t min=12.6 calendar months
E= 58 person-months.