The SEI CMM and Estimating

< Free Open Study >

The SEI CMM and Estimating The Software Engineering Institute (SEI) Capability Maturity Model (CMM) supports activities described here. Software project planning is a key process area for maturity Level 2, the repeatable level. The KPAs in Level 2 are a necessary foundation for the mature processes that follow in subsequent levels�planning the project is essential in the support of the software engineering, measurement, and continuous improvement activities occurring in levels 3 (defined), 4 (managed), and 5 (optimized). The importance of software estimation is emphasized by a specific goal (Goal 1) in the project planning KPA. Because the plan provides the basis for performing the product development activities and managing those activities, its significance is paramount. A subset of the goals, abilities, and activities associated with project planning is listed next.[1] A Goal of SEI CMM Level 2, Key Process Area (KPA): Software Project Planning (PP) Goal 1. Software estimates are documented for use in planning and tracking the software project. Ability to Perform, associated with KPA PP, Goal 1 Ability 4. The software managers, software engineers, and other individuals involved in the software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility. Activities Performed Activity 10. Estimates for the software project's effort and costs are derived according to a documented procedure. This procedure typically specifies that: Estimates for the software project's effort and costs are related to the size estimates of the software work products (or the size of the changes). Productivity data (historical and/or current) are used for the estimates when available; sources and rationale for these data are documented. The productivity and cost data are from the organization's projects when possible. The productivity and cost data take into account the effort and significant costs that go into making the software work products. Examples of significant costs that go into making the software work products include: direct labor expenses, overhead expenses, travel expenses, and computer use cost. Effort, staffing, and cost estimates are based on past experience. Similar projects should be used when possible. Time phasing of activities is derived. Distributions of the effort, staffing, and cost estimates over the software life cycle are prepared. Estimates and the assumptions made in deriving the estimates are documented, reviewed, and agreed to. Activity 11. Estimates for the project's critical computer resources are derived according to a documented procedure. Critical computer resources may be in the host environment, in the integration and testing environment, in the target environment, or in any combination of these. This procedure typically specifies that: Critical computer resources for the project are identified. Examples of critical computer resources include: computer memory capacity, computer processor use, and communications channel capacity. Estimates for the critical computer resources are related to the estimates of the size of the software work products, the operational processing load, and the communications traffic. Estimates of the critical computer resources are documented, reviewed, and agreed to. Activity 12. The project's software schedule is derived according to a documented procedure. This procedure typically specifies that: The software schedule is related to the size estimate of the software work products (or the size of changes), and the software effort and costs. The software schedule is based on past experience. Similar projects are used when possible. The software schedule accommodates the imposed milestone dates, critical dependency dates, and other constraints. The software schedule activities are of appropriate duration and the milestones are of appropriate time separation to support accuracy in progress measurement. Assumptions made in deriving the schedule are documented. The software schedule is documented, reviewed, and agreed to. A software engineering process group (SEPG) can help immeasurably in improving software cost estimation. Frequently, the starting point is a short course in software estimation given to project managers as well as estimators, if they are different people. The SEPG can also define the standards for collecting all project metrics, including effort, schedule, and cost estimation figures. They can be the party responsible for calibrating estimation models as the number of data points grows. The SEPG works well in tight coordination with SQA/SQE activities of defining and documenting policies, processes, and procedures, including those for cost estimation. These working groups can plan and help managers execute training and purchase and license estimation tools. Recall that we have some idea, however vague, about the product to be built by the time we begin to estimate size. Estimating is an iterative process (Figure 11-3), so we will get some requirements; estimate size, effort, schedule, and cost; create or update the work breakdown structure (WBS); forecast resource needs; check the software project management plan (SPMP) to see if anything needs to be updated; model as much of the requirements as we have; create or update the software requirements specification (SRS) document; go back to the requirements gathering; and repeat the cycle until the SRS is sufficient for design. Figure 11-3. Steps in Sizing and Estimating In Figure 11-1, the estimating process is shown occurring with the integral task of planning for project management. The planning activities occur in parallel with the development life cycle phases of concept exploration, system exploration, and requirements. Figures 11-3 and 11-6 show more precise steps in estimating. The process inside Steps 1�5 shown here in Figure 11-3 (eliciting requirements, estimating size, estimating effort, estimating schedule and cost) are further defined in Figure 11-6. Figure 11-6. Steps in Estimating One of the widely published and frequently quoted experts in the field of estimation, Capers Jones, claims that our first estimations are typically off by a factor of four. As the project progresses and more knowledge is gained, the updated estimates begin to converge on the actual. It's a chicken-and-egg situation�it's hard to estimate if requirements are not solid, yet, if we don't estimate something, we'll never get a contract (permission or funding) to move forward. These figures, shown in Figure 10-2, were first proposed by Dr. Barry Boehm and later were corroborated by Jones. Sizing is an important first step because all the following steps build upon it. Even if size is estimated in function points or object points, they are translated into thousands of lines of code (KLOC) before being placed into formulas or fed into estimating tools. Whether we like them or not (many do not), no other unit of measure has surfaced in the last 30 years that provides the same sort of universal acceptance. Size is typically estimated by analogy (comparisons to completed projects that are similar in scope and complexity), by a wideband Delphi process, or by counting function points, feature points, or object points. Whatever method is used by a project manager to arrive at his first size estimate for a project, size will be the basis for our discussion of effort, schedule, and cost estimating.

< Free Open Study >