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 analytical models

Micro-level analytical models provide formalisms to assist in the modelling of design knowledge from a process perspective. They represent individual process steps and decisions, indicating how they relate to specific features of the design context. The contextual information is thought to provide "guidance to reapply knowledge at the most appropriate time".

An early approach called PROSUS uses a matrix system for knowledge modelling during the design process. The matrix columns are defined by three micro-level activities, namely generate, evaluate, and select. The rows denote the problem, requirements, functions, concept, and the detail design. As the designer proceeds through iterative cycles, they are intended to capture their knowledge regarding proposals, arguments, and decisions within the appropriate cells of a PROSUS matrix. It is proposed that a different matrix should be used for each design situation encountered. A subsequent approach called the design history system (DHS) represents technical knowledge relevant to a design in terms of the processes and decisions that generated it. DHS represents: design steps; product data such as assembly relations and geometry, including successive versions and configurations; the relationships between design steps and product data they operate on; and the rationale underlying decisions. Emphasis is placed on intelligent querying of the history to help designers understand and reuse past designs. Addressing similar issues, the engineering history base (EHB) of Taura and Kubota allows designers to model the rationale behind design attributes in two ways: their relationships to design goals; and the need to work within constraints created by the previous decision-making activities. A prototype software tool allows the reasoning behind a particular attribute to be traced through the process. Both these papers focus on defining classes and relations to structure knowledge databases, and propose form-oriented interfaces. The Decision Rationale Editor (DREd) 2.0 tool reported by Aurisicchio and Bracewell instead uses a less formal graphical network representation building on the gIBIS approach, which allows designers to model the rationale structure supporting each process step or decision. Deployment and acceptance in an industry context were achieved.

Other models focus on representing micro-level process knowledge with the specific objective of guiding a designer from one step to the next. For example, Signposting was developed to support rotor blade design by guiding the designer towards tasks that are available and appropriate for each design context that is reached. The unique feature of this approach is the notion that designer confidence is an important factor driving task selection. In Signposting, a task is considered available if the designer indicates that their confidence in its input parameters meets specified thresholds, and appropriate if completing the task is expected to increase confidence in one or more parameters. In this context, high confidence in a parameter means that its value is detailed, accurate, robust, well understood, and physically realistic. In a prototype implementation, the designer indicates their confidence in each design parameter, and the tool proposes tasks that are available and appropriate to attempt next. The manufacturing integration and design automation system (MIDAS) also aims to dynamically guide the designer through the design process, in this case using a hierarchical grammar-based model. In MIDAS, a design process is initially represented as a flow of logical tasks including inputs and outputs. This expresses what needs to be done on a high level of abstraction. As the process is executed, a database of production rules is consulted to detail logical tasks as they are encountered, replacing them on-the-fly with more detailed process flows. These can comprise more concrete logical tasks and/or atomic tasks, which encapsulate a specific approach for completing a step. Each production rule represents a possible strategy for approaching the logical task that it replaces. MIDAS includes a way to roll back the process instantiation and prompt the designer to try another strategy, which is needed when design data produced by a task do not satisfy constraints.

Finally, a third group of analytical models on the micro-level concern coordination support. For example, the agent-based decision network (ADN) of Danesh and Jin manages the process of decision-making and negotiation of solutions among agents, embedding models of a design problem alongside normative procedural models of the negotiation process, such as those mentioned in the previous subsection.