1. Chapter-7 ESTIMATION FOR SOFTWARE PROJECTS

2. Software Project Planning
Software project planning encompasses five major activities
Estimation, scheduling, risk analysis, quality management planning, and change management planning
Estimation determines how much money, effort, resources, and time it will take to build a specific system or product
The software team first estimates
The work to be done
The resources required
The time that will elapse from start to finish
Then they establish a project schedule that
Defines tasks and milestones
Identifies who is responsible for conducting each task
Specifies the inter-task dependencies

3. Observations on Estimation
Planning requires technical managers and the software team to make an initial commitment
Process and project metrics can provide a historical perspective and valuable input for generation of quantitative estimates
Past experience can aid greatly
Estimation carries inherent risk, and this risk leads to uncertainty
The availability of historical information has a strong influence on estimation risk

4. Observations on Estimation
When software metrics are available from past projects
Estimates can be made with greater assurance
Schedules can be established to avoid past difficulties
Overall risk is reduced
Estimation risk is measured by the degree of uncertainty in the quantitative estimates for cost, schedule, and resources
Nevertheless, a project manager should not become obsessive about estimation
Plans should be iterative and allow adjustments as time passes and more is made certain

5. Task Set for Project Planning
Establish project scope
Determine feasibility
Analyze risks
Define required resources
Determine human resources required
Define reusable software resources
Identify environmental resources
Estimate cost and effort
Decompose the problem
Develop two or more estimates using different approaches
Reconcile the estimates
Develop a project schedule
Establish a meaningful task set
Define a task network
Use scheduling tools to develop a timeline chart
Define schedule tracking mechanisms

6. Software Scope Software scope describes
The functions and features that are to be delivered to end users
The data that are input to and output from the system
The "content" that is presented to users as a consequence of using the software
The performance, constraints, interfaces, and reliability that bound the system
Scope can be define using two techniques
A narrative description of software scope is developed after communication with all stakeholders
A set of use cases is developed by end users

7. Software Scope
After the scope has been identified, two questions are asked
Can we build software to meet this scope?
Is the project feasible?

8. Feasibility After the scope is resolved, feasibility is addressed
Software feasibility has four dimensions
Technology – Is the project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application's needs?
Finance – Is is financially feasible? Can development be completed at a cost that the software organization, its client, or the market can afford?
Time – Will the project's time-to-market beat the competition?
Resources – Does the software organization have the resources needed to succeed in doing the project?

9. Resource Estimation
Three major categories of software engineering resources
People
Development environment
Reusable software components
Often neglected during planning but become a paramount concern during the construction phase of the software process
Each resource is specified with
A description of the resource
A statement of availability
The time when the resource will be required
The duration of time that the resource will be applied

10. Categories of Resources

11. Human Resource
Planners need to select the number and the kind of people skills needed to complete the project
They need to specify the organizational position and job specialty for each person
Small projects of a few person-months may only need one individual
Large projects spanning many person-months or years require the location of the person to be specified also
The number of people required can be determined only after an estimate of the development effort

12. Development Environment Resources
A software engineering environment (SEE) incorporates hardware, software, and network resources that provide platforms and tools to develop and test software work products
Most software organizations have many projects that require access to the SEE provided by the organization
Planners must identify the time window required for hardware and software and verify that these resources will be available

13. Reusable Software Resources
Off-the-shelf components
Components are from a third party or were developed for a previous project
Ready to use; fully validated and documented; virtually no risk
Full-experience components
Components are similar to the software that needs to be built
Software team has full experience in the application area of these components
Modification of components will incur relatively low risk
Partial-experience components
Components are related somehow to the software that needs to be built but will require substantial modification
Software team has only limited experience in the application area of these components
Modifications that are required have a fair degree of risk

14. Reusable Software Resources
New components
Components must be built from scratch by the software team specifically for the needs of the current project
Software team has no practical experience in the application area
Software development of components has a high degree of risk

15. Project Estimation Options
Options for achieving reliable cost and effort estimates
Delay estimation until late in the project (we should be able to achieve 100% accurate estimates after the project is complete)
Base estimates on similar projects that have already been completed
Use relatively simple decomposition techniques to generate project cost and effort estimates
Use one or more empirical estimation models for software cost and effort estimation

16. Project Estimation Approaches
Decomposition techniques
These take a "divide and conquer" approach
Cost and effort estimation are performed in a stepwise fashion by breaking down a project into major functions and related software engineering activities
Empirical estimation models
Offer a potentially valuable estimation approach if the historical data used to seed the estimate is good

17. Problem Based Estimation
Here we subdivide the problem into small problems. When all the small problems are solved the main problem is solved.
Lines of Code
Function Point
LOC (Lines of Code), FP(Function Point) estimation methods consider the size as the measure. In LOC the cost is calculated based on the number of lines. In FP the cost is calculated based on the number of various functions in the program.

18. Problem Based Estimation
For both approaches, the planner uses lessons learned to estimate an optimistic, most likely, and pessimistic size value for each function or count (for each information domain value)
Then the expected size value S is computed as follows:
Optimistic Value, Most Likely Value
Pessimistic Value
Once the Expected Value has been determined, Historical (LOC) and (FP) Productivity data are applied.

19. Statement of Scope
The mechanical CAD software will accept two- and three-dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer.

20. EXAMPLE OF (LOC) BASED ESTIMATION
FUNCTIONS ESTIMATED LOC - User Interface and Control Facilities (UICF) 2,300 - Two Dimensional Analysis (2DGA) D Geometric Analysis Function (3DGA) 6,800 *** - Database Management (DBM) 3,350 - Computer Graphic Display facility (CGDF) 4,950 - Peripheral Control Function (PCF) 2,100 - Design Analysis Modules DAM) _____________________________________________________________ TOTAL ESTIMATED LOC ( ∑ LOC ) ========================================================= For Example:- Using the Expected Value Equation we can calculate the Estimated Value for (3DGA) Function as follows:- Optimistic Estimation = 5,000 LOC Most Likely Estimation = 6,700 LOC Pessimistic Estimation = 9,000 LOC

21. EXAMPLE OF (LOC) BASED ESTIMATION
Historical data obtained from the Metrics indicates the following Organizational Averages:
Average Productivity is 620 LOC / Pm (Lines of Code Per Month)
Average Labor Cost is $8,000 Per month.
Cost for a Line of Code can be calculated as follows (COST / LOC)
COST / LOC = (8000 / 620) = $13
Total Estimated Project Cost and Project Effort can be calculated as: follows-
Considering that the Total LOC ( ∑ LOC) for the System is 33,200
Total Estimated Project Cost = (33200 * 13 ) = $431,600
Total Estimated Project Effort = (33200 / 620) = ~ 54 Man Months

22. EXAMPLE OF (LOC) BASED ESTIMATION

23. EXAMPLE OF (FP) BASED ESTIMATION
Decomposition for FP-based estimation focuses on information domain values rather than software functions.
For the purposes of this estimate, the complexity weighting factor is assumed to be
average.

24. EXAMPLE OF (FP) BASED ESTIMATION

25. EXAMPLE OF (FP) BASED ESTIMATION
The estimated number of FP is derived:
FPestimated = count-total *[ *(Fi)]
FPestimated = 320 *[ *(52)] = ~ 375
FPestimated = 375
organizational average productivity = 6.5 FP/pm
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated project cost is $461,000 and estimated effort is 58 person-months.

26. EMPIRICAL ESTIMATION MODELS
Estimation models for computer software use empirically derived formulas to predict effort as a function of LOC or FP
Resultant values computed for LOC or FP are entered into an estimation model

27. EMPIRICAL ESTIMATION MODELS

28. COCOMO Introduction Stands for COnstructive COst MOdel
COCOMO is one of the most widely used software estimation models in the world
It was developed by Barry Boehm in 1981
COCOMO predicts the effort and schedule for a software product development based on inputs relating to the size of the software and a number of cost drivers that affect productivity

29. COCOMO Model Hierarchy of Cocomo Model Basic COCOMO model
Intermediate COCOMO model
Detailed COCOMO model

30. The Development Modes: Project Characteristics
Organic Mode
Relatively small, simple software projects
Small teams with good application experience work to a set of less than rigid requirements
Similar to the previously developed projects
relatively small and requires little innovation
Semidetached Mode
Intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.
Embedded Mode
Software projects that must be developed within a set of tight hardware, software, and operational constraints.

31. The Development Modes: Project Characteristics

32. COCOMO : Some Assumptions
Primary cost driver is the number of Delivered Source Instructions (DSI) Delivered Line Of Code developed by the project
COCOMO estimates assume that the project will enjoy good management by both the developer and the customer
Assumes the requirements specification is not substantially changed after the plans and requirements phase

33. Basic COCOMO Model: Formula
Effort(E) = ab * (KLOC)bb(in Person-months)
DevelopmentTime(D) = cb * (E) db (in month)
Average staff size(SS) = E/D (in Person)
Productivity(P) = KLOC / E (in KLOC/Person-month)

34. Basic COCOMO

35. Basic COCOMO

36. Basic COCOMO-Example
We have determined our project fits the characteristics of Semi-Detached mode
We estimate our project will have 52,000 Delivered Source Instructions. Using the formulas, we can estimate:
Effort = 3.0*(52) 1.12 = 250 man-months
Schedule = 2.5*(250) = 17 months
Productivity = 52,000 DSI / 250 MM = 208 DSI/MM
Average Staffing = 250 MM /17 months

37. Intermediate COCOMO Extension of Basic COCOMO Why Use ?
Basic model lacks accuracy
Computes software development effort as a function of program size and set of 15 Cost Drivers
Cost Driver: A multiplicative factor that determines the effort required to complete the software project.
Why Cost Drivers?
Adjust the nominal cost of a project to the actual project Environment.
For each Characteristics, Estimator decides the scale factor
Very Low
Low
Nominal
High
Very High
Extra High

38. Intermediate COCOMO: Cost Drivers
Product: The characteristics of the product that are considered include the inherent complexity of the product, reliability requirements of the product, etc.
Computer: Characteristics of the computer that are considered include the execution speed required, storage space required etc.
Personnel: The attributes of development personnel that are considered include the experience level of personnel, programming capability, analysis capability, etc.
Development Environment: Development environment attributes capture the development facilities available to the developers. An important parameter that is considered is the sophistication of the automation (CASE) tools used for software development.

39. Intermediate COCOMO: Cost Drivers

40. Intermediate COCOMO
Multiply all 15 Cost Drivers to get Effort Adjustment Factor(EAF)
E(Effort) = ab(KLOC)bb * EAF(in Person-Month)
D(Development Time) = cb(E)db (in month)
SS (Avg Staff Size) = E/D (in persons)
P (Productivity) = KLOC/E (in KLOC/Person-month)

41. Intermediate COCOMO

42. Intermediate COCOMO-Example
A new project with estimated 400 KLOC embedded system has to be developed. Project manager hires developers of very low quality but a lot of experience in programming language. Calculate the Effort, Development time, Staff size & Productivity.

43. Intermediate COCOMO-Example
EAF = 1.29 * 0.95 = K LOC implies Embedded System Effort = 2.8*(400)1.20 * = 3712 * 1.22 = 4528 person-months Development Time = 2.5 * (4528)0.32 = 2.5 * = 36.9 months Avg. Staff Size = E/D = 4528/36.9 = 122 persons Productivity = KLOC/Effort = 400/4528 = KLOC/person-month

44. COCOMO 2
COCOMO was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch.
Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development.

45. COCOMO 2
COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates.
The sub-models in COCOMO 2 are:
Application composition model.
This models the effort required to develop systems that are created from reusable components. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance are paramount.
Early design stage model.
Used once requirements have been stabilized and basic software architecture has been established.
Post-architecture-stage model.
Used during the construction of the software

46. Application Composition Model

47. Application Composition Model
Assess object counts: Estimate the number of screens, reports and 3 GL components that will comprise this application.
Classification of complexity levels:
simple
medium
Difficult
Assign complexity weight to each object :
The weights are used for three object types
screen
report
3GL components

48. Application Composition Model
Determine object points: Add all the weighted object instances to get one number and this known as object-point count.
Compute new object points: We have to estimate the percentage of reuse to be achieved in a project. Depending on the percentage reuse, the new object points (NOP) are computed.
Object Points * (100 - %reuse)
NOP =
100
NOP are the object points that will need to be developed and differ from the object point count because there may be reuse( percentage of the Product development which is accomplished by exploiting the existence of existing component's design-or-development effort).

49. Application Composition Model
Calculation of productivity rate: The productivity rate can be calculated as:
Productivity rate (PROD) = NOP/Person month
Compute the effort in Persons-Months: When PROD is known, we may estimate effort in Person-Months as:
NOP
Effort in PM =
PROD

50. COCOMO 2-Example
Consider a database application project with the following characteristics:
The application has 4 screens with 4 views each and 7 data tables for 3 servers and 4 clients.
The application may generate two report of 6 sections each from 07 data tables for two server and 3 clients. There is 10% reuse of object points.
The developer’s experience and capability in the similar environment is low. The maturity of organization in terms of capability is also low. Calculate the object point count, New object points and effort to develop such a project.

51. COCOMO 2-Example

52. COCOMO 2-Example

53. COCOMO 2-Example

54. Make/Buy Decision
It is often more cost effective to acquire rather than develop software
Managers have many acquisition options
Software may be purchased (or licensed) off the shelf
“Full-experience” or “partial-experience” software components may be acquired and integrated to meet specific needs
Software may be custom built by an outside contractor to meet the purchaser’s specifications
The make/buy decision can be made based on the following conditions
Will the software product be available sooner than internally developed software?
Will the cost of acquisition plus the cost of customization be less than the cost of developing the software internally?
Will the cost of outside support (e.g., a maintenance contract) be less than the cost of internal support?

55. Creating a Decision Tree
The steps just described can be augmented using statistical techniques such as decision tree analysis.16 For example, Figure depicts a decision tree for a software based system X. In this case, the software engineering organization can
(1)- build system X from scratch,
(2)- reuse existing partial-experience components to construct the system,
(3)- buy an available software product and modify it to meet local needs, or
(4)- contract the software development to an outside vendor.

56. Decision Tree

57. Decision Tree
If the system is to be built from scratch, there is a 70 percent probability that the job will be difficult.
Using the estimation techniques discussed earlier, the project planner estimates that a difficult development effort will cost $450,000.
A “simple” development effort is estimated to cost $380,000. The expected value for cost, computed along any branch of the decision tree is
where i is the decision tree path. For the build path

58. Decision Tree

59. Decision Tree
It is important to note, however, that many criteria—not just cost— must be considered during the decision-making process. Availability, experience of the developer/ vendor/contractor, conformance to requirements, local “politics,” and the likelihood of change are but a few of the criteria that may affect the ultimate decision to build, reuse, buy, or contract.