Project Planning and Estimation

Chapters 23, 24
Software Engineering: A Practitioners Approach
Roger S. Pressman

Project Planning
When: need for software has already been established; stakeholders are on-board; coding is ready to begin What: project planning spans five major activitiesestimation, scheduling, risk analysis, quality management planning, and change management planning Who: software project managers, with information from stakeholders and engineers

Estimation
Planning requires estimation early-on, even though it is likely this commitment will be proven wrong Some degree of uncertainty is unavoidable when predicting into the future Solid techniques and concrete procedures help reduce the inaccuracy of estimates

Process-based estimation
Most commonly-used technique for project estimation Project is broken down into a relatively small set of tasks and the effort required to accomplish each task is estimated Begins with a delineation of software functions obtained from the project scope

Process-based estimation
A series of framework activities must be performed for each function Representative framework activities:
Customer communication Planning / risk analysis Engineering Construction / release

Functions and activities may be shown together as a table:

Process-based estimation table

Activity Function UICF 3DGA GCDF DBM PCF DAM Totals % effort .25 1% .25 1% .25 1% CC Planning Risk analysis Engineering Anal. 0.75 0.50 0.50 0.50 0.25 0.50 3.00 7% Design 2.50 4.00 4.00 3.00 2.00 2.00 17.50 45% Release Code 0.40 0.60 1.00 1.00 0.75 0.50 4.25 12% Test 5.00 2.00 3.00 1.50 1.50 2.00 15.00 40% n/a n/a n/a n/a n/a n/a 8.65 7.10 8.50 6.00 4.50 5.00 34.80 CE Totals

Process-based estimation
Once functions and activities are melded, the planner estimates the effort (personmonths) required to accomplish each activity per function Average labor rates are then applied to the estimated efforts (may vary per task) Cost and effort for each function and activity (row and column totals) are computed as the last step

Estimation with use-cases

Use-cases provide insight into software scope and requirements However, developing an estimation approach with use-cases is problematic:
There is no standard form for use-cases They represent an external view (the users view) of the software, and vary in levels of abstraction Use-cases do not address the complexity of a feature Use-cases do not describe complex interactions between many functions and features

Estimation with use-cases

One persons use-case could require months of effort, another just a day or two Estimation using use-cases has been investigated, but no proven method has emerged to date. Smith suggests a method for using usecases, but in a strict, hierarchical manner

Use-case estimation
A structural hierarchy is described for the project Any level of the hierarchy can be described by no more than 10 use-cases Each of the use-cases would encompass no more than 30 distinct scenarios

Use-case estimation
Use-cases for a large system are described at a much higher level of abstraction then use-cases for individual sub-systems Before use-cases can be used:
The level within the structural hierarchy is established Average length (in pages) of each use-case is determined The type of software (business, scientific, etc) is defined Rough architecture for the system is considered

Use-case estimation
Once those characteristics are established, empirical data can be used to determine estimated LOC or FP per each use-case for each level of the hierarchy Historical data are then used to calculate the effort required to develop the system

Sample use-case estimation

LOC = N LOCavg + [(Sa/Sh - 1) + (Pa/Ph - 1)] LOCadjust
N = actual number of use-cases LOCavg = historical average LOC per use-case for this type of system Sa = actual scenarios per use-case Sh = average scenarios per use-case for this type of system Pa = actual pages per use-case Ph = average pages per use-case for this type of system LOCadjust= represents an adjustment based on n percent of LOC where
n is defined locally and represents the difference between this project and average projects

Reconciling estimates
The various estimation methods encountered result in multiple estimates which must be reconciled The goal of a reconciliation process is to produce a single estimate of effort, project duration, or cost Complicated methods might not yield a more accurate estimate, particularly when developers can incorporate their own intuition into the estimate. -- Philip Johnson, et al.

Reconciling estimates
Widely divergent estimates can often be traced to one of two causes:
The scope of the project is not adequately understood or has been misinterpreted by the planner Productivity data used for problem-based estimation is inappropriate for the application, obsolete, or has been misapplied.

The planner must determine the cause of the divergence to reconcile the estimates

Estimation for Agile projects

Requirements for an agile project are defined as a set of user scenarios (e.g., stories in Extreme Programming) It is possible to develop an estimation approach that is informal, but reasonable disciplined for each software increment This approach uses a decomposition method with the following steps:

Estimation for Agile projects

1. Each user scenario is considered separately for estimation purposes 2. The scenario is decomposed into the set of functions and engineering tasks required to develop them 3. Each task is estimated separately, based on historical data, an empirical model, or experience 4. Estimates for each task are summed to obtain an estimate for the scenario

Estimation for Agile projects

5. The effort estimates for all scenarios are summed for a given increment to obtain the increment estimate
Because the project duration of an increment is short (3-6 weeks), the estimation approach serves two purposes:
Ensure that the number of scenarios conforms to available resources Establish a basis for allocating effort as the increment is developed

Estimation for web engineering projects

Web engineering projects often adopt the Agile process model Along with the Agile estimation approach, a modified function point (FP) measure can be used to develop an estimate for a web application Roetzheim suggests the following information domain values when adopting function points:

Web application domain values

Inputs are each input screen or form, each maintenance screen, and each tab (if that design metaphor is used anywhere) Outputs are each static web page, each dynamic page (script), and each report (whether web-based or administrative) Tables are each logical table in the database, or each XML object or collection of XML attributes (if XML is used for storage)

Web application domain values

Interfaces retain their definition as logical files (for example, unique record formats) into our out-of-the-system boundaries Queries are each externally published or use a message-oriented interface. A typical example is DCOM or COM external references Function points computed with these values are a reasonable indicator of volume for a web application

Web application estimation

Mendes suggests that the volume of a web application is best determined by collecting measures associated with the application called predictor variables These include:
Application level: page, media, and function count Page level: page, linking, and graphic complexity Media level: media size, duration Functional characteristics: code length, reused code length

Software project scheduling

Creating a network of software engineering tasks enabling you to get the job dome on time Responsibility is assigned for each task, progress is tracked, and the network is adapted to changes in the process as they occur

Software project scheduling

I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams

Relationship between people and effort

For small software projects, one person can analyze requirements, perform design, generate code, and conduct tests As the projects grow in size, more people most become involved As this happens, more and more time is spent managing the interaction and communication among the people involved

Relationship between people and effort

Common myth still believed by many software managers:
If we fall behind schedule we can always add more programmers to catch up. Smiths law: Adding more people to a late software project always makes it later.

Relationship between people and effort

People added to the project must learn the system, and the people who can teach them are the people currently producing code In addition to learning time, more people means more communication paths and increasing the complexity of communication throughout the project

Elasticity of project schedules

Empirical data and analysis has demonstrated that project schedules are elastic It is possible to compress a desired project completion date to some degree by adding resources Conversely, removing resources can extend a completion date

Putnum-Norden-Rayleigh Curve
The PNR Curve provides an indication of the relationship between effort applied and delivery time for a software project There is a highly non-linear relationship between chronological time to complete a project and human effort applied

Putnum-Norden-Rayleigh Curve
The number of delivered lines of code L is related to effort and development time by the equation:
L = P E1/3t4/3
E is development effort in person-months P is a productivity parameter that reflects that result in high quality (typically 2,000-12,000) t is the project duration in calendar months

Putnum-Norden-Rayleigh Curve
Rearranged to solve for development effort:
E = L3/(P3t3)
E is effort expended (in person-years) over the entire project life-cycle L is lines of code (source statements) P is a productivity parameter that reflects that result in high quality (typically 2,000-12,000) t is the development time in years