4 Towards a Structured Market Engineering
4.2 A Design Process Roadmap for Market Engineering
4.2.2 Design Process Models
4.2.2.1 Descriptive Design Process Models
Principally, the number of various design process models that have been covered in literature is simply huge. In many times these deviations between the single models are very small. This stems from the fact that there is an inherent order concerning the sequences of activities. For example, any design task starts with a problem definition. Then, a possible design description is identified, which is subsequently evaluated. Deviations occur mainly in the process of re-vising a previous design description or the design requirements (Maher 1990).
One central characteristic concerns the definition of the process either structured along activi-ties or abstract phases (Tate and Nordlund 1996). This characteristic can be used to distin-guish the design process models into two categories: activity-based models and phase models.
4.2.2.1.1 Activity-Based Models
One popular view in literature assumes that the design process can be decomposed into three sub-activities, each represented by a step (Grant 1979; Tate and Nordlund 1996). Figure 16 illustrates activity-based design process in more detail. In essence the stylized process model matches the version that was introduced by Asimov, who divided the design process into three steps analysis, synthesis, and evaluation (Asimov 1962).
Needs and Desires Informal Requirements Analysis
Formal Requirements Synthesis Candidate Solutions
Evaluation Final Solution
Figure 16: Cyclical Analysis-Synthesis-Evaluation Model
Analysis
The inputs of the design process are the needs and desires and the informal requirements con-cerning the solution, i.e. what features must the solution satisfy, and which are the disturbing features? Step 1 comprises an analytical task, which identifies the problem class. In other words, the design problem is analyzed and transformed into operational, formal requirements.
Synthesis
Step 2 comprises the original synthetic problem of constructing the solutions. In particular, step 2 always involves creativity concerning the generation of candidate solutions. As the set of candidate solutions can become extremely large or even infinite, the generation of all feasi-ble solutions may in many cases not be attainafeasi-ble. Thus, in order to solve synthetic profeasi-blems the use of further domain150 knowledge, e.g. precedent cases in a specific domain, can delimit the design space. In other words, domain knowledge imposes structure on the design problem and can hence help to simplify the synthesis in two ways. Firstly, it may allow the generation of a restricted set of candidate solutions, which excludes infeasible or unpleasant solutions.
Secondly, domain knowledge may simplify the control of the search through the large design space.151
150 A domain denotes some area of interest. Example domains are chemical processes or securities trading.
151 One could argue that in case of extremely well structured problems there are methods that simply com-pute the solution without the use of any search. However, here the view of Chandrasekaran is supported, who regards such methods as degenerated cases of search, where at every point of the design process sufficient knowledge is available to make the correct decisions (Chandrasekaran 1990). From an imple-mentation point of view there is of course a distinction between those methods and search.
Evaluation
Finally in step 3, the decision concerning the final solution is made. This decision is guided by the appraisal of the candidate solution against the requirements.
Any activity-based model necessarily comprises these three core activities that are iterated.
Due to these predominant activities, the activity-based process models are frequently dubbed analysis-synthesis-evaluation model (Maher 1990).
The activity-based sequencing of the activities is rather intuitive. Design process models are, however, also intended to provide tools or design methods that can support the designer in performing the activities. As such, the design process model ideally suggests for any activity a design method or a tool, e.g. configuration method, parametric design, etc (Kusiak and Wang 1993; Motta and Zdrahal 1996; Wielinga and Schreiber 1997).
Example 4.2-1: Design Process Model and Problem-Solving Methods
The integration between design process model and (design) problem-solving methods is exemplary depicted according to the generate-activity (synthesis step). This step is se-lected because designers often make use of ad-hoc methods in a trial and error way. Al-though it is indisputably easier to select from a set of inadequate candidate solutions, the real challenge of design lies in the creation of better solutions. “There should be a shift […] in our approach to problems – a shift from searching for the best way between unsat-isfactory answers to searching for a better answer” (Nadler 1967, 644). Hence, a discur-sive method that supports this task may contribute to improvement along the design proc-ess.
Chandrasekaran distinguishes three groups of proposal methods for generating restricted design spaces by the use of domain knowledge: (1) decomposition (2) case retrieval (3) requirement152 satisfaction (Chandrasekaran 1990). The complexity of the design process can be tremendously reduced, if the creative process of generating the design space (step 2) is simply replaced by one of the three proposal methods.
• Decomposition
In this case domain knowledge is used to map the problem or parts of it into several sub-problems that are treated as a separate design task. The corresponding solutions are subse-quently recomposed into a solution for the original design problem. The re-composition can be aggravated by the complexity of the problem. Consider the following scenario: two solutions of sub-problems are connected in the final solution for the design. In order to connect them, certain pre-conditions and post-conditions might need satisfied. These con-ditions may a-priori not be available. In those cases the recomposed solution must be checked whether it satisfies these newly introduced conditions.
Another issue concerns the order in which the sub-problems are in a given decomposition attacked. The primary determinant of the order pertains to knowledge about the dependen-cies among the sub-problem. If the sub-problems are totally independent, a sequential ap-proach appears to be possible (Chandrasekaran 1990; Maher 1990; Kusiak and Wang 1993).
• Case retrieval
Case retrieval refers to case-based reasoning in design. It involves the solution generation by using already-completed solutions from previous design problems as a basis. The
152 In artificial intelligence frequently the difference between requirements and constraints is emphasized.
As this discussion is of more theoretical nature, this book uses the term requirements only.
sign strategy simply suggests choosing a solution to already solved design problem that resembles the current design problem most. The primary problem of case retrieval marks – no wonder – the matching of the problems: which already-completed solution is the closest to the current problem?
Apparently, case-based reasoning has a lot in common with analogical reasoning. Ana-logical reasoning, i.e. finding the appropriate related cases, “is at the heart of design crea-tivity” (Chandrasekaran 1990, 65).
• Requirement satisfaction
Requirement satisfaction suggests an approach to design in which the initial set of re-quirements is mapped into a solution. That means the solution is located in the space de-termined by several requirements; computational algorithms, such as linear, integer or dy-namic programming techniques, can detect this space.
4.2.2.1.2 Phase-Based Models
Phase-based models assume a top-down hierarchical approach to design processes. The core problems are firstly treated on an abstract, high level. Then, the solutions of a previous phase are progressively refined to more detailed solutions until the final solution is reached. As such, the approach can be characterized as coming from the abstract to the detailed design.
Principally, any phase constitutes in turn a design process, which can be represented by the analysis-synthesis-evaluation process. The difference lies in the different level of abstraction, which increases as the design process progresses until the detailed final document is reached (Pahl and Beitz 1984; Hubka and Eder 1988; MacPherson, Kelly et al. 1993). Though indi-vidual models may differ, phase models are usually divided into four parts (Eder 1998).
Planning and clarifying the task
The product idea that is to be designed is specified as requirements and constraints.
Conceptual Design
The design problem is abstracted and decomposed. For any sub-problem an abstract solution is produced, which are integrated into a concept. The concept is evaluated in terms of eco-nomic and technical criteria.
Embodiment Design
The concept of the product is elaborated in the form of a preliminary layout. As such, em-bodiment design bridges the gap between the abstract concept and the detailed solution.
Detail Design
In the last phase all details of the solution must be generated. Also the final economic and technical feasibility of the solution can be re-checked. Furthermore, all necessary production documents are finalized.
When the design process is strictly linear, a clear border between the phases can be drawn.
However, iterations are most likely and accordingly blurring away those clear borders.
4.2.2.1.3 Comparison
Activity-based and phase-based models typically characterize state-of-the-art design process models. But what model type appears to be superior? Which one to take? These questions can be answered referring to the list of criteria Tate and Nordlund compiled (Tate and Nordlund 1996). Basically, the criteria specify desired characteristics any useful design process must explain or predict, or allow for explanation or prediction (Tate and Nordlund 1996). The de-siderata comprise the following key characteristics
Desiderata Description
Decision Making The general purpose of a design process is to achieve a decision concerning a solu-tion that solves a design problem. As such, the design process requires clear decision points and criteria.
Performance Measures The performance of a design process is evaluated in terms of the used resources time and costs along the design process.
Iteration Typically, the design process must allow for iterations. When a failure occurs, the designer must have the possibility to fall back to a precedent activity. As such, simi-lar activities may be performed at different times.
Sequence of Activities The design process must also explain or predict the sequencing of activities. The activities can thereby sequenced in different ways in order to allow for flexibility in the design process.
Levels of Scope and Abstraction The design process model is usually concerned with problems “on multiple levels”.
As such, the design process model must cope with problems that have either a dif-ferent impact on the overall design (i.e. some problems have a greater impact on the design than others) or a different level of abstraction.
Information management Information about the design object is generated and collected and forms the basis for subsequent decision-making. This information can furthermore be stored for subsequent related design problems.
Table 5: Desiderata for Design Process Models
Embattled with those criteria the weaknesses and strengths of the two types of models can be analyzed (Tate and Nordlund 1996; Tate 1999).
Activity-based models
The greatest strength of the activity-based models is the emphasis of decision-making. In the evaluation step, the candidate solutions are assessed concerning their match with the require-ments. As the steps of the design process model are clearly defined, it is principally possible to measure the performance of the single design steps in terms of used resources and the time.
Although some activity-based models explicitly incorporate iterations of activities (cf. Gero 1998), activity-based models usually recommend repeated iterations of all three activities (Tate 1999). This also implies that activity-based models cannot cope with iterations of the same activity, which may be necessary when the problem is on multiple levels (Tate 1999).
As such, activity-based models lack flexibility in sequencing the activities. Lastly, the process yields information in the form of factor lists, or partial and combined solutions.
Comprising, activity-based models are especially strong in supporting the decision, which candidate solution is selected. Their weakness concerns the flexibility of sequencing the ac-tivities. Suppose the design problem is complex and the design object consists of many parts.
Then, the activity-based model suggests designing one part at a time. As one part affects the design of another, backtracking must be possible. However, the activity-based models only allow iterations after the evaluation. Apparently, activity-based models are vulnerable to complex design problems.
Phase-based models
The greatest strength of the phase-based models concerns the information that is produced along the design process. Firstly, information about the design object is available in its gression from the abstract to the detailed. Secondly, the amount of information that is pro-duced increases with the progression of the design process. Another great strength of phase-models is that the solution generation during the conceptual design phase is decoupled from specific solution details. As such, the understanding of the design problem is moved to the very beginning of the design process.
As the understanding of the design problem is emphasized, phase-based models are especially useful for complex design problems. The complex design problem is firstly abstracted and
conceptually solved. It is thus independent of design details that exert a good deal of the de-sign complexity.
Opposing Tate’s opinion, the phases of the model are clearly bordered (Tate 1999). Any phase ends with a decision concerning either the concept, or the preliminary or the definitive layout (Pahl and Beitz 1984). Those boundaries are, however, blurred if iterations occur.
Nonetheless, it is possible evaluate the performance of the single phases in terms of resources and time.
The greatest weakness of phase-models concerns – as aforementioned – iterations. When the designer is forced to reiterate a phase, the subsequent detail information must be revisited. As such, iterations are highly undesirable. However, empirical studies have shown that the design process is characterized by zigzagging making the process highly iterative. Prescribing a phase model is thus often criticized to be of inferior value, as the designers anyway do not use such methodology, as it hinders creativity.
Conclusion
Having stated the pros and cons of the two types of design process models, it becomes appar-ent that neither model satisfies all desiderata. On the one hand, activity-based models are sus-pected to be vulnerable to complex design. On the other hand, phase models are too idealistic (no iterations) to trace the progression of design. The conclusion to dismiss design process models as inadequate since the designers will not exactly stick to the process is certainly over-sized. Design process models seek to structure the design process and can thus only work as a general guide – the exact procedure will vary from project to project. Nonetheless these mod-els do provide general guidance, which is more effective than ad-hoc or intuitive methods. As market engineering is an inherently complex design task, it is referred to phase-based models.