Process Models in Design and Development

Domain-integrating task network models

Domain-integrating task network models explicitly integrate process models capturing an end-to-end flow of tasks with detailed information about other domains such as the product being designed. Eckert et al. argue that such models could be useful to guide trade-offs between design characteristics and process performance. For example, they might help to decide whether design changes should be accepted during a project, considering whether the design improvements would justify the additional time and effort in the development process.

Recently a lot of attention has been paid to domain-mapping matrices (DMMs) and multiple-domain matrices (MDMs). These are extensions to the DSM which allow modelling of linkages between different types of element. Danilovic and Browning discuss application of DMMs to explore connectivity between the process domains of tasks, components, and teams. By analysing the domains independently and in combination, it is possible to identify mismatching structures. For example, a team structure which does not reflect the decomposition of tasks in the process may contribute to communication overhead or rework. Sosa et al. discusses how such structures can be identified using a DMM approach, and how this can be used to focus coordination effort on the interactions which are likely to drive design change and iterations. A key aspect of MDM methodology is the use of filter operations to derive indirect dependencies, for example, computing an implied Task DSM from an MDM showing the tasks' inputs and outputs. Another element is using graph-theoretic metrics such as betweenness centrality and cycle count to develop insights about the importance of nodes and patterns in the network. Lindemann et al. and Kreimeyer and Lindemann define a standard set of domains (e.g., subsystems, tasks, resources, etc) which can be modelled in a development project and a set of metrics and filters for analysing models thus constructed.

Object-process methodology (OPM) provides an integrated representation of processes and objects using a formal graphical notation or equivalent formally structured sentences. A model constructed using OPM comprises a hierarchically organised set of object-process diagrams (OPDs) that represent both processes and their related objects. Several types of structural link allow the modeller to connect diagram elements within the process domain or within the object domain, while several types of procedural link can be used to connect elements across these two domains. OPM is a general-purpose methodology that has been applied in different contexts. Of particular interest to this review, Sharon et al. consider how it can support planning and control of development projects, by clarifying how the project tasks (modelled as processes) are interrelated with the required resources and the hierarchy of deliverables (modelled as objects). In their approach, a project is decomposed into a hierarchy of tasks and deliverables, considered concurrently. The OPM representation is then analysed to generate summary views useful for project management. Sharon and Dori further develop this method, arguing that it could help to avoid mismatches and inconsistencies between the models and documents used to manage a project.

Other models integrating product and design process information have been developed with the specific objective to support resolution of conflicts among design parameters. For example, the DEPNET approach stipulates modelling a process as it unfolds, along with the design information associated with each task. The resulting trace constitutes a network of dependencies among information items, which can be used to assess the knock-on impact of design changes. A similar approach is taken in CoMoDe, an object-oriented model intended to maintain a trace of the model versions that are created and used at each step in a collaborative design process. CoMoDe represents a hierarchy of process activities and constituent operations; requirements; the actors who perform each activity; characteristics of the artefact as it is evolved; and decision rationale. Gonnet et al. describe how it can be applied to detect conflicts among models that exist simultaneously in the collaborative design process, according to the logic by which those models were generated. Overall, process-oriented conflict management seems a theoretical approach involving step-by-step capture of design history using rather complex representations. Although the potential is demonstrated by examples, the respective authors do not report evaluation of the proposed support tools in an industry context.

Focusing on coordination in major projects, Rouibah and Caskey develop an engineering work flow (EWF) approach based on identifying the engineering parameters whose values need to be determined - this can be partly constructed by reference to similar past projects. The parameters are linked into a network to represent their interdependencies, which can evolve during a project. Parameters are also linked to the responsible parties. During design, parameter values are iteratively developed through increasing "hardness grades”. Six steps are defined to transition between successive hardness grades, to ensure that the change is coordinated among impacted parties. This approach seems to have strong potential to support the coordination tasks to ensure consistency and transparency during a project. However, it does not describe the specific engineering tasks required to determine each parameter's value.

In comparison to the approaches reviewed in Sects. 4.2.1, 4.2.2, and 4.2.3, domain-integrating models more strongly emphasise how a DDP interacts with its context. While this potentially offers more insight, it also requires more information. Consequently, it may be difficult to create large-scale models in such approaches and ensure their consistency, as well as to visualise and understand the models once created. There are many other approaches in this category. For focused reviews of integrated models and further discussion of their advantages and limitations, the reader is referred to Eckert et al. and Heisig et al.