Required development schedule

Changes to underlying effects (less impact)

The EAF multiplier again represents the combined effects of multiple parameters. In Ada COCOMO, however, there were several changes to reflect general improvements to COCOMO, Ada-specific effects, and the effects of a more iterative process. This adjustment resulted in two new cost drivers (RUSE and SECU), one split cost driver (VIRT was split into host and target components: VMVH and VMVT), and several new ratings or changes to the underlying effects of a cost driver.

One of the foundations of Ada COCOMO was the use of the Ada process model. It was not necessary to use the Ada language in order to use the primary techniques of this process model. However, at the time it was developed, there was so much Ada underhype and overhype within the defense software market that the process description was coupled to the use of Ada. This approach had its pros and cons. In retrospect, the Ada process model can be viewed as an intermediate state between the conventional process and the modern process framework described in this book. Ada process model strategies are summarized here to provide an understanding of the process parameterization of the Ada COCOMO exponent.

One critical strategy of the Ada process model was to emphasize the preliminary design review (PDR) milestone, which was required by the applicable military standard, as an architecture review supported by an executable demonstration of capabilities. This overarching goal led to several substrategies that exploited the techniques, tools, and technologies of the Ada environment:

• A small core design team with expertise in software architecture and the applications domain

• An early focus on executable architecture skeletons for demonstrating critical components and system-level threads and for exposing risk

• Incremental and separate detailed design walkthroughs for components and builds rather than a monolithic critical design review (CDR) across the whole system

• Continuous integration via Ada compilation and architecture-first development

• Test program and requirements verification focused on engineering string tests (now called use cases) and component stand-alone tests

• Self-documenting Ada code and big-picture descriptions instead of massive, detailed design documents that describe the as-built design

• Automated metrics derived from the evolving code baselines

The Ada COCOMO process exponent ranged from 1.04 to 1.24 and was defined from the combined effects of the following four parameters:

1. Ada process model experience. This process maturity rating ranged from "no familiarity" with the process to "successfully employed on multiple projects."

2. Design thoroughness at PDR. This parameter characterized the level of design detail inherent in the design baseline demonstrated at PDR. It ranged from "little thoroughness (20%)" to "complete thoroughness (100%)."

3. Risks eliminated at PDR. This parameter assessed the level of uncertainty inherent in the project at PDR, after which full-scale development is initiated. It ranged from "little risk resolution (20%)" to "complete resolution (100%)."

4. Requirements volatility during development. This parameter ranged from "many large changes" to "no changes," characterizing the amount of process turbulence confronted by the project.

The actual exponent for Ada COCOMO was determined by summing the ratings for each parameter across a scale from 0.00 to 0.05. The embedded mode exponent (1.20) from the original COCOMO would relate to an Ada COCOMO process with a 0.04 rating on each of the process parameters [1.04 + (4 x 0.04)]. In terms of the process parameters just described, this would correspond to (1) little familiarity with the Ada process model, (2) some design thoroughness at PDR (40%), (3) some risks eliminated by PDR (40%), and (4) frequent but moderate requirements changes.

These four parameters were aimed primarily at characterizing the process and its ability to relieve the diseconomies of scale inherent in the conventional process. By keeping the design team smaller and establishing a more tangible architecture description by PDR, the process attempted to optimize interpersonal communications, avoid late downstream rework, and encourage earlier requirements convergence.

Was this article helpful?

0 0
Corporate Domination Tactics

Corporate Domination Tactics

Learning About Corporate Domination Tactics Can Have Amazing Benefits For Your Life And Success! Own The Corporate World And Be Your Own Man! Huge businesses like Wal-Mart have demonstrated to us all the mightiness of a corporation, now you as well may harness that might.

Get My Free Ebook

Post a comment