Capturing design rationale

Computer-Aided Design 41 (2009) 173–186

Contents lists available at ScienceDirect

Computer-Aided Design journal homepage: www.elsevier.com/locate/cad

Capturing design rationale Rob Bracewell a,∗ , Ken Wallace a , Michael Moss b , David Knott b a

Cambridge University, United Kingdom

b

Rolls–Royce plc, United Kingdom

article

info

Article history: Received 23 August 2006 Accepted 6 October 2008 Keywords: Aerospace design IBIS Knowledge representation Engineering knowledge management

a b s t r a c t The subject of this paper is the Design Rationale editor (DRed). This is a simple and unobtrusive software tool that allows engineering designers to record their rationale as the design proceeds. DRed is one of the latest of many derivatives of the venerable IBIS concept. Thus it allows the issues addressed, options considered, plus associated pro and con arguments, to be captured in the form of a directed graph of dependencies. The research was conducted in close collaboration with, deployed, and tested in a major multinational aerospace company. The paper describes the main features of the tool, by means of a real design example from the company. It then examines the methodology and process by which the tool was researched, implemented and introduced into industrial practice. Finally, DRed is compared with other IBIS-based software, to identify and explain how it addresses problems that seem to have made earlier tools unsuitable for routine use by designers. Simplicity seems to be a key factor for real world acceptance of such tools. © 2008 Elsevier Ltd. All rights reserved.

1. Introduction Industrial organisations are having to adapt to an increasingly competitive global economy. There is considerable pressure on them to improve their product development processes in order to deliver new, high-quality products and services to the market rapidly and cheaply. Many of the key decisions that influence the product to be produced and marketed are made during the conceptual phase of the engineering design process, so any improvements made to this phase have a considerable positive impact. Engineering design can be modelled as an information processing activity. Each step in the process involves members of design team identifying the information that defines a particular subproblem and then using their knowledge and skills, along with the available tools, to process that information into a state that defines the selected sub-solution. The final product definition is an appropriate combination of carefully selected sub-solutions. Engineering designers cannot retain all the information they need to solve complex design problems in their heads, so they must retrieve that information from external sources, including colleagues, documents, drawings, models and databases. The ability to retrieve and use information throughout the design process is therefore crucial to the

∗ Corresponding address: Engineering Design Centre, Department of Engineering, Trumpington Street, Cambridge, CB2 1PZ, United Kingdom. Tel.: +44 (0)1223 3 36246; fax: +44 (0)1223 3 32662. E-mail address: [email protected] (R. Bracewell). 0010-4485/$ – see front matter © 2008 Elsevier Ltd. All rights reserved. doi:10.1016/j.cad.2008.10.005

outcome. In order to be able to retrieve information from a source, that information must have been captured and stored — either formally in external repositories or informally in peoples’ memories. The process of retrieving information involves four steps: (1) establish need, (2) form query, (3) identify source, and (4) extract information. Observational studies by Marsh in the civil aerospace division of Rolls–Royce (RR) in 1996 produced the result that 90% of designers’ information queries in that company were answered by approaching another person and only 10% from external repositories, such as documents and drawings [1]. Similar studies by Aurisicchio in RR in 2003 showed that this figure had dropped to around 70% [2]. The reduction can be partly explained by significant improvements in IT in the intervening period. However, the message is clear: members of a design team still rely very heavily on being able to consult colleagues and experts. Marsh’s results also showed that when designers approached a colleague for information, on nearly 80% of these occasions the information was provided from that person’s memory. It is known that large amounts of information are never documented and are only stored in the heads of individuals [3]. This is not a great problem if those individuals are available to consult. In some ways modern mobile communication technology is making it easier to contact people wherever they are. However, increasingly transient industrial organisations along with greater personal mobility between organisations, means that those with the required expertise are not going to be so readily available to consult in the future — and consequently a very large source of information will no longer be available. Designers will increasingly have to rely

174

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

on retrieving information captured and stored independently of human memory. Research into the capture, storage and retrieval of information has been going on in the Cambridge Engineering Design Centre for over 20 years. A tangible outcome of this research is a software tool that assists designers to structure their design thinking, captures their rationale as they gain understanding of and solve design problems, and reduces the need for written reports. The tool is called the Design Rationale editor (DRed). DRed originated as research software, but has been developed into a tool that has gained widespread use in RR and is now part of their standard Product Lifecycle Management (PLM) toolset. DRed complements the analysis, CAD, office, web and communication applications that designers use to support their day-today activities. It facilitates the creation of a design folder, storing all the electronic information generated during a design project, which is structured according to the dependencies inherent in the design rationale. On completion of the project it can easily be published on-line for future reference within the company, either using a conventional document management system or a simple web server. This paper addresses the following research questions: (1) ‘‘How can design rationale be captured routinely in an industrial context?’’, ‘‘How can software tools for designers be researched, implemented then successfully introduced into industrial practice?’’ and (3) ‘‘What difficulties have limited the application of design rationale capture software and how can they be overcome?’’. Section 2 describes the background on design rationale capture. In Section 3, an answer to question (1) is provided by presenting the underlying concepts, major features and typical applications of DRed using a worked example from RR. Research question (2) is addressed in Sections 4 and 5. In Section 4 the methodological approach taken in the research, implementation, and evaluation of DRed is described. Section 5 describes the process of progressive industrial deployment of the tool, and identifying and justifying the perceived key factors in its success. Section 6 concerns research question (3), suggesting problems that may have limited the application of previous design rationale capture software, and arguing how these are solved in DRed. Finally, conclusions are drawn, ongoing and future work described. 2. Background on design rationale capture It has long been recognised that there is great potential for design rationale capture tools to improve the design process, if only they could fit naturally with the working methods of designers and not impede them. The field of design rationale capture was reviewed by Lee [4] and Szykman [5]. Lee listed the advantages that such a tool could offer. These include the provision of better support for redesign, reuse, maintenance, learning, documentation, collaboration, and management of projects. Research into capturing and mapping the rationale for complex decision spaces can be traced back over 35 years to the pioneering work of Kunz and Rittel [6], addressing ‘‘wicked’’ or ill-structured problems using a proposed Issue-Based Information System (IBIS). IBIS is a simple but powerful concept. It consists of a tree, or directed graph, where some nodes represent issues to be solved that are linked by arcs to other nodes that represent alternative solutions. These in turn are linked to nodes representing arguments for or against. Many derivatives of the basic IBIS concept have been proposed, such as gIBIS [7], PHI [8], QOC [9], ÉGIDE/ DRAMA [10], PROSUS [11], RObjects Pepper [12], Questmap [13], DRIFT [14] and IDIMS [15]. As can be judged from the large number of its derivatives, IBIS has strong intellectual appeal in the research community, which may be due to its combination of simplicity and expressive power. However, while IBIS-based rationale capture initially seemed a good

idea, it gradually became apparent that such tools were rarely able to successfully applied in industry. As a result, in the design research field at least, work on design rationale capture reduced significantly for a period. However, the use of IBIS did not die out entirely. The first graphical IBIS tool, gIBIS, was followed by direct descendants Questmap and Compendium [13]. While these were not generally found to be suitable for routine capture of the design rationale by individual designers, in the hands of skilled facilitators they were found to be highly effective for structuring and capturing discussions in real and virtual meetings. This facilitative skill became known as Dialogue Mapping [16], subsequently extended into the Conversational Modelling participatory analysis approach [17,18]. With appreciable developments in functionality, and free downloads, Compendium has gathered a sizeable user community, supported by an active website (http://www.compendiuminstitute.org). The SEURAT tool of Burge [19] demonstrated that IBIS rationale capture could be seamlessly integrated into a mainstream integrated development environment (IDE) used by software developers, and applied to aid software maintenance tasks. The Clockwork Project [20] has recently shown that a web-based approach to capturing design activities and rationale can be deployed and tested successfully in practical use in industry. If such research is able to overcome the capture bottleneck problem for design decisions and rationale, the result will be the creation of large design information databases. The NIST and UMR Design Repositories [21,22] are both prototype systems exploring how such a repositories should be structured. DRed was created by systematically analysing the shortcomings of previous IBIS tools for routine design rationale capture by individual designers. The following section describes its underlying concepts, major features and typical applications by means of a worked example. 3. Case study of design rationale capture using DRed The best way to describe the functionality and interface of DRed is to use the example of a real case study taken from RR. This illustrates the four main applications that DRed was initially used for, namely:

• • • •

Diagnosing a problem (problem understanding). Designing a solution (solution synthesis). Completing a standard checklist template. Communicating the final design and its rationale.

3.1. Introduction to case study One of the main products of RR is a range of turbofan engines to power civil airliners, see Fig. 1. Most of the thrust from such an engine comes from the fan at the front, which acts like a shrouded propeller. The fan is surrounded by a fancase that has a number of functions, including controlling the flow of air passing through the fan, providing a means of containing the fan blades should a failure occur, and supporting an internal acoustic liner to reduce the noise generated by the fan. The acoustic liner is the focus of the case study. Small sections of the covering material started to break away in flight. These caused no damage to the engine and created no safety concerns. These occurrences were, however, the subject of an in-service problem report, and a designer in the company was given the task of solving this problem. First the designer diagnosed the problem, and then designed a solution. The proposed design solution had to be assessed against the company’s standard design checklist and communicated to those attending the design review meeting. Finally it had to be released for implementation and recorded for future reference.

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

175

failure was due to brittleness of the adhesive at the very low temperatures ( − 50 ◦ C) experienced by the engines at cruising altitude. The selected solution involved two changes to the design: first the bonding area was increased by reducing the cell size of the honeycomb; and second the adhesive was replaced by one known to be tough and compliant at low temperatures. Unfortunately, when it came to the panels, the new honeycomb was found to be too stiff to form the required double curvature to fit inside the fancase. The problem was thus revisited and, as reported in the second DDR, the designer weighed the evidence and decided that the new adhesive alone was sufficient to solve the problem. The honeycomb cell size was therefore returned its original value. The design rationale for this case study has subsequently been stored using DRed and the following sections demonstrate the four main uses of DRed: diagnosing the problem; designing a solution; completing a standard checklist template; and communicating the final design and its rationale. Fig. 1. Cut away image of a turbofan engine showing the fancase.

3.3. DRed usage 1 — Diagnosing a problem 3.2. Details of the in-service problem The in-service problem involved the internal panels lining the fancase of a particular model of turbofan engine. These curved panels consist of a perforated aluminium skin, bonded to an aluminium honeycomb core. Their main function is to absorb noise from the fan, whilst being able to withstand the impact of ice shed from the spinner. There were several cases of small sections of the perforated skin becoming detached from the honeycomb core due to failure of the adhesive bond between the skin and the honeycomb, thus leaving small sections of the honeycomb exposed. The interior of the fancase is lined with six curved panels, with the gaps between them smoothed off with epoxy filler, which is protected from erosion by a glass fibre covering strap. The problem report stated that the affected panels were modified from the original design. For more recent engines, the modification was incorporated during production, but for engines already in service, the modification was reworked. The report also stated that the problem had not been seen in the reworked engines. The only difference between the two was that for reworked panels, a cold curing adhesive was used, whereas for the production panels hot curing was used. To diagnose the problem, the designer first consulted the design and service records for the engine. The obvious first thing to do was to retrieve the rationale for the modification of the panels. The company has a strong culture of capturing design knowledge and rationale where feasible, so when any modification is designed and implemented, the rationale for it is captured by writing a formal Design Definition Report (DDR) and assembling a Design Scheme Folder (DSF) of the documents, formal and informal, involved in the design. The records showed that since the original design of the engine, two DDRs had been issued regarding the acoustic panels. Both predated the use of DRed to capture design rationale in the company. Trying to piece together the full picture from the loosely arranged folders, ranging from formal reports and CAD drawings through to rough notes and sketches, was difficult and time consuming. In such cases, it is common to discuss the modifications with the designer who was responsible for them. However, as is increasingly the case, the designer had retired and was therefore no longer available to consult. Fortunately, the team leader who had approved the modifications was still with the company, and a faceto-face discussion with him clarified the position and provided many of the missing details. The first DDR addressed problems with the original adhesive, which was failing due to fatigue at both faces of the honeycomb. The diagnosis suggested that this

A designer naturally starts by forming theories about potential causes of the problem, and looking for evidence to support or refute them. DRed can be used to capture this diagnostic activity as it proceeds, and Fig. 2 shows the resulting chart with the diagnosis of the acoustic liner problem almost complete. The title of the chart is ‘‘Debonding Diagnosis’’, which is simply stored in a file ‘‘Debonding Diagnosis.dre’’ in the designer’s working folder. DRed charts are zoomable, scrollable, twodimensional surfaces of unlimited size. The chart in Fig. 2 follows good practice in limiting its extent, such that the whole chart can be printed at a readable scale. The first step in creating it was to place an element stating the top-level issue — in this case: ‘‘What causes are contributing to the debonding?’’ The element is signified as being an Issue by the coloured graphic question mark behind the text. All the elements in a DRed chart are given a ‘‘traffic light’’ status. When an Issue is first created, its status is Open and its colour is accordingly amber. Decisions are captured by manual changes of status, reflected in changes of colour to either green or red. Once the designer is satisfied that the diagnosis is complete and correct, he or she will record this by changing the status of the top-level Issue to Resolved, shown by the question mark turning green. Conversely, if an Issue has to be marked Insoluble, it is turned red. Any amber elements that appear on a chart provide clear prompts of what still needs to be addressed, thus DRed combines the functions of a notebook and a to-do list. While colour is used to make the rationale clearer to interpret on screen, it is important that the meaning is unambiguous if a chart is printed in monochrome; so a Resolved Issue is supplemented with a green tick, and an Insoluble Issue with a red cross. An important consideration in the design of DRed was that there should be no hidden information. Everything is displayed directly on the chart rather than requiring pop-up windows or dialogs. This is felt to greatly ease scanning, and means that comprehensive hard copy is available, identical to the representation on screen. delRey-Chamorro demonstrated that scanning was the information extraction strategy used by designers when they were exploring a topic and understanding the issues. These activities account for around one third of the time a designer spends on information retrieval [23], and are crucial during the conceptual design phase when many of the key decisions that affect the success of the product are made [24]. A designer’s various hypotheses are captured as Answer elements, e.g. ‘‘Engine vibration’’ in Fig. 2, linked to the top-level Issue. For successful resolution, an Issue depends on one or more of its Answers being Accepted. Such dependencies are shown by unidirectional arrows on the links. Arguments for or against an

176

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

Fig. 2. Diagnosing a problem.

Answer are captured as Pro and Con elements respectively. Like Issues, Answers are created by default with an Open status, coloured amber. They are changed to green or red as they are Accepted or Rejected. This can be seen in the elements ‘‘Thermally induced strain’’ (Accepted — green) and ‘‘Pressure loading from fan blades’’ (Rejected — red). The default status of both Pro and Con elements is that the argument Holds. If a single argument is felt to be particularly strong, the designer can show this by changing its status to Dominant, signified by the text being underlined. For example the argument against the Answer ‘‘Fancase flexure’’ being a cause has been declared to be Dominant and is underlined, resulting in this Answer being Rejected. The capture of decisions that have been rejected and the reasons for their rejection is crucial for an effective design rationale tool. The facility to link arguments to supporting evidence is equally important, and this is provided through the File reference element. In this case the dominant argument against ‘‘Fancase flexure’’ is supported by a file containing the results of a Finite Element (FE) structural analysis, see the bitmap graphic showing a thumbnail of the displaced shape in bottom left-hand corner of Fig. 2. When double clicked, the file is loaded into its parent application. The standard representation for a File element is a small icon representing the file type; see for example the.pdf file icon in the bottom righthand corner of Fig. 2. The default behaviour for links between elements is for them to terminate on an element border, pointing at its centre. The graphical File element displaying a photo of

the revealed honeycomb on the right-hand side of Fig. 2 shows another option, where individual link endpoints may be anchored to a specific location in an element. Here a Text element ‘‘Note clean detachment of skin’’ annotates the photograph with a link anchored to the point of interest. Pro and Con elements can exist in one further status, that is, where an argument Fails. An example of this is shown in the top right-hand corner of Fig. 2, indicated by the text being struck through and the graphic being greyed out. Very often arguments that are initially thought to be true are later realised to be fallacious, perhaps by a vital piece of new information coming to light. To avoid the same mistake being made in the future, the fallacy must be retained in the rationale but clearly marked as such. An example of great importance is the failing argument in favour of ‘‘thermally induced strain’’. This is based on the statement in the problem report that debonding did not occur when cold curing adhesive was used. This was later found to be untrue — the problem did still occur but the debonding was less obvious. Without considering this new piece of information, a solution might be implemented that would not work. The diagnosis is now complete and the designer can present a justified belief that the problem is primarily caused by cycles of ‘‘Thermally induced strain’’ in the low temperatures at high altitude, along with ‘‘Adhesive failure at elevated temperature’’ caused by insufficient glue strength at the high temperatures experienced on take-off.

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

177

3.4. DRed usage 2 — Designing a solution

3.5. DRed usage 3 — Completing a standard checklist template

The next step is to design a solution to the problem. Fig. 3 shows how this may be captured. The top-level issue is ‘‘How to stop the perforate skin debonding from the honeycomb’’. Initial experience with DRed suggested strongly that for clarity, it is highly desirable to avoid intermingling rationales for diagnosing a problem and designing a solution. Indeed on reflection it is self evident that it is desirable for all charts to present clearly a single activity or theme, succinctly described in the title of the chart. Hence a new chart has been opened entitled ‘‘Prevent debonding’’. Fig. 3 shows this chart at a point where the designer’s exploration of potential solutions is nearing completion. While the diagnosis and solution should not be mixed on one chart, there are, however, important dependencies between them that need to be maintained. For example the validity of Pro arguments in favour of a particular solution proposal may well depend on the Accepted status of an Answer from the diagnosis. Thus these two elements should be linked, even though they are in separate charts. If the initial diagnosis is later found to be incorrect, the knock-on effects can be propagated by following arrows from the now Rejected Answer and considering whether these dependent elements should have their statuses changed as well. A simple concept called tunnel linking provides this linking between charts. A tunnel link appears to burrow into the working surface of a chart, reappearing elsewhere in a different chart and continuing to its destination element. Tunnel links may also be used on a single chart, typically where links would otherwise cross confusingly, or where the two ends are so widely spaced that they cannot both be viewed without excessive scrolling or zooming out. Tunnel entrance and exit mouths are shown as small circular icons (see Fig. 3), which are always created as a mutually referencing pair. Double clicking a tunnel mouth carries the mouse pointer ‘‘through the tunnel’’ to the opposite mouth, displaying its chart and leaving the tunnel mouth icon visible and selected. Thus if the far end turns out not to be of interest, by immediately double clicking (or hitting the return key), the original view is restored. To enable tunnel links to be traced on hardcopies of charts, a pair of tunnel mouth shows a small (one character if possible) integer ID number, unique in both the linked charts. Beneath each mouth is displayed the name of the chart in which the far end of the tunnel emerges, in the form of a relative file path if the linked charts reside in different project sub-folders. If required, they can also be given an additional text label in order to give a better indication of what lies at the other end of the tunnel. Tunnel links allow a large rationale space to be distributed over as many charts as necessary, maintaining both legibility and necessary connectivity. The largest design rationale created to date involved linking 190 DRed charts. Even at this size the rationale remained clear and could be easily navigated and scanned. When a particular working chart is becoming too large and crowded, it is often desirable to move a portion of the chart into a new one in order to create more space and relieve the layout. To facilitate this, a selected portion can be cut and pasted between charts via the DRed clipboard and tunnel links will automatically be created and updated to maintain all of the existing connectivity between elements. When designing a solution, a number of related, but separate, issues arise and have to be addressed. For example, while working on the solution to the acoustic panel debonding problem, the designer has been instructed to consider whether anything could be done to reduce manufacturing costs. For the sake of clarity, the rationale for this is captured in a separate, but tunnel linked, chart with the title ‘‘Manufacturing Costs’’, see Fig. 4. A link to the ‘‘Debonding Diagnosis’’ chart can be seen in the bottom right-hand corner of Fig. 4.

A part of the design procedure of the company is for the final design definition to be checked against a checklist of standard criteria, or ‘‘Associated Effects’’. Fig. 5 shows how these checks and their justification may be carried out by instantiating and elaborating a standard template file that lists the checklist questions. Once again, where elements in these arguments are dependent on elements in other charts, they are tunnel linked, see Fig. 5. As the design solution nears completion, a syntax check can be performed on the set of linked charts to point out possible flaws in the rational justification for the design. Fig. 6 illustrates the main types of error that are highlighted. For example an Accepted Answer with Con arguments but no Pros will be flagged as erroneous. It might be thought necessary to interface an efficient inference engine with pattern-matching rules such as CLIPS [25] to perform the syntax check, but this has not proved the case. Instead, each erroneous element relationship illustrated in Fig. 6 is identified by one of a list of custom Tcl procedures. The syntax check simply iterates through all of the charts in the project, applying the list of error identification procedures to each node in turn. The check stops and highlights the current node and its relevant neighbours, with an explanatory message to the user, when an error is identified. Together with the CAD drawings of the final design, printouts of the DRed charts provide a clear and visual basis for the discussion at the final Design Definition Review and Audit Meeting (DDRAM), which reviews the rationale from a range of different perspectives, and checks that the technical content of the final solution meets the requirements. 3.6. DRed usage 4 — Communicating the final design and its rationale The final step is to prepare a narrative description of the solution, complete with details such as the rework procedures required to apply the solution to engines in service. Being narrative, these descriptions are best written as standard word-processed reports, see Fig. 7. DRed can provide a clearly structured starting point for the preparation of these reports by exporting the accepted (green) part of the rationale as outline-structured HTML for import into the word processor. To maintain traceability, it is also important that main points in the narrative description are, as shown, hyperlinked back to the points in the rationale where they were defined, see Fig. 7. After clearing the last hurdle of the formal Product Control Board meeting, the design scheme is signed off and all files checked into their on-line Design Scheme Folder (DSF) in the PLM document repository. Since DRed stores all the information it captures in ordinary document files, it can work with a company’s existing file access, editing and approval permissions and procedures. For collaborative editing of files on shared drives, DRed enforces a simple editing lock-file protocol to prevent simultaneous editing conflicts. Having established what DRed is and how it is used in practice, the following section will examine the methodology and process by which it was researched and implemented. 4. Research and software implementation methodology 4.1. Socio-technical approach The early stages of DRed research were undertaken in the context of a collaborative research project investigating the capture, sharing and reuse of knowledge in the aerospace industry. This involved researchers in engineering design, work

178

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

Fig. 3. Designing a solution.

psychology and computer science from three universities, working with RR and another large international aerospace company. The project focused on the engineering design process in each company at several UK sites. The objective was to research and implement a software tool-set to support designers in their dayto-day activities, embedded within appropriate social systems to maximize their effectiveness. Through an extensive program of interviews, presentations and workshops, requirements for the tool-set were elicited from designers, and then evaluated and prioritised [32]. One of the most important requirements identified was to provide a tool capable of capturing design rationale that designers would be prepared to use as their designs proceed, not just retrospectively. The application of a novel methodological approach [33,34] to researching and developing software tools for designers, extending the well-known DRM [35], led to the unanticipated choice of IBIS as the basis of such a tool [36]. The following sections will discuss the research and development of DRed with respect to the phases of DRM as portrayed in Fig. 8. 4.2. Criteria definition It was not considered appropriate in this project to define quantitative measurable success criteria from the outset, as the DRM methodology encourages. There is general agreement in the research literature that if the rationale capture bottleneck in engineering design can be overcome, then the potential benefits to individuals and companies are wide-ranging. Section 2 listed these

as benefits including the provision of better support for redesign, reuse, maintenance, learning, documentation, collaboration, and management of projects [4]. Improvements to collaboration and project management would be immediate, but the remaining benefits would only build up slowly as a repository of captured rationale accrued and was available for reuse. The initial requirements elicitation study among RR engineers, on computer support needs for knowledge capture, sharing and reuse [32] confirmed that the practising designers in the company also saw these potential benefits. The fundamental initial measure of success would be to establish whether a DR capture tool could be created that designers would adopt and keep using without coercion, because it helped, or at least did not hinder them in their daily work. 4.3. Descriptive study I In our DRM-derived methodological approach [33], the Description I phase aims to model suitable aspects of the existing design process in question, using well-defined knowledge structures, to generate a proposal as to how that process could be improved. The pre-existing RR standard practice for DR capture was the preparation of a textual Design Definition Report (DDR), and the compilation of a loosely-structured paper Design Scheme Folder (DSF) at the end of a project. Despite the perceived poor usability of IBISlike approaches as reported in the research literature, a preliminary examination of the contents of DDRs suggested that IBIS looked a good fit and was worth a try. Hence IBIS-like graphs were chosen

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

179

Fig. 4. Reducing manufacturing costs.

as knowledge-level representations for the description of RR design rationale. The next step was to choose a suitable knowledge modelling tool or tools to allow the representation to be tested and iteratively refined by instantiating it with DR from real cases. The tool chosen was Graphlet, a general purpose interactive graph editor, then freely available for non-commercial use, from the University of Passau [37]. Graphlet was used to explore the use of IBIS-like representations to structure graphically the DR contained in existing DDRs [36]. When the reverse-engineered DR graphs were presented to designers in RR their reception was favourable. It was felt that they could be easier and quicker to understand than the textual reports from which they had been derived. The conviction grew that this approach was promising, and that the frequently reported problems with IBIS might be surmountable if careful attention was paid to usability. The use of DR from real projects in this study convincingly demonstrated the feasibility and possible benefits of such a design support tool, attracting great interest in the companies. Some designers expressed the wish to try out the approach for themselves. 4.4. Prescriptive study One of the biggest challenges facing design researchers is that of producing prototype software tools that are sufficiently appealing and robust to be tested in practice. Many potentially good ideas have failed at this stage. Stetter [38] argues that the involvement of designers in the implementation process is essential to avoid

later resistance. A serious difficulty in doing so is that it is becoming increasingly difficult to ‘sell’ software with a primitive appearance to users familiar with sophisticated user interfaces [39]. Equally, designers are easily put off if software is overly complex or unintuitive to use, or if it fails frequently, particularly if it loses or corrupts a significant quantity of work. Once they have been put off, it is virtually impossible to win them back. The key to the solution of this problem was the earlier decision to use Graphlet to support the Description I phase. One of the main reasons it had been chosen is that it employs a ‘‘two language’’ philosophy, in which a robust and efficient compiled core underlies an easily configurable user interface written in an interpreted scripting language. This approach has been applied successfully in a number of design research projects, for example n-dim [41], SEED [42], Ascend [43] and Schemebuilder [44]. Thus Graphlet could equally provide the basis of a tool for designers to use. Its general purpose graph editing GUI was gradually modified through straightforward scripting, to give an effective tool for rationale capture. From the start it was recognised that the tool would need to be as intuitive as possible to anyone familiar with the conventions of Windows object-based drawing software such as that in MS Word or Visio. Fortunately, Graphlet already followed these conventions, and it was possible to produce a rationale capture tool of steadily increasing capability, and ease of use, with a reasonably polished graphical user interface from the outset. Graphlet’s underlying core is the C++ Graph Template Library (GTL), which allows graphs to be represented, navigated,

180

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

Fig. 5. Partially completed checklist template.

modified, loaded from, and saved to, plain text Graph Markup Language (GML) files. The GTL representation is extensible, allowing arbitrary persistent attributes to be defined at run-time for any node or arc and these are automatically saved to file along with the rest of the graph. GTL is bound to a library of Tcl procedures that enable easy access from the scripting language. The implementation of DRed thus required no modification of the C++ layer. A common bottleneck in this type of research is the time consuming and difficult problem for the researcher to convert partially worked out research ideas into a sufficiently precise specification for satisfactory implementation by a software developer. The only way to avoid this problem completely is for the researcher to write the software personally, which can be very effective if productive choices of languages, components and tools are made. This was the approach adopted here, with all the software being written by the first author. Thus it was possible to release, in less than one month of software development, an initial prototype, DRed v0.1. This was sufficiently functional to support real design work by a small group of collaborating designers in RR. Moreover, due to its solid foundations in the unmodified GTL library, and the run-time error checking of the modified and newly written Tcl scripts, it proved robust enough for designers to use with confidence. First reactions were very positive and included many helpful suggestions with regard to functionality and usability. There were also indications that its use in the design process, rather than being a hindrance, was actually

Fig. 8. DRM Design Research Methodology.

proving beneficial in lending structure to designers’ thoughts as they developed. An efficient and productive research cycle of idea generation, implementation and testing ensued. Seven further releases, of steadily increasing capability and refinement, followed over the next eight months. 4.5. Descriptive study II In the DRM, the role of the Descriptive Study II is to evaluate: (1) whether the method or tool produced by the descriptive study can indeed be used in the situation and manner for which it is intended, and (2) whether or not it does have a positive impact on

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

181

Fig. 6. Examples of invalid syntax that are highlighted by the syntax checker.

predefined measurable success criteria. The case study presented in Section 3 shows by example of a real design project, that DRed can be used to capture and present design rationale in a clear and logical manner, and thus the answer to (1) above is affirmative. As argued in Section 4.2, rather than defining quantitative criteria, the primary measure of success for (2) was to establish whether DRed is tool that designers will adopt and keep using without coercion, because it helps, or at least does not hinder them, in their daily work. The first stage of this process was a six month trial followed by questionnaire evaluation, as reported in [45]. It is important to emphasise that this was evaluation was merely the first step on a long road of progressive deployment, evaluation and of increased resource commitment, based on steadily accumulating evidence of positive benefit to the company from the use of the tool. This deployment process is examined in detail in the following section. To further investigate whether the claimed benefits of captured DR are substantiated in practice, a parallel stream of empirical work evaluated aspects of the rationale being captured using DRed, in comparison with earlier DDRs and DSFs. One study compared the contents of pre-DRed DDRs with the rationale captured in DRed charts. In the projects studied, DRed charts were found to be richer in the number of recorded design solutions and in the number of pro and con arguments underpinning those solutions, as compared with earlier documentation by textual DDR [46]. Another study compared the comprehension by RR engineering trainees of the same technical documentation, presented in either a textual report or in DRed. Results suggested that the DRed presentation improves

the speed with which recorded information is retrieved and results in more complete answers to questions requiring wider, more global searches [47]. 5. Industrial deployment and evaluation 5.1. Initial deployment Perhaps the biggest practical difficulty in placing a prototype tool in the hands of working designers for evaluation is the need to meet appropriate quality standards before it can be installed on a company network. It was argued by Wiseall that this problem has been exacerbated in recent years by the common practice of outsourcing the provision of IT services [39]. He pointed out that the emphasis of such providers is on managing and operating large-scale networks and that the internal company infrastructures that were once able to productionise prototype software have largely been lost. Fear of penalty clauses inservice agreements provides a strong disincentive to causing any disturbances to an IT system. Thus expensive and timeconsuming quality assurance procedures are likely to be insisted upon before new software can be installed. This expense is likely to prove prohibitive, unless the benefits of the tool can clearly be demonstrated, which is of course impossible without performing a realistic evaluation. This unfortunate chicken and egg situation was initially circumvented by distributing DRed on a few dedicated PCs not connected to the network. However, this was clearly a far from

182

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

Fig. 7. Narrative description of final solution hyperlinked to the rationale.

ideal way of evaluating a tool intended to integrate seamlessly into designers’ normal working practices. Fortunately, the MS Windows versions of both Tcl/Tk and Graphlet, by virtue of their cross platform UNIX heritage, do not require to be installed onto individual PCs in order to run. Thus it was possible to create a distribution CD, from which DRed could be run directly, without copying any files onto the PC or modifying its environment in any way. This crucially enabled designers to run DRed on their normal networked PCs, without which successful evaluation would not have been possible. 5.2. First formal trial and evaluation An important success factor identified by Stetter for the introduction of a method or tool into industry is the need for an enthusiastic and powerful ‘‘method champion’’ [38]. Wiseall broadly agreed, but argued the need for two distinct active support roles: a senior company sponsor and an internal technology champion [39]. It was fortunate that in the case of DRed a Chief Design Engineer saw its potential early on, and enthusiastically assumed the senior company sponsor role. With his support, and backed by the very positive feedback from the small team of initial users, the decision was taken to commit the resources for a wider trial of six months duration. In a survey by Gouvinhas of perceived roadblocks to the implementation of design methods and associated software tools, lack of training in their use came top of the list [40]. With this in mind the senior sponsor rightly

insisted that careful consideration should be given to modifying working practices in order to accommodate the tool, and that the users should receive prior training in both the proper use of the tool and in the modified working practice. The main change of working practice made to accommodate the use of DRed was in the content of Design Definition Reports (DDRs) The Specification Requirements section previously contained a textual description of the problem understanding gained in the design project, and the Alternative Solutions section a retrospective description of the main rejected solutions, along with reasons for their rejection. It was agreed that if DRed was used to capture the problem understanding and solution generation at the time that these activities were performed, the textual contents of these sections could be replaced by the DRed charts pasted into the MS Word document file of the DDR. Since report writing is rarely a popular activity among engineers, this provided a direct benefit to users, that we consider was significant in the facilitating the successful adoption of the tool. Additionally, the pre-existence of the DDR certainly made it easier for the senior sponsor to argue within the company, that DRed was merely an incremental improvement on their current rationale capture practice. In a company without such a pre-existing culture of formal design project reporting, these helpful factors would not apply. However the subsequent successful introduction of DRed in documenting design work out-sourced to an external company in India (see Section 5.3), suggests that a pre-existing rationale capture culture is not necessary providing the benefit is recognised by key management decision makers.

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

The role of technology champion was taken by the third author, who, having been closely involved with the software implementation, was well qualified for the role of tool expert within the company and for supporting users during the trial. He also took the lead in preparing a two-hour introductory training course, which was delivered in two batches three months apart, to a total of 54 designers. The training involved hands-on use of the tool, and was given to groups of roughly six participants. The designers who trialled DRed were given a questionnaire. It was an initial disappointment to discover that only 12 of the 32 designers who responded had used DRed in practice after their initial training. However, eleven of the designers who had not used DRed expected to use it in the future. The main reasons identified for not using DRed were: (1) the availability of the software was limited to a Windows PC platform (CAD users at that time still used UNIX); (2) lack of time; and (3) their current work was thought to be inappropriate for DRed. Telephone interviews were carried out with 14 designers to gain a deeper understanding of these reasons. The telephone interviews found that the major reason for designers to state lack of time as an issue was again due to the availability of the software being limited to PC. A job was usually described as inappropriate for DRed when the designer was already part way through a project when the training was given. The reasons for limited uptake were therefore unrelated to the concepts behind the software itself, but highlighted the importance of ensuring easy access to the tool and of providing training at the most appropriate time, ideally just before undertaking a new project. The conduct and results of the questionnaire are reported in [45], but the main findings can be summarised as follows: (1) DRed was found easy to use; (2) it improved the overall view of the design process and the ability to keep track of it; and (3) it assisted evaluating and deciding between concepts. None of the feedback said that it hindered the design process, even slightly. Designers also perceived future benefits, such as improving communication and monitoring progress. 5.3. From initial installation to company-wide roll-out The results of the evaluation were considered sufficiently positive to justify the necessary expenditure to have DRed installed on a subset of the company’s technical PC network. Before the first installation, it was important to ensure that the tool had the functionality needed by the majority of users and was sufficiently stable, since once installed it would be a much more involved and expensive process to release updates. Stetter argues that to anchor new methods in an organisation, they should be subject to a continuous improvement cycle, with tools regularly refined and updated [38]. At the same time, he cautions of the danger of methods becoming increasingly complex in response to requests for new features. Thus the technology champion needs ‘‘to make conscious decisions to focus on the most important requirements and to neglect others, in order to keep the method and tools simple and appropriate’’. The process by which this was achieved was for the technology champion to filter user suggestions and to feed them back to the researcher/software developer by creating and regularly updating a master worksheet of ‘‘DRed Ideas and Problems’’. New or modified features introduced in response to these suggestions were similarly subject to careful scrutiny. During this process, usage of DRed was allowed to spread naturally by personal recommendation among designers, the software continuing to be run from CDs. Responsibility for training new users was assumed by the company’s Learning and Career Development organisation. Eventually the functionality was sufficiently stable and the software sufficiently debugged to

183

pass the necessary quality tests for it to be installed on a subset of the company’s technical PC network. Usage continued to grow steadily and reports of its successful application accumulated. It was agreed by the Design Process Council that it should be accepted as part of the company’s standard PLM tool-set, and it won the Research and Technology Director’s Award for Creativity in December 2004. In February 2005 DRed was also a Finalist in the Sir Henry Royce Award for Technical Innovation. The eventual winner of this award was the design of the Intermediate Pressure Turbine power off-take the Trent 1000 engine, that powers the Boeing 787 Dreamliner aircraft. This highly successful innovation achieves a large (up to 6%) fuel saving on short haul routes compared with a comparable engine employing a conventional High Pressure Turbine power off-take [48]. DRed played an important role in supporting the conceptual design and embodiment of this innovation. A leading member of the design team described its role and effectiveness as follows [49]: ‘‘DRed proved to be a powerful tool when considering the complex issues surrounding the many concept options. It enabled rational down select of the leading designs. The rationale has proven to be a valuable reference pack throughout the design evolution’’. A year after the initial installation, the head development version of DRed once again underwent a process of critical refinement, intensive debugging and testing. As a result, just four years after the first research use of Graphlet to model the rationale contained in DDRs, DRed 1.0.8 was rolled out across the company’s worldwide PLM PC network in November 2005. In September 2006 DRed was again an award Finalist, this time ‘‘Highly Commended’’ for the RR Director of Engineering & Technology Quality Award. In the presentation to the award judging panel, it was reported that to date 400 engineers had been trained in the use of DRed, on request of themselves or their team leaders, in Derby, Bristol, Dahlewitz and Montreal, via a 2.5 h introductory course. An application where DRed had been found to be particularly effective was in facilitating communication for design tasks that had been outsourced to India. A Chief Engineer was quoted: DRed has been key in establishing effective communications between our Engineering teams in the UK and India. A RR Technical Operations Manager in India added: In my experience of using DRed with engineers in India, it is fantastic in overcoming the communication barriers that sometimes exist . . . it is one of the first things we look at in any technical discussion. Especially when working across the telephone as we often are, it can be easily referred to and provides a framework for discussion. Another design area where it was reported to the judging panel that DRed is effective is in capturing and managing diagnostic Root Cause Analysis of Civil Aerospace fleet events. It was reported that DRed is being used to good effect and transforming the way we do root cause analysis in Technical Service and Operations. The root of this transformation has was a successful initial application of DRed to manage a complex failure investigation and subsequent re-design. The investigation followed an in-flight incident in 2003, as reported by the US National Transportation Safety Board [50]. 6. Discussion In this section we suggest what have been the key issues that have limited the application of previous design rationale capture software, and explain how these are addressed in DRed. 6.1. Visual and spatial disorientation A major problem with gIBIS was that the whole rationale for a potentially large, complex project, if it was to be inter-linked, had to be captured on a single two-dimensional chart. This led to problems of visual and spatial disorientation and confusion due

184

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

to the resulting large number of unavoidable link crossings [7]. This problem was addressed in Questmap and Compendium by adopting Nelson’s concept of transclusive linking [26] to allow the distribution of a single large rationale across multiple twodimensional charts. Transclusive linking simply means that the same node appears in more than one view, so that any modification in one view is reflected in all the others. However, this use of transclusive linking to maintain connectivity in distributing large IBIS graphs across multiple, individually comprehensible views, may lead to a further problem of decontextualisation of the transcluded nodes as discussed in the following section. Tunnelling links, as described in Section 3.4, provide an alternative way of distributing large rationales across multiple charts while maintaining connectivity. By contrast with transclusion, each element appears on the single chart in which it was defined, so there can be no problem with decontextualisation. Tunnelling links are covered by European, United States and World patent applications [30].

6.3. Problems with hierarchical outliners: (Lack of clarity)

6.2. Difficulty of appreciating the whole context of an element

6.4. Reliance on a database

While for some users and applications, transclusive linking in Questmap was found to be an appropriate and powerful representation [27], it was suggested that many users never used it because they found it counterintuitive [28]. However, this does not seem to have been a problem with the highly successful UML notation for object-oriented modelling [29], a cornerstone of which is the transclusive display of class representations in multiple views. We argue that there is a particular comprehensibility problem with the use of transclusive linking to maintain connectivity in distributing large IBIS graphs across multiple views. In UML, the meaning of the representation of a class is always clear, no matter in what view it is displayed. That is not generally the case with design rationale elements other than issues. Answers generally make little sense when separated from the issue they are addressing, and arguments make little sense when separated from what they are arguing about. In such cases the defining context has been obscured. For example, pro and con arguments of a design solution may depend on accepted or rejected answers from a problem diagnosis. In Fig. 3 the pro argument ‘‘Thermal strain is thought to be a major cause of the problem’’ is dependent on the accepted answer ‘‘Thermally induced strain’’ to the issue ‘‘What causes are contributing to the debonding?’’ in Fig. 2. It is thus tunnel linked to it. If this link was alternatively made by transcluding ‘‘Thermally induced strain’’ into Fig. 3, it would be separated from the question it is answering and the clarity of Fig. 3 would be reduced as a result. Similarly, arguments about answers to checklist questions depend on the design solution elements chosen. Expressing these dependencies by transcluding isolated checklist arguments into the solution rationale might greatly reduce its clarity. It can also be difficult to appreciate the complete context of any transcluded element, since to find out the type and direction of the dependency of all elements to which it is linked, the user must visit all views in which that element appears. A user interface enhancement in recent versions of Compendium makes this somewhat easier: a small integer number in the corner of an element shows the number of transclusions, and moving the mouse cursor over it produces a pop-up list of hyperlinks to them. Visiting each in turn still requires a sequence of precisely executed mouse actions however. One way to address this problem might be to provide for cycling forward or backward through all the transclusions of a selected element, using suitable keyboard shortcuts.

Another problem identified as a hindrance to the adoption of rationale capture in industry was the need of previous tools for a dedicated Database Management System (DBMS) to store the rationale. This does not fit well with designers’ normal working practices and IT support systems, which are generally based on the creation and management of document files and folders. A further benefit of the tunnel linking approach is that it removes the need for a DBMS as the rationale capture can be entirely based on files and folders. The set of mutually referencing rationale documents reside in the same design project folder as all other files created during the design process, and the whole is managed by whatever document management system exists in the company. As a design proceeds, this folder provides a repository where the team can store the emerging product definition; the ideas evaluated; their acceptance or rejection; clear rationale for these decisions; and all supporting documents. DRed therefore provides a unified map of the whole information space. The folder can be arbitrarily partitioned into sub-folders, the naming of which can follow any convenient project, group or company structure. Once finally completed and approved, the design folder can be made available for read-only searching and browsing, by simply copying it into the file space of a standard Intranet or Internet web server. Thus DRed, even without the support of a formal PLM system, is able to support the necessary progression of design information from private to public to published states, as advocated by the ndim project [31].

Hierarchical outliner-style IBIS tools, such as Pepper [12] or SEURAT [19], allow arbitrarily large rationales to be managed on a single chart, thus providing an alternative way of avoiding the problems of transclusive links in this role. The user can choose what to display at any time, by expanding or collapsing levels at will. Additionally, unlike most graph-based tools, producing comprehensive hard copy is not a problem. The outline is simply printed fully expanded as hierarchically structured text. However, these advantages bring with them two problems. Firstly, it can be very awkward to represent design or decision spaces that are not entirely tree-structured, using a tool that enforces a rigid hierarchy. Another problem is the lack of clarity inherent in the outline style of presentation, since it is difficult to determine which levels need to be collapsed and which need to be expanded to fully appreciate a particular issue. It is easy to miss a crucial argument simply because it is hidden in a collapsed branch, or if it has been scrolled off screen by the expansion of branches of lesser importance.

6.5. Node label being limited to a line of text Another impediment to the use by designers of earlier IBIS tools such as gIBIS and Questmap, but which has recently been solved in Compendium, was the limitation that each node label had to be a short, single line. Any more extensive text had to be displayed in a separate window accessed by right clicking or moving the mouse pointer over the node. This causes several difficulties. Firstly, a designer, on capturing a thought in a node, has to make a conscious effort to summarise that thought into three or four meaningful words. This can be difficult and a distraction from the task in hand. Secondly, the fact that the text of several related nodes cannot be scanned at a glance makes a rationale much harder to interpret. Against this it might be argued that there is little difference to the user, between the invocation of a ‘‘node details’’ dialog in Questmap and following a tunnel in DRed. The fallacy of this argument is that the requirement for

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

easy rationale comprehension is the presentation of the full text of whole issue/answers/argument clusters, with easy navigation between such clusters. This is provided by tunnelling. By contrast, the limitation of short labels with a ‘‘node details’’ dialog prevents any rationale cluster being fully appreciated at a glance. Thirdly, it means that it is not possible to comprehend the rationale in hardcopy, since most of the text is missing. Thus DRed, and recently Compendium, allow each node to display an arbitrary number of lines of text at a user-controllable wrap width. While there is no hard limit, too much text in a single DRed node is generally considered as bad practice, and better to be broken down into multiple linked elements, either in the local chart or in a tunnellinked chart addressing some specific sub-problem. The amount of text in the elements in Figs. 1–4 is broadly typical of good practice. 6.6. Making best use of limited screen space In DRed, the text overlays coloured graphics that signify the node types and statuses, whereas in Compendium the node type is signified by an icon offset from the text. The elimination of offset icons has the advantage of saving precious screen space, and with a complicated and tightly packed rationale, of easing the difficulty of associating an element, its type and status, with its textual contents.

185

The result with DRed has been the creation of a lightweight tool optimised for the needs of RR engineers. Compendium, currently the most widespread software of a similar nature to DRed, was designed as a general purpose modelling tool for a much broader audience, and is consequently much more heavyweight in user interface and its need for an underlying database. However like DRed’s parent application Graphlet, it is open source and has run time error handling. It might, for example, be fruitful to consider what might result from a similarly radical reconfiguration of Compendium to create a lightweight tools optimised for particular purposes. Current and future work involving DRed has revolved around extending its bi-directional linking in two ways: firstly creating bi-directional hyperlinks between DRed elements and selected locations in a range of external document types [51]; and secondly adding support for hierarchical decomposition and transclusion in addition to tunnelling. The aim is to support not just the capture of rationale, but the creation of a unified, easily navigable hypermedia information spaces covering the requirements analysis, problem understanding, solution generation, calculations, design tasks and the emerging product definition. Research is also underway to use the strong rationale structure inherent in a DRed charts, combined with semantic reasoning techniques, to facilitate retrieving information about past design solutions and root cause analyses.

7. Conclusions and further work Acknowledgements When designers require information to progress their design tasks, and they do not have that information in their memories or their own personal reference sources, they have to retrieve that information from external sources, including colleagues. Research has shown that the preferred source of information, by a long way, is another person. However with the increasing transience of modern industrial companies and the large number of senior engineers close to retirement, there is an urgent need to capture and store information about past design solutions and their rationale in a repository that is independent of human memory. DRed a new design rationale capture tool has been described, along with the research methodology and deployment process by which it achieved widespread multinational use in Rolls–Royce. Detailed problems in the use by designers of earlier IBIS tools have been identified and the solutions to these problems provided by DRed explained. This tool originated in a small research group, with the software being written by one person. There was close collaboration with the company during its development and deployment. The tool is based on the IBIS concept and overcomes the problems that have prevented previous IBIS-based rationale capture tools fulfilling their potential. The features of DRed include: based on well-established IBIS principles; easy to learn and use; and robust and flexible. In practice it has been found to: help designers view, clarify and structure their design thinking; assist with managing design tasks; capture design rationales as they are created without an additional overhead; and reduce the need for written reports. This paper has also demonstrated that instead of starting software tool development from scratch using a suitable high-level language and application development framework, an attractive alternative can be to start from an existing open source application and progressively customise it. This approach may be particularly effective if the initial application is suitable to support both knowledge modelling for a descriptive industrial case study, and also to be customised into a prescriptive end-user tool inspired by the results of the descriptive study. Suitable applications to support this approach are likely to have been created as general purpose tools, and it may help if the user interface is defined using a scripting language that provides run-time error handling.

The authors acknowledge the all round support of RR and the financial support of BAE SYSTEMS through the UTP for Design; and the support of the EPSRC through various research grants. The support of Saeema Ahmed is acknowledged for conducting the evaluation questionnaire and telephone interviews; and the support of Jim Wickerson and designers in RR for their assistance with training, evaluation and helpful feedback. References [1] Marsh JR. The capture and utilisation of experience in engineering design. Ph.D. thesis. Cambridge University; 1997. [2] Aurisicchio M, Wallace KM. Information requests and consequent searches in aerospace design. In: Proceedings of DESIGN 2004. 2004. [3] Court A. The modelling and classification of information for engineering designers. Ph.D. thesis. University of Bath; 1995. [4] Lee J. Design rationale systems: Understanding the issues. IEEE Expert 1997; (May/June):78–85. [5] Szykman S, Sriram RD, Regli WC. The role of knowledge in next-generation product development systems. ASME Journal of Computing and Information Science in Engineering 2001;1(1):3–11. [6] Kunz W, Rittel HWJ. Issues as elements of information systems. Working paper 131. Center for Planning and Development Research, Berkeley; 1970. [7] Conklin J, Begeman ML. gIBIS: A hypertext tool for exploratory policy discussion. ACM Transactions on Office Information Systems 1988;6(4): 303–31. [8] McCall R. PHI: A conceptual foundation for design hypermedia. Design Studies 1991;12(1):30–41. [9] MacLean A, Young RM, Bellotti V, Moran TP. Questions, options, and criteria: Elements of design space analysis. Human–Computer Interaction 1991;6: 201–50. [10] Bañares-Alcántara R, King JMP, Ballinger GH. ÉGIDE: A design support system for conceptual chemical process design. In: Sharpe JEE, editor. AI System support for conceptual design. Springer-Verlag; 1995. p. 138–52. [11] Blessing LTM. A process-based approach to computer-supported engineering design. Ph.D. thesis. University of Twente; 1995. [12] Ernst J. Collaborative decision making and personal knowledge management with R-Objects Pepper. In: Workshop WF6 — Real world RDF and semantic web applications, Proceedings of WWW2002. 2002. [13] Buckingham Shum SJ, Selvin AM, Sierhuis M, Conklin J, Haley CB, Nuseibeh B. Hypermedia support for argumentation-based rationale: 15 years on from gIBIS and QOC. In: Dutoit A, McCall R, Mistrik I, Paech B, editors. Rationale management in software engineering. Springer-Verlag; 2006. p. 111–32 [Computer Science Editorial]. [14] Nomaguchi Y, Ohnuma A, Fujita K. Design rationale acquisition in conceptual design by hierarchical integration of action, model and argumentation. In: Proceedings of DETC/CIE 2004, CIE-57681. 2004.

186

R. Bracewell et al. / Computer-Aided Design 41 (2009) 173–186

[15] Kato Y, Taketa K, Hori K. Capturing design rationale by annotating e-mails. In: Proceedings of 6th world multiconference on systemics, cybernetics and informatics. 2002. [16] Conklin J. Dialogue mapping: Building shared understanding of wicked problems. Chichester: Wiley; 2005. [17] Sierhuis M, Selvin A. Towards a framework for collaborative modeling and simulation. In: Workshop on strategies for collaborative modeling and simulation, Proceedings of ACM CSCW’96. 1996. [18] Selvin A. Supporting collaborative analysis and design with hypertext functionality. J Digital Inform 1999;1(4). [19] Burge JE. Software engineering using design rationale. Ph.D. thesis. Worcester Polytechnic Institute; 2005. [20] Zdrahal Z, Mulholland P, Valasek M, Bernardi A. Worlds and transformations: Supporting the sharing and reuse of engineering design knowledge. Internat J Hum–Comput Stud 2007;65(12):959–82. [21] Szykman S, Racz J, Bochenek C, Sriram RD. A web-based system for design artifact modeling. Des Stud 2000;21(2):145–65. [22] Bohm MR, Stone RB, Simpson TW, Steva ED. Introduction of a data schema to support a design repository. Comput Aided Des 2008;40: 801–811. [23] del-Rey-Chamorro FM, Wallace KM. Understanding the search for information in the aerospace domain. In: Proceedings of ICED’05. 2005. [24] French MJ. Conceptual design for engineers. London: Design Council; 1985. [25] Giarratano JC, Riley G. Expert systems: Principles and programming. Boston (USA): PWS Publishing Co.; 1994. [26] Nelson TH. Literary machines. Swarthmore (Pennsylvania): T.H. Nelson; 1981. [27] Selvin AM. Supporting granular reuse of knowledge elements in an organizational memory system. In: Proceedings of seventh international workshop on hypertext functionality: Organizational memory systems & HTF. 1998. [28] Conklin J, Selvin A, Buckingham Shum S, Sierhuis M. Facilitated hypertext for collective sensemaking: 15 years on from gIBIS. In: Proceedings of LAP’03 (Keynote Address). 2003. [29] Page-Jones M. Fundamentals of object-oriented design in UML. New York: Dorset House; 2000. [30] Bracewell RH. A method, tool and system for increasing the efficiency of a design process. Applicant: BAE Systems plc; Rolls Royce plc. EP1639510, WO2005001721, US2005177531. Published 2006-03-29. [31] Subrahmanian E, Reich Y, Konda SL, Dutoit A, Cunningham D, Patrick R, Thomas M, Westerberg AW. The n-dim approach to creating design support systems. In: Proceedings of DETC/DTM 1997, DTM-3873. 1997. [32] Kerr MP, Waterson PE, Clegg CW. A socio-technical approach to knowledge capture sharing and reuse in aerospace design. In: Proceedings of DETC/CIE 2001, CIE21254. 2001. [33] Bracewell RH, Shea K, Langdon PM, Blessing LTM, Clarkson PJ. A methodology for computational design tool research. In: Proceedings of ICED01. Paper 122. 2001.

[34] Bracewell RH, Shea K. CaeDRe: A Product platform to support creation and evaluation of advanced computer aided engineering tools. In: Proceedings of ICED01. Paper 369. 2001. [35] Blessing LTM, Chakrabarti A. DRM: A Design research methodology. In: Proceedings of international conference on the science of design-The scientific challenge for the 21st Century. 2002. [36] Bracewell RH, Wallace KM. A tool for capturing design rationale. In: Proceedings of ICED03. Paper 1437. 2003. [37] Himsolt M. Graphlet: Design and implementation of a graph editor. Softw Practice Exp 2000;30(11):1303–24. [38] Stetter R, Lindemann U. The transfer of methods into industry. In: Clarkson PJ, Eckert CM, editors. Design process improvement—A review of current practice. Springer; 2005. p. 326–43. [39] Wiseall SS, Kelly JC, Kelly TP. Transferring design research into Rolls–Royce. In: Proceedings of ICED01. Paper 410. 2001. [40] Gouvinhas RP, Corbett J. A discussion on why design methods have not been widely used within industry. In: Proceedings of ICED99. 1999. p. 685–90. [41] Dutoit A, Levy S, Cunningham D, Patrick R. The basic object system: Supporting a spectrum from prototypes to hardened code. In: Proceedings of OOPSLA 96. 1996. p. 104–21. [42] Flemming U, Woodbury R. Software environment to support early phases in building design (SEED): Overview. Journal of Architectural Engineering 1995; 1(4):147–52. [43] Piela P, McKelvey R, Westerberg A. An introduction to the ascend modeling system: Its language and interactive environment. J Manage Inform Syst 1993; 9:91–121. [44] Bracewell RH, Sharpe JEE. Functional descriptions used in computer support for qualitative scheme generation— ‘‘Schemebuilder’’. AI EDAM JournalSpecial Issue: Representing Functionality in Design 1996;10(4):333–46. [45] Bracewell RH, Ahmed S, Wallace KM. DRed and design folders: A way of capturing, storing and passing on knowledge generated during design projects. In: Proceedings of DETC/DAC 2004, DETC2004-57165. 2004. [46] Aurisicchio M, Bracewell RH, Wallace KM. Evaluation of DRed: A way of capturing and structuring engineering design processes. In: Proceedings of NordDesign conference. 2006. [47] Aurisicchio M, Gourtovaia M, Bracewell RH, Wallace KM. Evaluation of how DRed design rationale is interpreted. In: Proceedings of ICED’07. 2007. [48] http://www.rollsroyce.com/civil_aerospace/products/airlines/trent1000/ engine.jsp [accessed 11.10.06]. [49] Salustri FA, Bracewell RH, Eng NL, Weerasinghe JS. Visualising early engineering design information with diagrams. J Design Res 2007;6(1–2): 190–217. [50] Rosenker MV. Safety recommendation. National Transportation Safety Board: A-06-85 through —87. December 14, 2006. [51] Bracewell RH, Gourtovaia M, Wallace KM, Clarkson PJ. Extending design rationale to capture an integrated design information space. In: Proceedings of ICED’07. 2007.