1. Software Project Management
Lecture # 5

2. Outline Chapter 23 – “Estimation” Introduction What is Estimation
Estimation and Risk
Project Planning Activities
Software Scope and Feasibility
Resources
Software Project Estimation
Decomposition Techniques
Empirical Estimation Models

3. Introduction
Software Project Management begins with 'Project Planning’ activities
Software project planning includes five major activities:
Estimation (of work, resources, time)
Scheduling
Risk Analysis
Quality Management Planning
Change Management Planning

4. What is Estimation? Estimation is to determine how much…
Money/cost,
efforts,
resources and
time
…will be taken to build a specific software based system or product.
Estimation is foundation for all project planning activities

5. Estimation Steps – Summary
Description of product scope
Decomposition of problem into set of smaller problems
Each sub problem is estimated using historical data, software metrics and experience (from past projects) as guides.
Problem complexity and risks are considered before final estimate is made

6. Estimation and Risk
Estimation carries inherent risk & risk leads to uncertainty
Estimation risk is measured by the degree of uncertainty in the quantitative estimates established for resources, cost, and schedule.
Availability of comprehensive historical information and software metrics (from past projects) helps establish better estimates and hence reduces risk factors

7. Project Planning Process
Software project planning provides a framework that enables the manager to make reasonable estimates
Although there is inherent uncertainty, the team embarks on a project plan
But, this plan must be adapted and updated as the project progresses

8. The Software Project Planning Activities

9. Software Scope It is defined in one of the following ways:
Narrative description developed after communication with all stakeholders
A set of use-cases developed by end-user
It describes
functions & features to be delivered to end-user ( these are evaluated and sometimes refined before estimation is started)
“content” presented to users as they use the software
Performance considerations (processing and response time, etc)
Constraints (limits placed on software by external hardware, available memory, or existing systems)
Input and output data
Interfaces and reliability that bound the system

10. Software Feasibility It is conducted after scope identification
It is very crucial but is often overlooked either by software engineers or by the impatient customers and managers
It addresses questions like
Can we build software to meet this scope?
Is the project feasible?

11. Software Feasibility (Cont.)
Putnam and Myers address feasibility in four dimensions
Technology
Is the project technically feasible? Is it within state of the art? Can defects be reduced as needed?
Finance
Is it financially feasible? Can the development be completed at a cost that the software organization, the client or the market can afford
Time
Will the project’s time-to-market beat the competition?
Resources
Does the organization have enough resources needed to succeed?

12. Resources Three categories of resources:
People/Human resources
Reusable software components
Development environment (s/w & h/w tools)
Each resource has 4 characteristics
Description of resource
Statement of availability
Time when resource will be required
Duration of time when resource will be applied

13. 1.Human resources This estimation involves
Selecting Skills (required to complete development)
Specifying organizational positions (manager, senior s/w engr, ..) and specialty
Determining number of people based on development effort
For small projects, single person can do all s/w engg tasks
For large projects, more number of people involved which may be geographically distributed. So, location of resource also specified

14. 2. Reusable Software Resources
CBSE emphasizes the creation and reuse of software building blocks (components)
4 categories of software components
Off-the-shelf components
Ready-to-use existing software acquired from third party (COTS) or from (internal) past projects
Full-experience components
Existing specifications, designs, code, test data from past projects similar to software to be developed (for current project). May require little modifications
Partial experience component
Existing specifications, designs, code, test data from past projects related to software to be developed (for current project) but will require substantial modifications
New components
Software components that must be built for current project

15. 3. (Development) Environment resources
These include hardware and software support for a software project
Hardware and software elements availability and time window must be specified

16. Software Project Estimation
Options for cost and effort estimates
Delay estimation until late in project
Not a practical approach
Base estimation on similar past projects
Reasonable approach but not always successful
Use simple decomposition techniques to generate estimates
Divide and conquer approach. Divide project into major activities/functions and make estimates
Use some empirical model for estimation
Complements decomposition techniques
Which option is better?
Each approach can be used as a cross-check for the other

17. Decomposition Techniques
Decomposition can be performed in two aspects
Decomposition of problem
Decomposition of process

18. 1. Software Sizing
Proper estimation of software size and mapping of size estimate to human effort, calendar time and cost are important things which contribute to accuracy of overall software project estimation
Direct approach – size is measured as LOC
Indirect approach – size is measured as function-points
Putnam and Myers suggested 4 different approaches for sizing problem
Fuzzy logic sizing
Function point sizing
Standard component sizing
Change sizing

19. Other types of estimations…
Problem based estimation
FP-based estimation
Process-based estimation
Use-case based estimation

20. Empirical Estimation Models
An estimation model for software uses empirically derived formulas .
These formulas can predict effort as a function of LOC or FP.
Empirical data (that support most estimation models) are derived from limited sample of projects, that is why, no estimation model is appropriate for all classes of software and in all development environments.
Estimation model must be calibrated for local conditions.

21. Structure of Estimation Models
A typical empirical model is derived using regression analysis on data collected from past projects
Overall structure of such models takes the form
E= A+B x (ev)C
A, B and C are empirically derived constants, E is effort in person-months and ev is estimation variable (either LOC or FP)

22. Empirical Estimation Models - Examples
Proposed LOC-oriented estimation models
E= 5.2 x (KLOC) Walston-Felix model
E= x (KLOC)1.16 Bailey-Basili model
E= 3.2 x (KLOC) Boehm simple model
E= x (KLOC) Doty model for KLOC>9
Proposed FP-oriented estimation models
E= FP Albrecht and Gaffney model
E= FP Kemerer model
E= FP small project regression model

23. The COCOMO II Model
Boehm suggested a hierarchy of software estimation models named: COCOMO.
COCOMO stands for COnstructive COst MOdel
Original COCOMO model became one of the most widely used and discussed software cost estimation models
COCOMO evolved into COCOMO II

24. COCOMO II Model (Cont.) COCOMO II addresses the following areas:
Application composition model
Used during the early stages of s/w engg.
when UI prototyping, s/w and system interaction, performance assessment and tech. evaluation are paramount.
Early design stage model
Used once requirements have been stabilized and basic architecture has been established
Post-architecture stage model
Used during the construction of software
Like other estimation models, COCOMO II uses sizing information (object points, function points and lines of code).

25. COCOMO II Model (Cont.)
COCOMO II Application composition model uses object points
Object points is an indirect software measure computed using
Screens (at UI)
Reports
Components likely to be required to build the application
Each object instance is classified into one of these complexity levels (simple, medium, difficult) on criteria suggested by Boehm.
Complexity is a function of number of client and server tables required to generate a screen or report and number of sections or views within a screen or report
After determining complexity, no. of screens, reports and components are weighted as in figure (23.6).
The object point count is determined by multiplying original no. of object instances by weighting factor.

26. Figures 23.6 & 23.7 Object Type Complexity Weight Simple Medium
Difficult
Screen 1 2 3
Report 5 8
3GL component 10
Developer’s experience/capability
Very Low
Low
Nominal
High
Very High
Environment maturity/capability
Very high
PROD 4 7 13 25 50

27. COCOMO II Model (Cont.)
For component-based development or when software reuse is applied, the %reuse is estimated and object point count is adjusted:
NOP = (object points) x [(100 - %reuse)/100]
NOP is new object points
To derive estimate of effort based on computed NOP value, a productivity rate must be derived
PROD = NOP / person-month
Estimate of project effort can be derived as:
Estimated effort = NOP/PROD

28. Excluded
23.8
23.9 and sub topics