Process Models in Design and Development

Read this article. It provides an overview of planning models. Pay particular attention to Figure 1 as it visually provides a global view of planning models. Then review Figures 2 -17 for more in-depth visual planning processes.

Micro-level models

Micro-level procedural models

Micro-level procedural models provide prescriptive guidelines for the design and problem-solving activity which occurs at many points throughout a project. There are four main groups of model in this category.

First, on the most conceptual level, certain overall strategies for design are recommended by many authors. Foremost is the idea that designers should proceed systematically and resist their preconceptions. Evbuomwan et al. review the early work incorporating this recommendation, including Marples, Jones, and Archer. They find that all these authors prescribe the three main steps of analysis, synthesis, and evaluation. Analysis involves focusing on a problem and structuring it into a set of objectives. Synthesis involves generation of a range of candidate solutions. Evaluation involves the critical appraisal of those solutions against the objectives, to rationally select between them and/or to drive iterative improvement. Models incorporating this strategy have often been described as problem oriented. They are based on the premise that designers can formulate solution-neutral problem statements, and that doing so is useful to direct their creative insights with systematic reasoning. Another common recommendation is to begin by deliberately expanding the perceived boundaries of a problem, e.g., by relaxing constraints, attempting to reframe the problem, or attempting to perceive it on a higher level of abstraction. This may help to avoid artificial overconstraint and ensure that a broad range of potential solutions is considered. A third common strategy is to decompose a problem into simpler subproblems with well-defined interactions as early as possible, such that the subproblems can be addressed individually prior to recombining solutions (Fig. 3). This is thought to encourage "the discipline to proceed systematically" and enable "rationally organised division of labour". Overall, the design strategies discussed in this paragraph are desirable but might not provide much practical guidance for implementation. For this reason, they are often embedded in more concrete procedural models, many of which are reviewed elsewhere in this article.

Fig. 3

Method of structuring problems and systems.

The second group of models in this category comprises more concrete systematic methods that support the execution of specific design steps. Examples include approaches to promote creativity such as C-Sketch; use of morphological matrices to search for possible combinations of working principles; and decision methods such as the analytic hierarchy process (AHP) and the controlled convergence method. Axiomatic Design recommends a process of zig-zagging through a hierarchy of functional requirements (FRs) and design parameters (DPs) while striving to satisfy design rules derived from two axioms - presented as "fundamental truths" about the characteristics of good designs. TRIZ/ARIZ offers methods to support innovation by identifying and resolving contradictions in a design situation.

Such systematic methods (and there are many more) may be useful at many points in a DDP. Pugh describes them as "the designer's tool-kit" which allows discipline-specific engineering knowledge to be applied efficiently and effectively. Hubka expresses a commonly held view by recommending systematic procedures when searching for concepts to cover a wider search space. He also suggests that a systematic approach can be particularly beneficial in all review and revision activities. Archer proposes that systematic approaches are particularly useful under one or more of three conditions: when mistakes can have significant consequences; when the likelihood of making mistakes is high, for example due to inexperience; and/or when the situation is complex, characterised by many interacting variables.

A third group of models recommend procedures for solving problems encountered during a DDP. The archetypical procedural model of problem-solving is the Shewhart Plan–Do–Check–Act (PDCA) cycle, which dates from 1939. The PDCA cycle recommends an iterative process in which thorough up-front analysis of the problem (Plan) and solution implementation (Do) are followed by seeking feedback (Check) and adjustment of the solution (Act). This iterative feedback process may help to obtain robust and validated solutions. It is thought to be especially useful where the problems being solved are ill-defined, complex enough that they cannot be easily grasped, are set in a changing context, and/or in a context where the solution can influence the nature of the problem. Related to PDCA, more recent problem-solving models such as Define–Model–Analyse–Improve–Control (DMAIC), Look–Ask–Model–Discuss–Act (LAMDA), A3 Problem-Solving, and Kepner–Tregoe methodology also often appear in DDP practice, and include similar iterative elements. For further discussion and review of prescriptive problem-solving models in the DDP context, the reader is referred to Mohd Saad et al..

The fourth and final group of micro-level procedural models concern negotiation protocols for design. The issue addressed by these models is that different stakeholders in a design problem are usually responsible for different variables and objectives, some of which will be in conflict. Negotiation protocols or methodologies prescribe processes for interaction between human and/or computational stakeholders, to assist them in reaching a mutually satisfactory outcome without excessive iteration.