Process Integration

When performing systems engineering activities it is important to consider the mutual relationship between the processes that are to be followed and the product system or service system that is being realized. The type of product or service being produced, as indicated in System Life Cycle Process Drivers and Choices will affect the needed processes. This is important when tailoring defined processes as described in Application of Systems Engineering Standards.

Lawson has developed a set of models in A Journey Through the Systems Landscape that illustrates the process-product relationship (Lawson 2010). Further Boehm has observed several practical aspects of the relationship (Boehm, et al, 2012). This article introduces the models and discusses the practical aspects.

Process and Product Models

In Figure 1 of the introduction article to the topic on Life Cycle Models, the perspective of viewing stage work products provided by process execution as versions of a System of Interest at various life stages was introduced. In making a further model abstraction one can observe that fundamental changes that take place during the life cycle of any type of defined man-made system include Definition, Production and Utilization. Building upon these fundamental life cycle properties, it is useful to consider the structure of a generic process and product life cycle stage model for any type of System of Interest as portrayed in Figure 1.

Figure 1: Generic (T) Stage Structure of System Life Cycle Models (Lawson 2010, Figure 6-2)

The (T) model indicates that one or more Definition stages precede a Production stage(s) where the implementation (acquisition, provisioning or development) of two or more system elements has been accomplished. Also in these stages the system elements are integrated according to defined relationships into the System of Interest. Thus, both the process and product aspects are portrayed. The Implementation and Integration processes are followed in providing the primary stage results; namely an assembled system product or service instances. (However, as noted in Life Cycle Models the Definition of the System of Interest when provided in a Development Stage can also be the result of first versions of the Product or Service; for example a prototype which may be viewed as a form of Production or pre-Production stage.) Following the Production stage a Utilization Stage is entered. Further relevant stages can include Support and Retirement. Note that this model also displays the important distinction between definition versus implementation and integration.

As noted, this structure is generic for any type of man-made System of Interest to be life cycle managed according to ISO/IEC 15288. 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.

Using recursive decomposition the implementation of each system element can involve the invocation of the standard again at the next lowest level thus treating the system element as a System of Interest in its own right. Thus a new life cycle structure is utilized for the lower level System(s) of Interest.

This is illustrated in the dual Vee model (Figure 2). The Dual-Vee is a three-dimensional system development model that integrates product and process in the creation of the system and component architectures. It emphasizes

Concurrent opportunity and risk management,
User in-process validation,
Integration, verification and validation planning,
Verification problem resolution

When decomposition terminates according to the practical need and risk/benefit, system elements are then implemented (acquired, provisioned, or developed) according to the type of element involved.

Figure 2 a and b - The Dual Vee Model (Forsberg, Mooz, Cotterman. 2005, pg 350-351)

A practical aspect, that can very well affect the process and product aspect, is the decision to use off-the-shelf elements in the form of Commercial Off The Shelf (COTS). In this case further decomposition of the element is not necessary. The wide spread use of COTS (and its internally-created neighbor, Non-Development Item or NDI) has proven their value. However the developers must make sure that the COTS product is appropriate for their environment. A known flaw, which occurs infrequently in normal use of the product in its intended environment, may be benign and easily dealt with. In a new situation it could have dramatic adverse consequences, as occurred on the USS Yorktown Cruiser in 1998. The customer mandated that Windows NT be used as the primary operating system for the ship. A “divide by zero” fault caused the operating system to fail, and the ship was dead in the water. It had to be towed back to port on three occasions. (Wired News. 1998.)

Spiral models concurrently engineer not only process and product models, but also property models and success models. Figure 3 shows how these models provide checks and balances among these models, not only at milestone reviews but as individual model choices are made. Methods and tools supporting this concurrent engineering are provided in (Boehm-Port 1999; Boehm-Port-Al-Said 2000; and Al-Said 2003).

Figure 3. Spiral Model support for Process Models, Product Models, Success Models, Property Models. (Boehm and Port. Jan 1999, Fig 1.1.)

Here is some example guidance from these references. The choice of type of process will affect the type of product and vice versa. For example, if you need a rapid development process to meet a competitive market window, you will likely want a COTS- or cloud services-based product to get a critical mass of capability in a short time. If you develop a COTS- or cloud services-based product where the purchased capabilities determine most of the "requirements," you likely won't use a waterfall process model where the requirements determine the capabilities. If many of your desired product capabilities will emerge with use or have a lot of change traffic, you likely will want an evolutionary development process. If your product involves high-risk elements, you'll likely want a process with a good deal of early prototyping. Some of these are covered in Figures 2 and 3 in System Life Cycle Process Drivers and Choices.

For software systems, entry into the Production stages is the point at which “builds” that combine software elements (code modules) into versions, releases, or some other form of managed software product are created. Thus, the major difference between systems in general and software systems is the slight variant of the generic model as presented in Figure 4.

Figure 4: T-Model for Software System (Lawson 2010, Figure 6-3)

Stage Execution Order

The most straightforward execution order for life cycle stages is sequential. That is the stages are simply executed in sequence starting with definition stages includes proceeding to production (implementation) related stages and then to utilization. As presented in System Life Cycle Process Models: Vee and System Life Cycle Process Models: Iterative, variants of the V-Model and the Spiral Model provide highly useful non-sequential models that meet many practical needs of execution order. Building upon these two models it is important to note that various types of complex systems require that the stages of the life cycle model be revisited as insight (knowledge) is gained as well as to handle changing stakeholder requirements. The iterations may involve necessary changes in the processes as well as in the product or service system. Thus, within the context of the (T) stage model, various orderings of stage execution reflecting forms of non-sequential stage ordering can be conveniently described as portrayed in Figure 5.

Figure 5: Iteration through Life Cycle Stages (Lawson 2010, Figure 6-4)

Each of the patterns of stage execution involves iteration where previous stages are revisited perhaps with altered requirements for the processes or the product or service. The heavy lines in the figure denote the demarcation of the iteration end points. Three iterative forms, for which several variants can be extracted, are:

A. 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 a Concept stage and is revisited from a Development stage. For systems where products are based upon physical structures (electronics, mechanics, chemicals, and so on) it is important to get it right before going to production. The need to iterate after production has begun can involve significant costs and schedule delays. Thus, the early stages are 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 defined 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 as noted in B.

B. 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 Concept and/or Development stages. Such iterations resulting in “builds” are typical within software system development where the cost of “production” is not as significant as in the case of defined physical systems. A variant of this approach is the Spiral Model where successive iterations fill in more detail (Boehm 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 as a product and/or service to customers will meet their requirements.

C. Incremental or Progressive Acquisition involves releasing systems in the form of products and/or services to the consumers. This approach is appropriate for systems whose structure and the capabilities (functions) to be provided will change in a controlled manner after deployment. The use of this approach can be due to not knowing all of the requirements at the beginning leading 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 related and Production stages. The utilization of these approaches must be based upon well-defined agreement 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 equally well be used in gaining insight into the potential problems and opportunities associated with the latter stages of utilization and maintenance (for example, in gaining insight into the required logistics and help-desk aspects).

Allocating and Meeting Requirements - Integration of Process and Product Models

Regardless of the form of stage execution model deployed, stakeholder requirements for the system, including changed requirements in each iteration must be allocated into appropriate activities of the processes used in projects for various stages as well as to the properties of the elements of the product system or service system and their defined relationships. This distribution was illustrated in the fourth variant of Lawson’s T-model as presented in Representative System Life Cycle Process Models

The project management team will implement proven project management processes that will integrate the technical process models with the project management product models to manage any of the processes discussed earlier including incremental and evolutionary development. The processes shown are the Project Management flow starting with the beginning of the development phase (Forsberg, Mooz, Cotterman. 2005, page 201).

Figure 6 A – New Product Planning Process – Getting Started (Forsberg, Mooz, Cotterman 2005 pg 201)

Figure 6 B – New Product Planning Process – Solving the Problem (Forsberg, Mooz, Cotterman 2005 pg 201) “If you don’t know where you are going, you’ll probably end up somewhere else.” Yogi Berra

Figure 6C – New Product Planning Process – Getting Commitment (Forsberg, Mooz, Cotterman 2005 pg 201)

References

This article relies heavily on limited sources. Reviewers are requested to identify additional sources.

Citations

Boehm, B., W. May 1988. A Spiral Model of Software Development and Enhancement. IEEE Computer. 21(5) , pp. 61-72.

Boehm, B., D. Port. January 1999. "When Models Collide: Lessons From Software System Analysis," IT Professional. 1,(1), pp. 49-56.

Boehm, B., J. Lane, S. Koolmanojwong, and R, Turner. 2012 (planned publication date). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. New York,NY, USA: Addison Wesley.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management. 3rd Ed. New York, NY, USA: J. Wiley & Sons.

Lawson, Harold. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Wired News. July 24, 1998. "Sunk by Windows NT".

Primary References

Boehm, B., W. May 1988. A Spiral Model of Software Development and Enhancement. IEEE Computer. 21(5) , pp. 61-72.

Boehm, B., J. Lane, S. Koolmanojwong, and R, Turner. 2012 (planned publication date). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Addison Wesley.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management. 3rd Ed. New York, NY, USA: J. Wiley & Sons.

Lawson, Harold. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Additional References

Boehm, B., D. Port. January 1999. "Escaping the Software Tar Pit: Model Clashes and How to Avoid Them," ACM Software Engineering Notes, pp. 36-48.

Boehm, B., D. Port. January 1999. "When Models Collide: Lessons From Software System Analysis," IT Professional. 1,(1), pp. 49-56.

Boehm, Barry, Dan Port, Mohammed Al-Said. November 2000. "Avoiding the Software Model-Clash Spiderweb," Computer, 33,(11), pp. 120-122.

Lawson, H. and M. Persson 2010. Portraying Aspects of System Life Cycle Models, EuSEC Conference, Stockholm.

Mohammed Al-Said. December 2003. "Detecting Model Clashes During Software Systems Development," PhD Dissertation, Department of Computer Science, University of Southern California.