Concept: Systems Engineering - Lifecycle Architecture Milestone
This guideline discusses the evaluation criteria for the Lifecycle Architecture Milestone at the end of the elaboration phase. The state of the essential artifacts is also described for a Systems Engineering project.
Main Description

At the end of the Elaboration Phase is the second important project milestone, the Lifecycle Architecture Milestone. At this point, you examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks.

Evaluation criteria

  • The product Vision and requirements are stable.
  • The architecture is stable.
  • The key approaches to be used in test and evaluation are proven.
  • Test and evaluation of executable prototypes have demonstrated that the major risk elements have been addressed and have been credibly resolved.
  • The iteration plans for the Construction Phase are of sufficient detail and fidelity to allow the work to proceed.
  • The iteration plans for the Construction Phase are supported by credible estimates.
  • All stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture.
  • Actual resource expenditure versus planned expenditure are acceptable.

The project might be aborted or considerably re-thought if it fails to reach this milestone.

Artifacts

Essential Artifacts State at Milestone
Prototypes One or more executable architectural prototypes have been created to explore critical functionality and architecturally significant scenarios. See the note below on the role of prototyping.
Risk List Updated and reviewed. New risks are likely to be architectural in nature, primarily relating to the handling of nonfunctional requirements.
 Development Case Refined based on early project experience. The development environment, including the process, tools, and automation support required to support the construction team will have been put in place.
 Tools The tools used to support the work in Construction are installed.
Software Architecture Document / System Architecture Document For software development, the Software Architecture Document is created and baselined, including detailed descriptions for the architecturally significant use cases (use-case view), identification of key mechanisms and design elements (logical view), plus definition of the process view and the deployment view (of the System Deployment Model) if the system is distributed or must deal with concurrency issues.

For systems engineering, at the end of elaboration, the System Architecture Document is similarly complete in terms of its description of  behavioral, structural, physical, and other quality characteristics, as they appear in the important (architecturally significant) aspects of the system.

System Deployment Model

The System Deployment Model has been refined to descriptor level as the system architecture stabilizes, then to implementation level as actual hardware acquisitions begin, as executable system architectures are produced.

Design Model (and all constituent artifacts) / System Design Model For software development, the Design Model has been defined and baselined. Use-case realizations for architecturally significant scenarios have been defined, and required behavior has been allocated to appropriate design elements. Components have been identified and the make/buy/reuse decisions sufficiently understood to determine the Construction Phase cost and schedule with confidence. The selected architectural components are integrated and assessed against the primary scenarios. Lessons learned from these activities might well result in a redesign of the architecture, taking into consideration alternative designs or reconsideration of the requirements.

For systems engineering, the System Design Model is stable by the end of Elaboration, and most, if not all system use-case realizations are complete. The structure of the system in terms of subsystems is stable and the Construction Phase (or acquisition) of at least some of the subsystem developments has already begun. 

Data Model
[software development]
Defined and baselined. Major data model elements (for example, important entities, relationships, tables) defined and reviewed.
Implementation Model (and all constituent artifacts, including Implementation Element)
[software development]
Initial structure created and major components identified and prototyped.
Vision Refined, based on new information obtained during the phase, establishing a solid understanding of the most critical use cases that drive the architectural and planning decisions.

Software Development Plan System Development Plan

Updated and expanded to cover the Construction and Transition phases.
Guidelines. The guidelines used to support the work.
Iteration Plan Iteration plan for the initial Construction Phase iteration completed and reviewed.
Use-Case Model A Use-Case Model (approximately 80% complete)-all use cases having been identified in the Use-Case Model survey, all actors having been identified, and most use-case descriptions (requirements capture) have been developed-certainly all the important ones that have a significant impact on architecture.
Supplementary Specifications Supplementary requirements capturing the nonfunctional requirements are documented and reviewed.
Test Suite ("smoke test")
[software development]
Tests implemented and executed to validate the stability of the build for each executable release created during the elaboration phase.
 Test Automation Architecture
[software development]
A baselined composition of the various mechanisms and key software elements that embody the fundamental characteristics of the test automation software system.

Subsystem Supplementary Requirements

This is a subsystem-level artifact as viewed from the system level-it is stable by the end of the Elaboration Phase for the subsystem, which might already have occurred.

Subsystem Use-Case Model

This is a subsystem-level artifact as viewed from the system level-it is stable by the end of the Elaboration Phase for the subsystem, which might already have occurred.

Optional Artifacts State at Milestone
Business Case Updated if architectural investigations uncover issues that change fundamental project assumptions.
Analysis Model / System Analysis Model Might be developed as a formal artifact; frequently not formally maintained, evolving into an early version of the Design Model/System Design Model instead.
 User Support Material User Manuals and other training materials. Preliminary draft, based on use cases. Might be needed if the system has a strong user interface aspect.

The role of prototyping

The Rational Unified Process gives the Software Architect, System Architect, and Project Manager the freedom to construct prototypes of several types (see Prototypes) as a risk reduction strategy. Some of these prototypes might be purely exploratory, and are subsequently discarded. However, it is likely (certainly for larger or unprecedented systems) that the architecture will have been constructed as a series of evolutionary prototypes-covering different issues as elaboration proceeds-and by the end of elaboration, will have culminated in an integrated, stable architectural base. This is not to suggest here that the prototyping effort during Elaboration need result in a set of architectural fragments, which need not be integrated.