Chapter Comments
Chapter
23-1
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-2
SEPA, 6/e Instructor’s Guide
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
Chapter Comments
23-3
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 problembased 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
23-4
SEPA, 6/e Instructor’s Guide
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 miniuse-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.