A software project manager is confronted with a dilemma at the very beginning of a software engineering project. Quantitative estimates and...
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 requirements 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.
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?
Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input?
Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?
Software project scope must be unambiguous and understandable at the management 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, maximum 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.
Problem decomposition, sometimes called partitioning or problem elaboration, is an activity that sits at the core of software requirements analysis . During the scoping activity no attempt is made to fully decompose the problem. Rather, decomposition is applied in two major areas:
(1) the functionality that must be delivered and
(2) the process that will be used to deliver it.
Human beings tend to apply a divide and conquer strategy when they are confronted with a complex problems. Stated simply, a complex problem is partitioned 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. Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful.
As an example, consider a project that will build a new word-processing product. Among the unique features of the product are continuous voice as well as keyboard input, extremely sophisticated “automatic copy edit” features, page layout capability, automatic indexing and table of contents, and others. The project manager must first establish a statement of scope that bounds these features (as well as other more mundane functions such as editing, file management, document production, and the like). For example, will continuous voice input require that the product be “trained” by the user? Specifically, what capabilities will the copy edit feature provide? Just how sophisticated will the page layout capability be?
As the statement of scope evolves, a first level of partitioning naturally occurs. The project team learns that the marketing department has talked with potential customers and found that the following functions should be part of automatic copy editing:
(1) spell checking,
(2) sentence grammar checking,
(3) reference checking for large documents and
(4) section and chapter reference validation for large documents.
Each of these features represents a subfunction to be implemented in software. Each can be further refined if the decomposition will make planning easier.