The Evaluation algorithm

As mentioned above, the change impact is evaluated by four criteria, namely the functionality, development time, development cost, and development risk. With help of general knowledge base for engineering products, designers can find knowledge regarding development time, development cost and development risk of pre-change components and after-change components. The formula below is used to calculate a measure for how much impact (CI) a design change would cause.

∑ { ( ( ) ( ) ( ))} ∑ { _{( )}} (4.9)

This formula takes all the four criteria into consideration. Parameters in this formula are explained as follows:

-92-

Integer [ ] indicates all the components being changed that are caused directly or indirectly (propagated) by the initial change.

Integer [ ] indicates the functions that have been directly or indirectly influenced by the initial change.

wcj represents the relative importance of a component Cj

wfi represents the relative importance of a function Fi

Tj represents the developing time of the pre-change component Cj

Tj’ represent the developing time of the after-change component Cj’

CTj represents the developing cost of the pre-change component Cj

CTj’ represents the developing cost of the after-change component Cj’

Rj represents the developing risk of the pre-change component Cj.

Rj’ represents the developing risk of the after-change component Cj’

α, β, γ represent coefficients of developing time, developing cost and developing risk,

where . Values of are determined by designers according to the project aims. For example, if the project is time sensitive then α will be assigned a relatively larger value; if the project is cost sensitive then β will be assigned a relatively large value; or if the quality of the product is critical then γ will be assigned a larger value.

Relative importance of an entity can be acquired by comparing with entities within the same domain at the same level of detail. The relative importance of a function f in the functional requirement domain can expressed as wf (f). It is calculated by comparing

-93-

other functions at the same level of detail, in terms of their contributions to the product functionality by using AHP (Analytical Hierarchy Process) method (Saaty, 1988). The relative importance of a component c in the physical structure domain can be expressed as wc(c). Differing from functional importance, relative importance of a component is obtained by its contributions to related functions (expressed as wcf (c, f)) and importance of related functions. For example, C1 in Figure 4-5 is involved in both

F2 and F3, then

( ) ∑ { ( ) ( )} (4.10)

wcf (c, f) is also evaluated by AHP method by comparing the contributions of different

components to a function.

In equation 4.10, F and F’ represent ranges of functional specifications. Each function has some outputs, and these outputs have target values or ranges which are determined during the translation from customer requirements to functional requirements by designers. When components have been changed because of the propagation of the initial change, they would possibly change the outputs of the function whose realisation involves these components. Thus, it is important to examine the actual functional outputs against the original functional specifications, which is expressed as Functional Inconsistency (FI) to indicate how different the functional outputs are from the target functional outputs. ( ) can be represented as the following formula:

( ) { (4.11)

Therefore, if the actual functional outputs range is outside of the range of the functional specification, the change impact , which means that change is not successful. Designers either need to continue the physical structure change or adjust the functional requirements.

-94-

4.7 Summary

Based on the literature review and industrial investigations, it has been found that there is a lack of support for engineering change management in the design phase of product development. The methodology of design change management is intended to facilitate four business objectives of product development projects, i.e., efficiency of development, quality of product, cost of development, and knowledge reuse. The implementation of this methodology can be summarised in three stages. In the first stage, modelling methods have been used to clarify the dependency and relationships between elements of design (including functional requirements and physical components) and analyse design propagations. In the second stage, design knowledge has been used to resolve design conflicts emerging from analysis of change propagation. In the last stage, a method has been proposed to evaluate design change solutions by considering four factors of project success.

There are four types of models employed which include functional dependency model, physical interaction model, CAD model and the composite matrix model. The functional dependency model employs SysMLTM block definition diagram to capture functional requirements and their relationships. The physical interaction model employs the SysMLTM activity diagram to capture behavioural interactions between physical components. The CAD model is used to display the spatial relationships between physical components, which is however not an emphasis in this research. The composite matrix model synthesises information from the other three types of models. It is used to trace change propagation caused by the initial change either from the functional domain or from the physical domain of product design. The process regarding how to use the matrix to trace design propagations has been described in association with an example from industry.

It is also argued in this chapter that change propagation in design change is essentially caused by design conflicts. The reason why a change passes to another one is because the implementation of the first change causes harms or obstructs the functionality of

-95-

some part of the system. That means that part of the system also needs to change in order to get it fixed. Using these generated models, change propagations arising from the initial change can be traced and design conflicts emerging from analysis of change propagations can be identified.

The idea of design change analysis and change propagation tracing remains an important unanswered question which is how to solve design conflicts arising from change propagation analysis. A TRIZ-inspired and knowledge based method has been proposed to formalise design conflicts and reusing knowledge captured from previous design cases to obtain the most semantically similar solutions as reference solutions for target design conflicts.

In order to find solutions for design conflicts in a general approach rather than a keywords-based searching approach, the TRIZ-aspired method firstly identifies key elements of a design conflict and then uses functional and component ontology to semantically formalise the design conflict. By doing this, every element of a design conflict can find a position for itself in predefined ontology.

Using the same predefined ontology, design cases from previous engineering activities can be also formalised to store in the knowledge repository which make key elements of a solution have semantic meanings and in turn these semantic meanings are associated with certain solutions. Therefore, when some elements of a design conflict find semantically similar elements in the knowledge repository, similar or potential solutions can be retrieved.

The reasoning mechanism is used to find and compare semantic similarities between elements of a design conflict and elements of solutions from design cases. By exploring the knowledge repository, the reasoning mechanism can find similar generalised design cases for target design conflict. An algorithm is used to calculate overall similarity between a design conflict and design cases.

The evaluation algorithm is proposed to find out which solution selected from the reasoning mechanism is the optimum in terms of success of a project. Technical

-96-

success in many cases does not lead to success of a project, since engineers need to consider more beyond purely technical viability. They also need to consider the timeline of the project, budget for the project set by the top management and risks of solutions in the product life cycle. Thus these three aspects (development time, development cost and development risk) plus functionality consistence are used in the proposed algorithm to evaluate potential solutions. The functionality consistence represents how much the potential solution can fulfil target functions of the design. Apart from the functionality consistence, information of developing time, developing cost and developing risk need to be obtained from other enterprise systems. Therefore, system integrations are practically necessary for the evaluation method

-97-