The CAFCR process model is developed and defined in (Muller, G. 2004). The model copes with the complexity of the systems life cycles by defining a set of views and fo- cuses on the relation between the customer world and the product. In total five views are defined: the Customer objective, Application, Functional, Conceptual and Realiza- tion view. In contrast to the waterfall models as described earlier, the views are execut- ed in parallel and must be used concurrently. To use the model, a set of generic or basic methods are defined to aid the systems engineer in his work. These basic methods in- clude viewpoint hopping, decomposition, decision making and modelling. Further- more, for each view a set of sub-methods exist to guide the systems architect through
Figure 7 Spiral model
Production and construction Support and maintenance Phase-out and disposal System analysis Functional analysis Requirement analysis Architecture synthesis Requirements verification Functional verification System
verification Risk analysis anddecision points Conceptual design Preliminary design Detailed design
to each other, a set of qualities is defined. Examples of these qualities are: useability, safety and testability. These qualities are the integrating concepts through the five views. The CAFCR process model is depicted in figure 8. Note that the model does not explicitly map the views on the systems life cycles, however, an implicit mapping can be given as depicted in figure 8.
The CAFCR process model was developed especially for embedded systems architect- ing and focuses on the customer’s requirements. It allows for a high degree of uncer- tainty in the project up to the level where it is still unknown what the system should do. Additionally, the model is used iteratively, meaning that the process can fold back onto itself, to understand the customer’s customer. Furthermore, the process introduces a set of activities that are the same (recursive in CAFCR terms) and concurrent within the subsequent levels of complexity of the system. These activities also provide feedback towards the higher levels of complexity of the system.
Figure 8 CAFCR model
Conceptual
design Preliminarydesign Detaileddesign ConstructionProduction/ Support/ Maintenance Phase-out/ Disposal usability safety testability Customer
objectives Application Functional Conceptual Realization
4
The search for a knowledge exchange model
As can be seen from the discussion of different process models in the previous chapter, a process is not the holy grail for systems engineering. The systems engineer cannot just pick a model and let that define the way of working. Instead, the systems engineer must tailor a systems engineering process to the specific problem that needs to be solved, and choose a development approach that fits the problem. For instance, a com- plex software system could benefit from an iterative development approach, whereas a complex communication system could be developed using an incremental approach. An overview of the process models from chapter 3 and their relation to a development approach is given in table 1.
Although the relations from table 1 can be useful, it should be used with caution; a de- velopment approach in itself does not necessarily imply a systems engineering process model. Additional factors play a role in deciding upon a process model. For example, the complexity of the organization is an important factor. A small company with only a few people would hardly benefit from a complex spiral model or V-model. In fact, it might decide to use the basic waterfall model without any feedback and follow a linear development approach even though the product or system is quite complex. This is es- pecially true if the members of the (small) development team have a very good over- view of the problem at hand and are brilliant designers as well.
If a randomly picked, real life, process is examined, it will contain aspects from differ- ent processes. This implies that the taxonomy from the previous chapter might not be useful for defining a new process that is to be used for the problem at hand. A real-life process is likely to have aspects of all the described models. When trying to describe a real-life process, generalizations must be made and details are bound to disappear. These details often consist of parts of other models that are conveniently overlooked. The descriptions of the process models in chapter 3 are not detailed enough to be used in practice. Even when a process is described in full detail, it is seldom the case that a company selects that process and uses it as is. In practice, a description of the way of working in an organization is made and translated into a process model of some sort to introduce a consistent and reproducible way of working (this process model might not even fall into the given taxonomy). New employees can then get familiar with this way of working by studying the process descriptions.
Process name Process deployment
Waterfall model Discipline driven approach
(Linear development) Waterfall model with limited
feedback
Functional driven approach (Iterative development) Waterfall model with full
feedback
Solution driven approach (Incremental development)
V-model Verification driven approach
Spiral model Risk driven approach
CAFCR User driven approach
4.1
Choosing a systems engineering process model
So, how should the systems engineer (or the organization) decide on a process model? As described earlier, the choice of the model depends on the organization, its environ- ment and the nature and complexity of the product. (Land, F. 1998) showed that it is possible to identify four categories of relationships between (information) systems and their organisational environment. The four categories he identifies are:
• The Unchanging Environment. The requirements are unchanging for the lifetime of
the system (for instance those depending on scientific algorithms or physical laws). Requirements can be stated unambiguously and comprehensively and a high degree of accuracy is essential. In this environment, the waterfall and waterfall with limited feedback process models, could provide the necessary completeness and precision required by the system. Examples of this environment are paper-clip production and house-building;
• The Turbulent Environment. The organization is undergoing constant change and
system requirements are always changing. A system developed on the basis of the conventional Waterfall Model would be already partly obsolete by the time it is implemented. Many business systems fall into this category. In this environment, process models like the waterfall with full feedback, the V-model and the spiral model could prove successful. Examples of this environment are telecommunica- tion systems and consumer electronics;
• The Uncertain Environment. The requirements of the system are unknown or
uncertain. It is not possible to define requirements accurately ahead of time because the situation is new or the system being employed is highly innovative. Here, the development process must emphasize learning. Experimental process models, like the waterfall with limited feedback, the spiral model and the CAFCR model, are most appropriate. Examples of this environment are universities, knowledge institutes, research departments of companies;
• The Adaptive Environment. The environment may change in reaction to the system
being developed, thus initiating a changed set of requirements. Self-learning sys- tems and expert systems fall into this category. For these systems, adaptation is key, and the methodology must allow for a straightforward introduction of new rules. For this environment, the waterfall with full feedback and the V-model proc- esses could provide the required results;
Even with this categorization, it is not clear or straightforward to just pick a process model. A process model must be engineered in order to fit the environment and the sys- tem to be designed. Defining the right process for a project is a systems engineering activity in itself and to execute this activity, the systems engineer can and must take the analysis from this chapter into consideration. When the development approach and the environment of a process to be developed can be determined in advance, an existing process model can be used as a starting point for the development of the new process.