Page 96 -

CHAPTER 3 PROJECT MANAGEMENT CONCEPTS 67

3.3 THE PRODUCT

A software project manager is confronted with a dilemma at the very beginning of a
software engineering project. Quantitative estimates and an organized plan are
required, but solid information is unavailable. A detailed analysis of software require-
ments would provide necessary information for estimates, but analysis often takes
weeks or months to complete. Worse, requirements may be fluid, changing regularly
as the project proceeds. Yet, a plan is needed "now!"
Therefore, we must examine the product and the problem it is intended to solve
at the very beginning of the project. At a minimum, the scope of the product must be
established and bounded.

3.3.1 Software Scope
The first software project management activity is the determination of software scope.
Scope is defined by answering the following questions:
Context. How does the software to be built fit into a larger system, product, or
business context and what constraints are imposed as a result of the context?
If you can’t bound a
characteristic of the Information objectives. What customer-visible data objects (Chapter 11) are
software you intend to produced as output from the software? What data objects are required for input?
build, list the Function and performance. What function does the software perform to
characteristic as a transform input data into output? Are any special performance characteristics
major project risk.
to be addressed?
Software project scope must be unambiguous and understandable at the manage-
ment and technical levels. A statement of software scope must be bounded. That
is, quantitative data (e.g., number of simultaneous users, size of mailing list, maxi-
mum allowable response time) are stated explicitly; constraints and/or limitations
(e.g., product cost restricts memory size) are noted, and mitigating factors (e.g., desired
algorithms are well understood and available in C++) are described.

3.3.2 Problem Decomposition
Problem decomposition, sometimes called partitioning or problem elaboration, is an
activity that sits at the core of software requirements analysis (Chapter 11). During
the scoping activity no attempt is made to fully decompose the problem. Rather,
In order to develop a decomposition is applied in two major areas: (1) the functionality that must be deliv-
reasonable project ered and (2) the process that will be used to deliver it.
plan, you have to Human beings tend to apply a divide and conquer strategy when they are con-
functionally fronted with a complex problems. Stated simply, a complex problem is partitioned
decompose the
problem to be solved. into smaller problems that are more manageable. This is the strategy that applies as
project planning begins. Software functions, described in the statement of scope, are
evaluated and refined to provide more detail prior to the beginning of estimation