Developed by Reneta Barneva, SUNY Fredonia Software Project Planning

Developed by Reneta Barneva, SUNY Fredonia

Software Project Planning


Observations on EstimationEstimate what?resources, cost, and schedule for a software engineering effort

What does it require?experience, access to good historical information, and … the courage to commit to quantitative predictions when qualitative information is all that exists.

Estimation carries inherent risk and this risk leads to

uncertainty.


Observations on EstimationFactors:Project complexity has a strong effect on the uncertainty inherent in planning. Complexity is a relative measure: beginner or experienced team.Project size can affect the accuracy and efficacy of estimates. As size increases, the interdependency among various elements of the software grows rapidly.

Murphy's law: "What can go wrong will go wrong"—and if there are more things that can fail, more things will

fail. Degree of structural uncertainty: structure refers to the ease with which the task can be subdivided.


Project Planning ObjectivesThe objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule.

These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progresses. In addition, estimates should attempt to define best case and worst case scenarios so that project outcomes can be

bounded.


Software ScopeThe first activity in software project planning is the determination of software scope.

A statement of software scope must be bounded.

Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability.


Software ScopeFunctions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful. Performance considerations encompass processing and response time requirements. Constraints identify limits placed on the software by external hardware, available memory, or other existing

systems.


Software Scope: Obtaining Information Necessary for Scope

How should we initiate communication between the developer and the customer?

Gause and Weinberg suggest that the analyst start by asking context-free questions:

Who is behind the request for this work?

Who will use the solution?

What will be the economic benefit of a successful solution?

Is there another source for the solution?



The next set of questions enables the analyst to gain a better understanding of the problem:

How would you (the customer) characterize "good" output that would be generated by a successful solution? What problem(s) will this solution address? Can you show me (or describe) the environment in which the solution will be used? Will any special performance issues or constraints affect the way the solution is approached?



The final set ("meta-questions”) of questions focuses on the effectiveness of the meeting:

Are you the right person to answer these questions? Are answers "official"?

Are my questions relevant to the problem that you have?

Am I asking too many questions?

Can anyone else provide additional information?

Should I be asking you anything else?


Software Scope: FeasibilityOnce scope has been identified, it is reasonable to ask: "Can we build software to meet this scope? Is the project feasible?"

Software feasibility has four solid dimensions:

Technology—Is a 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 it financially feasible? Can development be completed at a cost the software organization, its client, or the market can afford?

Time—Will the project's time-to-market beat the competition?

Resources—Does the organization have the resources needed to succeed?


Software Scope: ExampleA conveyor line


Resources


ResourcesThe development environment—hardware and software tools—provides the infrastructure to support the development effort.

At a higher level are the reusable software components—software building blocks that can dramatically reduce development costs and accelerate delivery.

The primary resource is people.

Each resource is specified with four characteristics:

description of the resource,

a statement of availability,

time when the resource will be required;

duration of time that resource will be applied.


ResourcesHuman Resources: The number of people required for a software project can be determined only after an estimate of development effort (e.g., person-months) is made.


ResourcesReusable software components:

Off-the-shelf components. Existing software that can be acquired from a third party or that has been developed internally for a past project.

Full-experience components. Existing specifications, designs, code, or test data developed for past projects that are similar to the software to be built for the current project.

Partial-experience components. Existing specifications, designs, code, or test data developed for past projects that are related to the software to be built for the current project but will require substantial modification.

New components. Software components that must be built by the software team specifically for the needs of the current project.


Software Project EstimationIn the early days of computing, software costs constituted a small percentage of the overall computer-based system cost.

Today, software is the most expensive element of virtually all computer-based systems.

Software cost and effort estimation will never be an exact science.

Too many variables—human, technical, environmental, political—can affect the ultimate cost of software and effort applied to develop it.


Software Project EstimationTo achieve reliable cost and effort estimates, a number of options arise:

Delay estimation until late in the project (obviously, we can 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 models for software cost and effort estimation.


Software Project EstimationCritics:First option is not practical. Cost estimates must be provided "up front." Secon option: unfortunately, past experience has not always been a good indicator of future results.

Ideally, the techniques noted for each option should be applied in tandem; each used as a cross-check for the other.


Software Project EstimationDecomposition techniques take a "divide and conquer" approach to software project estimation; cost and effort estimation can be performed in a stepwise fashion.

Empirical estimation models can be used to complement decomposition techniques and offer a potentially valuable estimation approach in their own right.

A model is based on experience is d = f (vi)

where d is one of a number of estimated values (e.g., effort, cost, project duration) and vi are selected independent parameters (e.g., estimated LOC or FP).

Automated estimation tools implement one or more decomposition techniques or empirical models. In such systems, the characteristics of the development organization (e.g., experience, environment) and the software to be developed are

described. Cost and effort estimates are derived from these data.


Decomposition TechniquesSoftware sizing problem.

Size refers to a quantifiable outcome of the software project.

If a direct approach is taken, size can be measured in LOC.

If an indirect approach is chosen, size is represented as FP.



"Fuzzy logic" sizing. This approach uses fuzzy logic. To apply this approach, the planner must identify the type of application, establish its magnitude on a qualitative scale, and then refine the magnitude within the original range.

Function point sizing. The planner develops estimates of the information domain characteristics. (Chap. 4)



Standard component sizing. Software is composed of a number of different "standard components" that are generic to a particular application area.

Change sizing. This approach is used when a project encompasses the use of existing software that must be modified in some way as part of a project. The planner estimates the number and type of modifications that must be accomplished.


Decomposition TechniquesProblem-Based Estimation


Decomposition TechniquesLOC-Based Estimation


Decomposition TechniquesFP-based estimation

Decomposition for FP-based estimation focuses on information domain values rather than software functions.

The project planner estimates inputs, outputs, inquiries, files, and external interfaces.

For the purposes of this estimate, the complexity weighting factor is assumed to be average.




Decomposition TechniquesFP-based estimationEach of the complexity weighting factors is estimated and the complexity adjustment factor is computed as described in Chapter 4:

Factor Value

Backup and recovery 4

Data communications 2

Distributed processing 0

Performance critical 4

Existing operating environment 3

On-line data entry 4

Input transaction over multiple screens 5

Master files updated on-line 3

Information domain values complex 5

Internal processing complex 5

Code designed for reuse 4

Conversion/installation in design 3

Multiple installations 5

Application designed for change 5

Complexity adjustment factor 1.17



Finally, the estimated number of FP is derived:

FPestimated = count-total x [0.65 + 0.01 x S (Fi)]

FPestimated = 375

The organizational average productivity for systems of this type is 6.5 FP/pm. Based on a burdened labor rate of $8000 per month, the cost per FP is approximately $1230. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months.


Empirical Estimation Models

An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC or FP.

Values for LOC or FP are estimated, but instead of using the tables described in those sections, the resultant values for LOC or FP are plugged into the estimation model.



A typical estimation model is derived using regression analysis on data collected from past software projects.

The overall structure of such models takes the form

E = A+ B (ev)C

where A, B, and C are empirically derived constants, E is effort in person-months, and ev is the estimation variable (either LOC or FP).

The majority of estimation models have some form of project adjustment component that enables E to be adjusted by other project characteristics (e.g., problem complexity, staff experience, development environment).



LOC - oriented



FP- oriented


The Make/Buy DecisionSoftware engineering managers are faced with a make/buy decision. It may be further complicated by a number of acquisition options:

(1) software may be purchased (or licensed) off-the-shelf,

(2) "full-experience" or "partial-experience" software components may be acquired and then modified and integrated to meet specific needs, or

(3) software may be custom built by an outside contractor to meet the purchaser's specifications.


The Make/Buy DecisionFor more expensive software products, the following guidelines can be applied:

1. Develop specifications for function and performance of the desired software. Define measurable characteristics whenever possible.

2. Estimate the internal cost to develop and the delivery date.

3a.Select three or four candidate applications that best meet your specifications.

3b. Select reusable software components that will assist in constructing the required application.

4. Develop a comparison matrix that presents a head-to-head comparison of key functions. Alternatively, conduct benchmark tests to compare candidate software.

5. Evaluate each software package or component based on past product quality, vendor support, product direction, reputation, and the like.

6. Contact other users of the software and ask for opinion.


The Make/Buy Decision: 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 in this chapter, the project planner projects 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

expected cost = S (path probability)i x (estimated path cost)i

where i is the decision tree path. For the build path,

expected costbuild = 0.30 ($380K) + 0.70 ($450K) = $429K



Following other paths of the decision tree, the projected costs for reuse, purchase and contract, under a variety of circumstances, are also shown. The expected costs for these paths are

expected costreuse =

0.40 ($275K) + 0.60 [0.20($310K) + 0.80($490K)] = $382K

expected costbuy = 0.70($210K) + 0.30($400K)] = $267K

expected costcontract = 0.60($350K) + 0.40($500K)] = $410K


Automated Estimation ToolsAutomated estimation tools allow the planner to estimate cost and effort and to perform "what-if" analyses for important project variables such as delivery date or staffing.

All automated tools perform the following six generic functions:

•Sizing of project deliverables. The "size" of one or more software work products is estimated.

– Output: e.g., screen, reports,

–The software itself (e.g., KLOC),

– Functionality delivered (e.g., function points),

– Descriptive information (e.g. documents).


Automated Estimation Tools•Selecting project activities. The appropriate process framework is selected and the software engineering task set is specified.

•Predicting staffing levels. The number of people who will be available to do the work is specified.

•Predicting software effort. Estimation tools use one or more models that relate the size of the project deliverables to the effort required to produce them.

•Predicting software cost. Given the results of step 4, costs can be computed by allocating labor rates to the project activities noted in step 2.

•Predicting software schedules. When effort, staffing level, and project activities are known, a draft schedule can be produced by allocating labor across software engineering activities based on

recommended models for effort distribution.

Documents

Developed by Reneta Barneva, SUNY Fredonia Software Project Planning