Chapter 23

Chapter 23

Software Project Planning

CHAPTER OVERVIEW AND COMMENTS

This chapter provides students with basic information on estimating for software projects. The estimating task involves estimating how much time, effort, and resources are required to build a software product. In most cases, there is enough information provided in the text to allow students to estimate their own projects and write their own planning documents.  Students should be assigned the task of using the planning document template on the SEPA web site to write a planning document as part of their coursework early in the semester.

23.1     Observations on Estimating

The point to get across in this section is that project estimation is a difficult task to do without historical data and a fair amount of experience with the proposed application. Nonetheless, it is a task that is required for virtually all projects. Project complexity, project size, and structural uncertainties affect the reliability of the estimate.

23.2     The Project Planning Process

The objective of software project planning is providing a framework that allows managers to make reasonable estimates of the resources and time required to build a software product. It is important to point out to the students that the more information an estimator has, the better his or her estimates will be. This is an important reason to update all estimates, as the actual project costs and schedule become known as the project unfolds.

The task set presented in this section should be discussed during lecture. Students may be unfamiliar with many steps, if they do not have actual project experience.

23.3     Software Scope and Feasibility

Determining the scope of a software project is the first project planning activity. Students need to understand that until the developer and customer agree on the scope of the project it is impossible to determine what the project will cost and when the project will end. The best software practices call for the customer and developer to work together to identify the problem areas to be addressed and to negotiate different approaches to their solutions. Once the project scope is established, feasibility is the next issue to address. It is sometimes hard for young software developers to recognize that having the resources and capabilities needed to build a system, does not always justify building it. The best interests of the customer must come first, even if it means advising against the creation of a new software product.

23.4     Resources

For software project work the resources used involve people, reusable software components, the development environment (hardware and software). The number of people required for software projects can only be determined after an estimate of development (e.g. person months) effort is computed.  Students may have a tough time relating to software reuse. Student are either anxious to build their own software or naively believe that all they need to do is browse the Internet for some code to download. A more detailed discussion of component-based software design and software reengineering appears later in the text. In modern software development, people and hardware may be shared among several projects. Time windows for resource availability must be prescribed and planned for.

I would suggest using Figure 23.1 for your talking points as you discuss this topic during lecture.

23.5     Software Project Estimation

Software is now the most costly element of virtually every computer-based system. Cost and effort estimates may determine whether an organization can realistically undertake the development of software product or not. Software estimating can never be an exact science, but even students can be taught the steps needed to make estimates having acceptable risks associated with them. It is important to get students used to the idea or using 2 or more methods for making an estimate and then using the results to cross check one another. Students should be encouraged to reconcile the differences between multiple estimates to improve their confidence in the values computed.

23.6     Decomposition Techniques

This section compares two methods of performing software sizing (directly by estimating LOC or indirectly using FP). The function point method seems to be a little easier for students to work with during the planing phase of their projects. The text suggests using the expected value (3 point) method of adjusting their software size estimates (either LOC or FP). It will be easier for students to develop meaningful LOC or FP estimates if they attempt to decompose their projects along functional lines and then estimate the size of each subfunction individually. This approach is called problem-based estimation. Process-based estimation is also discussed in this section. Students often prefer process-based estimation since they are estimating the amount of time they plan spend on the tasks that make up each phase of their process model after they have determined the work products for each phase (several low cost PC scheduling tools support this method, like MS Project). It may be wise to have the students reconcile the results obtained from a problem-based method like FP with their process-based estimates. It is important to point out that without some historical data to give these estimates a context LOC and FP values may not be very useful for estimating cost or effort.

Sections 23.6.7 and 23.6.8 discuss estimation using use-cases. It’s important to emphasize that this approach is still in its infancy and is likely to result in somewhat less reliable estimates.

23.7     Empirical Estimation Models

This section describes the general process of creating and using empirical cost estimation models. It may be wise to work through an example showing how a simple linear regression model is created from raw data and used to predict the value of dependent variables from new data points. Most students have not seen linear regression prior to this course and may not appreciate how these models are built. The equations in these models still require inputs like LOC or FP but users do not need local project data to compute their estimates. Model users only need to be confident that their project is similar to those used to create the model in the first place. The complete details of COCOMO II are not given in text and will need to be found on the COCOMO II Web site. Similarly, the details of the Software Equation will need to be located on the Web.

23.8     Estimation for Object-Oriented Projects

You should examine the similarities and differences between the model presented for conventional and OO project estimation. Lines of code (LOC) and function point (FP) techniques are not always relevant to estimating object-oriented projects. Students should be encouraged to use the OO estimating and scheduling approach presented in this section on one of their own projects. Examining predicted versus actual time and project size for a completed project (using the text values) may be a worthwhile activity.

23.9     Specialized Estimation Techniques

Estimation for agile software development and Web engineering projects is presented in this section. The steps outlines for agile projects make heavy use of scenarios (a mini-use-case) as the independent estimation variable. You should note that the “modified” FP measure suggested for WebE projects must be calibrated locally before it can be used at the project level.

23.10     The Make-Buy Decision

The make-buy decision is an important concern these days. Many customers will not have a good feel for when an application may be bought off the shelf and when it needs to be developed. The software engineer needs to perform a cost benefit analysis in order to give the customer a realistic picture of the true costs of the proposed development options. The use of a decision tree is a reasonable way to organize this information. Outsourcing is a popular idea for many companies these days. The decision is usually motivated by the promise of reducing costs. This promise may or may not prove to be true, if the outside contractor handles the project management.