Project Life Cycle and

Effort Estimation
 Software Processes and Process Models
The term software specifies to the set of computer programs, procedures and
associated documents (Flowcharts, manuals, etc.) that describe the program and how
they are to be used.
A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are four
key process activities, which are common to all software processes. These activities
are:
1. Software specifications: The functionality of the software and constraints on its
operation must be defined.
2. Software development: The software to meet the requirement must be produced.
3. Software validation: The software must be validated to ensure that it does what
the customer wants.
4. Software evolution: The software must evolve to meet changing client needs.
 Software Process Models
A software process model is an abstraction of the actual process, which is being described.
Process models may contain activities, which are part of the software process, software
product, and the roles of people involved in software engineering. Some examples of the types
of software process models that may be produced are:
1. A workflow model: This shows the series of activities in the process along with their
inputs, outputs and dependencies. The activities in this model perform human actions.
2. A dataflow or activity model: This represents the process as a set of activities, each of
which carries out some data transformations. It shows how the input to the process, such
as a specification is converted to an output such as a design. The activities here may be at
a lower level than activities in a workflow model. They may perform transformations
carried out by people or by computers.
3. A role/action model: This means the roles of the people involved in the software process
and the activities for which they are responsible.
 Choice of Process Models
• Process means an idea of a system in action
• Active system executes one or more activities
• Interrelated activities create final product
• These activities organized in different ways is called process model
• Example of processes:
• Unified software development process(USDP)
• Structured system analysis and design method(SSADM)
• Human centered design etc..
• The planner selects methods and specify how they are to be applied
• Examples of process model
• Water fall model
• Software prototyping ( Rapid prototype model)
• Incremental delivery
 Waterfall model

The waterfall model

5
 Evolutionary delivery:
Prototyping
•Prototype model
•An iterative process of creating quickly and inexpensively live
and working models to test out requirements and assumptions
•Prototypes can be classified as
• Throw away prototypes
•Evolutionary prototypes
•what is being prototyped?
•human-computer interface
•functionality
6
Incremental delivery
• Breaks the application down into small components
• These small components are then implemented and delivered in
sequence.
• Each component delivered gives some benefit to the user.
• Time boxing is associated with incremental approach
• Agreed deadline is an important constraint
 Incremental delivery
delivered
system

desig buil instal evaluat

n d l e
increment
first incremental delivery 1

desig buil instal evaluat increment

n d l e 2
second incremental delivery

desig buil instal evaluat increment

n d l e 3

third incremental delivery

8 ©The McGraw-Hill Companies,

2005
 The incremental process

Intentional
incremental
delivery

9 ©The McGraw-Hill Companies,

2005
Incremental delivery - Advantages
• The feedback from early increments improves the later stages
• The possibility of changes required is reduced
• User get benefits earlier
• Early delivery of some useful components improves cash flow
• Smaller sub-projects are easier to control and manage
• Less Gold Plating-Requesting of features that are unnecessary may be
added later
• The project can be temporarily abandoned if more urgent works emerges
• Job satisfaction is increased for developers
Incremental delivery - Disadvantages
• Later increments might require modifications to earlier increments
• This is known as software breakage
• Software developers may be more productive working on one large
system than on a series of smaller ones
Incremental Delivery Plan
• Nature and the order of delivery has to be planned
• Attention is given to the increments of user applications rather than
whole application
• The elements of incremental plan are
• System objectives
• Open technology plan
• Incremental plan
 Elements of Incremental Delivery Plan
• System objectives
• Functional goals
• Objectives to be achieved
• Jobs the system has to do
• Computing or non computing functions to achieve
• Quality goals
• Reliability
• Response and
• Security
• Open technology plan
• The system should be extendible ,portable and maintainable to add new
components
• Minimum requirements
• A standard high-level language
• A standard operating system
• Small modules
• A standard database management system
• Variable parameters to be updated without programmers knowledge
 Elements of Incremental Delivery Plan
•Incremental Plan
•Guidelines
• Steps typically should consist of 1-5% of the total project
• Non-computer steps to be included
• An increment should, ideally, not exceed one month and should
not take more than three months
• Each increment should deliver some benefit to the user
• Some increments will be physically dependent on others
• In other cases, value-to-cost ratios may be used to decide
priorities
Rapid Application Development (RAD)
• RAD model is also sometimes referred to as the rapid prototyping model
• This model has the features of both the prototyping and the incremental
delivery models
• Aims of RAD model
• To decrease the time taken and the cost incurred to develop software systems
• To limit the costs of change to minimize the unexpected development and testing
cost
• In RAD model, development takes place in series of short iterations
• Plans for one iteration at a time; each iteration time is a time box
• A quickly developed prototype given to the customer may be refined based on their
feedback
• RAD is used as instrument for gathering customer feedback not for regular use
• RAD emphasizes code reuse
Agile Methods
• Agile model is an umbrella term that refers to a group of
development processes, and not any single model of software
development
• Though same as RAD, specially designed to overcome the
disadvantages of the other methods
• There are various agile approaches
• Crystal Technologies
• Atern ( formerly DSDM)
• Feature Driven Development
• Scrum
• Extreme Programming(XP)
Agile Methods
• Principles
• Agile model emphasizes face-to –face communication over written documents
• Team size is deliberately kept small (5-9 people) to help the team members effectively communicate
with each other and collaborate
• Well suited to the development of small projects
• In large project , the collaborating teams work at different locations and different teams maintain
daily contact through video conferencing, telephone, e-mail etc.
• An agile project usually includes a customer representative in the team
• At the end of each iteration, the customer representative along with the stakeholders
• review the progress made ,
• re-evaluate the requirements ,and
• give suitable feedback to the development team
• Agile development projects usually deploy pair programming
• Two programmers work together at one work station
• One types the code while other reviews the code as it is typed
• The two programmers switch their roles every hour or so
• It is assumed that programmers working in pairs commit fewer errors
Extreme Programming (XP)
• Four core values
• Communication and Feedback
• Best method of communication is face-to-face communication
• The nature of the software under production is communicated to the users
with frequent working increments
• Simplicity
• A method which adopts user requirements
• Responsibility
• The developers are responsible for the quality of the software
• Courage
• Courageous to throw away the work which does not work and start with the
fresh design for better solutions
 Extreme Programming (XP)- Core Practices
• The Planning Exercise
• It is the process whereby the features to be incorporated in the next release are
negotiated
• Features are documented in a short textual description known as story
• Small releases
• The time between releases of functionality to users should be as short as possible
• Metaphor
• System architecture is called metaphor
• System component to be built as software code reflects the real world application
• Simple Design
• Practical implementation of the value of simplicity
• Testing
• Testing is done at the same time as coding
• Two types of testing
• Unit Testing- focuses on the code a developer has just written
• Function Testing- checks the correctness of a particular feature
Extreme Programming (XP)- Core Practices
• Refactoring
• With modifications the structure becomes more spaghetti-like
• Hence changes may be as minimum as possible
• At the same time the changes should not introduce bugs
• Pair Programming
• All software code is written by pairs of developers
• One actually doing the typing
• Other observing, discussing and making comments and suggestions about what the other is
doing
• At intervals, the developers can swap roles
• Creates chances to know the wide range of features that are under development
• Collective ownership
• Corollary of pair programming
• The team takes the collective responsibility for the code in the system
• Continuous integration
• Another aspect of testing practice
• As changes are made to software units, integrated tests are run regularly
• At least once a day-to ensure that all the components work together correctly
Extreme Programming (XP)- Core Practices
• Forty-hour weeks
• It points out working excessive hours can lead to ill-health and be generally
counterproductive
• Though there is a need for over time for a particular problem , the principle is
that normally developers should not work more than 40 hours a week
• On-site customers
• Fast and effective communication with the users is achieved by having a user
domain expert on site with the developers.
• Coding standards
• If code is genuinely to be shared, then there must be common, accepted,
coding standards to support the understanding and ease of modification of
the code
Limitations of Extreme Programming (XP)
• Success of XP depends on the following conditions
• There must be easy access to users
• At least a domain expert should be available with the user
• This may be difficult where developers and users belong to different organizations

• Development staff need to be physically located in the same office

• As users find out about how the system will work only by visual interface
• Otherwise there may be some communication problems

• For sequential and small iterations of work, it must be possible to break the
system functionality into relatively small and self-contained components

• Large, complex systems may initially need significant architectural effort.

• which may preclude use of XP
Scrum
• Projects are divided into small parts of work that can be incrementally
developed
• Delivered over time boxes that are called sprints
• Gets developed over a series of manageable chunks.
• Each sprint typically takes only a couple of weeks.
• At the end of each sprint, stake holders and team members meet to
assess the progress
• Stakeholders suggest to the development team any changes and
improvements they feel necessary .
• The team members assume three fundamental roles
• Product owner : responsible for communicating the customer vision
• Scrum master : liaison between the product owner and the team
• Team member: facilitate the development work
Managing Iterative
Processes
• Two levels of development
• The macro process
• Related to waterfall process model
• Activities carried out by a variety of specialist groups
has to be coordinated
• We need to have some dates when that major
activities will be finished so that to bring in staff to
work on subsequent activities
• The micro process
• Within this macro process, there will be micro
process activities which might involve iterative
working
• With iterative micro processes, the use of time-boxes
is needed to control at the macro level.
• There are cases where the macro process
itself can be iterative .
A macro process containing three
iterative micro processes
Atern/Dynamic Systems Development Method

• Iterative and incremental approach

Eight Core Atern principles:
1.Focus on business need
2.Deliver on time
3.Collaborate
4.Never compromise quality
5.Develop iteratively
6.Build incrementally from firm foundations
7.Communicate continuously
8.Demonstrate Control
Atern Life cycle Phases

•Feasibility/foundation- business case-requirements

•Exploration cycle-investigate business requirements and
converted into design of application
•Engineering cycle – Takes the design and converted into
usable components of the final system
•Deployment- get the application created in the
engineering cycle into actual operational use.
Software Effort Estimation
 Basics of software estimation
• Need for historical data
• Estimating methods need some information about past projects
• But possible differences ( languages, staff experience)should be considered
• Parameters to be estimated
• Effort : measured in work month (wm)or person month(pm)
• Duration : measured in months
 Basics of software estimation contd..
• Measure of work ( size of project )
• Includes cost and time over which the work to be completed
• Both are difficult to calculate at the early stage as they vary depends upon the
project
• Standard practice is
• to consider project size( independent variable) first and
• by using it effort and duration ( dependent variables) can be calculated
• Project Size
• Measure of the problem complexity in terms of effort and time not the number of bytes
occupied
• Two Metrics are used to measure size
• Source Lines of Code(SLOC) : one way of indicating the size of the system
• No precise definition
• Difficult to estimate at start of a project
• Only a code measure
• Programmer –dependent
• Does not consider code complexity
• Function Point(FP) : considers operational environment in addition to number and complexity to
compute effort
Software Effort Estimation Techniques
• Algorithmic models
• Use effort drivers representing characteristics of the target system and environment of
implementation
• Expert judgment
• Based on the advice of the knowledgeable staff
• Analogy
• A similar, completed project is identified and its actual effort is used as the basis of the estimate
• Parkinson
• Staff effort available to do a project becomes the estimate
• Price to win
• Estimate is a figure that seems sufficiently low to win a contract
• Top-down
• Overall estimate of the whole project is broken down into effort required for the component task
• Bottom-up
• Component tasks are identified and sized and these individual estimates are aggregated
Bottom-up Estimating
• The estimator breaks the project into component task for a large
project
• The process of breaking it down into task is iterative
• Each task is decomposed into its component subtasks
• Though it seems like top-down approach by producing a work
breakdown schedule(WBS)
• Bottom up part comes in by adding up the calculated effort for each activity
to get an overall estimate
• When a project is completely novel, or there is no historical data
available, the estimator could be forced to use the bottom up
approach
 Bottom-up Estimating cont,…
• A procedural code-oriented approach at the level of software
components
• Envisage the number and type of software modules in the final system
• Estimate the SLOC of each identified module
• Estimate the work content, taking into account complexity and technical
difficulty
• Calculate the work-days effort
Top-down Approach and Parametric Models
• Associated with parametric (or algorithmic) models.
• A model to forecast software development (effort) with two key
components
• Accessing the amount of the work needed(System size)
• Accessing the rate of work at which the task can be done(Productivity rate)
• A parametric model to calculate effort
Effort= System size X Productivity rate
Example
If system size in terms of KLOC = 3 KLOC
KLOC: thousands line of code
Productivity rate = 40 days / KLOC
Then Effort = 3 X 40 = 120 days
• KLOC is a size driver, indicating the amount of work to be done
• A parametric model to calculate Productivity
Productivity=effort/size
 Expert Judgment
• Asking for an estimate of task effort from someone who is
knowledgeable about either the application or the development
environment
• This method is often used when estimating the effort needed to
change an existing piece of software
• Someone already familiar with the software would be in the best
position to do this
• There may be cases where the opinions of more than one expert
may need to be combined.
 Estimation by Analogy
• Also called as case-based reasoning
• The estimator identifies completed projects (source cases) with
similar characteristics to the new project (target case)
• The effort recorded for the matching source case is then used as a
base estimate for the target
• The estimator then identifies differences between the target and the
source and adjusts the base estimate to produce an estimate for the
new project
• Euclidean distance is calculated as
• Distance= square-root of ((target_parameter 1–source_parameter1 )2 +……
(target_parameter n–source_parametern )2)
 Estimation by Analogy- Example
• The new project(target) is known to require 7 inputs and 15 outputs.
One of the past cases ,Project A(source), has 8 inputs and 17 outputs.
Find the Euclidean distance between the source and target .

Euclidean distance= square-root of ((target_parameter 1–source_parameter1 )2

+…… (target_parameter n–source_parametern )2)
= square-root of (7-8)2+(17-15)2
= 2.24
 Albrecht Function Point Analysis
(Top down approach)
Basis of function point analysis
• Information systems comprise five components or ‘external user types’
• External Input types
• Input transactions which update internal computer files
• External output types
• Transactions where data is output to the user
• External inquiry types
• Transactions initiated by the user which provide information but do not update the internal
files
• Logical internal file types
• File refers to a group of items that is usually accessed together
• External interface file types
• Allow for output and input that may pass to and from other computer applications
 Albrecht Complexity Multipliers
External user Type Multiplier
Low Average High
External input type 3 4 6
External output type 4 5 7
External inquiry type 3 4 6
Logical internal file type 7 10 15
External interface file type 5 7 10

International FP user group (IFPUG) file type

complexity
Number Number of data types
of Record
Types <20 20-50 >50

1 Low Low Average

• TCA(Technical complexity adjustments)
calculations are less accurate
2 to 5 Low Average High

>5 Average High High

 Function Points Mark II
• The ‘Mark II’ implies an improvement and replacement of the
Albrecht method
• As with Albrecht, the information processing size is initially measured
in unadjusted function points (UFPs) to which a technical complexity
adjustment can then be applied(TCA)
• For each transaction the UFPs are calculated by
Wi * (number of input data element types)+
We*(number of entity types referenced)+
Wo*(number of output data element types)

Wi, We ,Wo - weightages derived by asking developers the proportions of effort

spent in previous projects developing the code dealing with inputs, accessing
and modifying stored data and processing outputs
COSMIC (Common software measurement international consortium) Full Function
Points
• The full function point(FFP) method has its origins in the work of two interlinked research
groups in Quebec, Canada
• COSMIC deals with this by decomposing the system architecture into a hierarchy of software
layers.
• Peer-to-peer communication
• Inputs and outputs are aggregated into data groups
• Data groups can be moved about in four ways
• Entries(E)
• effected by sub processes that move the data group into the software component from ‘user’ outside its boundary
• Exits(X)
• effected by sub processes that move the data group from the software component to ‘user’ outside its boundary
• Reads(R)
• Data movement that move data groups from persistent storage ( database) into the software component
• Writes(W)
• Data movement that move data groups from software component to persistent storage (database)
• The overall FFP count is derived by simply adding up the counts for each of the four types of
data movement
• The resulting units are Cfsu(COSMIC functional size units) ISO/IEC 19761:2003
COCOMO II: A Parametric Productivity Model
• Boehm’s COCOMO( COnstructive COst MOdel) – used for software
estimation
• The term COCOMO refers to a group of models
• The basic model was built around the equation
Effort= c x (Size )k
Effort – measured in pm or the number of ‘person-months’
Size- measured in kdsi,thousands of delivered source code instructions
c,k – constants System Type c k
Organic mode 2.4 1.05
• The constants c,k depends on
Boehm’s terms Embedded mode 3.0 1.12
• Organic mode – small teams Semi-detached 3.6 1.20
• Embedded mode-operates within tight constraints mode
• Semi-detached mode- Combined elements of the above
 Estimation of person month (pm)
•
 COCOMO II Scale factors
• Precedentedness(PREC) :
• Degree of availability of similar past cases for the current project
• Development flexibility(FLEX)
• Number of different ways to meet the requirements
• Architecture/risk resolution(RESL)
• Degree of uncertainty about the requirement
• Team Cohesion(TEAM)
• Degree to which there is a large dispersed team
• Process maturity(PMAT)
Drive Very Low Nomin High Very Extra High
• Software Quality r Low al High
PREC 6.20 4.96 3.72 2.48 1.24 0.00
These are summed then multiplied by 0.01 FLEX 5.07 4.05 3.04 2.03 1.01 0.00
and added to the constant 0.91 to get the
RESL 7.07 5.65 4.24 2.83 1.41 0.00
overall exponent scale factor
TEAM 5.48 4.38 3.29 2.19 1.10 0.00
PMAT 7.80 6.24 4.68 3.12 1.56 0.00
 Cost Estimation
• Project cost can be obtained by multiplying the estimated effort(in
man-month, from the effort estimate) with the manpower cost per
month
• In addition to manpower cost, a project can incur overhead costs
which include the costs of hardware and software required for the
project and the company overheads for administration, office space,
etc.
 Staffing Pattern
• The staffing requirement for the project needs to be determined with
the help of Putnam work and Norden’s Work
• Norden’s Work
• The staffing patterns of several R&D projects were studied
• At the start of an R&D project, the activities of the project planned and initial
investigations are made
• During this time, the manpower requirements are low
• As the project progresses, the manpower requirement increases until it
reaches a peak
• Thereafter the manpower requirement gradually diminishes
 Staffing Pattern
• Putnam’s Work
• He studied the problem of staffing pattern for software development projects
have characteristics very similar to R&D projects
• Only a small number of developers are needed at the beginning of a project
to carry out the planning and specifications tasks
• As the project progresses and more detailed work is performed, the number
of developers increases and reaches a peak during product delivery
• After project delivery, the number of project staff falls consistently during
product maintenance
Effect of Schedule Compression
•