10.36 Estimating for Reality | Managing Software Deliverables: A Software Development Management Methodology

< Day Day Up >

Every project is part art, part science, and part wizardry. Estimates are a high form of wizardry. Good estimates come from good project planning. The ability to fully comprehend the depth and scope of the effort is not something everyone intuitively knows. How is it that some Project Managers can be so far off the mark while others are so close to the mark? It boils down to knowing how to scope things out at a level of detail that can be tracked and that accurately reflects reality. How do you learn that? Experience is a good teacher, but not for the person who never hits the mark. Well, how then?

Several techniques are used for project cost estimation, but the two basic approaches are top-down and bottom-up. In a top-down approach, cost is derived from a business analysis of the major project components. In a bottom-up approach, cost is derived by accumulating estimates from the people responsible for various components. Formal software project estimation depends on analysis of four key factors: size, complexity, capability, and process. Models that quantified these factors and compare them with industry norms can yield highly accurate estimates for software efforts. The primary techniques used most often for cost estimation of these components are explained in the following paragraphs.

10.36.1 Size

Software size is rated based on either quantification of physical characteristics of an application (e.g., source code, tables, screens) or logical characteristics about the work that an application performs (i.e., function points). Physical characteristics such as source lines of code are useful for estimating if all you want to predict is the time and cost of coding. That might sound reasonable, but keep in mind that coding is only a small part of the overall budget. If you’re developing in a modern environment using C++, for example, odds are that coding will only account for 5 to 10 percent of your cost. It’s not much different than for mainframe COBOL either, by the way. Function points correlate extremely well to all aspects of a software project. If you want to manage software development, predict cost, effort, duration, staffing, and other key factors, this is the only real choice.

10.36.2 Complexity

When gauged for the purpose of software estimation, complexity operates as an adjustment for technology (required as in algorithmic complexity or as a function of the technology, as with code or data complexity.) Three commonly used types of complexity factor are the following:

Algorithmic complexity: Correction for the level of effort required to resolve complex business problems
Structural complexity: Quantitative scale that describes recursive statements in the source code.
Relational complexity: Extent of data organization complexity

10.36.3 Capability

Software organization capability (also referred to as maturity level) is a significant factor in the estimation of software projects. Addressing the factors cited as follows throughout a software project mitigates risk:

Personnel: Experience and skills of managers, developers, users
Technology: Software tools and platform issues
Process: Development methods, quality assurance, testing, documentation
Product: Hardware and software requirements, constraints, and architectures
Environment: Organization, office and physical environment

10.36.4 Process

The WBS reflects the activities undertaken during a project. This may be a formal methodology (e.g., Waterfall, Spiral, Object-Oriented) or it may be ad hoc. In any case, the following information from each task may be identified and/or quantified:

Work effort and associated cost
Capital (fixed) costs
Duration
Staffing (roles and number of full-time equivalents)
Deliverables (e.g., source code, documentation, test cases, defects found)
Predecessor and dependent tasks

The following excerpted from the DoD Parametric Cost Estimating Handbook[17], describes this process approach in further detail.

  The work breakdown structure provides a framework for spec- ifying the technical objectives of the program by first  defining the program in terms of hierarchically related  product-oriented elements and the work processes required  for their completion. Each element of the work breakdown  structure provides logical summary points for assessing  technical accomplishments, and for measuring the cost and  schedule performance accomplished in attaining the speci- fied technical objectives.

For each work breakdown structure element, the detailed technical objectives are defined as well as the specific work tasks assigned to each of the resources, materials, and processes required to attain the objectives. As resources are employed and work progresses on the task, current technical, schedule, and cost data are reported. The task data may then be summarized to provide successive levels of management with the appropriate report on planned, actual, and current projected status of the elements for which they are responsible. Management will, thus, be better able to maintain visibility of status and to apply their efforts to assure desired performance.

Work is effort performed by people to transform or create products to solve identified problems in order to verifiably meet specified objectives. Just as the organization hierarchically structures the people who perform work, so the work breakdown structure hierarchically structures the products to be produced and on which the people work. Examples of these products include equipment (hardware/software), data, services and facilities for such systems as missile systems, helicopter systems, automated systems, etc.

In order to use the work breakdown structure as a framework for structuring the technical objectives of a program, in addition to its use as a management tool for cost and schedule control, it is important that the work breakdown structure be product-oriented. Its elements should represent identifiable work products whether they be equipment (hardware, software), data, or service products. Because any work breakdown structure is a product structure, not an organizational structure, complete definition of the effort encompasses the work to be performed by all participants.

The program work breakdown structure should be developed in the conceptual stages of the program. The program work breakdown structure evolves during conceptual design from an iterative analysis of the program objective, functional design criteria, program scope, technical performance requirements, proposed methods of performance, including procurement strategy, as well as drawings, process flow charts, and other technical documentation.

< Day Day Up >