CS 477 Lecture Notes

Week Ten, Tuesday: Planning

Planning should take place during all phases of the software life cycle, but is usually most intense right after the specification phase.

Estimating Duration and Cost

Software project cost and duration estimating is inherently problematic. No fully satisfactory approach exists today. The best known and most successful cost model, COCOMO (Boehm), relies on an estimate of the size of the product (KDSI).

The FFP metric for medium scale data processing products uses a linear formula:

Cost = b * (Files + Flows + Processes)

Albrecht's function point metric is also linear, making it suspect for larger software projects.

FP = TCF * (4 * Inp + 5 * Out + 4 * Inq + 10 * Maf + 7 * Inf)

Estimates using function points are generally only off by a factor of two, while estimates based on source size are generally off by a factor of eight or more.

	Assembler version	Ada version
Source code size	70 KDSI	25 KDSI
Development costs	$1,043,000	$590,000
KDSI per man-month	0.335	0.211
Cost per source statement	$14.90	$23.60
Function points per man-month	1.65	2.92
Cost per function point	$3,023	$1,170

Comparison of assembler and Ada products, C. Jones, 1987,
copyright 1987 IEEE.

Techniques of cost estimation fall into three categories:

Expert judgement by analogy.
Bottom-up.
Algorithmic cost model.

After the project is underway, the predictions must be tracked to detect deviations and take corrective action.

Components of a SPMP

Work description, human, hardware, facilities, and other resources, and money.

Resource consumption follows the Rayleigh curve:

R = (t / k²) * e^{-t² / (2 * k²)}

with t running from zero to infinity. The parameter k is the time of peak consumption.

Rayleigh curve for k = 10.

IEEE SPMP

The formalized SPMP framework is concerned with the development phase of software production. Any maintenance plan must be attached at the end, almost as an afterthought.

Planning of Testing

As with the maintenance plan, the IEEE SPMP treats test planning as an afterthought. For traceability, the requirement and specification item identification numbers should be used for test plan items. This will have meaning only if those numbers are also used to identify the corresponding design and code modules.

For large projects, a traceability database can be useful (see the traceability database development plan document handout). Traceabilty, however (and this is a sad reminder of how bad a state software engineering practice is in today) is generally carried out on an ad hoc basis.

Planning of Object Oriented Projects

Object reuse can affect the planning of projects. Creating objects for deliberate reuse can cost more initially, but will result in lowered maintenance costs and reduced costs for future projects. Identifying objects for reuse can be problematic, but designing all objects for reuse can be costly and unrealistic. Making objects sufficiently generic for reuse can also increase code size, hurt performance, and increase the difficulty of software understanding, which can adversely impact maintenance.

Training Requirements

Software engineers must understand the customer's world. Sometimes that requires formal training. For instance, developing software for medical instruments requires some knowledge of medicine. Building software for tactical fighter planes requires some knowledge of warfare. New tools and languages also require training of developers.

The users already know their own job environments. Ideally, software should be so well designed that its use is intuitive enough that user training is unnecessary. In some cases, workplace automation, when done in the best way, eliminates waste and duplication to the point that work methods are streamlined such that the workers will require training (not so much in software operation, but in whole new approaches to their jobs).

Documentation Standards

Jones: 28 to 66 pages per KDSI (IBM). Boehm: 3/5 to 2/3 of production time spent on documentation (TRW).

Standards in document format and content reduce confusion. Code format standards assist the maintenance effort. User manual standards help keep the users from getting confused, reducing the support effort.

CASE Tools for Planning

Nine out of 10 users of word processors at TRW do not use paragraph tags. The default tags include the heading tags H1, H2, H3, etc. The reason that tags are not used is that training of users is generally neglected. MS Word, the TRW standard word processor, comes with a tutorial, but it's obvious most users have never taken it.

PERT (project evaluation and review techniques) is a network (graph) in which the nodes are milestones and the edges are durations. The "critical path" is identified. To be useful, the PERT network must be continuously updated.

PERT chart for the Robo-Butler project example.

Here is a PERT chart generated by Microsoft Project, for a producibility modeling and optimization project I am working on at TRW:

In this PERT chart, each block is a task with a duration.
The critical path is shown in red.

In this example, the nodes are tasks and the edges are relationships (such as finsih-to-start). "Summary tasks" are shown on the left. Notice how the automatically generated chart is not very artfully laid out, with edges running under nodes. If this chart were any larger, it could get confusing fairly fast. One software vendor, Tom Sawyer Software, makes tools for untangling messy diagrams, as shown below:

The Graph Layout Toolkit automatically calculates the coordinates
of objects, enabling you to model data from any application domain in
the form of a graph.

Planning Testing

This does not mean "the planning of the testing," but rather "how to test the SPMP." SQA checks the SPMP. Duration and cost estimates should be independently computed.

This page established March 12, 1998; last updated January 17, 2000.