Integrated Product Development Lifecycle Process

 The ACE integrated product development lifecycle process has been refined through experience on many projects over decades of systems development.  It is fully compliant with DOD-STD-2167A, MIL-STD-498, and Level 3 of the Software Engineering Instituteís (SEI) Capability Maturity Model (CMM).  Our process is shown in Figure 1 and described in the following paragraphs.  As shown in the Figure, tracing down the left column represents the decomposition portion of the lifecycle and tracing up the right column shows the recomposition through project completion.

Figure-1.  Our Development Lifecycle Process Incorporates Commercial Best Practices and is Fully Compliant with DoD-STD-2167A, MIL-STD-498, and Level 3 of the SEI-CMM.

In the Figure, the boxes represent the lifecycle phases. To the right of each phase lists the document that captures the information produced or captured during that phase as a natural byproduct of our engineering process.  To the left of each phase lists the associated Review to ensure we are fully coordinated at each step of the development process.  The baselines are also listed beside the appropriate phase to illustrate our developmental configuration management (CM), and conclude with a new operational baseline that is controlled by our formal CM processes.

This lifecycle is fully complete, and can be accelerated based on priority to be highly responsive and meet time critical needs.  We have accomplished the entire lifecycle in a few days on small, high priority projects.  This provides the balance of proven sound engineering processes with responsive support.

Project Requirements Analysis Phase.  Joining with our customer in Project Requirements Analysis we examine the needs of the project and capture this analysis in the project specification.  A project can be a system of systems like the space shuttle, it could be an integrated hardware/software system, or it could be a single piece of system or piece of software.  We analyze it from the enterprise view to ensure efficiencies will be fully incorporated.  This includes identifying and eliminating duplication of effort and functionality as well as generating candidates for efficiencies in other areas across the enterprise.  If the project is a mission-related system like the EuroRoland Surface to Air Missile (SAM), this analysis will also include all requirements of the mission including hardware, software, facilities, transportation, environmental, safety, etc.  This information is captured in the Project Specification document and is reviewed at the Project Requirements Review.

Project Planning Phase.  In the Project Planning phase, we define our plan to meet the project requirements.  This may include reusing systems, strategies, components, and approaches from similar efforts in the past. We define all resources required to successfully complete the project.  We identify key risks and define a mitigation strategy for each risk, then track that risk throughout the lifecycle until either project completion or when the risk is no longer poses a threat to the project.  This information is captured in the Project plan and is reviewed at the Project Plan Review.

Project IT Support Definition Phase.  Moving to the Project IT Support Definition phase, we detail the Information Technology support required by this project.  This includes all aspects of support including server support (CPU, Disk, tape, etc.), network bandwidth (wired and wireless), workstation, laptop, Personal Digital Assistant (PDA), and other components (such as security and backups) as required.  This information is captured in the Project IT Support Definition document and is reviewed at the Project IT Support Review.  This information may be updated later in the lifecycle as more information becomes available. This reflects the flexible, iterative nature of our lifecycle process where we can go back and update information at any step (following the CM rules at every step and updating the affected baselines accordingly).

System Requirements Analysis Phase.  Keeping in mind the business requirements, in the System Requirements Analysis phase we detail the system level requirements that are derived from the Project IT Support Definition.  This phase takes the high level requirements from the Project IT Support Definition and refines them to a lower level of detail that more explicitly defines what is required from each system. This information is captured in the System Segment Specification and is reviewed at the System Requirements Review.  Once approved, this becomes the functional baseline and is placed under formal Configuration Management (CM) control.

System Design Phase.  Evolving the System Design, we specify the systems level components that meet the Systems Requirements defined in the previous phase.  This includes existing systems, Commercial Off The Shelf (COTS) components, Government Off The Shelf (GOTS) components, reusable components, and components which must be developed.  Components that must be developed are each assigned a unique Configuration Item (CI) identifier.  The aggregate capability of these components will meet all system level requirements.  This information is captured in the System Design Specification and is reviewed at the System Design Review.

CI Requirements Analysis Phase.  Your next step is to focus on the lower level requirements for the software component.  During the CI Requirements Analysis phase we focus in on a single CI component that is to be developed and fully analyze and document the requirements that the CI must meet.  This information is captured in the Software Requirements Specification and is reviewed at the Software Specification Review.  Once approved, this becomes the allocated baseline and is placed under formal CM control.

CI Preliminary Design Phase.  Supporting the system level design, we focus on the specific software component during CI design. During the CI Preliminary Design phase we design the internal elements of the CI.  The CI can be atomic (a single element), or it can be composite - and we break it down into its component parts - each of which will be assigned a new CI identifier.  Each new CI iterates through the CI Requirements Analysis Phase (focusing on the lower level requirements of the single CI) - which illustrates how our lifecycle process is both iterative as well as recursive (recursing on the new CI).  During the Preliminary Design phase we also fully define the external interface to the CI.  This can be the user interface, or simply the application programmers interface, which defines the exported functions to CI clients that preserve the integrity of the object/class, encapsulating the data type and operations, while abstracting the lower level details from the client interface.  This information is captured in the Software Design Description and is reviewed at the Preliminary Design Review.

CI Detailed Design Phase.  Just as in the Preliminary Design phase, the Detailed Design phase focuses on the internal components of the CI. During the CI Detailed Design phase we design the internal elements of the CI including any data structures and algorithms that must be used during coding.  At the conclusion of this phase each component is fully specified and ready for implementation (coding).  This information is captured in the Software Design Description (refined and more detailed than the preliminary version of the same document) and is reviewed at the Critical Design Review.

CI Code & Unit Testing Phase.  In the CI Code and Unit Testing phase we implement (code) our design and perform unit testing by the programmer.  We create the Software Test Descriptions, which provide step-by-step instructions for conducting the CI test down to the keystroke level, as well as the expected results.  This information is captured in the CI Test Description and is reviewed at the Test Readiness Review.

CI Integration & Testing Phase.  Moving to the Project CI Integration & Testing phase, we integrate multiple CIís and perform integration testing of the combined components.  We create the Software Test Descriptions (for the multi-CI component) that will provide step-by-step instructions for conducting the integration test down to the keystroke level, as well as the expected results.  This information is captured in the Integration Test Description and is reviewed at the Integration Test Readiness Review. Once complete, this becomes the product baseline for that CI, and is placed under formal CM control.

Integration & Testing Phase.  Keeping the symmetry of our lifecycle in tact (decomposing down the left side of the figure, and recomposing up the right side of the figure) we integrate and test. During the Integration and Testing phase we integrate custom developed software components with COTS, GOTS, and reused components.  We create the System Acceptance Test Description that satisfies the system level requirements specified in the System Segment Specification as well as the intent of the system in the Project Plan.  This information is reviewed at the SAT Test Readiness Review to ensure we are ready for systems level testing. Once complete, this becomes the release baseline and is placed under formal CM control.

System Acceptance Testing Phase.  Evaluating the system to ensure the requirements were met as well as the business needs, we perform System Acceptance Test. During the System Acceptance Test phase we perform formal system acceptance testing to ensure all system level requirements are met.  This is sometimes performed by an independent test group within ACE (for internal systems), and other times by the customer (for systems delivered to the government and ACE supports System Acceptance Testing) depending on the nature of the system being developed. Once complete, this becomes the system baseline and is placed under formal CM control.

Initial Deployment.  Your next step before full-scale deployment is usually to deploy to a single installation or site first to ensure the system meets all operational needs in a live environment.  This enables us to make any refinements before full-scale deployment.

Full-Scale Deployment.  Supporting Full-Scale Deployment includes plans for cutover as well as backup plans and contingency operations in the event that problems are encountered. After refinement, we are ready for full-scale deployment to all installations or sites that will be hosting the new capability.  This includes updating the operational baseline to keep all configuration management data accurate and current.