Project Life Cycle andEffort Estimation

1. Project Life Cycle and
Effort Estimation

2. Software Processes and Process Models
• A software product development process usually starts with a
request from the customer
• This is known as project inception stage
• From inception, a product undergoes series of transformations
towards its release
• After the release for customer usage, the product enters into the
maintenance stage for
• Fixing bugs and
• Enhancing the functionalities
• When the product is no longer useful to the customer, it enters into
the retire stage
• These set of identifiable stages form the life cycle of a product and is
commonly referred as Software Development Life Cycle (SDLC) and
software process

3. 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

4. 4
Waterfall model
The waterfall model

5. 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

7. ©The McGraw-Hill Companies, 2005
7
Incremental delivery
design build install evaluate
design build install evaluate
design build install evaluate
increment
1
increment
2
increment
3
first incremental delivery
second incremental delivery
third incremental delivery
delivered
system

8. ©The McGraw-Hill Companies, 2005
8
The incremental process
Intentional
incremental
delivery

9. 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

10. • 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 - Disadvantages

11. 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

12. • 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

13. • 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
Elements of Incremental Delivery Plan

14. ©The McGraw-Hill Companies, 2005
14
V/C ratios: an example
step value cost ratio
profit reports 9 1 9 2nd
online database 1 9 0.11 5th
ad hoc enquiry 5 5 1 4th
purchasing plans 9 4 2.25 3rd
profit- based pay
for managers
9 0 inf 1st
Value : by customer
Cost : by developers
Ratio : value / cost

15. 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

16. 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)

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. • 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.

27. Software Effort Estimation

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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.

35. 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)

36. 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

37. 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

38. 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
Number
of Record
Types
Number of data types
<20 20-50 >50
1 Low Low Average
2 to 5 Low Average High
>5 Average High High
Albrecht Complexity Multipliers
International FP user group (IFPUG) file type complexity
• TCA(Technical complexity adjustments)
calculations are less accurate

39. 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

40. 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

41. 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
• The constants c,k depends on
Boehm’s terms
• Organic mode – small teams
• Embedded mode-operates within tight constraints
• Semi-detached mode- Combined elements of the above
System Type c k
Organic mode 2.4 1.05
Embedded mode 3.0 1.12
Semi-detached
mode
3.6 1.20

42. Estimation of person month (pm)
pm= A(size)(sf)x (em1) x (em2)…. X (emn)
A is a constant and set as 2.94
size is measured in kdsi (thousands of delivered source
code instructions)
The scale factor is derived
sf= B + 0.01 X (𝑒𝑥𝑝𝑜𝑛𝑒𝑛𝑡 𝑑𝑟𝑖𝑣𝑒𝑟 𝑟𝑎𝑡𝑖𝑛𝑔𝑠)
where B is a constant set as 0.91

43. 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)
• Software Quality
Drive
r
Very
Low
Low Nomin
al
High Very
High
Extra High
PREC 6.20 4.96 3.72 2.48 1.24 0.00
FLEX 5.07 4.05 3.04 2.03 1.01 0.00
RESL 7.07 5.65 4.24 2.83 1.41 0.00
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
These are summed then multiplied by 0.01
and added to the constant 0.91 to get the
overall exponent scale factor

44. 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.

45. 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

46. 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

47. Effect of Schedule Compression
• When there is a need to deliver the projects earlier as per clients
request , delivery schedule has to be compressed
• Putnam studied the effect of schedule compression on the
development effort and expressed it in the form
Pm new= Pm org X( 𝑡𝑑 𝑜𝑟𝑔/𝑡𝑑 new)
where Pm new - new effort
Pm org - originally estimated effort
𝑡𝑑 𝑜𝑟𝑔 - originally estimated time for project completion
𝑡𝑑 new - compressed schedule