The systems engineering process model within the framework of the systems engineering concept
Other process models – such as the Waterfall Model, the Vee Model, INCOSE methodology, simultaneous (concurrent) engineering and agile models – are described and discussed comparatively following a description of the systems engineering process models.
2.1 Components of the Systems Engineering Process Model
To proceed from the general to the detailed, and not vice versa
To follow the principle of thinking in variants, i.e., essentially not being content with a single variant (generally the first available one), but rather consistently looking for alternatives
To structure the process of systems development and implementation according to temporal perspectives (phased approach)
To apply a kind of work logic as a formal procedural guideline in solving problems, regardless of their type and of the phase in which they occur (problem-solving cycle, PSC)
These four components form a meaningful whole, for they can be linked together. We first describe them individually and independently of one another to make their basic idea easier to understand. Then, for didactic reasons, we later address divergent ideas, modifications, extensions, and restrictions. The observations in Parts II through V of this book contain more concrete statements and recommendations for action, along with explanations and examples from case studies.
2.1.1 The Principle “From the General to the Detail” (Top–Down)
2.1.1.1 Basic Idea
Frequently, planners who spend little time discussing questions of a basic nature, and instead quickly propose concrete solutions, are considered to be especially competent. They thereby create the specific conditions for addressing the universally beloved detailed questions in which, as we well know, the devil resides. Here, no case should be made for any major discussion on a general, less concrete level. But we do not think there is much sense in trying to deal with the devil in the detail right away – and ignoring his grandparents, who may be hidden in an inappropriate, mistaken, or non-existent overall concept.
Dealing immediately with detailed matters may be appropriate and allowable in cases of small problems or detailed improvements of a functioning solution or with routine problem-solving that came up earlier in a similar form and was already dealt with. For this, the methodology of systems engineering is not absolutely essential. The methodology of systems engineering should be used for solving problems that are difficult to comprehend, complex in nature, and/or substantially intertwined with the environment, and not for solving problems in which the mutual impact is evident and thus requires no closer scrutiny or deliberation.
Principle “from the general to the detail” (top–down)
2.1.1.2 Application to the Structuring of the Initial Situation (Problem-Structuring) and to the Draft Solutions
At the start of a project, areas that are to be developed and delineated may need closer investigation or changes should or may be made. Important components or areas of the problem field and the factors that influence them should be identified and presented in their dependencies. In terms of systems thinking (see Part I, Chap. 1) these are the elements of a system and their relations, in addition to important environmental elements and their relationships. Only when the problem is structured and defined clearly enough for the planners and their customers does it make sense to address the qualitative and quantitative investigation of the details to define the design area and to systematically develop draft solutions for them.
Narrowing the field of observation
The areas of analysis (situation) and design areas (solutions) do not need to be identical. The outer circle on Level A marks the borders of the analysis area; the inner dotted one, the design area, in other words, the area within which changes can and should be made. The process of increasing concretization and detailing is indicated on Level B.
With this consideration, the underestimated risk involved in the application of systems thinking should be faced: the definitely desirable and recommended thinking in effect relationships should not mislead anyone into needlessly turning small problems into large problems. The recommendation to expand the observation horizon, especially at the beginning of a project, is thus consistently connected to the demand for narrowing, that is, a skillful and conscious delimitation.
2.1.1.3 Alternatives to the “From the General to the Detail” Approach
One fundamental alternative to the top–down approach would be the reverse, the bottom–up approach, which would mean that we begin with the detail and that the whole is a product of the sum of the individual steps. This approach may be appropriate under special conditions, for example, when dealing with improvements to an existing and functioning solution (see Sect. 6.3.3.2 or Improvement (Melioration) Projects, Sect. 6.5.2). In this case, timely knowledge of the details is important, for rapid measures with deliberately limited effectiveness are usually the main goal. But with new constructions and reconfigurations on a larger scale, we consider it essential to develop a general concept that can represent the indispensable orientation frames for the planning and execution of partial steps.
The so-called agile process models occupy a special position and offer advantages in very dynamic, continually changing situations. The logic tends to be bottom–up, with relatively small increments of development, which, considering their priorities, can continually be reconsidered, along with rather frequent iteration steps (Stelzmann 2011).
2.1.1.4 Summary
The field of view is first to be grasped broadly and subsequently to be narrowed down gradually. This applies to the analysis of the problem field, the starting situation, and the drafting of solutions.
The analysis of the starting situation (of the problem field) should not begin with detailed inquiries before the problem field is structured roughly, is embedded in its environment or isolated from it, and the interfaces are defined (often only in the sense of a working hypothesis).
In structuring the solution, the first general objectives and a general solution framework should be established, whose degree of detailing and concretization is gradually increased as the rest of the work on the project advances (this does not exclude later modification, correction, and perhaps even discarding of a selected framework). To some extent, concepts on higher levels serve as guidance for the detailed design of the solution.
Supplementary considerations, modifications of the top–down principle, and application instructions can be found in Parts II and III.
2.1.2 The Principle of Variant Creation
2.1.2.1 Basic Idea
For practically every task or every problem, there are several possible solutions. One important principle of systems engineering is thus not to be satisfied with the very first solution idea, but rather taking as broad an overview as possible of the solution variants that are conceivable at a specific level of consideration. These solution principles can also be understood to be different variants of a systems architecture that always have very distinctive characteristics. One should therefore consistently attempt to be aware of the basic idea on which a solution is based, and seek alternatives before beginning to develop it in greater detail. This helps us to remember the correlation with the starting situation and to direct attention to other conceivable solution principles.
Of course, the principle of variant creation also applies to the next lower system levels. As a rule, different variants of a basic structure or even architecture are also conceivable at a subsystem level. But the multiplicity of variants would grow so quickly, with consistent variant creation at all levels, that it could scarcely be managed if the variant creation did not involve a simultaneous, stepwise reduction in the resulting multiplicity of variants.
Staged variant creation and elimination, connected to the “from the general to the particular” action principle
The following would be a generally valid approach. Starting with a specific task, one should formulate several basically conceivable solution principles in terms of systems architecting, structure them to the point where it is possible to form a picture of their effects, requirements, and consequences, and then choose the variant that offers the greatest promise of success. For a specific solution principle, various configuration variants are possible at the next lower concretization level (variants of overall concepts), among which a choice must again be made.
In this stepwise top–down approach, the effect-oriented view and the structure-oriented view come into play alternately: at one specific level, there is above all the question of what effect the system or the various elements of the system should produce (= effect-oriented view or black box principle). At the next lower level, this view must be abandoned and one must consider how elements are to be structured, in other words, how the solution is to be configured so that the desired effect is produced (structure-oriented view).
However, the necessity of this stepwise setting of the course entails the fact that decisions have to be made based on an incomplete insight into detailed problems and on insufficient information. It may thus be that the right way is not immediately found, or even that a point is reached when the selected way proves to be impracticable. Then, the only recourse is to return in the planning process to a higher step and search for the solution in another direction –the excellent qualifications of the people involved in the planning notwithstanding.
This risk could be circumvented by basically deferring the choice and deciding only when all the possible solutions at all concretization levels have been worked out in all variants. However, because of the workload and time required, this method has no practical meaning. Commissioning parties and planners should keep this in mind whenever a selected solution subsequently proves to be impracticable.
However, under special conditions, within a restricted time frame, it may indeed be appropriate, or even necessary, to pursue several solution principles simultaneously. This is especially true when the risk associated with the commitment to a specific solution principle is relatively high and the additional effort for the simultaneous pursuit of multiple variants appears in relation justifiable.
It is particularly important for the commissioning party to realize the significance of the above-mentioned interim decisions to avoid surrendering the illusion that he or she could intervene in the decision to go ahead with implementation without consequences and influence the solution with his or her ideas, as the multiplicity of variants would already have been so restricted at the transitions between the individual hierarchical steps that the solution could scarcely be influenced any longer at this time, but rather only accepted or rejected.
2.1.2.2 Principle Variants Versus Detail Variants
Principle variants are those clearly differentiated from others by their basic idea, and to which – consciously or unconsciously – a particular architecture has been given that can be distinguished from other possibilities. Detail variants, on the other hand, are those that are based on the same fundamental idea, but shape it differently in detail.
In practice, planning and decision situations are sometimes characterized in that variants that are not different in principle, but only in the details, are submitted for a decision. This indicates that the course has either already been set consciously, or that soon it will have to be set unconsciously. The former obviously occurs when the previously explained approach principles are followed consistently, and is quite harmless. However, the latter case should give rise to the following cautions: careful, we are about to put time and money into the selection of variants that essentially differ very little from each other! Are there really no fundamentally different alternatives? Have we done our homework on variant creation?
The so-called improvement plans (in the sense of improvements to existing solutions) constitute a special case. These often have no clearly distinguishable alternatives, as the improvements may result from a number of individual measures that can be combined in many ways or broken down into individual steps. There may be a whole series of improvement measures for every variant, and they may have little in common with one another and may even be contained in different variants, e.g., in the sense that a greater melioration may include all the medium-sized measures, and that these include all the small measures. For example, consider the renovation or the remodeling of a building, the variants for improving the logistics of an enterprise, the reworking of a product concept, the improvement of a legislative text, etc.
2.1.2.3 Alternatives to the Principle of Variant Creation
With respect to methodology, we see no alternative to the principle of variant creation. Even though this is frequently violated in practice – often due to a lack of time – we consider this principle to be a special feature of good planning. As far as a lack of time is concerned, lots of energy is often invested – also under time pressure – in the variation of details, whereas it could be invested more effectively in developing or considering a variety of basic variants. This is not only a question of methodology, but also one of mindset and mental agility. If, despite all efforts, an alternative to a specific solution is not even conceivable, which is rarely the case in practice, the futile search for alternatives had entailed not only disadvantages, but also one advantage: greater certainty concerning the truth of the selected way.
One phenomenon observed in practice also involves the fact that sometimes basically different variants crop up at a point in time when, because of the work already done, it would be time for realization: This may be a sign of changed value judgment that later gives rise to possible solution ideas that were not conceivable earlier, e.g., planning in the public sector under strong political pressure. But it can be a sign of methodological weakness if, for reasons of convenience, lack of inspiration, or for other reasons, a particular solution direction is settled prematurely and unnecessarily.
2.1.2.4 Summary
We consider the principle of variant creation, of thinking in alternatives, to be an indispensable component of good planning. This is a methodically basic attitude, and – when the principle of from the general to the detail is followed – it should not lead to any significant increase in planning effort.
If this principle is not followed, there is a higher risk that fundamentally different solution approaches are introduced into the discussion in the late phases of development. Possible consequences include the discussion stalling or the planning stopping and the return to a higher level. Both results are unsatisfactory: the waiver to a better solution, due to the advanced development phase, which usually is connected to time pressure, in addition to the waiving of some detailed planning done needlessly.
2.1.3 The Principle of Structuring into Project Phases as a Macro-logic
2.1.3.1 Basic Idea
Phase concept – basic version
The number of project phases, and even the formalism with which they are processed, are surely dependent on the type, scope, and significance of a project. Smaller projects can generally be developed satisfactorily by using a smaller number of phases and less formalism. The designation of the individual phases is also of secondary importance, as it is influenced by the business sector, the task, the terms used in the company, and many other factors. What is important is that the complexity of a problem statement and the risk of a wrong decision can be reduced through purposeful structuring into individual steps of planning, decision-making, and implementation.
The phase model is first described in its simplest form. The purpose and the contents of the individual phases are explained. Subsequently, we move into other process models (Sect. 2.2) and into supplements (Sect. 3.2.3).
2.1.3.2 The Individual Project Phases
In the following, the early phases (the preliminary and main studies) are treated more thoroughly than the later phases. This is mainly because the methodical aspects are of particular importance in the early phases, whereas special expertise and methods dominate in the phases approaching implementation, which are not universally valid and thus cannot be described in general terms. On the other hand, as the project progresses, the effort of the practical execution increases noticeably; the early phases generally require less effort in this regard.
Impulse
This rather unstructured phase encompasses the time between the perception of a problem, the unease with the current situation, the detection of an opportunity, the emergence of more or less vague solution ideas, etc., and the resolve to undertake something concrete, e.g., to start an organized investigation in the form of a preliminary study. The problem statement can then either be formulated relatively clearly already, or it may consist merely of vague suspicions concerning problems and their causes. It does not matter where the impulse comes from. It is far more decisive that it be accepted by a person or an entity with the competence to initiate concrete actions, issue a project mandate – initially for a preliminary study only – and of course to grant the necessary personnel, finances, informatics, infrastructure, and other resources.
The impulse phase is short if adequate awareness of the problem (psychological stress), awareness of the opportunity, readiness to act, appropriate personnel, and the means for execution at least are available in a preliminary study. It takes a long time if these factors are not very clearly defined, especially on the side of the commissioning party or the entity authorized to issue the mandate. Unfavorable prerequisites for the execution of a project exist in particular if, just to get started, major promises must be made to put into use a possible solution that of course at this early stage cannot be particularly legitimate. Promises of this type reduce the intentionally delayed planned possibilities for correction, modification, or even termination of an unnecessary or an unjustified development on the basis of emotional or prestige barriers.
It is also important that in the impulse phase, no decision should be made concerning the realization of a solution, but only concerning whether or not a preliminary study should be initiated. With respect to the preliminary work required, e.g., agreeing on a project mandate, building up a project group, etc., we refer the reader to Part II, Sect. 4.2.1, “Start-Up Work.”
The Preliminary Study
How broad the scope of analysis contest of the study shall be (the boundaries of the problem field)
Which mechanisms have an effect in the problem field
What the problem or the opportunity consists of
Whether the right problem/ right opportunity is being addressed
In what way and to what extent is there a need for a new or modified solution
What area a new or modified solution should encompass (i.e., where the boundaries of the design area should lie)
What requirements the solution should satisfy (system or design goals)
Whether the solution principles are basically conceivable (variants) and whether they appear to be feasible for technical, economic, political, social, psychological, temporal, ecological, and other reasons
Which solution principle offers the greatest promise of success, for which the relevant evaluation criteria are to be worked out
Whether by replacing an existing solution it is possible/desirable to reconstruct on an existing system architecture or whether a new architecture is required.
If we establish a relationship between the project phases and the principle of a staged variant creation (Fig. 2.4), the preliminary study encompasses the uppermost level, that is, the working out of the problem and the variants of solution principles that come into question, including the decision basis for choosing the variants that promise the greatest success. In our view, the preliminary study is explicitly not limited to picturing the actual state (although at least a general knowledge of it is obviously a component of a preliminary study), but rather it clearly goes beyond that, because it must also offer possible solutions.
In the preliminary study, one should first deliberately take into consideration the investigation area (see Level A in Fig. 2.3) and also adequately consider the environment in which the solution is to function subsequently, and with which it is interrelated.
As the nature and extent of the needs are not always clear at the beginning of a project, preliminary study is of particular importance. Often at the start, there are only a few known symptoms of an unsatisfactory situation, a possible danger, or clues for an opportunity, and there exist only vague objectives. These symptoms must be investigated to determine their causes and possible ways of eliminating them; the opportunities and risks must be worked out clearly before it is possible to set the course for developing solutions.
Closely connected to the question of needs is the question of delimiting the analysis area and the subsequent design area. In the systems approach, which can be very helpful with this delimitation, there is a certain inherent tendency – because of the challenge of considering external factors and their influences – to expand the original task. However, it is by no means stated that this is always appropriate. Although in most cases a better mutual balance of the various subsystems or system aspects can be reached through a more comprehensive systems concept, the fact remains that the necessary expenditure of time and money can increase considerably, and yet the available resources and the available time are generally limited.
Thus, preliminary study can be understood as a clarification process that should be followed by a fundamental decision by some decision-making body. The systems designer should work out the possible problem solutions, the consequences that arise from them, and the requisite preconditions; generally, he or she has no authority to decide on the way forward for a project.
The termination of a project at the end of a preliminary study should thus not be scored as a stigma or an admission of incorrect deliberation. This is far more likely an intentional course setting, which can also lead to termination for sure. Thus, the effort of a preliminary study can be compared to an insurance premium that is intended to reduce the risk of an undesirable outcome. Heeding this reflection increases the probability of terminating in a timely and orderly fashion less promising projects, before great expense has been incurred in the planning (Fig. 2.5).
If it is decided to proceed with the project – possibly with modified objectives – the probability of a later termination is thus reduced, even if not to zero. Also, during the main study, and even after completion of various detailed studies, it may prove necessary to terminate the development and renounce the implementation because of better insights into the relationships among the problems and the possible solutions (Fig. 2.5). But with further progress, the likelihood of this should decrease.
- Is the task or the problem defined clearly enough?
Do we know which problem or which task we want to solve and why?
Is it adequately defined?
Is its connection to the environment clear?
Is there clarity on this within the project team and with the commissioning party?
Is the design area adequately defined, known, and delimited sensibly as the area in which changes should or may be made?
Are the objectives in terms of the demands on the solution clear (which functions should be implemented, economic objectives, human resources/social objectives, temporal, ecological objectives, etc.)?
Is there an adequate comprehensive view over basically conceivable variants (solution principles)?
Can these variants be evaluated with respect to their suitability (including requirements and consequences)?
Is it possible to make a decision on a specific solution principle? Can this be justified logically and comprehensibly?
Are the critical assumptions or components known?
Note: This check list should not be used to deliberately lengthen preliminary studies. It involves basic and not detailed evaluations.
The Main Study
The purpose of the main study is to concretize and refine the structure of the overall system based on the solution principles (architecture, framework) selected in the preliminary study. This results in overall concepts (variants) that should facilitate a valid assessment of the functionality, usefulness, and profitability, plus any negative consequence of the possible solutions. Now, the focus is on the specific creation of the solution itself. The environment is important, especially to the extent that it affects the further elaboration of the concept designs or is influenced by them positively or negatively. Particular attention must be paid to interfaces.
Critical system components, in other words, those that are particularly important and for which there is reason to suspect that later on they could pose problems when worked out in detail, should be brought to the fore. Detailed investigations and concepts can thus be worked out in the form of well-defined detailed studies within the framework of the main study (or, in extreme cases, as early as the preliminary study). We address this later in greater detail when we treat the case study applications (Part II, Sect. 3.2.3). In extreme cases they can lead to a termination of the development, and this offers the advantage that little or no unnecessary planning is done.
The degree of detailing and the basic observation levels (overall system versus sub- or aspect systems) are thus sometimes difficult to distinguish from one another. We return to this in greater detail later on, in the treatment of the application aspects (Part II, Sect. 3.2).
The result of the main study is the decision on an overall concept (framework, master plan) that should make it possible to organize further development and realization within an orderly framework (Note: the term concept is to be understood broadly here. Depending on the state of the development phase, it can involve a graphic plan, a design drawing, supported by a verbal description, tables, etc., plus combinations of these types of presentations.).
Present a master plan for the next phases
Make investment decisions
Facilitate the definition of partial projects
Set the priorities for carrying out detailed studies and system building
Is the suggested overall concept convincing and feasible (functionally, economically, with regard to personnel, organizationally)?
Is there a comprehensive view of conceivable alternatives?
Are the critical components known?
Is the situation ready for the decision? Is the decision generally considered worth supporting? Is it inwardly and outwardly reasonable or manageable?
Especially on the side of the project team, are there clear ideas about how one should move forward?
Are any necessary or foreseen priorities for further detailing or realization clear? For example, has it been determined in what logical and/or temporal sequence the detailing or realization should take place?
The Detailed Studies
In this phase, the objects treated are individual subsystems or system aspects that are picked out from the system concept for temporary, segregated treatment. The demarcation of the problem fields or design areas becomes increasingly easier, as the requirements for the partial solutions are generally deducible from the overall concept. The observation field is now narrowed down drastically.
To work out detailed solution concepts and make decisions on appropriate design variants
To concretize the individual partial solutions to the point that they can subsequently be built and introduced as smoothly as possible. Thus, the clarification of important partial problems, which, because of a particular detail concept, are to be expected in the following realization phases, belongs in the task area of the corresponding detailed study.
With respect to the interaction and the integration of partial solutions, see Part II, Sect. 3.2.3.3.
Are the requirements derived from the overall concept met by the detailed concepts? Do the detailed concepts meet the goals?
Can the detailed concept be embedded in the framework of the overall concept; can it be integrated? Does it perform its intended functions? Does it exhibit characteristics that are undesirable from the viewpoint of the overall concept?
Is it concretized in such a way that it can be subsequently built?
Note: here, the analysis criteria explained in Part III, Sect. 6.3.4 can be used.
Systems Building and Tests
The purpose of systems building is the building of solutions in the broadest sense, e.g., the construction of buildings and facilities, the making of products (machines, devices, perhaps prototypes, pilot runs), the creation of IT software including documentation, connected with the detailed preparation of organizational measures and the creation of user-oriented documentation or operating instructions, the organization of lines of communication, the defining of organizational regulations that should apply in cases of a malfunction or breakdown, the appropriate training of users, service personnel, and others (perhaps overlapping with the next phase), the determination of maintenance or service procedures and intervals, etc.
The objects treated here are partial or overall solutions that should be prepared for introduction. Tests or trials before introduction can be particularly significant. It is necessary to distinguish between individual tests that deal with trials for individual components, and system tests (integration tests), in which the proper functioning of the overall system is tested. Sometimes, it is even usual to provide specific project phases for performing systems tests, because defining the acceptance and testing procedure can be of particular significance.
System Implementation
Only relatively small, simple solutions, after appropriate preparation, can be implemented in their entirety without great risk. By and large, with complex systems, an abrupt implementation can be very risky because of the variety of unforeseeable side effects; thus, this should be realized gradually. In such cases, one begin with an overall concept, but make the detailed implementation of further steps dependent on the initial implementation results. This is possible in particular with organization projects, and is naturally more difficult with construction, machine, and installation projects.
For the purposes of know-how transfer, adequate training of the handler, operator, and end user is especially important. Before acceptance of the system, the goals, specifications, or guarantees should be reviewed by the commissioning party, customer, developer, operator, and others. This phase ends with formal delivery by the producer, possibly in conjunction with a closing ceremony.
Project Conclusion
The project also concludes with the proper acceptance of a solution by the commissioning party. Now, there are a number of final tasks that must be carried out, such as billing, debriefing (lessons learned as a learning opportunity for carrying out similar projects in the future), dismissing the project group, etc.
Usage and Maintenance
Now that the project is over, the utilization lifecycle begins. Operation experiences should be collected to improve the existing solution or to design similar systems. The solution is to be consolidated, maintained, and perhaps improved.
Reconfiguration, Redesign, Decommissioning
If, during the use of the system, it becomes apparent that a reconfiguration of fairly significant magnitude, or even a redesign of the solution, is necessary, there will be an impulse for a new preliminary study, and the entire procedure begins anew at this point (Fig. 2.5). This may be the case when further use is no longer allowed, justified, or (economically) sensible.
Changes of smaller magnitude normally require no formal development procedure. They are made during the usage phase, likewise without distinguishing among the various project phases. A formal treatment of requests for changes may help in the organized collection of change requests and thus facilitate an orderly, coordinated reconfiguration.
The redesign of a system commonly involves the decommissioning of an existing system. To complete removal smoothly, the decommissioning must also be the subject of thoughtful planning. With systems whose decommissioning may be difficult, this issue (removal) must be given greater consideration as early as possible in the design process. The removal may even turn into a separate project.
2.1.3.3 Other Phase Models
- 1.Of course, depending on the scope and the complexity of a project, the planner is free to include more or fewer phases:
A combination (merging) of the preliminary, main, and perhaps even detailed study phases into a single development phase in small and manageable projects is just as conceivable as
An expansion, e.g., by introducing a pre-feasibility study (before a preliminary study) or a separate testing and acceptance phase
- 2.
Later on, we address the possibilities of (partially) doing without a clear temporal border between phases, in terms of an overlapping approach – see Part II, Sects. 3.2.3.5 (Dynamics of the Overall Conception) and 3.2.3.6 (Temporal Overlapping Process).
2.1.3.4 Alternatives to the Principle of Dividing Into Sequential Phases
One alternative would be to set aside the phased approach. This may make sense with small projects, or with complex projects, where requirements are developed and understood in parallel to developing concepts. We address approaches that are critical with respect to the phase concept in Sects. 2.2.1.6, 2.2.1.7 and 2.2.1.8, for example, prototyping, versions concept, and simultaneous engineering, because we view them as alternatives or complements to the entire systems engineering process model and not just to the phase model.
Alternatives that should be taken seriously are agile methods such as Scrum, originating in software development, and spreading visibly to hardware projects. Causes are the cumbersome nature of the phase model – see Sects. 2.2.2, 2.3, and 4.7. If one analyzes carefully, following the Scrum approach, there are phases of a kind, but with a different logic and no pre-defined manner.
2.1.3.5 Summary
It offers a time-structured pattern that helps in dividing the development of a solution into manageable partial stages.
A stepwise planning, decision-making, and realization process, with predefined stops or adjustment points, reduces the complexity of project handling, and provides mutual learning opportunities for the planners, the implementers, and the commissioning party.
In the sense of a macro-logic, the concept of the project phases can be seen as a management-oriented module of the process model. It demands contact between designers and commissioning party/management at previously defined points, a common decision-making process, and a decision.
Further instructions for application are in Part II, Sect. 3.2.3.
2.1.4 The Problem-Solving Cycle as a Micro-logic
2.1.4.1 Basic Idea
Search for objectives or goal-setting: where are we? What do we want/need? Why?
Search for a solution: what are the possibilities, what are the ways of getting there?
Selection: which one is the best/most appropriate?
Problem-solving cycle (PSC) – basic version
The status of the development or implementation work (project phase) has a crucial impact on the content and the degree of detailing for these steps. The PSC can also be applied in agile approaches, namely in each “sprint.”
The PSC is of initial interest from the viewpoint of the logic of the development. Figure 2.6 presents mainly the content, the “what,” of the individual procedural steps and their logical consequences. In Part II, Sect. 3.3.2, these guidelines, the “how,” is emphasized further; there are also reference points that deal with the concrete procedure and application-related expansion or narrowing.
2.1.4.2 The Individual Steps in the Problem-Solving Cycle
Impulse
The impulse is to a certain extent to be understood as a trigger that sets the work logic in motion. At the beginning of a preliminary study, the impulse is to be understood as the initial spark and is identical to the impulse that also sets the preliminary study in motion (Fig. 2.5).
However, the impulse can also have the character of a concrete task: if a result has already been reached in earlier planning steps (e.g., a decision on a particular solution principle), it is then a question of concretizing this result in the next-lowest planning step. Generally, this means that the parts of a concept are singled out and detailed.
The logic of the PSC would be in both cases an appropriate guideline for going forward.
Situation Analysis
The purpose of the situation analysis (assessment of the situation) consists in familiarization with the initial situation and the task, or generally clarifying it, understanding it, and creating a basis for the setting of concrete goals.
At an early stage (e.g., the preliminary study), this may involve taking a closer look at the symptoms of an unsatisfactory situation, for the purpose of achieving a better understanding of the problem, at possible opportunities, and dangers or their causes.
At a later stage in the project (e.g., detailed studies) the emphasis is on dealing with the concrete initial situation at that time. The following are relevant questions: which overall concept was agreed upon? Which special conditions or restrictions must be considered for further design, including among others the interfaces of adjacent elements?
- 1.The system-oriented view originates from systems thinking and should help in structuring the starting situation, especially with respect to functionality.
The problem field can be made transparent, that is, processed and delimited, with the help of the terms element, relation, black box, suprasystem, subsystem, environment, system boundaries, etc.
Various observation aspects of the same situation can be both highlighted and distinguished from one another with the help of the term system aspect (filter or glasses).
An analysis of the influencing variables makes it possible, for example, to work out the source, type, and extent of a possible influence on a particular project.
Dynamic, process-oriented views allow process operations and behavioral characteristics in the problem field to come to the fore.
The system-oriented view provides deeper insights into the situation and gives rise to the following observations:
- 2.
The cause-oriented (diagnostic) view is aimed at describing the symptoms as concrete manifestations of an unsatisfactory situation or a possible opportunity or danger, at ascribing them to the appropriate elements of a situation description, and ultimately work out possible causes.
- 3.
The solution-oriented (therapeutic) view directs attention at solution ideas and possible interventions (catalog of resources, state of the art, models, etc.) and is very helpful in understanding the problem more effectively, defining the intervention area, and working up realistic goals. With an idea of what a better target condition could look like, it naturally becomes easier to scrutinize the actual state. Solution-oriented concepts should, however, not get out of hand in the situation analysis, as the real solution development comes later (synthesis/analysis).
- 4.The future- or time-oriented view approach is overlaid on these three perspectives, which can consist, for example, of the following questions:
How will the situation develop in the future (short-, medium-, and long-term) if no action is taken today (development of the problem field)?
Which important developments must be identified in the solution field?
Which effects can possible interventions produce; in what direction can or will the changes lead?
In addition, boundary conditions for the solution search are worked out and secured in the situation analysis; they should be understood as determinants from:The system environment (natural, economic, technical, human resources, social, legal, and perhaps even emotional and other types)
Earlier decisions that for the moment cannot or should not be influenced
The commissioning party’s ideas, such as cost limits, deadlines, etc., or
The actual state in which constituent elements are seen as (perhaps only temporarily) unchangeable.
The result of the situation analysis should produce both qualitative and quantitative information that provides a better view of the problem. All the considerations used in this context contain not only objective facts, but single out the facts, connect them with opinions, mindsets, and individual evaluations. One characteristic of a good situation analysis is that the compilers take pains to distinguish between facts and their interpretation.
Based on the situation analysis it may become necessary to revise some objectives expressed in the problem statement. This applies especially at the early stages of a system development (preliminary study). In the advanced phases (development of detailed concepts), the impulse rather takes the character of a concrete task and the situation analysis may become correspondingly shorter, for the content and the framework of the further activities have already been narrowed down greatly through earlier decisions. For more on situation analysis, see Part III, Sect. 6.1.
Formulation of Objectives
Generally ideas and expectations are expressed as early as the impulse or the project mandate: what is to be accomplished or avoided through the redesign or the re-structuring of a system, e.g., requirements with respect to performance and scope of services, costs, and availability. However, especially during the early stages of a project, there is the difficulty that these ideas or expectations are built on a relatively insecure information basis. Frequently, neither the problem nor the solution field (e.g., the state of the art) is particularly well-known. Thus, a concrete and realistic formulation of objectives in the very early stages is of course difficult. Such goals should rather be taken as preliminary working hypotheses.
In accordance with the problem solution cycle presented here, the formulation of objectives is placed at the end of the search for objectives, and not at the beginning. The results of the situation analysis should be used as a source of information for the setting or adjusting the specific goals.
These goals, as oriented to a particular project, should be adequately tuned to higher-level goals, e.g., the objectives of the company, and they should support them as far as possible.
Solution-neutral, in other words, the functions or effects (the “what”) of solutions should be described, and not the solutions themselves (also the “how”)
Complete and thus should contain all the important requirements for the desired solution
As operational as possible in the sense of precise and understandable
Realistic, i.e., it should consider the objective circumstances of the situation, plus the social circumstances and the subjective values, especially of the decision-makers, the opinion=makers, and the affected parties
Mandatory, Desired, and Recommended Objectives
The diverse demands on a formulation of objectives often cannot be met completely, and of course there may also be contradictions and inconsistencies among conflicting demands.
To establish priorities concerning the importance of goals, the distinction between mandatory and desired objectives has proven useful. Mandatory objectives are those that must be met; desired objectives are those that should be achieved as thoroughly as possible, but not imperatively (nice to have). Some authors also recommend an additional category of recommended objectives whose importance falls between the mandatory and desired objectives. We agree with this recommendation and adopt the term.
The recommended or desired objectives form the starting point for a set of criteria for subsequent evaluation. Included hereinafter is a list of operational subgoals used to measure the quality of the solution concepts as developed later on. This list can and will be expanded during the search for a solution, when the specific requirements for particular solutions and their alleged consequences are known.
The decision (or approval) for objectives is the conclusion of the step of formulating objectives; at this point, the goals agreed upon by the commissioning party and the project group should be set down. The goals worked up should also be stated as the binding basis for further planning work. However, it has to be taken into consideration that legitimate change requests may possibly occur later on, which may lead to subsequent adjustments. These should be made as clear and transparent as possible.
The degree of concretization and detailing of objectives is of course dependent on the current project phase. During the early stages, the goals are more global and only partially qualitative and oriented toward the overall solution; in later phases they are more detailed, primarily quantitatively substantiated, and concentrated on the partial solution.
For the process of formulating objectives see Part III, Sect. 6.2.5. Regarding cooperation between the commissioning party and the project group in formulating objectives, we refer the reader to Part II, Sect. 3.4, Expanded Problem-solving Cycle. Concerning the increasing concretization of objectives in the phase process we refer the reader to Part III, Sect. 6.2.3.5, Thinking in Terms of Objectives and Means, and Part IV, Chap. 8, Case Study 1: Private House Building: Additional Domicile.
Synthesis of Solutions
The synthesis of solutions is the constructive, creative step in the PSC. The purpose of the synthesis is to develop solution variants appropriate to the level of concretization of each phase, from the results of the situational analysis, based particularly on knowledge of the situation, on understanding of the problem, the formulation of objectives, and related challenges. This may involve drafts, concepts, constructions, detailed guidelines for implementation, etc. The level of concretization of the variants should be adequate to allow comparison of the individual variants and choice of the most appropriate one.
In this step, creativity techniques are of particular importance. For further information on synthesis, see Part III, Sect. 6.3.
Analysis of Solutions
Although the synthesis can be designated as a synthesizing–constructive step in the PSC, the solution analysis is the critical, analytical–destructive step. The purpose of the analysis is to assess (validate) whether a solution, a concept corresponds to the stated requirements, or whether it exhibits fundamental flaws, which of course are easier to repair as long as the solution exists only on paper. With increasing concretization of a solution, the analysis becomes more elaborate, more solid, and more detailed.
Formal aspects, such as the agreed-upon mandatory objectives, can be achieved
The individual draft solutions are at the proper concretization level for the corresponding phase, or whether unimportant parts are too detailed and essential parts have not yet been addressed
A solution is capable of integration, “outward looking”
The functionality of a solution is discernable and it can be evaluated with it (“inward look”)
Questions concerning the operational efficiency (e.g., safety, reliability, operability, maintainability, etc.) can be answered
The requirements and consequences of selecting the solution just analyzed can be evaluated in economic, technical, personnel, social, emotional, ecological, and other terms
With the increasing concretization of a solution in the phase process, this analysis step becomes more elaborate, more concrete, and more detailed. Thus, the analysis creates the basis for the subsequent evaluation, from which it must, however, be separated conceptually.
In the analysis, it is a question of assessing every individual solution for its usefulness and suitability. On the one hand, this serves as pre-selection, in which unsuitable or clearly less desirable solutions can be discarded early, and on the other hand, as an impulse for a targeted improvement of solution drafts by subjecting them to revision and synthesis.
The evaluation involves systematically comparing the remaining variants considered to be basically suitable.
In the course of the analysis, it is entirely possible to encounter essential features of a solution that previously were neither sought nor expected, but which nonetheless come up and may be either desirable or undesirable. These should be used as an opportunity to augment the criteria plan already begun in the step formulation of objectives.
Often, it is not possible to neatly separate synthesis and analysis from one another temporally, because at the moment when a solution idea comes up, the critical controversy also immediately begins. This gives expression to a rather intuitive analysis that has little predictability and that should be avoided by most → creativity techniques (“the principle of deferred judgment,” not prematurely criticizing ideas). On the contrary, in the problem-solving process, a systematic analysis in particular is called for, which should be used formally and consciously when there are essential planning results, and perhaps should even be implemented by other persons or with their support.
With reference to the hierarchical presentation of the procedural principle from the general to the particular (Fig. 2.2), a particular sequence of synthesis–analysis can also contain several detailing and concretization steps, whereby the number of variants with increasing detailing is expanded and reduced several times. One proceeds to the next step and conducts a formal evaluation and selection only after achieving concrete results. This reduction in variants in the analysis framework can be considered an intermediate decision that, once the situation is clear, can also be made with reduced formal effort. For more information on synthesis/analysis, see Part III, Sect. 6.3.
Evaluation of Solutions
The purpose of the evaluation consists of systematically comparing suitable variants with one another to determine which is the most appropriate. The criteria for the evaluation are, of course, the objectives that have steered the development and the pre-selection. Thus, only variants that meet all mandatory objectives are accepted for evaluation. The relevant elimination is made in the solution analysis.
A formal evaluation of variants thus makes sense if the presumed best variant is not immediately apparent. The difficulty lies in the fact that sometimes solutions with very different characteristics and manifestations must be compared.
The required criteria for evaluation are ultimately determined from the mandatory or desired objectives as developed in the framework of the formulation of objectives, and from any additional characteristics, conditions, and consequences of the individual solutions. This consists of a list of partial aspects that are considered essential for evaluating the quality of the individual draft solutions.
There are many methods and techniques that can be used in the evaluation phase, e.g., → plus-and-minus balance sheet, → value-benefit analysis, → cost-benefit calculation,→ cost-effectiveness analysis, → economic feasibility calculation, and → real options. Such methods should not be regarded as instruments that take the place of decision-making, however. They merely make the decision-making situation transparent, for on the one hand, they force the decision-maker to think about his/her criteria and structure them. On the other hand, a clear view is required of the extent to which the individual criteria are considered to have been met.
By reducing irrationality and arbitrariness or intuition as the only criteria, evaluation methods can help to improve the quality of decisions. For further information on evaluation see Part III, Sect. 6.4.
Decision/Selection
The purpose of this step is to appoint the solution variant for further processing, based on the evaluation results. With respect to the “how” of conducting the evaluation and decision, refer to Part III, Sect. 6.4. For the division of duties between commissioning party and project team, see Part II, Sect. 3.2.3.1.
Result
The result of the planning activities may consist of finding a satisfactory solution that either can serve as an impulse for the next project phase (e.g., main study or detailed studies) or can now be realized, built, and implemented.
However, it may also be that no satisfactory solution is found, or the problem cannot be solved with the currently available personnel, financial, or material resources.
The project is terminated; the existing status is not changed, or is changed only insignificantly.
The cooperation with the systems developers up to this point is ended (revocation of trust).
The demands on the solution are trimmed back (goal reduction).
One returns to a higher system level, perhaps to deal with the existing problem based on a different concept.
The problem is rewritten or defined in a totally different way.
Information Procurement
Information is needed during all steps of the PSC: in the search for objectives, for solutions, and in the selection. The type and extent of the information procurement should take into account, the varying requirements of the individual steps (Fig. 2.6).
In the search for objectives information procurement should be mainly problem-oriented; in other words, it should serve the identification and delimitation of the problem, the development of realistic objectives so that the solution can be worked out, in addition to the basic clarification of possibilities for intervention and solution.
In the search for a solution and the selection, information gathering must become increasingly solution-oriented, that is, oriented toward the development and evaluation of particularly functional and instrumental solution concepts.
An overview of the various procedures of information procurement or processing is given in Part VI.
Documentation
The results and interim results of the individual steps should be documented in a comprehensible manner. This increases credibility and makes subsequent detailing and modifications easier or possible.
2.1.4.3 Alternatives to the Problem-Solving Cycle
Many of the process models, just like the systems engineering PSC, are based on the Dewey problem-solving model; thus, there are some unmistakable similarities. This especially includes models that describe management decisions and that are promoted by various consulting firms.
In addition, there are also process models that place clear emphasis on the sequence of actions – especially involving the sequence of steps in the PSC. We want to divide them into actual-state-oriented and desired-state-oriented models and subsequently analyze them briefly.
Actual-State-Oriented Process Models
Assessment of the current condition
Critical review of the current condition
Development of a solution for the desired state
- 1.
The term assessment of the current condition almost imperatively directs the gaze to the present or the past; the methodology makes no statement concerning the assessment of development trends in the problem and solution areas.
- 2.
For an inexperienced planner, an actual assessment can turn into occupational therapy in a state of perplexity. For example, extensive surveys are conducted and information is gathered, about which nobody really knows whether it is needed at all, or for what, and whether the degree of detail in the inquiry and the evaluation of the questioning are even appropriate. The more time these surveys require, the greater the probability that the area of investigation will change or be modified by measures introduced in the meantime, and that the results obtained so far will be largely invalidated.
- 3.
In addition, an excessively detailed work with the current circumstances, especially at the beginning, can significantly blur the view toward the future or, for that matter, the concept of a fundamental improvement.
- 4.
Moreover, the fundamental question arises whether the logic of this procedure is even correct: is it meaningful to criticize an actual state at all, without having defined a reference basis for this criticism? Or stated differently: what is the actual state compared to in this criticism? It is not and cannot be the desired state, for that is not developed until the next step. But at least the requirements of the desired state should be defined in conjunction with this criticism, or should be worked out simultaneously. If this does not happen, an evaluation of the current condition is possible only on the basis of preconceptions. This is not fundamentally negative; we all work with preconceptions, and without them we are incapable of making judgments or acting. The only negative aspect is that the methodology recommends no structuring of the preconceptions and thus of the collective mindset (e.g., analogous to the “formulating objectives” step in the PSC).
On the basis of these considerations, we deem this methodology to be a usable general outline for writing a report. A developed solution can certainly be argued effectively on the basis of this outline with the actual state: what is it like today? What is unsatisfactory? (= critique). Desired state: what should it be like in the future?
However, in our opinion, it is too sketchy and imprecise for a process recommendation.
Desired-State-Oriented Process Models
These methodologies2 present one radical deviation from the procedural method described above: the actual state for developing a solution is initially of secondary importance. An ideal concept is conceived on the basis of a short functional allocation, and only afterward are the specific conditions , the so-called actual state, worked out. Then trade-offs on the ideal concept or alternatives to it are elaborated until a useful compromise between the requirements of the as-is state and the possibilities for implementing the ideal solution is found.
The ideal solution thus provides the structure for the investigation of the actual state. This is an advantage, because then there exists a reference basis for the actual assessment. One know which questions must be followed up in the as-is assessment: those that help in evaluating the usefulness, suitability, or practicality of the ideal concept. As a result, the actual state assessment necessarily turns out to be structured and target-oriented.
However, it can be a disadvantage to probe the needs and problems of the actual state and its causes primarily from the viewpoint of a rashly selected solution. In that case, fundamental problems may remain undiscovered.
In addition, thinking in terms of ideal concepts and the subsequent discovery of those factors that hinder or preclude their implementation can involve a significant potential for frustration.
Position of Our Concept
In routine situations that are adequately structured because of the experience of the developer/designer/project engineer and that have a predetermined development process, the classical process methodology may be adequate.
In situations where actual or presumed difficulties and limitations to the actual state predominate so that there is a tendency to eventually accept the latter as the best compromise, a radical avoidance of the actual state in the sense of the “IDEAL concept” may be appropriate.
- For most cases, though, the logic of the PSC is suitable, which, with respect to information search, can be characterized as follows:
The definition of the requirements of a solution is necessary and not possible without knowledge of the existing unsatisfactory situation and its environment.
The familiarity with possible solutions – in terms of the “state of the art” – supports the formulation of the requirements. But these do not have the character of IDEAL concepts, but are at first still neutral.
A situation analysis is necessary, even with new developments, to clarify the needs or the opportunities that led to its impulse.
The information search should correspond to the respective detailing phase and proceed in measured steps (from the general to the particular).
At first, it should be problem-oriented; in other words, it should serve the structuring and the delimiting of the problem, the definition of the requirements, and the assessment of possible developments and interventions.
The targeted investigation of quantitative information should be carried out only after qualitative problem structuring.
The information gathering is increasingly solution-oriented as the process goes on, that is, it is oriented toward the development and evaluation of concrete draft solutions.
2.1.4.4 Summary
- 1.Searching for objectives or concretizing objectives, consisting of the steps situation analysis and formulation of objectives, which should direct attention to the following questions:
Where are we?
What do we want/where do we want to go?
Why?
- 2.Searching for a solution, consisting of solution synthesis and analysis:
What possibilities exist for getting there?
- 3.Selection, consisting of evaluation and decision:
Which possibility is the best or the most appropriate?
With an absolutely acceptable reduction to these basic steps, we believe that the PSC is applicable as a universal thought pattern to simple and highly complex problems.
2.1.5 Relations Between the Individual Components of the Process Model
Relations between the various modules of the systems engineering process model (arrangement by tendency)
Interaction of the components of the process model:
- 1.
The principle from the general to the detail (top–down) and the principle of variant creation are presented in the left part of Fig. 2.7.
- 2.The project phases module concretizes these principles in terms of management orientation where the phases are presented with a temporal pattern on which the various levels of the top–down procedure can be arranged:
The preliminary study involves working out the problem and developing various solution principles.
The main study, developing various variants of overall concepts.
The detailed studies, developing detailed concepts.
- 3.
The principle of variant creation is also represented in the graphic representation of the principle from the general to the detail, and of course it is also an essential component of the search for a solution (synthesis/analysis) in the PSC.
- 4.
The PSC is the micro-logic that makes it possible to attack any problem.
The Significance of the Process Steps in the Problem-Solving Cycle
The PSC as a whole undoubtedly takes on the greatest significance in the development phases (the preliminary, main, and detailed studies) because most of the problems that occur here should be solved methodically and appropriately. In the realization phases (systems building and systems introduction), routine processes and a situation-oriented improvisation tend to take on additional significance. But in principle the PSC can be used by any problem occurring during implementation.
In the PSC of the preliminary study, because of the fundamental soft settings, the search for objectives (situation analysis and formulation of objectives) should be given particular attention; then, it may diminish in the main study and the detailed study.
The search for a solution (synthesis and analysis) is important in the preliminary study, the main study, and the detailed study. The preliminary study deals with basic approaches (architecture decisions); the others deal with their design.
The same applies to the selection (evaluation and decision).
It should be further noted that the focus of the individual steps changes successively throughout the development: as solutions are developed it becomes increasingly narrower, but in steps that integrate the developed parts into superordinate concepts, the focus should become increasingly broad.
2.2 Other Process Models
Other process models are described below. They can be regarded as alternatives to the systems engineering process model (Hall/BWI) explained above. In this context it is helpful, inspired by B. Boehm, to distinguish between “plan-driven” methods and “agile methods”.3
Plan-driven methods specify a high degree of structure – in the sense of a clear sequence of steps – and combine this with the expectation that qualitatively highly advanced solutions can be worked out in an efficient manner. The systems engineering process model described predominantly belongs in this category.4 Other representatives of this group include the waterfall model, the Vee model, the International Council on Systems Engineering (INCOSE) methodology, IEEE-15288, and simultaneous (concurrent) engineering.
Despite the undisputed advantage of being able to contribute a logical procedural structure to projects, the plan-driven methods are sometimes vehemently criticized, especially in combination with software projects. In particular, they are accused of making the (software) development process unnecessarily cumbersome and requiring long development times, but without producing satisfactory results, because they impose very restrictive behavior regarding subsequent, valid specification changes. From this need – beginning in software development – the so-called agile methods have developed.
Agile methods are procedures that are differently structured, with a view to reacting flexibly and adaptively to new results, insights, needs, and desires.
2.2.1 Plan-Driven Models
The systems engineering process model with its four components, as mentioned, predominantly belongs to the plan-driven models category – even though it certainly has agile characteristics (see Sect. 2.2.3.2).
In the following, we present nine more plan-drive models. We think we can show that the systems engineering process model is a more comprehensive approach that helps in interpreting its alternatives in addition to also being open to the situation-dependent adoption of good ideas. In addition, the confrontation with other approaches also helps to clarify one’s own viewpoint, emphasize it, or put it into perspective.
2.2.1.1 Waterfall Model
The waterfall model is the oldest and best-known process model for systems development, and it is a traditional top–down development approach. In its original version, it was a linear (non-iterative) process model in software development.5
A project is subdivided into individual phases in which the results (outputs) of one phase constitute the input for the following one – thus the term waterfall. This is a result- or milestone-oriented model, and it therefore corresponds in its basic idea to the phases module in the systems engineering process model. However, because the latter entails four modules in total, the two concepts are not directly comparable with one another.
Waterfall model with iterations
The waterfall model is generally used to advantage where requirements, achievements, and procedures can be described relatively precisely in the planning phase and seem to stay stable.
A clear delimitation of the phases is at least theoretically possible: activities are to be carried out completely in a given sequence. Each activity must be concluded before the next one begins.
Simple possibilities for planning and control: at the end of every activity there is a completed result in the form of documents, models, or software/hardware, i.e., the waterfall model is a results-driven model.
The process is top–down.
It is a simple, comprehensible model that is easy to manage in the linear form presented. With stable requirements and a clear assessment of costs and scope, this can be an effective model.
Phases clearly delineated from one another are often unrealistic – in reality the transition between them is fluid: parts of one system can still be in the planning stage, whereas others are already in implementation or in use.
In practice it is often unavoidable to return to previous phases.
As user participation is provided only in the startup phase and subsequently the design and the implementation are done without stipulating any participation by the user or the commissioning party, the model is rather inflexible with respect to new knowledge, insights, and needs for change.
To avoid subsequent changes to the requirements, an early commitment is pursued (this continues until the “signing” of the lists of requirements). The consequences of this kind of bureaucratic behavior can be the commissioning party’s dissatisfaction with the system delivered when subsequent changes are refused, or expensive changes result from the multiple iterations of the process.
2.2.1.2 Vee Model
Vee model. Dependencies between requirements, verification, and validation. (Authorized source: 3DSE Management Consultants GmbH, Munich)
The descending left side of the V represents the breakdown of the customer goals into technical specifications, initially for the overall system, and then for the subsystems. The downward iterations encompass all steps for understanding user requirements, and the demonstrations of feasibility, all the way down to the level of the smallest system elements.
The right side represents the integration of the components into subsystems and of the latter into the overall system, along with the simultaneous verification in terms of a comparison with the requirements defined on the other side of the V. The upward iterations support the technical basis, making especially certain that the solution is also capable of ensuring the user’s requirements in reality. Finally, the system is validated to be sure that it satisfies the client’s needs. The result of the integration on the right side of the V is thus always verified against the requirements on the left side and then validated. As shown in Fig. 2.9, in some Vee model representations, any iterations are possible in all directions.
The first ideas involving the Vee model as a process approach appeared at the end of the 1970s.6 Today, there are multiple interpretations of this model, both in software development and in overall systems development.7 The model was expanded in succession into the Vee Model 97 and later into the V Model XT (XT = extreme tailoring). This makes the system adaptable to particular needs (tailoring), and it facilitates a stronger orientation toward agile and incremental approaches.
Use of the Vee model in the development of automobile power train systems. (Authorized source: AVL List GmbH, Graz)
2.2.1.3 The SIMILAR Process
The SIMILAR process. (Authorized copy: Bahill and Madni 2017. Springer Nature)
State the problem, including formulation of the requirements of the solution
Investigate alternatives, but only once (not several concretization steps)
Then, follow the steps that we would assign to the project phases: model the system, integrate (modules), launch the system, and assess performance
Bahill and Gissing describe the individual steps in the following.9
State the Problem
The problem statement starts with a description of the top-level functions that the system must perform: this might be in the form of a mission statement, a concept of operations or a description of the deficiency that must be ameliorated. Most mandatory and preference requirements should be traceable to this problem statement. Acceptable systems must satisfy all the mandatory requirements. The preference requirements are traded off to find the preferred alternatives. The problem statement should be in terms of what must be done, not how to do it. The problem statement should express the customer requirements in functional or behavioral terms. It may be composed of words or as a model. Inputs come from end users, operators, maintainers, suppliers, acquirers, owners, regulatory agencies, victims, sponsors, manufacturers, and other stakeholders.
Investigate Alternatives
Alternative designs are created and are evaluated based on performance, schedule, cost, and risk figures of merit. No design is likely to be best on all figures of merit; thus, multicriteria decision-aiding techniques should be used to reveal the preferred alternatives. This analysis should be redone whenever more data are available. For example, figures of merit should be computed, initially based on estimates by the design engineers. Then, concurrently, models should be constructed and evaluated; simulation data should be derived; and prototypes should be built and measured. Finally, tests should be run on the real system. Alternatives should be judged for compliance of capability against requirements. For the design of complex systems, alternative designs reduce project risk. Investigating innovative alternatives helps to clarify the problem statement.
(Note: this step would correspond to the principles “from the general to the particular” and “variant creation.”)
Model the System
Models are developed for most alternative designs. The model for the preferred alternative is expanded and used to help manage the system throughout its entire life cycle. Many types of system models are used, such as physical analogs, analytic equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations, and mental models. Systems engineering is responsible for creating a product and also a process for producing it. Therefore, models should be constructed for both the product and the process. Process models allow us, for example, to study scheduling changes, create dynamic PERT charts, and perform sensitivity analyses to show the effects of delaying or accelerating certain subprojects. Running the process models reveals bottlenecks and fragmented activities, reduces cost, and exposes the duplication of effort. Product models help to explain the system. These models are also used in tradeoff studies and risk management.
As previously stated, the systems engineering process is not sequential: it is parallel and iterative. This is another example: models must be created before alternatives can be investigated.
Integrate
No man is an island. Thus, systems, businesses, and people must be integrated so that they interact with one another. Integration means bringing things together so that they work as a whole. Interfaces between subsystems must be designed and subsystems should be defined along natural boundaries. Subsystems should be defined to minimize the amount of information to be exchanged between the subsystems and well-designed subsystems send finished products to other subsystems. Feedback loops around individual subsystems are easier to manage than feedback loops around interconnected subsystems. Processes of co-evolving systems also need to be integrated. The consequence of integration is a system that is built and operated using efficient processes.
Launch the System
Launching the system means running the system and producing outputs. In a manufacturing environment this may mean buying commercial off-the-shelf (COTS) hardware or software, or it may mean actually making things. Launching the system means allowing the system do what it was intended to do. This also includes the system engineering of deploying multi-site, multi-cultural systems.
This is the phase where the preferred alternative is designed in detail; the parts are built or bought (COTS ), the parts are integrated and tested at various levels leading to the certified product. In parallel, the processes necessary for this are developed – where necessary – and applied so that the product can be produced. In designing and producing the product, due consideration is given to its interfaces with operators (humans, who need to be trained) and other systems with which the product interfaces. In some instances, this causes interfaced systems to co-evolve. The process of designing and producing the system is iterative, as new knowledge developed along the way can cause a re-consideration and modification of earlier steps.
The systems engineers’ products are a mission statement, a requirements document including verification and validation, a description of functions and objects, figures of merit, a test plan, drawing of system boundaries, an interface control document, a list of deliverables, models, a sensitivity analysis, a tradeoff study, a risk analysis, a life cycle analysis, and a description of the physical architecture. The requirements should be validated (Are we building the right system?) and verified (Are we building the system right?). The system functions should be mapped to the physical components. The mapping of functions to physical components can be one to one or many to one. But if one function were assigned to two or more physical components, then a mistake might have been made and it should be investigated. One valid reason for assigning a function to more than one component would be that the function is performed by one component in a certain mode and by another component in another mode. Another reason would be deliberate redundancy to enhance reliability, allowing one portion of the system to take on a function if another portion fails to do so.
Assess Performance
Figures of merit, technical performance measures, and metrics are all used to assess performance. Figures of merit are used to quantify requirements in the tradeoff studies. They usually focus on the product. Technical performance measures are used to mitigate risk during design and manufacturing. Metrics (including customer satisfaction comments, productivity, number of problem reports, or whatever you feel is critical to your business) are used to help manage a company’s processes. Measurement is the key. If you cannot measure it, you cannot control it. If you cannot control it, you cannot improve it. Important resources such as weight, volume, price, communications bandwidth, and power consumption should be managed. Each subsystem is allocated a portion of the total budget and the project manager is allocated a reserve. These resource budgets are managed throughout the system life cycle.
Re-evaluate
Re-evaluation is arguably the most important of these functions. For a century, engineers have used feedback to help control systems and improve performance. It is one of the most fundamental engineering tools. Re-evaluation should be a continual process with many parallel loops. Re-evaluation means observing outputs and using this information to modify the system, the inputs, the product or the process.
Bahill and Gissing characterize their SIMILAR model as follows: the process of drafting, designing, and producing a system is iterative. If new knowledge and new experience are gained, they should be used to improve the design or the construction. Thus, a return to earlier steps in connection with the development of new solutions should be seen as normal, to the extent that it serves to improve the solution in terms of the project goals.
The results that a systems engineer delivers in the course of his work are a clear statement of task, a list of requirements (including verification and validation),10 a description of the functions and objects, a test plan, identification of the system boundaries and of the relevant environment, and definition of the interfaces. A list of the deliveries and performances (deliverables) agreed upon supports the verification that the requirements have been met. Further analyses to be conducted include sensitivity analyses of the evaluation results, risk analyses, life-cycle analyses, descriptions of the physical architecture, etc.
2.2.1.4 VDI Guideline 2221
The guideline was developed with a view toward closed systematics for the development/design of machine systems in collaboration with the VDI (association of German engineers). It contains a step and phase process from the abstract to the concrete and from the concept to the installation drawings, the development and elimination of variants, and a microcycle not presented here (determination of requirements, development of solutions, and evaluation).
Comparison of the action plan of the VDI guideline 2221 and the systems engineering procedure (Jänsch, J. and Birkhofer, H. (2006): The Development of the Guideline VDI 2221)
2.2.1.5 Engineering Design Methodology According to Pahl and Beitz
The main phases of the design engineering process. (Simplified representation according to Pahl and Beitz (Pahl et al. 2007)
- 1.
Task clarification
First, it is necessary to gather appropriate information about the customer needs, the market, the competitive situation, etc. This is the basis for preparing a list of requirements (specifications, functional specifications)11 from which the product functions result.
- 2.
Conceptual design
The product functions are broken down into partial functions, for which various solution principles are sought. Connecting the various principles gives rise to solution variants. These are evaluated, and the preferred variant determines the working structure.
- 3.
Embodiment design
The individual functional components are structured to scale (= general assembly drawing) and analyzed, evaluated, and calculated. Then they are detailed into a full-scale detailed drawing. In this process, the technical flexibility must also be taken into consideration. Styling considerations are addressed as needed and physical models are prepared. These sketches or designs are evaluated and a choice is made of the preferred variant(s). Functional models may be made, with which the function of the selected technical solutions must be verified. Often, a combination of several models is created before the detailed development of product function or construction groups occurs during a further work phase (transmission, motor, etc.).
- 4.
Detailed design
The necessary manufacturing documentation is drawn up. If the individual component drawings are available, prototypes are manufactured and tested for early detection of weaknesses, flaws, or problems. Based on the existing error log, the product is reworked, and the specification may be adjusted. Further prototypes may be manufactured. In the so-called pilot run, it is determined whether resources such as tools and jigs are suitable for series production. With an initial production run/first series (often of reduced batch size), it is determined whether trouble-free production can be expected.
2.2.1.6 The Prototyping Approach
Prototyping as a procedural principle occurred in the mid-1970s in data processing. On the one hand, the trigger was the heavy phased process, with its relatively high number of formalisms (project mandates, decision reports, documentation, etc.), was also held partly responsible for the so-called user backlog; and, on the other hand, the trigger was the users’ difficulties in having to specify concrete requirements at an early stage, without being able to imagine what ultimately would come from them. Often, the user only realizes after implementation of the solution what he should have wished for. Each deviation of the developed solutions from the expectations is seen as a disappointment on the part of both the developer and the user.
Basic Idea
The idea of designing a sort of prototype, initially at a relatively low cost, before developing the ultimate product, to visualize and evaluate the product’s essential characteristics, was adopted long ago in machinery construction, engineering, and the building industry. There, it is very common to realize solution designs into physical models at various phases before the ultimate (mass-produced) product is manufactured, e.g., in the form of functional or laboratory prototypes, pilot models, etc. These do not involve the expectation that the prototype can be used by the commissioning party/user. It is rather intended to provide a better evaluation of the concept pursued so far, and may also serve for testing under operating conditions.
In the construction industry or in plant manufacturing, physical models are used that can provide a better idea of the subsequent solution. Modern design tools can often take the place of realizing physical models and thus save time and money (e.g., digital 3D models, computer simulations, etc.).
Proof-of-principle prototype (model): this kind of prototype serves to investigate a particular design (layout, architecture) of a solution, without precisely simulating the outer form or the future materials of the finished product, etc. Among other things, this makes it possible to recognize which design options work and which ones do not, thereby identifying further development paths. For example: a new chassis is combined with an existing body.
Form study prototype (model): this should allow developers to assess the size, shape, look, and feel of a solution without making it in detail. It should reveal ergonomic factors or visual aspects of the end product. Such prototypes are often made from materials that are cheap and easy to work with (wood, clay, foam, etc.).
Visual prototype (model): as a mock-up of the subsequent solution, this kind of prototype should facilitate an evaluation of the esthetics, design, colors, and surface structure of the contemplated product. The functions that the subsequent product is to deliver are not yet represented, for example, a model or a photomontage of a housing complex.
Functional prototype (model): this provides a fairly clear representation of the ultimate design, materials, functionalities, etc. But it can, for example, for reasons of cost, be reduced in size, for example, a production facility on a laboratory scale.
Design aids (= explorative prototyping), with the goal of concretizing solutions more quickly and thus achieving more efficient communication between developers and, for example, users. Prototyping should then help to close in on the user’s needs. When these are clear, the prototype is perfected and made into a solution that is ready to be introduced.
However, prototyping can have different meanings, for example, when an especially quick solution is sought that does not need to be either complete or perfect. This (quick and dirty) solution is delivered to the user (e.g., pilot installation) and if necessary it is changed, adjusted, or perfected during the operational phase (evolutionary prototyping). The procedure is supported in the area of data processing by software tools that use powerful commands to facilitate a very quick and efficient procedure for the developer. In the early stages, this procedure may appeal to everyone concerned. But people should be aware of the danger of the addiction toward improvisation increasing and the solutions remaining quick and dirty.
Comparison of Prototyping with Systems Engineering Concept
Prototyping as a design aid in the phase process
On the one hand, speed often comes at the expenses of quality, and inadequate quality can quickly dampen the pleasure of a quick solution. On the other hand, it is often difficult for developers to convince users, or decision-making bodies (management) of the necessary effort required to turn a functioning prototype into a well-engineered solution.
Last but not least, we consider a general waiving of conceptual phases and a solely user-oriented development of application software to be shortsighted and even dangerous. How are solutions developed in this way (e.g., programs or programming systems) to be integrated subsequently if the interfaces were not designed with an overall view? How can they be maintained if the documentation is inadequate or non-existent because they were produced so quickly?
Therefore, prototypes should, as in the original sense of the word, be disposable products that perform important functions temporarily, with the transition to what is known as the “versions concept” emerging, which is described in the next section.
2.2.1.7 The Versions Concept
The so-called versions concept exhibits similarities to the prototyping approach of the quick solution and is applicable in developments of all types (machines, devices, installations), and sometimes it may even be unavoidable.
Basic Idea
The basic idea is that a solution is not to be perfected at one blow, but rather that a first version should be designed and implemented, and made available to the user. On that basis, improvements become possible because of operational experience and take place from one version to the next (slow-growing systems). This involves a shift from the design orientation of the phase concept to an implementation orientation. The purpose and the similarities to the prototyping approach are thus unmistakable.
In addition to the definite appeal of such a process, especially with respect to the speed of development and the achievable visible progress, in our view, there are also a few attendant limitations. This process can lead to less careful design, because it is easier to shift problems or improvements to the next version. Furthermore, the versions concept places high demands on documentation and project administration, as at every point it must be clearly understood where each version is valid and how the individual components of a solution were implemented, or how they are interdependent. The configuration management briefly described in the glossary (Part VI, Chap. 15) is certainly is an essential requirement.
Comparison of the Versions Concept with the Systems Engineering Concept
Without taking a dogmatic view, we consider both concepts to be compatible, in particular if the versions concept is restricted to a weight shift inside the phases and is not intended to totally eliminate the phase concept. The development phases (preliminary, main, and detailed studies) are consciously streamlined. The planning horizon for the usage phase is quite short, because subsequent, modified versions must be reckoned with right from the start.
The phase model, the versions concept, and the prototyping approach can thus be combined very effectively: the first version is developed after a (shortened) phase model (with observance of the action principle “from the general to the particular” and the principle of variant creation). The prototyping approach is chosen for selected conceptual components (detailed studies, systems building). The creation of a second or third version no longer follows prescribed rules, unless comprehensive changes are involved, for which a (reduced) phase process could be used.
2.2.1.8 Simultaneous Engineering, Concurrent Engineering
Simultaneous engineering (also known as concurrent engineering) has its origin in product development. The trigger for this idea is the demand for shorter development times that are reflected in favorable, early market entry effects such as higher prices, greater market share, and thus savings through scale effects, positioning as market leader, higher accumulated profits, etc.13
Basic Idea
Simultaneous (concurrent) engineering as an overlapping phase concept
Basic idea of acceleration:
- 1.
Involves a rethinking of the traditional process logic for development projects with a view toward carrying out partial steps as far as possible in parallel rather than sequentially. In particular, the time-critical and independent partial steps come to the fore. The main maxim is critical in the sense of concept-defining first, so that the follow-up activities can begin without delay.
- 2.
Requires a holistic work approach, in which the follow-up activities later encountered (production, materials management, logistics, cost accounting, integrated product teams, perhaps with external suppliers, etc.) are integrated into the development process as early as possible. On the one hand, errors can be avoided early or additional possibilities can be used, and, on the other, the follow-up activities can be started earlier, that is, simultaneously. In this team-oriented approach many simultaneous engineering supporters see a significant potential for setting changes and innovations in motion.
- 3.
Increasingly tends to promote the inclusion of CAD, CAM, and CAx technologies and thereby the acceleration or even the elimination of entire steps or step sequences. As an example, the use of CAD technologies in connection with design, accounting, parts list management, materials information, computational or pictorial simulations, etc., can make the time-consuming creation of physical prototypes or laboratory experiments and trials superfluous, or at least reduces it greatly.
Comparison of Simultaneous Engineering with the Systems Engineering Concept
In our view, the concept of simultaneous engineering is not in contradiction to the systems engineering concept. It can be understood as an application-oriented interpretation of the phase concept. The phase concept is not seen as strictly linear, in the sense that the product development must be totally completed in detail before the development of the production resources can be addressed. We should not wait until even this development is completed to start procuring the resources – as shown in the left part of Fig. 2.15.
A partially simultaneous handling is made possible by an overlapping arrangement of the phases. This new structuring of the process logic can force us to fix central details during the very early phases so that the follow-up activities can be tackled quickly. This can have effects on the content of the early phases of product development.
However, there should be a minimum level of advancement in the sense of a temporal progressing. There is some danger, for example, before the selection of a solution principle, in conducting excessively intensive discussions with the “implementers,” or letting them start too soon. The building and plant industry could serve as a warning example here. An opposing tendency can be observed: a careful and detailed design of the object is given clear preference before the start of realization. A quicker and especially more cost-effective construction process because of fewer subsequent changes is perceived there as an essential argument.
Although advantages are no doubt linked to the simultaneous handling of a detailed development of the product and to the preparation of production or even outside procurement, there are also risks, e.g., with subsequent, unforeseen changes in the product and the associated effects on production facilities that have already been ordered or procurement agreements on parts purchased from a third party. In the interest of speeding up the process, this risk may be acceptable. Good project organization and, in particular, good coordination and communication among the people involved in the project, are essential prerequisites.
There is another consideration here in the comparison with the systems engineering concept: the more subjects are handled in overlap, of course, the quicker the decrease in alternatives. This concerns both the detailed product design and eventually also the choice of production processes and external suppliers. This loss of options is less risky if one has already had some experience with a product, that is, if it involves the reworking of an existing product and/or production concept rather than a new development.
2.2.2 Agile Process Models
The plan-driven methods as described above are sometimes vehemently criticized, despite the unquestioned advantage that they can bring a logical process structure to projects, especially in connection with software projects. In particular, they are criticized for making the (software) development process unnecessarily difficult, requiring long development times, and usually producing unsatisfactory results because they may encourage a very restrictive behavior with respect to subsequent, justifiable specification changes. The so-called agile methods have grown out of this need.
This category includes mainly process models that were developed in connection with software development. Prototyping and the versions model are exceptions that can easily be transferred to any type of development, although here they have been assigned to the plan-driven models.
Agile process models are further developed and increasingly carried over to the development of systems comprising hardware and software components. We return to this matter later on.
2.2.2.1 Spiral Model
The spiral model is a process model in software development that was inspired by Barry W. Boehm as an alternative to the rigid waterfall model.14 The division into phases is retained, but by combining with the prototyping idea, the phases occur in overlap. In addition, the model provides guidelines on the conditions under which individual phases should be repeated. The risk of specification flaws is reduced through the prototyping approach, and a better starting basis for follow-up activities is created through the experience gained in programming the prototypes. The specifications (design, user interface, etc.) are tested in the iterative prototyping process. As long as the prototype is not accepted, the specifications are changed or expanded. This is continued until a satisfactory result for the developer and the user is achieved.
The spiral model. (Source: Wikimedia, commons)
If the spiral model is compared with the systems engineering process model, one may say that both the project phases and the PSC modules are recognizable: the sequence of the quadrants essentially corresponds to the logic of the PSC (1. Goals, 2. Alternatives, etc.). With every turn of the spiral, the degree of detailing in the planning grows from the inside toward the outside (requirement, preliminary design, detailed design, etc.) or in the results (prototype 1, prototype 2, operational prototype, etc.), which would correspond to the project phases – but in an iterative and prototyping-oriented approach.
2.2.2.2 Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We follow these principles behind the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity – the art of maximizing the amount of work not done – is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This Agile Manifesto arose in the climate of a general unease concerning the existing process concepts that were perceived as inflexible. At the same time, hope was pinned on the quicker availability of results, on the possibilities of an evolutionary adaptation of work and results to changed conditions, and not least, on satisfied clients.
In this field, a number of so-called agile methods have also been developed with a view to transferring the ideas contained in the Agile Manifesto to tangible project work. A few of the many agile methods are outlined briefly below.
2.2.2.3 Extreme Programming
Extreme programming arose from the needs and the insights of a small, top-quality software development team that was confronted with imprecise and continually changing requirements.16 In comparison with other development methodologies, it is very lean and flexible. It is based on intuitively comprehensible insights that reach into upper extremes – hence the name extreme programming.
A distinction between decisions based on business interests and on project interests
Test-driven development: writing test routines for program parts to be created and the continual use of these test routines throughout the entire program development
Continuous integration of the individual components: integration of all system components and tests of the entire system several times a day
Pair programming for the entire program development: two programmers with alternating roles in front of one display screen
Simple, minimalist design: at the beginning, projects have a simple design, which continually develops further with the inclusion of the project customer(s) to add required flexibility or to eliminate unnecessary complexity (KISS,17 YAGNI18);
The quickest possible implementation of a minimal system and its further development in the direction that makes the best sense or is the most worthwhile.
Extreme programming was developed by Kent Beck, Ward Cunningham, and Ron Jeffries in the years 1995–2000, within a software development project for payroll accounting in the Chrysler Corporation. The Comprehensive Compensation System project itself was introduced in 2000 on the occasion of the takeover by Daimler.
In the following years extreme programming experienced great popularity and an equal measure of criticism. Among the main criticisms was the high demand for qualifications and team spirit among the project collaborators, a lack of scalability for medium to large projects, and a neglect of potential in far-sighted planning or the application of previous knowledge.
2.2.2.4 Feature-Driven Development
Feature-driven development (FDD) is a collection of work techniques, structures, roles, and methods for agile software development.19 FDD places the emphasis on the notion of feature: every feature represents an added value for the client. The development is organized using a feature plan. The chief architect plays an important role; he or she continually observes the overall architecture and the specialized core models.
- 1.
Developing an overall model with the goal of reaching a consensus on the content and the scope of the system to be developed and the technical core model.
- 2.
Creating a features list and describing the features according to the pattern action, result, objective.
- 3.
Planning features with respect to the sequence in which they are to be carried out. This is geared toward the mutual dependence of the features, their complexity, and the work load of the programming team. The features are assigned to individual development teams for further processing.
- 4.
Features design: the development teams create sequence diagrams for the features, and the head programmer refines the class models on the basis of the sequence diagram. The developers then write the first class and method bodies. Finally, the results are inspected. If there are any technical ambiguities, the specialists are called in.
- 5.
Constructing features: the developers program the prepared features. In the process component tests and code inspections are applied for quality assurance.
The first three steps are carried out in a few days. Steps 4 and 5 are conducted in continuous change, as every feature should be implemented in no more than 2 weeks.
2.2.2.5 Scrum
Scrum is a collection of interrelated work techniques, structures, roles, and methods for project management within the framework of an agile product or software development.20 The goal is to optimize the development environment, reduce the organizational overhead, and come as close as possible to market demands by means of iterative prototypes.
Scrum contains few determinations a priori: teams or developers mostly organize themselves and select the methods used. The processes and the methods are continuously adapted to the current demands. Scrum builds on many basic assumptions of what is known as lean production and transfers experience from the automotive sector (Toyota) to software development. A central feature of both is the constant further development of the participants in the process, including the customer and partners, the manufacturing processes, and the tools and methods, with simultaneous, constant retention of the basic underlying assumptions: continually improving production to achieve the highest quality with the lowest expenditure (effort).
One central element of Scrum is the sprint, which designates the implementation of an iteration. Scrum allows for pre-defined iteration lengths for each sprint (e.g., 5–30 days). Before the sprint, the customer product requirements are collected in a product backlog, which states the features of the product to be developed. It includes all functionalities that the customer wishes, along with the technical dependencies.
- 1.
The product owner determines the overall goal that he and the team are to achieve, or he sanctions it. He makes the budget available and regularly sets the priorities for the individual product backlog elements. He also decides which features are the most important ones, among which the development team has a choice for the next sprint.
- 2.
The team estimates the expenditure for developing the individual backlog elements and starts implementing practicable elements for the next sprint. The team works in a self-organized manner in the frame of a time box (the sprint) and has the right (and the obligation) to decide for themselves how many elements of the backlog must be achieved after the next sprint; these are known as commitments.
- 3.
The scrum master has the task of directing the development and planning processes, plus overseeing the assigning of roles and rights. He maintains transparency during the entire development and encourages bringing to light the existing potential for improvement. He is not responsible for the communication between the team and the product owner, as they should communicate directly with one another. He stands by the team and makes sure that it can work productively.
Just like extreme programming, Scrum follows a hype cycle. Scrum is nowadays the most common agile process model.
After initial euphoria, critical voices multiply and report the unsatisfactory control possibilities of the development process, or relate a productive variant of Scrum whose use is restricted only to the lower development levels or defined scopes of development – see “Hybrid Forms of Project Organization” in Sect. 4.3.2.5.
2.2.2.6 Crystal
This term encapsulates a whole family of software development methods that are differentiated with respect to the number of people involved and the risk level (the so-called criticality): depending on the number of people, various communication mechanisms are required. The effort for ensuring the correctness and the reliability of the system to be developed is determined by the risk level.21
The methods of the crystal family are labeled with color attributes. The spectrum runs from crystal clear, crystal yellow, crystal orange, crystal red, and crystal magenta to crystal blue. The simplest variant, crystal clear, is recommended for team sizes of two to six people – the largest variant, crystal blue, for 200–500.
In comparison to other agile methods, the methods of the crystal family are less dogmatic and formalized. Likewise, strict programming in teams of two (extreme programming’s pair programming) is no more prescribed than involving the client in the program development on site.
According to the crystal philosophy there are also no static development methods for the development teams. New and appropriate methods are determined for each project. This means that with fairly simple projects, crystal becomes very similar to extreme programming and differs only in more complex projects, through more sophisticated procedures.
2.2.3 When Are Plan-Driven and Agile Methods Appropriate?
Comparison of agile and plan-driven action methods. (Inspired by Boehm, G. et al.)
2.2.3.1 Is a Convergence Possible?
Where does the systems engineering concept already show approaches to a certain agility, or support agile principles?
With respect to which principles is the systems engineering concept neutral, or which agile principles are possible within the systems engineering concept, even if they are not actively supported?
Where does incompatibility between agile principles and the systems engineering concept exist, or where does the integration of agile principles into the systems engineering concept require more extensive research?
2.2.3.2 Existing Agility in Our Systems Engineering Model
The conceptual division of the four modules, in particular, the phase and the PSC modules, facilitate adaptation of the methodology to various sizes of projects. Small projects do not need to be subdivided into several development phases with increasing concretization (from the general to the particular). A single run-through of the PSC with an immediate transition to realization (systems building) may be perfectly adequate.
Due to the fact that also within the systems engineering concept, the responsibility of choosing the process falls to the team and can be adapted to the requirements of the project, there is an accord with the agile methods.
Continual learning and the application of experiences are just as important in the systems engineering concept as in the agile methods. The systems engineering concept is not a process to be used stubbornly, but rather a guideline for how specialized knowledge, experience, knowledge of methodology, etc., can best be combined.
The principle of variant creation on three levels (left in the illustration), combined with decisions at the end of each development phase (preliminary, main, and detailed studies, center of illustration) produces decision-making situations that allow the line of approach.
The backward-pointing arrows in the PSC (on the right in the illustration) represent recourses to earlier steps, and can be understood as iterations.
Relationships among the various components of the systems engineering action model (arrangement by tendency)
Every detail concept worked out in detail is integrated conceptually into the overall concept at a higher level (arrows pointing upward). Unsatisfactory situations can and must be processed at the levels of the overall concept or the detailed concept.
Even external influences that have nothing to do with the project can make an adaptation of the overall concept necessary (angled arrows in Fig. 2.19).
The arrows pointing upward form the detailed concepts involved in the overall concept and back down (= check, modification, adaptation) support flexibility and agility, in addition to attention to external influences (represented by angled arrows).
The broad arrows of different lengths leading beyond the detailed studies are intended to indicate a different implementation status, which, however, can also reduce flexibility (overall concept no longer adaptable, as the detailing or realization is already advanced).
The dynamic of the overall conception with stepwise integration of partial results and the possibility of external influences
2.2.3.3 Agility That Is Easily Used in the Systems Engineering Model
People-oriented approaches, such as the close involvement of the user in the development team (customer on-site), regular meetings at short intervals, etc.
The adoption of the idea of the backlog elements and Sprints (from Scrum)
The adoption of the idea of the use cases and of the explorative prototyping for selected modules of a system that are particularly difficult to design
The cooperation of small groups in the detailed development of concepts (based on pair programming)
Simplicity (KISS, YAGNI, etc.)
Strategies such as those described in Sect. 2.2.4: postponement of essential decisions, keeping options open, and choosing architectures that are relatively robust with respect to changes, can contribute agility to the development process
With modular architectures and the implementation of software-type rather than hardware-type functions, the developed systems can be made agile, which is easily changeable or more adaptable.
Use early sprints to define the basic correlations and decision criteria
Define early a system architecture and its degree of changeability depending on the kind of problem and environment
Identify the concept defining details from the architecture and prioritize them in your product backlog
Organize and staff your agile team so that they can work on the different levels of a problem, from architecture level to detailed parts or coding
A different possibility is the application of a combination of traditional and agile methods, such as the so-called hybrid models (Sect. 4.3.2.5).
2.2.3.4 Agility That Is Difficult to Reconcile with the Systems Engineering Model
Development in short iterations must always deliver a customer benefit: This principle has its origin in software development, cannot or should not be interpreted in the same manner as the development of hardware, because there, the customer benefit cannot be proven by a functioning subproduct that is ready for application. This is scarcely possible and not even expected in hardware projects (think of a vehicle and a functioning gearbox delivered to the customer). Although modern simulation methods (Hardware in the Loop, HIL, 3D printing) are very helpful, the expectations should be modified: one can take a benefit as already given if the contributing staff members of the clients state that significant progress has been caused by the respective iteration.
Neutrality toward changes: adaptations and changes of solutions are of course easier to manage in the early phases of system development than in later ones. If, for example, a specific solution principle or systems architecture has been decided on after a preliminary study, and if in the course of the main study these turn out to be impracticable or less than optimal (clearly better variants are subsequently discovered), an adaptation of the concept may still be possible. No further detailed developments are initiated. Fundamentally changing an overall concept (a master plan) that has been decided on at the end of the main study and that will then be worked out gradually in more detail would in comparison involve much greater difficulties, especially if the design of detailed concepts is already advanced, and if the detailed design is created by various working groups that are also geographically far apart.
However, this kind of problem exists in software development as well.
2.2.4 Keeping Options Open as an Approach in Support of Agility
Some years ago, several members of the BWI systems engineering development team were involved in a project (planning for a production site) that was characterized by a very dynamic environment. Solutions that had just been developed had to be discarded because the starting situation and the corresponding requirements had changed drastically and unexpectedly.
The systems engineering process model, with which the people involved in the project had had good experiences in the past, was not applicable in this specific instance. There, the installed decision-making logic specifically foresees that important decisions would be made at the end of each characteristic phase for the purposes of more detailed planning (decision on a solution principle at the end of the preliminary study, on an overall concept at the end of the main study, etc.).
The simplest solution to this dilemma would have been to stop the planning until the situation had been clarified. But in many cases, people could not or did not want to do this, to avoid incurring disallowed delays, or because they feared not being able to resume the project at a later point in time (movers and shakers and key people leave the company or turn to other tasks).
One chooses the variant that is deemed the most practicable and continue – with the declared intention of gravitating toward some other variant as soon as it becomes necessary or suitable.
One avoids making a commitment as long as possible, but still continue with the planning by intentionally keeping options open.25
- 1.
A (limited) number of solution concepts are developed (S1 to S4), all of which are considered reasonable and usable, but on which no decision can (yet) be made because of the uncertain situation.
- 2.
For every solution concept, one works up an implementation plan and investigates the solution variants for identical implementation steps.
- 3.
The specific implementation steps that are worked out are those similar for several solution concepts (as many as possible). In this case, a certain amount of flexibility is provided.
- 4.
These implementation steps are brought forward in time, for they leave open the greatest latitude and the most options.
- 5.
Thus, the first decisions do not involve concept variants, but rather implementation stages. In Fig. 2.20, this would be decision D1 over implementation step R1. The point of no return can therefore be delayed. It is assumed that at first, all four solution concepts, S1 through S4, remain open as options.
- 6.
Once implementation steps have been started, which only allow a restricted number of solution concepts or require the elimination of individual solution concepts, appropriate decisions are of course necessary. These may be easier, because developments at this (later) time can hopefully be evaluated better. This would be the case in Fig. 2.20, for example, at point 2. Here it should be assumed that decision D2 precludes solution principle S1 for implementation step R2.
- 7.
The situation is analogous for decision D3 and solution principle S4. From this moment on, solution concept S2 is used for guidance (possibly in modified form).
Keeping options open
The real options approach described in 2.2.5 presents excellent linking options with the considerations described above. It supports this mindset and provides an approach for evaluating this type of project.
The point of no return can be postponed.
It results in an implementation sequence that may not be the best from the viewpoint of the ultimately selected solution concept. But this is accepted in the interest of possibly greater flexibility.
The time gained is not allowed to pass idly by, but rather must focus on information gathering to facilitate the decisions that are ultimately made. It is thus reasonable to define indicators in terms of observables that are to be followed attentively, for they may help in evaluating the usefulness of both the solution concepts and the implementation stages.
Therefore, the basic idea of systems engineering of creating a conceptual framework before working out solutions in detail is not pointless, but it is rather intensified.
However, be warned of an extensive use of this mindset: it is tempting for commissioning parties who have difficulties in making decisions and who may agree to it eagerly because at first they are subject to fewer demands. The advantage of keeping options open is connected to the undeniable disadvantage of the increased planning effort, a potentially less than optimal process, or to the successive and unwitting loss of possible opportunities for action on the part of the decision-makers. The factual difficulty of the decision-making situation, rather than the insufficient resolution on the part of the decision-makers, should thus be crucial in choosing this type of process.
2.2.5 Real Options Approach
The real options approach can be considered a method for evaluating decisions (e.g., investments), in which the basic actuarial fundamentals of the option pricing theory are applied to project evaluation.26 But it can also be seen as a conceptual approach that influences the process through the possibility of purchasing additional options. We consider this added benefit to be important and have therefore placed remarks on real options in this section. Developers and designers should be motivated to consider the additional possibilities of a (partially) reduced or expanded implementation of concepts and address the attendant risk considerations.27
The difficulty that developers/planners and decision-makers face is that only prognoses, or reasonably plausible assumptions, can be made about the future, but of course without any certain prediction. But the future development of the investment and the relevant environment (market, business activity, competition, one’s own business operations) must be assessed in advance. All prognoses and suppositions concerning future developments are fraught with uncertainty.28
The traditional methods for investment appraisal in preparation for investment decisions on a so-called objective basis, proceed first from secure assumptions, for example, about market and business development, the amortization period, the interest rates for capital, etc. The uncertainty factor can be included through sensitivity analyses or assumptions based on probability. After using these processes, the decision-maker has either an individual model adapted to the uncertain development, or an entire array of possible scenarios concerning the future development, and must decide on one of them. Generally, he bases his investment decision on the scenarios that strike him as most likely and most plausible. It thus becomes quite possible to incorporate uncertainty as a factor in the planning, provided that the assumptions and possible risks are known or properly estimated in advance. Changing environmental conditions during the course of the project cannot be taken into account. Thus, the decision-making rule for the investor is, “Invest today in case the investment is profitable, or never.” Investment projects tend to be underestimated for reasons of caution, and thus are implemented with less probability.
An investment appraisal method that makes it possible to react to uncertain future expectations was presented by Stewart C. Myers and proved very popular among decision-makers. Myers recognized that this flexibility, opening up more room for maneuvering, can be seen as an option. He thus coined the term real option, which remains in use today. Behind this designation hides an approach to investment planning based on the option pricing theory. Although option pricing theories were previously applied to evaluation problems for financing (resources procurement), this approach broadens the application field to evaluation problems for investments, i.e., the use of resources.
Excursus on Uncertainty and Risk by Investment
Uncertainty commonly designates the possibility of a deviation from an expected value or an expected situation. Positive deviation = opportunity; negative deviation = risk, danger.
The term risk in terms of the decision-making theory describes a situation about whose probability of occurrence the decision-maker has objective information, or that he or she can at least assess subjectively. Objective probabilities are achieved through empirical studies or results of equivalent decision-making situations. It may be possible to calculate the probabilities on the basis of statistical data. Subjective probabilities are empirical values that cannot be checked statistically or empirically, or that have so far not been validated.
Uncertainty in terms of the decision-making theory designates a situation in which the decision-maker really does not know how things may turn out. There are neither objective nor subjective probabilities. A rational decision between various alternative courses of action is practically impossible in such instances. And yet it would not be a good recommendation to avoid making a decision and to do nothing, because of uncertainty due to a total lack of understanding of the situations to be expected. The following outlined practices may be helpful in generating possible courses of action.
Uncertainty and Flexibility
- (a)
Risk Avoidance
- (b)
Diversification Strategy
- (c)
Anticipation
- (d)
Creating Maneuvering Room
Recognizing and creating maneuvering room makes it possible to react flexibly to uncertainty and changing environmental conditions. The maneuvering room can be seen as options, according to Stewart C. Myers, as already mentioned, that are similar to the opportunities available to the owner of a financial option.
So, for example, the option to bring a product onto the market after a successful sale trial can be compared with a call option. A call makes it possible to purchase a share at an established price. In this case, the loss from an unfavorable share performance, in which the call option is not exercised, is limited by the level of the option price. On the other hand, the gain is theoretically unlimited.
Option to terminate an investment project. Liquidation proceeds can be achieved by the sale of tangible or intangible elements that are no longer needed – in addition to the elimination or reduction of future losses. This corresponds to a put option, which allows the sale of financial futures at a determined price. Here, too, the result is an asymmetrical risk profile because of the reduction of potential loss through the preservation of the potential for gain. Of course there are costs associated with creating this type of maneuvering room, e.g., from liquidation proceeds that do not cover the investment costs – just as with the purchase of financial options.
If there is maneuvering room for further investments (e.g., for expanding production), it may be possible that too much time is spent observing the market trend or that the investment decision is postponed for some other reason. In this way, market shares may be lost to competitors who invested more quickly and/or get into the market more aggressively. In such cases, the costs take the form of lost earnings, which are known as opportunity costs.
Great uncertainty over the future performance of the investment
Flexibility of the decision-makers to react to these uncertainties
The value of the investment without flexibility is close to the break-even point
The rationale: great uncertainty generally means that it is likely that the decision-makers receive new information in the course of the investment project. Thus, the option for maneuvering room is most valuable when the underlying situation is uncertain. This perspective is in contrast to the previous school of thought. Although in traditional investment calculations of the value of an investment diminish as risk increases, by considering courses of action with increasing risk, the value of the investment increases.
If by the traditional evaluation methods it has already been determined that an investment will be quite profitable, it is improbable that room for maneuver offering additional flexibility will be sought and paid for at a higher price. Therefore, they have a relatively lower value.
If it is foreseeable by traditional methods that the investment will never yield a profit, it should be suspected that even by using room for maneuver, it will likely not enter the profit zone. The value of the flexibility is low as well, for it may consist only of the passive option of termination to prevent future losses.
Here, too, the greatest value of active maneuvering room is in the gray area of the break-even point. In this case, the presence of flexibility can tip the balance in considering an investment project to be reasonable or not. And one is more likely prepared to “buy” this course of action.
Real Options as an Evaluation Tool
- 1.
Deferred option as the possibility of delaying an investment within a specific time period. The option owner must secure the right to implement the investment at any time within a determined deadline. Losses of value can occur because of the time value of money and/or because of the loss of market shares.
Example: a company wants to introduce a new product to the market. There are great costs associated with introducing the product (e.g., accompanied by a major marketing campaign). The introduction time is assessed as currently unfavorable (poor business activity, etc.). There is a fear that the product will not produce the desired sales figures and the marketing expenditure will be wasted. The decision is thus made to delay the product launch for a year and to watch how the economic situation evolves. But there is a risk that during this year a competitor who enters the market with a similar product could win a market share. If this were to occur, or if the business situation improved significantly before the year was over, there would certainly be the possibility of beginning sooner.
- 2.
Growth option: the possibility of following up an initial investment with subsequent ones, e.g., expanding the existing investment or making a new one.
Example: the successive development of production capacities and/or a market organization that is made dependent on market success.
- 3.
Termination option: the possibility of terminating (discontinuing) an investment if a project progresses poorly. If the project is ended, losses of value occur as a result of the discontinuance.
Example: a product is first launched in a test market. If the anticipated sales figures cannot be achieved, there is an option of stopping the project. The initial investments are admittedly lost, but further losses are avoided.
- 4.
Multi-stage investment: when one stage of a project goes well there is the option to enter the next one. Usually, the option can be exercised only at specific times (such as at the end of the previous stage). A loss of value arises from the fact that the investment is not made immediately in its entirety, and only the first stage is carried out initially.
Example: a pharmaceuticals company develops a medication. In the first stage, only an active substance is to be developed that mitigates the symptoms. The R&D department is convinced that an active substance can also be developed that could completely cure the disease. As this will take longer, at first, only the agent with the relieving properties is developed and marketed. With successful sales, the company has the option to continue developing the active ingredient in a second stage. Taking this decision, the risk involves the possibility that in the meantime a competitor will develop an active ingredient for a complete cure.
- 5.
Expansion or reduction option: with this option, the decision-maker has the possibility of expanding or reducing an existing project. Unlike the growth option, this does not involve a new investment, but merely the expansion or reduction of an existing project.
Example: a vehicle manufacturer that develops and assembles a small series for original equipment manufacturers (OEMs) designs a new assembly line on which vehicles of various types can be assembled in any desired sequence. The number of variants can be expanded and of course reduced within certain limitations (number of variants, dimensions of the vehicles, etc.).
- 6.
Option of temporary closing and reopening: if the proceeds from an investment no longer cover the variable costs to the desired extent, production should be temporarily suspended. The option involves the right to stop production and resume it later on.
Example: an oil producer has the option of temporarily suspending production on a specific oil field when market prices go down. This option is exercised if the extraction costs approach, to an extent to be defined, the price that can be realized on the market. Production is suspended until the market price rises to the point where extraction is profitable.
The possibility of deconstructing the 2008 European Championship soccer stadium in Klagenfurt (Sect. 1.3.2) can likewise be seen as an option. The selected architecture makes it possible to later reduce the capacity by about half and to use the upper part of the stands that are no longer needed elsewhere. The additional costs of realizing this architecture are the price of the option.
- 7.
Option for variation of input/output: also known as switching option, this describes the possibility of varying the input- and/or output factors independently on the demand for products and the development of prices for production factors.
Example: depending on the economic situation, a production company in the textile sector has the possibility of producing high-quality fabrics or fabrics of lesser quality (alternative input factors). If good prices can be realized for quality goods on the market, a higher-quality material is used for production. If the prices drop, raw materials of lower quality are made into more economically priced fabrics.
Of course it is possible to combine these option types, e.g., delay termination options, compound options, in addition to options with more than one source of uncertainty (rainbow options).
The option price theory is under development and is not yet widely used. Its major utility consists of the fact that it effectively supports agile systems engineering as a new design philosophy. The flexible mindset with respect to options is supported, and calculation methods are offered that make it possible to test economic feasibility on a totally new basis.
2.3 Outlook for the Future of Developing Products and Systems
In research and development-intensive industries such as mechanical engineering, the automotive industry, medical and electrotechnology, etc., global competition is becoming tougher.29 High dynamics in the technology and business markets, activities arising from as yet unknown and financially strong competitors change the innovative activities of traditional companies. Innovations in shorter cycles are needed, innovation projects have to be run quicker, cheaper, and must still be of high quality. Agile frameworks such as Scrum seem to be able to release unexploited potential that is increasingly turned into practice.
A study on the question to what extent agile methods are applied in practice shows an already extensive use and – quite interestingly – 27% of topics without an IT focus. It is remarkable that most of the participants of the study do not use agile methods in the pure form, but in a hybrid and selective form.30
Faster development: more rapid development enables faster reactions to market changes
More efficient development: the focus is not on cost reductions of their own process, but on developing better products that give more value to the customers.
More integrative development: the growing complexity of hardware, mainly caused by the integration with software in embedded systems, demands an interdisciplinary and cross-functional development approach. Developers coming from different subject areas increasingly work together, having to coordinate their development cycles, and thus jointly create new and integrated products. International competition also enforces cooperation in worldwide distributed teams.
What effects can this agile trend have on the systems engineering methodology?
- 1.The following modules of the systems engineering concept are practically unaffected by a conflict between plan-driven and agile methods. They have unaltered validity and applicability:
Systems thinking as a holistic approach to master complex interdependencies
Top–down approach, because an agile process needs a large framework – perhaps to a greater degree
Variant creation as a basic planning attitude, always asking: “what is the alternative to this idea”?
The PSC as kind of a micro-logic, asking in its simplest form: where are we now? Where do we want to go? Which ways, possibilities, and options are there? Which is best/most appropriate?
- 2.
A certain tension between the agile approach and the phase model cannot be denied. The agile model wants quick iterations, which are not offered by the phase model
- 3.Remedy is possible in two different ways:
- (i)
The phases are adapted to the agile needs and shortened radically in the form of sprints which go on for 2 or 4 weeks. This allows more flexibility. However, the early sprints would have to focus on the creation of a rough conceptual framework (architecture, solution principle)
- (ii)
Plan-driven and agile methods are not seen as opposites, but rather as two complementary approaches, which can be merged into a hybrid method. The rather management-oriented plan-driven methods are used for rough planning (milestones, decision points, allocation of resources etc.). The elaboration of this framework is handled by using agile methods, sprints, etc.
There is already some literature on approach (ii), where reports can be found on the practical and successful application of the hybrid approach (see Sect. 4.7).
- (i)
- (a)
To find a coherent product vision and product architecture: for that, he needs the top–down and variant creation modules, etc.
- (b)
Furthermore, the systems architectures should be open in principle and thus be compatible for updates/upgrades even for such that have not been known when they were developed (robust architectures)
The methods and tools of model-based systems engineering (MBSE) can add value. To work, the agile approach needs a model-based development environment to a special degree to be able to verify and integrate products, test results, releases, etc.
- (a)
The agile approach offers excellent opportunities for the development of so-called “minimal viable products.” This means the development of new products, with only a few features. But these products are improved and further developed step by step with the help of market and client feedback. It is important to consider that the products do not behave like prototypes that are not working very well. On the contrary, they have to work smoothly and reliably and have to deliver a customer benefit that makes themselves viable.
- (b)
An important cause of longlasting developments can be seen in existing contractual situations: if clients (OEMs) insist on binding contracts, based on detailed requirement specifications and fixed price agreements, the supplier has no other choice than to plan in a very detailed mode to avoid risk and contractual penalty.
- (c)
A more efficient approach would be to be limited to a rather vague agreement at the beginning and to specify a trust-based cooperation.32 This would probably be experienced positively from both sides: the clients and the suppliers. However, trust cannot be ordered but has to be earned by excellent professional skills, respectful interactions, resulting in a pleasant and esteemed cooperation, and this has to happen simultaneously at different levels of hierarchies and different functional areas.
In the field of systems engineering methodology in combination with agile approaches,33 there is certainly a need for future research, which can only be done in an interactive collaboration with practice partners.
Finally, an Interesting and Amusing Comparison (Offered by P. Kruchten)
The agile teenager: the agile movement is in some ways a bit like a teenager: very self-conscious, constantly checking its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times being cocky and arrogant.34 But there is no doubt that it will mature further, become more open to the outside world, more reflective, and also therefore more effective.
2.4 Summary and Rounding Off
Summary
- 1.The systems engineering process model is a broadly applicable taxonomy/systematic that consists of four components that can be combined with one another in a modular fashion:
From the general to the detailed
Principle of variant creation
Phase approach (project phases model)
PSC
- 2.The process principle “from the general to the detail” is intended to express that
The field of view must be first grasped and then gradually narrowed down
First general goals and a general solution framework should be established, whose degree of detailing and concretization is deepened in stages.
- 3.
The principle of variant creation is intended to indicate that in principle, one should not be satisfied with the very first solution, but rather must always think in variants or alternatives. This is especially important in the early phases of a project.
- 4.
The phase model (project phases) concretizes and complements the three general considerations. In combination with the principle “from the general to the detailed,” it represents a type of macro-strategy and should stimulate a stepwise planning, decision, and realization process with predefined reflection pauses and points for decision-making and adjustments. It should not be regarded as a means of describing the chronicle of the development and realization of a solution. Instead, it should be a planning instrument that first directs attention to the results that should or must be achieved at the end of the various phases. This can give rise to a series of activities that must also carried be out. Because of the explicit challenge of involving the decision-makers in the transitions of the individual development phases, the project phase model can also be marked as a management-oriented component of the process model.
- 5.The PSC should be understood to be a micro-strategy that complements the macro-strategy described above.
It consists of the sequence objective identification or formulation of objectives (situation analysis and goal formulation), solution search (solution synthesis and analysis), and selection (evaluation and decision).
It should be applicable to all problems regardless of what type they are and in which phase of the project they arise – even though with a different weighting of the steps.
- 6.
The phase model and the PSC are seen as essential components of the systems engineering process model that are conceptually separable from one another. Therefore, no new or more structured sequence of steps is extrapolated from it (as with the SIMILAR process, the value analysis working plan, the VDI guideline 2221, etc.). The situational combination of the building blocks tailored to the specific application.
- 7.
The user is thus free and even expressly advised to select from these building blocks the components that are best suited to his or her planning situation and to modify them as needed. The change (expansion or reduction) in the number of phases can thus be just as meaningful as an overlapping treatment or conceptual anticipation or fallback and repetition cycles. However, the basic logic of the considerations should be retained and remain recognizable.
- 8.
The individual components of the process model can also be found elsewhere in a similar form: nearly all project-oriented process models provide a phased procedure. Those models focusing on the theory of management decisions exhibit process steps that are similar to those in the PSC. The combination of the two is original and characteristic of the systems engineering concept.
- 9.
Of the other process models belonging to the plan-driven models category, engineering design methodology according to VDI 2221, the ideals concept, the prototyping concept, the versions concept, and the concept of what is known as simultaneous engineering, are presented here.
- 10.The agile methods should be regarded as alternative approaches to the plan-driven methods. We have addressed the represented mindset in the following way:
Plan-driven and agile are not to be taken as opposites between which battles of opinions should be fought out. For under certain application conditions, both of them have their justifications. These we have presented.
The systems engineering process concept, when not dogmatically used, as we have already stated, does indeed contain starting points for agility.
In addition, motivation can be taken from the various agile methods to further increase the agility of the systems engineering process concept as needed.
Agile process models will gain more importance in the future as they are driven by the technology and market dynamics
In our view, there are several components of the systems engineering process model that are valid for the future: (a) the top–down approach, (b) the variant creation principle, and (c) the PSC. The largest change may happen in the phase model: the phases will be replaced by sprints (length 1–4 weeks) or they will continue to exist in the form of hybrid models (see Sect. 4.7).
This development not only affects the methodology but also the way of thinking and the mindsets of the developing teams and their clients. Here, a process of learning and “getting used to” is unavoidable with intensive training in new thinking.
Rounding Off
We are convinced that the systems engineering process concept can serve as a viable basis for designing a problem-oriented process. It offers an extensive framework for changes or simplifications – without having to challenge its basic statements.
In the interests of a thoroughly critical reduction, a few principles for usage should be drafted in conclusion.
Is not for its own sake, but rather must serve the development of good solutions (the methodology should not beat problems and ideas to death)
Does not mean recipes that are simply to be followed, but is rather a guideline to be used creatively and intelligently
Is no substitute for talent, natural abilities, familiarity with situations, technical knowledge, involvement with the specific situation, ability to work as a team, and so forth, but rather requires these features or should guide them to a certain extent.
Thus produces merely a formal framework whose useful application results only from the intellectual and character potential involved,
Should align the required effort to the expected benefit.
In any case, systems and solutions are made or changed by people for people. This statement should be taken as a reminder for both the design of solutions and for every process intended to produce these results.
Note: application-oriented interpretations and more detailed presentation of individual components, steps, and interdependencies of the process model are to be found in Parts III (System Design), IV (Case Studies), and V (Systems Engineering in Practical Experience).
2.5 Self-Check of Knowledge and Understanding: The Process Model
- 1.
Describe the role of the process model in the systems engineering concept.
- 2.
What are the four components (basic principles) of the systems engineering process model?
- 3.
What are the individual components focusing on?
- 4.
How are these components interconnected, related to each other? Are there any logical relationships between the components that show the modularity of the concept?
- 5.
What is the difference between the project phases and the life cycle phases? Does it make sense to see a difference?
- 6.
Is it necessary to pass all project phases?
- 7.
The term “analysis” is embodied twice in the PSC. What is meant in each case?
- 8.
What is the difference between the steps analysis and evaluation of solutions?
- 9.
What is the difference between actual-state-oriented and desired-state-oriented process models? How or where would you position the Hall/BWI process model?
- 10.
What role does the client play in the PSC?
- 11.
What is meant by the “waterfall model”? To which component of the systems engineering process model does it relate?
- 12.
What is meant by the term “V-Model”? What are its characteristics?
- 13.
What is the “prototyping approach”?
- 14.
What does the term “simultaneous (concurrent) engineering” denote?
- 15.
What are the characteristics of the so=called “Agile Process Models”? Give some important examples of that category.
- 16.
What do you think is better: agile models or plan-driven models?
- 17.
Can you find some agile properties in our systems engineering model in spite of its primarily plan-driven character?
- 18.
What is the basic idea of the real options approach?
- 19.
What kind of risk considerations would you cite as examples?
- 20.
What are the consequences of the increasing use of agile methods for the systems engineering concept? Which modules will continue to apply and which one will be most affected?