17 April 2015

Integration of Process and Product Models – SEBOK (28)

When performing systems engineering activities, it is important to consider the mutual relationship between processes and the desired system. The type of system (see Types of Systems) being produced will affect the needed processes, as indicated in system life cycle process drivers and choices. This may cause the tailoring (glossary) of defined processes as described in application of systems engineering standards.

Process and Product Models

The life cycle models introduced the perspective of viewing stage work products provided by process execution as versions of a system-of-interest (SoI) at various life stages. The fundamental changes that take place during the life cycle of any man-made system include definition, production, and utilization. Building upon these, it is useful to consider the structure of a generic process and product life cycle stage model.

The (T) model indicates a definition stage precedes a production stage where the implementation (acquisition, provisioning, or development) of two or more system elements has been accomplished. The system elements are integrated according to defined relationships into the SoI. Thus, both the process and product aspects are portrayed.

The implementation and integration processes are followed in providing the primary stage results—namely, in assembled system product or service instances. However, as noted in life cycle models, the definition of the SoI when provided in a development stage can also be the result of first versions of the system. For example, a prototype (glossary), which may be viewed as a form of production or pre-production stage. Following the production stage is a utilization stage. Further relevant stages can include support and retirement. Note that this model also displays the important distinction between definition versus implementation and integration.

According to ISO/IEC/IEEE 15288 (2008), this structure is generic for any type of man-made SoI to undergo life cycle management. The production stage thus becomes the focal point (T) at which system elements are implemented and integrated into system product or service instances based upon the definitions. For defined physical systems, this is the point at which product instances are manufactured and assembled (singularly or mass-produced). For non-physical systems, the implementation and integration processes are used in service preparation (establishment) prior to being instantiated to provide a service. For software systems, this is the point at which builds that combine software elements into versions, releases, or some other form of managed software product are produced.

Stage Execution Order

A sequential execution of life cycle stages is the most straightforward. Three are iterative forms, for which several variants can be extracted:

1. Iterative development is quite frequently deployed in order to assess stakeholder requirements, analyze the requirements, and develop a viable architectural design. Thus, it is typical that the concept stage may be revisited during the development stage. For systems where products are based upon physical structures (electronics, mechanics, chemicals, and so on), iteration after production has begun can involve significant costs and schedule delays. It is, therefore, important to get it "right" before going to production. The early stages are thus used to build confidence (verify and validate) that the solution works properly and will meet the needs of the stakeholders. Naturally, such an approach could be used for software and human activity systems as well; however, due to their soft nature, it can be useful to go further by experimenting and evaluating various configurations of the system.

2. Iterative development and implementation involves producing (defining, implementing, and integrating) various versions of the system, evaluating how well they meet stakeholder requirements, perhaps in the context of changing requirements, and then revisiting the concept and/or development stages. Such iterations are typical within software system development, where the cost of production is not as significant as for defined physical systems. A variant of this approach is the spiral model, where successive iterations fill in more detail (Boehm and May 1998). The use of this approach requires careful attention to issues related to baseline and configuration management. In this approach, significant verification (testing) should be performed on software systems in order to build confidence that the system delivered will meet stakeholder requirements.

3. Incremental or progressive acquisition involves releasing systems in the form of products and/or services to the consumers. This approach is appropriate when structural and capability (functions) changes are anticipated in a controlled manner after deployment. The use of this approach can be due to not knowing all of the requirements at the beginning, which leads to progressive acquisition/ deployment, or due to a decision to handle the complexity of the system and its utilization in increments—namely, incremental acquisition. These approaches are vital for complex systems in which software is a significant system element. Each increment involves revisiting the definition and production stages. The utilization of these approaches must be based upon well-defined, agreed relationships between the supplying and acquiring enterprises. In fact, the iteration associated with each resulting product and/or service instance may well be viewed as a joint project, with actor roles being provided by both enterprises.

In all of the approaches it is wise to use modeling and simulation techniques and related tools to assist in understanding the effect of changes made in the complex systems being life cycle managed. These techniques are typically deployed in the earlier stages; however, they can be used in gaining insight into the potential problems and opportunities associated with the latter stages of utilization and maintenance (for example, in understanding the required logistics and help-desk aspects).