Tailoring the System Life Cycle

Abstract

Every system is unique and requires a tailored life cycle to ensure that its development can be managed efficiently. The process of tailoring the system life cycle is generally not well understood and is often poorly executed, which can result in inefficiencies and elevated risks for the project. This chapter defines a tailoring methodology that can assist Systems Engineers and Project Managers to better understand and apply the tailoring process. The tailoring methodology first considers the customization of a life cycle for individual subsystems, followed by a harmonization through the system life cycle. The technological and organizational factors that impact on the customization are identified and their impact on the life cycle is described. The chapter also defines how the life cycle can be optimized. Throughout the chapter, examples are given to illustrate how the methodology can be applied to complex and multi-disciplinary systems.

1. Introduction

The perception of how much value Systems Engineering (SE) brings to a project versus its cost and its effort varies widely amongst originations and industries [1]. There are many factors that shape these perceptions, some of which are purely subjective, while others highlight real problems with the application of the SE methodology.

The incorrect application of SE can incur a large amount of unnecessary effort on a project, slowing it down and making it heavy, costly and inefficient. On the other hand, a well-applied, minimum effort SE process that enhances the most important aspects of the project can be invigorating and add massive amounts of value. When starting a project, the question then becomes: “What is the ‘minimum effort’ that should be applied to this project and what are the ‘most important aspects’ that the SE process should be focused on?” This is a question about tailoring.

The nature of engineering projects varies widely across industries, organizations, technology domains and application domains. The method of effectively engineering these broad-ranging products varies to such a degree that, on the surface, their similarities are almost unrecognizable. For example, the engineering approach to develop consumer software on a mobile platform seems to be far removed from the engineering approach to building a large new bridge. Yet, these engineering processes all have similar underlying engineering principles and can all benefit from the SE approach, if applied appropriately. Thus, the SE process can look radically different between projects, depending on how it is tailored for the specific project.

A further complication for the application of the SE process is the trend of increasingly multi-disciplinary nature of projects. Many complex systems today involve multiple technology disciplines, such as infrastructure, mechanical, electronics, computing and multiple layers of software. For such systems, the aspect of SE process tailoring is even more important, as it is required that the process is tailored, not only for the system as a whole, but also individually for each subsystem. This is necessary for the SE process to be effective across the different technology domains. At the same time, these subsystem processes need to be harmonized by the overall system process to ensure a coherent approach to the engineering effort.

Although there is some literature describing SE tailoring methodologies [2], the aspect of life cycle tailoring specifically is limited. The growing need for tailoring the system life cycle is not sufficiently supported by publications and training. In general, the SE process and life cycle are documented and taught as a “standard life cycle model”. Different life cycle models are sometimes presented as competing design patterns [3] (e.g. V-model vs. agile development), or in other cases, some life cycle designs are labeled as outdated methodologies (e.g. waterfall model). This can leave inexperienced Systems Engineers confused and unsure which model to adopt, or how to apply the “standard life cycle model”.

The importance of a well-tailored life cycle model is further emphasized by the need for better integration of Program Management and Systems Engineering [4]. The System Life Cycle is one of the important integration mechanisms. A well-tailored life cycle is a valuable tool to structure both the programmatic and technical structures of a project.

The purpose of this chapter is to provide a practical approach to tailoring the “standard” SE life cycle processes. Specifically, the approach should be applicable for a wide range of application domains and for multi-disciplinary engineering problems. The hope is that such an approach can help Systems Engineers and Project Managers to navigate such complex projects more effectively.

The scope is limited to tailoring the system’s technical life cycle. More specifically, the focus is on the development portion of the life cycle from conceptualization until start of operations, which includes the following processes [5]: Stakeholder Requirements Definition; Requirements Analysis; Architectural Design; Implementation; Integration; Verification; Transitioning and Validation.

2. Tailoring methodology’s summary

The tailoring methodology is performed in two steps:

1. Customize the life cycle of individual subsystems: The major subsystems are identified. For each individual subsystem, the technical and organizational factors that impact on the life cycle are identified. With these factors in mind, the life cycle stages and stage gates are identified. Next, the systems engineering processes are mapped onto the life cycle stages. From this, the essential processes and deliverables for each life cycle stage are described. Finally, the life cycle stages are optimized by considering methods of improving their effectiveness and efficiency.

2. Harmonizing subsystem life cycles through the system level life cycle design: After the subsystem life cycles are defined, they are combined using the system life cycle. The various stages of the system life cycle are time-synchronized based on upward and downward dependencies. Additional subsystem stages and milestones are identified, where necessary, to support the system life cycle. Where possible, milestones are combined to reduce the overall workload.

These two steps are described in more detail in Sections 4 and 5, respectively, with examples to illustrate their practical application.

3. Technical and organizational factors that impact the life cycle

3.1 Technical factors

1. Design-build-test cycle cost: The cost of going through one complete cycle of design, implementation (build) and verification is a major factor in determining the system’s development life cycle. In this case, “cost” refers to the complete cost of the project for performing a full cycle, including the schedule delay. On one end of the spectrum: for technologies with a very low cost of implementation (e.g. software), it is efficient to follow an iterative approach of continuously cycling through the development process, thus benefiting from continuous de-risking and the verification of the implementation. This process places a smaller burden on the design phase, as the design and its implementation can easily be adapted. However, one pitfall of this mindset is a neglect of the up-front requirements analysis and well-thought through, stable architecture, which can result in unnecessary re-work. On the other end of the spectrum: for technologies with a very high cost of implementation (e.g. large-scale civil infrastructure), the implementation is performed only once. This places a large burden on verifying the design upstream, before implementation is started. For technologies that lie somewhere on the spectrum in between these two extremes, the cost and schedule impact of each iteration should be weighed off against the benefits of risk reduction per iteration.

2. Technology maturity: Technology maturity has a large impact on the design/development phase of the life cycle [6]. First-of-kind systems that use new technologies often go through one or multiple cycles of the design, prototyping and verification before the concept is sufficiently de-risked to proceed to the final design and implementation phases. On the other hand, mature products with minor changes have a much smaller burden to verify the updated design and go through a much-simplified development cycle, or to design upgrade process before proceeding with full implementation.

3. Production volume: Making even small changes to an item that is in high volume production can be very expensive and time consuming. The impact is even more severe if such items are already in operation. For these reasons, systems that are produced in large quantities require a very stringent verification of the design before it is transferred to the production line. This typically involves a design qualification phase where one or a small volume of units are produced and a thorough set of qualification tests are performed, including environmental and endurance testing. Depending on the production volume, an additional design optimization may be needed as part of the industrialization process, followed by a further production line verification.

4. Rigidity of requirements and boundary conditions: Some systems have evolving stakeholder requirements or requirements that are difficult to define up-front (for example, commercial software products). For such systems, the requirements are allowed to evolve alongside the architectural design, implementation and verification processes in an iterative development. On the other hand, development of systems that have a well-defined and mature set of requirements and boundary conditions can benefit from a rigorous upstream architectural design stage, which provides a firm foundation for the implementation stage. The degree of rigidity of requirements and boundary conditions is often overlooked when designing software systems.

5. Operating life, cost and environment: Systems that have a very long life expectancy, high operating cost or operate in a harsh environment typically require a more rigid design verification phase, including representative prototypes and extensive environmental and durability testing. This requires a well-defined design qualification phase with rigorous verification before proceeding from design to full implementation.

3.2 Organizational factors

1. Procurement strategy: If some stages of a system’s development are outsourced, the procurement strategy for outsourcing such work impacts on the design of the life cycle. The placement of all major contracts needs to be identified as milestones in the life cycle plan, with a baseline preceding the contract placement. The nature of the contract also needs to be considered in the design of the life cycle. For example, if a large, fixed-price contract is placed for the design and implementation of a subsystem, it is critical that the life cycle process is set up to ensure a stable and fully verified requirements baseline for such a contract. This would require that all the upstream work is completed and reviewed, including a full system architecture verification and subsystem requirements allocation. If, on the other hand, the design portion of the work was contracted as a cost-plus (flexible) contract, it would allow some leniency on the up-front work and enable a concurrent system architecture development.

2. Industry norms and standards: Some industries and organizations have well-established, standard life cycle patterns that are followed routinely. This typically occurs where organizations perform repetitive projects that are very similar. This sometimes results in industry-wide standard implementation of life cycle tailoring (e.g. civil engineering). In cases where a subsystem is contracted to an organization that follows such standard life cycle patterns, it is usually efficient to allow such organizations to follow their standard pattern. However, it still requires integration into the system life cycle and the optimization thereof by applying SE processes to complement weaknesses in the standard process.

3. Regulatory environment: Regulatory environment can have a significant impact on the system life cycle. Heavier regulation typically requires a more elaborate life cycle with more and stricter stage gates. Examples of heavily regulated environments are nuclear and aviation.

4. Tailoring the subsystem life cycles

4.1 Methodology

Designing the life cycle for a subsystem involves the following activities, while taking into account the technical and organizational factors that shape the system life cycle as described in Section 3:

1. Define the life cycle stages.

2. Allocate organizations to execute the life cycle stages.

3. Based on the organizational allocation, define procurement milestones.

4. Identify stage gates and the baselines that are needed at each gate. The procurements should be aligned with baselines.

5. Identify the applicable SE technical processes across the life cycle stages.

6. Optimize the life cycle for efficiency and effectiveness.

Optimizing the life cycle for efficiency means to eliminate unnecessary activities, or to minimize the work that has limited value to the end user. This could involve the reduction of effort in some of the SE technical processes or the elimination of entire life cycle stages.

Optimizing the life cycle for effectiveness means to focus the most effort on activities that add the most potential value. It is important to identify the SE activities that have the most potential value and to dedicate a larger fraction of the engineering effort on such activities.

4.2 Example 1: production hardware

The first example considers an array of Radio Frequency (RF) Antennas for application in radio astronomy. These antennas are large structures (~30 m) with complex electromechanical actuators. The structure is moved in three orthogonal axes to point the antenna. It has challenging mechanical specifications for structural tolerance and pointing accuracy across a large range of environmental conditions.

This subsystem has the following technical and organizational features that shape the life cycle design:

1. High design-build-test cycle cost (financial and schedule).

2. Low technology maturity: It is a new design and has characteristics and performance requirements that have not been previously proven (i.e. low technology maturity).

3. Moderate production volume: 50 units (i.e. small production volume).

4. Long operating life expectancy: 50 years for structural parts.

5. Harsh operating environment: It will be operated in a remote desert area and controlled remotely.

6. Procurement strategy: Outsource the design to a specialist, then place a separate open tender contract for the production phase to ensure a competitive production cost.

The features described above influence the tailoring of the life cycle as follows:

• Features (b), (d) and (e) drive the life cycle towards a comprehensive up-front requirements analysis and design life cycle, with an emphasis on fully verifying the design for performance and durability before proceeding with production.

• Feature (a) drives the life cycle towards a single design-build-test (prototyping) iteration because the project will likely not be able to afford multiple iterations.

• Features (c) and (f) require an industrialization stage following the design qualification to ensure that the design transfer between the design contractor and production contractor is successful, before commencing with full production.

The resulting life cycle design is shown below (Figure 1).

Figure 1.

Production hardware example life cycle design.

Because this subsystem is quite a complex system in itself, the tailored life cycle follows a typical “V”-style pattern with top-down design and bottom-up integration and verification [7]. But it is also strongly shaped by the two procurement milestones.

Conceptual design: This is an in-house activity that involves defining the stakeholder requirements, performing requirements analysis of the concept driving requirements, identifying candidate conceptual designs, trading off concepts, designing a preliminary architecture for the chosen concept design, verifying and validating the concept driving requirements and the conceptual design through review processes. The output of this phase is a conceptual design baseline (Baseline 1) that defines the stakeholder requirements, key system requirements and a preliminary design of the chosen design concept. This baseline forms the basis for the procurement of the design contract.

Detailed design: After placement of a design contract, the design contractor performs the identification and analysis of the complete set of requirements and completes a detailed architectural design of the chosen concept, down to leaf component level (i.e. procured component level). Verification and validation of the detailed design is done in the form of a detailed design review, resulting in a detailed design baseline (Baseline 2).

Design qualification: In order to mitigate the significant operational risks of this complex design, the contractor implements a prototype representing the full detailed design. A comprehensive set of qualification testing is performed with the prototype in a representative environment to verify the design. Validation of the prototype is conducted with involvement of the end user. The resulting baseline is a qualified design baseline (Baseline 3) that forms the “blueprint” for the production procurement.

Industrialization: After placement of the production contract, the production contractor sets up the production line for the product, based on the qualified design baseline (blueprint). A small number of units are produced on the production line and installed in the operational environment, followed by a thorough verification of the production process, production documentation and the compliance of the production samples. The resulting production baseline (Baseline 4) consists of the production line, production processes and production documentation.

Production: Following the production baseline gate, the full production process is started. Continuous verification of the produced items is conducted according to the approved production processes. Following the verification of individual production items, they are transitioned into the operational environment, resulting in individual as-built operational baselines for each produced item.

In this example, operational cost optimization is critical. The Radio Frequency (RF) Antennas are expensive and complex systems that operate in a harsh environment over many years. They represent the largest operational cost in the system. There should be an emphasis during the design phase to implement design elements that reduce operational cost (e.g. automatic lubrication systems). There should also be an emphasis during the qualification phase to carefully characterize the reliability of all maintenance significant items, to ensure that the target reliability is achieved before proceeding with production.

4.3 Example 2: software

The second subsystem example considers a software subsystem that is needed to control and monitor a large number of remotely installed Radio Frequency Antennas, in the context of a radio astronomy facility (as defined in Example 1). The software system needs to perform real-time control of all these antennas from a remote location and needs to monitor their health status and performance on a continuous basis, enabling real-time interaction of the array of antennas with end users and with maintainers. This subsystem has the following technical and organizational features that shape the life cycle:

1. Low design-build-test cycle cost. As for most software systems, they can be developed within a virtual test environment and be continuously built and tested.

2. High technology maturity: Well-established control and monitoring protocols are available that can be adapted to this application.

3. High rigidity of requirements and boundary conditions: The external interfaces of the software are well defined. External interfaces are mainly driven by the hardware, which have well-defined interfaces early on in the life cycle. The user interfaces are also fairly easy to determine early in the life cycle.

4. Procurement strategy: Procurement strategy is to develop the software in-house (i.e. no outsourcing).

5. Industry norms and standards: Software development has well-established standards and processes, most often implemented in the form of lean agile development frameworks.

6. Regulatory environment: In this case, there are no strict regulatory requirements. Safety requirements are localized to the antennas, i.e. the control and monitoring software is not safety critical.

The features described above guide the life cycle as follows:

• Features (a), (b), (d), (e) and (f) indicate that a typical iterative software development framework would be an efficient life cycle design.

• Feature (c) indicates that it will be beneficial to perform an up-front requirements definition and architectural design phase, before starting with the iterative implementation.

The resulting life cycle design is shown below (Figure 2):

Figure 2.

Software example life cycle design.

The resulting tailored life cycle follows a typical iterative life cycle pattern, but with a clear up-front requirements and architecture design phase before the iterative implementation commences:

Conceptual design: The conceptual design involves defining the stakeholder requirements, performing requirements analysis of the concept driving requirements, identifying candidate conceptual designs, trading off concepts, designing a preliminary architecture for the chosen concept design, verifying and validating the concept driving requirements and the conceptual design through review processes. The output of this phase is a conceptual design baseline (Baseline 1) that defines the stakeholder requirements, key system requirements and a preliminary architectural design of the chosen design concept.

Architectural design: In this phase, a comprehensive requirements analysis is performed. All external interfaces are defined. A complete software architecture is developed based on the requirements and external interfaces. Verification and validation of the requirements and software architecture is done in the form of a detailed design review, resulting in a detailed design baseline (Baseline 2).

Implementation (virtual environment): Software implementation follows a successful detailed design review and is based on the approved detailed architectural design. The software development follows an iterative development with regular planning/reporting cycles using a standard lean agile management framework. The initial implementation is deployed in a virtual environment which includes an integrated test framework where regular software releases (Baselines 3) are verified against the requirements and design. The first software release is a minimum viable product (MVP) that can be integrated into the system for system verification purposes. Validation is performed through regular testing in the virtual environment by end user representatives.

Implementation (deployed environment): When the software is sufficiently mature, software releases (Baselines 4) are deployed iteratively on the operational system based on the needs of the users and their validation feedback.

In this example, an optimization for efficiency is achieved by focusing the SE effort on the requirements definition and architectural design phases of the life cycle, where the software processes are often weak. For the implementation phase of the life cycle, the process can mostly rely on the well-established software development methodologies. The SE process can also add value in the definition of software releases during the implementation phase by defining clear, requirements-based targets that align with system level deployment goals.

4.4 Example 3: large-scale computing

The third subsystem example considers a large-scale computing subsystem in the context of a radio astronomy facility. In its final implementation, this subsystem performs a combination of real-time and offline data processing on high volume data received from a radio telescope. The high incoming data rates require real-time processing on a highly parallelized processing architecture that is deployed across many processing nodes in a high-performance computing facility. The purpose of the data processing is to extract the information from the antenna data needed by scientists (astronomers) for research purposes. Because the scientific needs evolve over time, the requirements and the architecture of the software may change over time. This subsystem has the following technical and organizational features that shape the life cycle design:

1. Low design-build-test cycle cost. As for most software systems, it can be developed within a scaled down virtual test environment and can be continuously built and tested, until it is mature to deploy on a full-scale system.

2. Technology maturity: Commercial computing platforms are used for the computing nodes. This technology evolves continuously and the price/performance ratio is continuously declining.

3. Low rigidity of requirements and boundary conditions: Although the interfaces for the incoming data are well defined, the end user interface is not well defined and the user requirements evolve over time.

4. Procurement strategy: Procurement strategy is adopted to develop the software in-house (i.e. no outsourcing) and procure commercially off-the-shelf hardware compute nodes.

5. Industry norms and standards: Software development has well-established standards and processes, most often implemented in the form of iterative development.

The features described above drive the life cycle as follows:

• Features (a), (d) and (e) indicate that a typical iterative, lean agile software development framework is applicable.

• Feature (c) indicates that it is not possible to define a complete set of requirements and detailed design up-front, and that these processes will evolve together with the implementation.

• Feature (b) implies that a late-as-possible procurement strategy for the bulk of the hardware platform would be appropriate.

The resulting life cycle design is illustrated below (Figure 3):

Figure 3.

Large-scale computing example life cycle design.

The resulting tailored life cycle follows a typical iterative life cycle pattern, with limited upstream definition. Deployment of the implementation develops from a virtual environment to a small-scale deployed environment before the full-scale procurement, which is done as late as possible.

Preliminary design: An initial phase of stakeholder requirements identification, requirements analysis and architectural design is performed. The purpose is to identify the hard constraints (e.g. incoming data interface and data rates) and the known stakeholder requirements. The emphasis of this initial requirements analysis is placed on the design driving requirements. From these requirements, an initial architecture is designed, taking into consideration the downstream needs for parallelization. The preliminary design is verified and validated through review processes, resulting in a preliminary design baseline (Baseline 1).

Virtual environment implementation: Software implementation proceeds in a virtual environment, based on the preliminary design. The software development follows an iterative development with regular planning/reporting cycles using a standard lean agile management framework. The initial implementation is deployed in a virtual environment which includes an integrated test framework where regular software releases (Baselines 2) are verified against the evolving requirements and design. The first baseline is a Minimum Viable Product (MVP) that can be integrated into the system for system verification. Validation is performed through regular testing in the virtual environment with end user feedback.

Small-scale deployment implementation: Initial transitioning into the deployed environment is done when the software is sufficiently mature, and the deployed environment is ready. The initial deployment is done on a small scale, with regular software releases (Baselines 3) that are verified against the evolving requirements and design. When the implementation is verified on the small scale and demonstrated to be fully scalable, a formal review is conducted to verify the full-scale architecture design, before procuring the full set of computing hardware. This results in a final design baseline (Baseline 4), which is used as a basis for the hardware procurement.

Full-scale deployment implementation: Procurement of the hardware follows a successful final design review. The software is deployed on the full-scale system, while the iterative software development continues, with regular software releases (Baselines 5). Verification is performed, prior to each new release. Validation occurs through end user operations with the full system.

In this example, an optimization for efficiency is achieved by focusing the SE effort on the upstream process of defining the concept driving and design driving requirements and to establish an initial architectural design that satisfies the external hard boundaries. For the implementation phase of the life cycle, the process can mostly rely on well-established software development methodologies. The SE process can also add value in the definition of software releases during the implementation phase by defining clear, requirements-based targets that align with system level deployment goals.

4.5 Example 4: civil infrastructure

The fourth subsystem example considers the building of civil infrastructure required for a typical radio astronomy facility located on a remote green fields site. This includes roads, buildings, electrical reticulation and optical fiber reticulation. This subsystem has the following technical and organizational features that shape the life cycle design:

1. Very high design-build-test cycle cost.

2. High technology maturity.

3. Rigid requirements and boundary conditions.

4. High operating cost and deployment in a remote environment.

5. Procurement strategy: Design and construction supervision to be outsourced to multi-professional engineering consultancy. Construction to be outsourced to one or more construction companies.

6. Industry norms and standards: The civil engineering industry has well-established, standard development and construction processes.

7. Regulatory environment: Significant regulatory constraints (safety, health, environmental, etc.), but well understood by construction contractors.

The features described above drive the life cycle as follows:

• Features (a), (c) and (d) indicate that a thorough requirements definition and detailed design phase are appropriate up-front before proceeding with construction contracting.

• Features (e), (f) and (g) indicate that the design and construction processes will primarily follow the standard civil engineering norms and standards. However, there should be awareness of the weaknesses in these standard processes, and the SE processes should be used to complement such weaknesses.

The resulting tailored life cycle design is illustrated below (Figure 4):

Figure 4.

Civil infrastructure example life cycle design.

The tailored life cycle follows a typical waterfall design pattern, flowing from requirements definition, to design, to implementation and transitioning.

Conceptual design: An in-house conceptual design is done based on the identified stakeholder requirements and the concept driving external interface requirements (i.e. infrastructure needs from other subsystems). Verification and validation of the conceptual design is performed through reviews involving representation from all relevant stakeholders. This results in a conceptual design baseline (Baseline 1), which forms the basis for the procurement of a design contract.

Detailed design: The design contractor performs a complete requirements analysis based on detailed external interface definitions and all relevant regulatory requirements. The design contractor kicks off all the regulatory application processes (which are typically long lead activities). A detailed design is produced based on the requirements analysis. The requirements and design are verified and validated through reviews by representative stakeholders. This results in a detailed design baseline (Baseline 2) that forms the basis for the construction procurement.

Design adoption: The appointed construction contractor performs a design adoption process where the detailed design is transferred from the designers to the construction contractor. Minor adjustments to the design may be needed. The adopted design forms the construction design baseline (Baseline 3).

Construction: During the construction phase, the design contractor performs continuous verification through on-site supervision to ensure that the as-built design complies with the construction design baseline and that as-built documentation is accurate and kept up to date. As the construction work packages are completed, the parts of the system are transitioned to the operational user system and validated by the end users. At the end of the construction phase, a final and comprehensive verification of as-built and operate-to documentation is reviewed, followed by the establishment of the operational and support baseline (Baseline 4).

In this example, efficiency optimization is achieved by focusing the SE effort on the weaknesses of the standard industry civil engineering practices. This includes: (a) the upstream processes in preparation for the placement of the construction contract: requirements definition, requirements analysis, architectural design and verification and validation of the design; (b) the downstream process towards the end of the project: ongoing verification of the construction work and as-built information; transitioning of the system into operations and end user validation.

5. System life cycle

Once all the subsystem life cycles have been tailored, they are combined and harmonized through the system level and stakeholder level life cycle. In this section, we describe the methodology for doing this. We also describe a typical design pattern that is used to combine subsystem, system and stakeholder processes. The chapter concludes with an example by combining the subsystem life cycles that are described in Section 4.

5.1 Methodology

The methodology includes the following activities, which are not necessarily followed in sequence, but typically done concurrently or iteratively:

1. Time-sequence the activities across the life cycles based on dependencies: The Stakeholder, System and Subsystem life cycle stages typically run concurrently, but they are sequenced to ensure that output/input dependencies between activities on the different levels are arranged logically. Typically, the dependencies are top-down (from system to subsystems) during the early stages and bottom-up (subsystems to system) in the later stages. There are sometimes also dependencies between subsystems, as is demonstrated in the example.

2. Identify driving and supporting activities: As the life cycle progresses, some of the activities are driving and some are supporting activities—it is important to distinguish the driving activities clearly, as they will dictate the time sequence of events.

3. Add supporting life cycle stages, if needed: It may be necessary to add life cycle stages to some subsystems to integrate them logically into the system life cycle.

4. Add new milestone gates, if needed: As the interdependencies become clear, it may be necessary to add new milestone gates to subsystem plans to ensure that such dependencies are formalized.

5. Combine milestone gates where possible: There may be opportunities to combine milestones and reviews across the project to reduce the workload on the project team. For example, combining conceptual design reviews of all subsystems with the system level conceptual design review.

5.2 Design pattern

A common design pattern for combining the system and subsystem life cycles is shown below (Figure 5).

Figure 5.

Design pattern for combining system and subsystem life cycles.

This pattern, which is based on the well-known “V-model” [7], shows which activities are typically the project driving and supporting activities. Initially, the stakeholder and system level requirements analysis activities drive the development, until the design driving requirements are mature. Following this, the focus is on establishing a mature system architecture supported by subsystem activities as needed. A baselined system architecture forms the foundation for the subsystem design and implementation. During the subsystem design, implementation and verification activities, the system and stakeholder level activities mostly support subsystem development, while maintaining the system level baseline. When subsystems start to deliver verified products, driving activity moves back to the system level, where system integration and verification typically dictate the activities of the project. Once the system is fully integrated and verified, the focus shifts to transitioning it to the operational environment and final user validation.

5.3 Example application

In this section, the methodology and design pattern described in the previous sections are deployed to define the system life cycle and to combine it with the subsystem life cycles from Section 4.

The combined life cycle is shown below, including the life cycle activities for the system level and all the subsystems. The diagram shows how the life cycle stages and milestones have been arranged temporally to align to critical dependencies between the system level and subsystem level activities (Figure 6).

Figure 6.

Example combined life cycle design.

The main features of the combined life cycle are as follows:

1. System conceptual design: The purpose of this stage is to define the system concept driving requirements and converge on a single, feasible conceptual system design that can meet all the critical stakeholder requirements. The system conceptual design activity is the main driving activity and is supported by subsystem conceptual design development. A number of alternative system design options are generated, which are typically combinations of subsystem concepts. A system level tradeoff study is performed to select the best option. The selection uses a value system that is based on the key stakeholder requirements. This stage is concluded with a conceptual design review, resulting in a conceptual design baseline.

2. System architectural design: A detailed system architecture design is developed, based on the conceptual design baseline. A full set of requirements is derived and baselined early on in this process to ensure a complete and stable baseline for the architecture. The development of the system architecture includes a derivation of subsystem requirements and subsystem interfaces. The architecture is verified and validated through a system architectural design review, followed by the establishment of the system architecture design baseline. This baseline constitutes the first critical downward dependency (system to subsystems) in the life cycle. The verified set of subsystem requirements and interfaces represents a firm foundation for the procurement of the infrastructure and RF Antenna design contracts. They also form the basis for the software and computing subsystem design activities.

3. Detailed design: At this stage, the subsystem detailed design activities become the driving activities in the project. As the details of the design on subsystem level emerge, the system architecture design baseline is updated and fleshed out, resulting in an updated system architecture design baseline after the subsystem detailed designs have been verified and baselined. The detailed design baseline is an important baseline for the construction procurement of the infrastructure.

4. Subsystem design qualification: As explained in Section 4.4.1, the design qualification of the RF Antenna subsystem is an important prototyping activity to verify the as-built design before initiating the production process. For this activity, some subsystem-to-subsystem interdependencies are identified, including the availability of the necessary infrastructure and control software to verify the antenna prototype. During this stage, the system team performs mainly supporting and oversight roles of the subsystem developments.

5. System integration and verification (I&V) - Antenna system: This stage represents the first upward dependency (subsystems to system), where subsystem deliverables are needed to establish a system integration, for the purpose of system verification. In this case, a qualified Antenna system and the necessary control software are needed to perform system level testing.

6. System I&V - Virtual environment: I&V in a virtual environment is a useful early risk mitigation activity. It allows the early integration and testing of multiple software components before hardware becomes available. This requires the regular deployment in a virtual environment of minimum viable products from the different software teams. A synchronized, iterative cycle of deployment, integration and testing needs to be coordinated between the system team and software teams to set clear goals for each increment and feedback test results.

7. System I&V – Small-scale deployed environment: When the hardware is available for a small-scale deployment of the system in the operational environment, and the software development is sufficiently mature, a small-scale deployment of the system may be integrated for deployed system verification. This integration and verification are also performed in a synchronized, iterative cycle. The scale of deployment may also be increased incrementally, depending on the availability of hardware. An early transfer into the user domain may also be done at this stage to de-risk the transfer process. When the small-scale deployment is mature and verified, it provides the confidence to proceed with the procurement for the full-scale computing hardware.

8. System I&V – Full-scale deployed environment: Once the full-scale hardware is procured and the production of antennas is completed, the focus shifts to establish a full-scale system for final system verification. This continues in a synchronized, iterative cycle of integration and testing until the functionality is complete and mature. The final successful verification results in a system product baseline, with the final transition to the user domain resulting in an operational readiness baseline.

6. Conclusion

Each project is unique and it is important to tailor the system life cycle to fit the unique characteristics of the system being developed. A well-tailored life cycle can significantly improve the programmatic and technical effectiveness of a project. The system and project characteristics that impact on the design of the life cycle are identified and the impact of the characteristics on the life cycle design is described. A structured method to tailor the system life cycle is presented, which involves first the customization and optimization of individual subsystem life cycles, followed by the synthesis thereof into the system life cycle. The application of the tailoring methodology is demonstrated through the use of various examples, showing how this process can be applied to complex and multi-disciplinary projects.

Acknowledgments

The author acknowledges the South African Radio Astronomy Observatory (SARAO) for their support in producing this publication.