Capturing Design
Improving conceptual ship design through the
capture of design rationale
Capturing Design
Improving conceptual ship design through the
capture of design rationale
PROEFSCHRIFT
ter verkrijging van de graad van doctor
aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus prof.ir. K.C.A.M. Luyben,
voorzitter van het College voor Promoties,
in het openbaar te verdedigen
op dinsdag 1 mei 2012 om 12.30 uur
door Thomas William DENUCCI
Master of Science in Naval Architecture and Marine Engineering
Massachusetts Institute of Technology, Cambridge,
De Verenigde Staten van Amerika
geboren te Springfield, Massachusetts,
Samenstelling promotiecommissie: Rector Magnificus voorzitter
Prof. ir. J.J. Hopman Technische Universiteit Delft, promotor Prof. dr. T.E. Taylor United States Coast Guard Academy Prof. dr. A. Hagen Norwegian Institute of Technology Prof. dr. F.M. Brazier Technische Universiteit Delft Prof. dr. ir. M.J.L. van Tooren Technische Universiteit Delft Dr. ir. F.E.H.M. Smulders Technische Universiteit Delft
Dr. ir. B.J. van Oers DMO / Netherlands Ministry of Defence Dr. ir. B.J. van Oers heeft met zijn begeleiding en ondersteuning een belangrijke bijdrage geleverd aan de totstandkoming van dit proefschrift.
published by: VSSD
internet: http://www.vssd.nl/hlf e-mail: hlf@vssd.nl
This research was made possible by the financial support of the United States Coast Guard. The views expressed in this thesis are those of the author and do not reflect the social policy or position of the United States Coast Guard, Department of Homeland Se-curity, or the U.S. Government.
Copyright c 2012 by T.W. DeNucci
keywords: knowledge management, knowledge capturing, ship design, design rationale, ship configuration, arrangements, rationale capturing, rationale elicitation
All rights reserved. No part of the material protected by this copyright notice may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage and retrieval system, without the prior permission of the author.
List of Figures vii
List of Tables xi
1 Introduction 1
1.1 Background . . . 3
1.1.1 The rationale behind design rationale . . . 3
1.1.2 What is design rationale? . . . 5
1.1.3 Rationales in the conceptual design of complex ships . . . 6
1.1.4 Benefits of rationale in conceptual ship design . . . 10
1.2 Research motivation. . . 12
1.3 Objectives of research. . . 13
1.3.1 Research questions . . . 13
1.3.2 Originality & contribution . . . 14
1.4 Method . . . 15
1.5 Organization of dissertation. . . 15
2 Difficulties Capturing Rationale in Complex Ship Design 19 2.1 Limited expression of DR in the conceptual design process . . . 20
2.2 Pitfalls of existing rationales (when captured...) . . . 23
2.2.1 Expressed rationale lacks content . . . 23
2.2.2 Design rationale lacks structure . . . 23
2.2.3 Expressed design rationale is limited in scope . . . 24 i
2.3 Obstacles to effective rationale capturing. . . 25
2.3.1 Human issues in rationale capturing . . . 26
2.3.2 Methodological shortcomings of rationale capture . . . 27
2.4 Summary . . . 27
3 Relevant Research 29 3.1 Elements of a generic rationale system . . . 30
3.2 Capturing design rationale (general case). . . 31
3.2.1 Expression of design rationale . . . 31
3.2.2 Structure & representation of design rationale . . . 36
3.2.3 Rationale storage & retrieval approaches . . . 40
3.3 Capturing configuration rationale in naval architecture . . . 41
3.3.1 Organic approaches. . . 42
3.3.2 Computer supported general arrangement design . . . 46
3.3.3 Capture of rationale consequences, not the rationale itself. . . . 50
3.4 Interesting applications outside naval architecture . . . 53
3.5 Summary . . . 55
4 Theoretical basis of a Rationale Capture Tool (RCT) 57 4.1 Requirements of a RCT in ship design . . . 58
4.2 Reactive Knowledge Capturing (RKC): a new elicitation approach . . . 62
4.2.1 Motivation & general description of RKC . . . 62
4.2.2 Applying RKC to ship configurations . . . 65
4.2.3 RKC requirements for capturing configuration rationales . . . . 66
4.2.4 Summary . . . 66
4.3 RKC Proof-of-concept . . . 67
4.3.1 Proof-of-concept experiment . . . 67
4.3.2 Proof-of-concept results & observations . . . 71
4.3.3 Proof-of-concept conclusions . . . 73
4.4 Description of solutions. . . 75
4.4.1 Design generation . . . 75
4.4.2 Rationale representation & structure . . . 80
4.4.3 Human-computer conversion of proximity rules. . . 86
4.4.4 Storage of DR . . . 86
4.4.5 Methodology to expand rationale database. . . 86
4.4.6 Addressing usability issues. . . 89
4.5 Summary . . . 89
5 Design of a Rationale Capture Tool 91 5.1 RCT system architecture . . . 92
5.2 Design Generation Module (DGM). . . 94
5.2.1 Improvements to the Packing-based Ship Design Approach for rationale capturing purposes . . . 94
5.3 Graphical User Interface (GUI) . . . 98
5.3.1 GUI requirements. . . 98
5.3.2 Description of GUI . . . 98
5.4 Rationale Capture Module (RCM) . . . 104
5.4.1 Implementation of DRL for the capture of configuration rationale 104 5.4.2 Implementation of Alternatives . . . 104
5.4.3 Implementation of Claims . . . 107
5.4.4 Implementation of Goals . . . 108
5.4.5 DR Inference . . . 108
5.4.6 Miscellaneous elements of the RCM . . . 109
5.4.7 RCM example . . . 109
5.5 Storage of design rationale . . . 109
5.5.1 MySQL relational database. . . 109
5.5.2 Design Structure Matrix (DSM) . . . 113
5.6 Feedback mechanism . . . 116
5.6.1 Controlling design generation . . . 117
5.6.2 Searching the rationale database . . . 117
5.6.3 Conversion of text-based rationale . . . 119
5.6.4 Optimization-based feedback mechanism . . . 120
5.6.5 Objective function formulation. . . 123
5.7 Validation of the Rationale Capture Tool . . . 126
5.7.1 Number of designs to review . . . 126
5.7.2 Inclusion of DR in subsequent designs. . . 127
5.7.3 Source code. . . 128
5.8 Summary . . . 129
6 Rationale Capture Tool Demonstration & Evaluation 131 6.1 Test case goals . . . 132
6.2 Test case participants . . . 133
6.3 Description of test case . . . 136
6.3.1 RCT training . . . 136
6.3.2 Test case mechanics . . . 136
6.3.3 Additional caveats . . . 140
6.4 Test case preparations . . . 140
6.4.1 RCT trial runs . . . 140
6.4.2 Test case initial conditions . . . 141
6.4.3 Sample designs generated during RCT trials. . . 142
6.5 Test case analysis & results . . . 144
6.5.1 Evaluation of RKC methodology. . . 145 6.5.2 RCT effectiveness . . . 148 6.5.3 Usability of RCT . . . 156 6.6 Observations . . . 159 6.6.1 Abstracting design . . . 160 6.6.2 Description levels. . . 160
6.6.3 Conflicting RDF’s . . . 161
6.6.4 Expression of assumptions . . . 161
6.7 Test case limitations. . . 162
6.8 Possible improvements . . . 163
6.8.1 The level of detail is extremely important . . . 163
6.8.2 Range of feedback rationale . . . 163
6.8.3 Two fold capture of position . . . 163
6.8.4 Adjust the definition of systems and descriptors . . . 163
6.8.5 Visibility of expressed rationale . . . 164
6.9 Summary . . . 164
7 Possible Applications of Design Rationale 167 7.1 Rationale Wizard (RW) post-processing tool . . . 168
7.2 Publication of design rationale . . . 170
7.2.1 DR application in the design preparation process . . . 171
7.2.2 DR application in the design review process . . . 172
7.3 Generation of “new” designs with previously captured DR . . . 173
7.3.1 Overview . . . 173
7.3.2 Combination of configuration preferences across organizations . 175 7.3.3 Conclusion . . . 177
7.4 Visualizing the follow-on consequences of configuration decisions . . . 178
7.5 Blueprinting organizational knowledge . . . 181
7.6 Summary . . . 181
8 Conclusions & Recommendations 185 8.1 Contributions . . . 185
8.2 Conclusions and discussion . . . 187
8.2.1 Main conclusions . . . 187
8.2.2 Ancillary conclusions & observations . . . 188
8.3 Future research . . . 189
A Proof-of-Concept General Arrangement Diagrams 193
B OPV Library Based Spaces 197
C Test Case Directions 203
D Usability Questionnaire 207
E RCT Database 211
Bibliography 213
Samenvatting 227
Curriculum-Vitae 231
List of Publications 233
1.1 Construction of Noah’s Ark. . . 2
1.2 Design spiral in ship design. . . 4
1.3 System Based Design framework . . . 7
1.4 Cost-Knowledge-Freedom curve . . . 11
1.5 Dissertation overview . . . 16
3.1 Elements of a notional DR System . . . 30
3.2 JANUS Kitchen Constructor graphical interface . . . 35
3.3 Diagram of relationships between issues, positions & arguments in IBIS 39 3.4 Summary of Decision Representation Language (DRL) vocabulary . . . 40
3.5 Rational Doors Software . . . 44
3.6 Development of object contact diagram and resulting superstructure layout 46 3.7 “Circles of Influence” created from designer preferences . . . 47
3.8 Case Based Reasoning (CBR) in concept ship design . . . 48
3.9 Architecture of an Expert System (ES) for concept submarine design . . 49
3.10 Fuzzy location preferences in general arrangements design . . . 51
3.11 Numerical adjacency values in general arrangements design . . . 52
3.12 ALDES (Accommodation Layout Design Expert System) . . . 53
3.13 BAE Systems DEGA ship configurations . . . 54
3.14 Preference selection using interactive genetic algorithms . . . 55
4.1 Reactive Knowledge Capturing (RKC) process . . . 64
4.2 General arrangement diagram of a Naval Supply Ship . . . 65 vii
4.3 3-D design generated with the Packing-based Ship Design Approach . . 79
4.4 Interactions potential between individual and zone defined objects. . . . 80
4.5 Graphical example of DRL . . . 83
4.6 Summary of rationale problems and solutions . . . 90
5.1 Rationale Capture Tool system architecture . . . 93
5.2 3-D vs. 2.5-D matrix description . . . 94
5.3 2-D rendering of vessel design . . . 95
5.4 2.5-D rendering of vessel design . . . 96
5.5 NL Offshore Patrol Vessel (OPV) . . . 96
5.6 Concept USCG Offshore Patrol Vessel (OPV) . . . 96
5.7 OPV operations template . . . 97
5.8 Illustration of the key features of the RCT Graphical User Interface (GUI) 99 5.9 Visualization of longitudinal cross-section of ship . . . 100
5.10 Visual description of layered design view . . . 101
5.11 GUI zooming functionality . . . 102
5.12 GUI filter menu . . . 103
5.13 Illustration of Rationale Capture Module (RCM) . . . 105
5.14 Definition of global positions in a vessel . . . 106
5.15 GUI implementation of Rationale Claims . . . 107
5.16 Example of error warning. . . 109
5.17 Graphical example of DRL . . . 110
5.18 SQL database description forDESIGNER TABLE . . . 111
5.19 SQL database description forDESIGN TABLE . . . 111
5.20 SQL database description forRATIONALE TABLE . . . 114
5.21 3-D Design Structure Matrix (DSM) . . . 115
5.22 DSM identification of object interactions. . . 118
5.23 DSM identification of missing object interactions . . . 118
5.24 Feedback mechanism block diagram . . . 121
5.25 Multi-objective optimization pareto front. . . 124
5.26 Inclusion of configuration rationale in a computer-generated design. . . 128
5.27 Pareto front depicting the compromise between the “triggering” of inter-actions and inclusion of rules . . . 128
5.28 GUI command window illustrating the inclusion of user expressed rules in design. . . 128
6.1 Test case activity diagram. . . 138
6.2 Functional color scheme used in test case designs . . . 142
6.3 First design in a RCT trial run . . . 142
6.4 Second design in a RCT trial run . . . 143
6.5 Third design in a RCT trial run . . . 143
6.6 “Prompt” mode in a RCT trial run . . . 144
6.7 “Unconventional” design generated by the RCT . . . 146
6.9 Adjacency matrix for third design . . . 147
6.10 Questionnaire results concerning RKC approach. . . 148
6.11 Rationale Wizard (RW) GUI . . . 149
6.12 Summary results of DR expression . . . 150
6.13 Rationale characteristics . . . 157
7.1 System diagram of rationale (re)use . . . 168
7.2 Color coding RDF quality . . . 170
7.3 Rationale Wizard (RW) GUI . . . 171
7.4 Design #1: Optimization-based design with configuration preferences (20 generations) . . . 175
7.5 Design #2: Optimization-based design with configuration preferences (50 generations) . . . 176
7.6 Design #3: Optimization-based design with configuration preferences (50 generations) . . . 176
7.7 Optimization-based design with an additional RDF . . . 177
7.8 Visualization of design interactions. . . 179
7.9 Description of preferable bridge positions in selection approach . . . . 180
7.10 Combined DMO & USCG goals . . . 182
A.1 Profile view of notional frigate using during proof-of-concept. . . 194
1.1 Generic description of knowledge types in ship design . . . 8
2.1 Typical concept design deliverables . . . 21
3.1 Examples of distinctive semi-formal representation schemas . . . 38
3.2 Classification of prior knowledge capture efforts for general arrange-ment design . . . 43
4.1 Shipboard spaces included in the RKC proof-of-concept experiment . . 68
4.2 Proof-of-concept instructions . . . 69
4.3 Expression of interactions during proof-of-concept testing . . . 70
4.4 Mapping proof-of-concept interactions to design goals . . . 72
4.5 Proof-of-concept user comments . . . 72
4.6 Examples of computer-based ship design software in naval architecture 78 4.7 List of Relevant Design Feature (RDF) predefined descriptors. . . 84
5.1 Offshore Patrol Vessel (OPV) model variables . . . 97
5.2 RCM priority descriptors . . . 105
5.3 List of predefined rationale goals. . . 108
5.4 Functional association of objects in OPV model . . . 116
5.5 Human to computer conversion of RDF’s . . . 120
5.6 Design constraints used in the RCT. . . 126
5.7 Examples of sample RDF’s included in later designs . . . 127 xi
6.1 Test case goals and assessment metrics . . . 134
6.2 Defence Materiel Organisation (DMO) test case participants . . . 135
6.3 U.S. Coast Guard SFLC test case participants . . . 135
6.4 Time required for participants to complete the test case . . . 145
6.5 DMO rationale classified by goal . . . 152
6.6 USCG rationale classified by goal . . . 152
6.7 RCT usability dimensions. . . 158
6.8 Examples of conflicting RDF’s . . . 161
CIC Combat Information Center
COR Configuration Optimization Routine DEGA Design of Efficient General Arrangements DGM Design Generation Module
DMO Defence Materiel Organisation DNV Det Norske Veritas
DR Design Rationale
DRL Decision Representation Language DSM Design Structure Matrix
ES Expert System
gIBIS Graphical Issue Based Information System GUI Graphical User Interface
HOS Hyper-Object Substrate I/O Input/Output
IBIS Issue Based Information System xiii
LCB Longitudinal Center of Buoyancy LCG Longitudinal Center of Gravity MES Marine Evacuation System OPV Offshore Patrol Vessel
PHI Procedural Hierarchy of Issues R&R Record & Replay
RCM Rationale Capture Module RCT Rationale Capture Tool RDF Relevant Design Feature RHIB Rigid Hull Inflatable Boat RKC Reactive Knowledge Capturing RW Rationale Wizard
SBD System Based Design
SFLC Surface Forces Logistics Center TLRs Top Level Requirements USCG United States Coast Guard VLS Vertical Launch System
1
Introduction
To improve understanding is for two ends; first our own increase of knowledge; secondly, to enable us to deliver that knowledge to others. -John Locke We sometimes forget why certain decisions were made and we often forget that in our Navy’s case -our organizations, processes, and policy represent the culmination of 234 years of lessons learned. -ADM J.C. Harvey, Jr., USN (2010)
The Old Testament Bible story of Noah and the ark, purportedly dating back to about 1000 B.C., describes one of earliest sea-worthy vessels1. The vessel was made out of
gopher wood and meant to house both people and a variety of animal species for 40 days and 40 nights. It had features such as windows and doors, as well as space for provisions (see Figure1.1). In addition, the ship was designed to withstand unpredictable turbulence, various water depths, and miscellaneous obstacles while afloat. The designer was given specific directions and with great faith built a magnificent vessel.
Unlike Noahs situation, the decisions taken in ship design and their justification, i.e. the rationales, are rarely received by “divine inspiration.” Instead, they develop from ex-perience, judgement, and in some cases, simply preference. Design rationales can add
1See Bible OT, Book of Genesis (chapters 6-9)
Figure 1.1: Construction of Noahs Ark (Schedel,1493)
knowledge to the design process, help improve individual designs, facilitate the transfer of design experience from senior to junior personnel and steer research and development. Unfortunately, human expression of rationale in the design process is implicit. As a result, design rationales are rarely captured, in spite of the benefits they provide. Two contemporary examples may help illustrate this point further.
During the (re)design of a popular car model, automotive engineers at Ford Motor Company wrestled with the lack of rationale concerning its development:
When car developers at Ford Motor Company wanted to learn why the original Taurus design team was so successful, no one could tell them. No one remembered or had recorded what made that effort so special; the knowledge gained in the Taurus project was lost forever. The most valu-able asset in any company is probably also its most elusive and difficult to manage: knowledge (Davenport and Prusak,2000).
A similar circumstance recently occurred in Amarillo, Texas when the U.S. began to disassemble its most powerful nuclear bomb nearly 50 years after it was put into service at the height of the Cold War. The disassembly process was protracted, largely in part to an absence of knowledge. Since theB53bomb was made using older technology, by engineers who have since retired or have passed away, developing a disassembly process took time. Engineers had to develop complex new tools and disassembly procedures in order to ensure the safety of those involved with the project (Blaney,2011).
In naval architecture as well, decisions in the design process and their attending ra-tionales are extremely important and influential. They should be expressed and captured! This thesis presents a methodology for capturing configuration rationale in complex ship design. Although design rationale is applied in all stages of ship design, configur-ation design (spatial arrangement) was specifically chosen as the area of concept design that might most benefit from the explicit expression of rationale. General arrangements not only constitute a principal deliverable of concept design, they require significant reasoning, which is often times implicit. Capturing configuration rationales can provide a history, justification, and a baseline for technical comparison of design attributes across relatively similar designs. In addition, the (re)use of configuration rationale in ship design may offer opportunities to improve the design process of complex ships. The motivation, description and outline of this research follows.
1.1
Background
1.1.1
The
rationale behind design rationale
Decisions are a hallmark characteristic of design. Design involves the translation of abstract and intangible customer needs into the concrete expression of an artifact. This is an extremely difficult task commonly characterized by the following attributes (Kunz and Rittel,1970;Andrews,1998;Erikstad,2004;Conklin,2005):
1. Ill-defined. The design problem is ill-defined with requirements that are often poorly specified, vague, conflicting and, in some cases, incorrect.
2. Open-ended. The design problem has a large degree of design freedom. Al-though constraints imposed on the design problem can reduce the design space, e.g., physics (first principles), availability of technology, budget or time, there is no prescribed set of solutions.
3. Complex. There are so many different aspects to design problems that it is dif-ficult to cope with them simultaneously. One of the biggest challenges in design is resolving the dependencies and interrelations among the different sub-problems and functions (Moran and Carroll,1996).
4. No “right” or “wrong” solution. Solutions to design problems are not singular, but relative, e.g., better or worse, and do not normally contain or require definitive answers.
To resolve the ill-defined and complex nature of design problems, designers typically adopt an iterative and sequential approach (Evans,1959;Andrews,1998). Figure1.2 il-lustrates the classic design spiral in ship design. This approach allows continual revision,
Figure 1.2: Design spiral in ship design (Evans,1959)
integration and estimation of the design and its resulting performance. Through sub-sequent iterations of the design, it becomes better defined, thus resulting in an increased awareness and understanding of the design2.
Yet, because the design space is also unbounded, i.e., open, it must be reduced in order to commence the design and to allow it to proceed. To do this, decisions must be
taken. Decisions enable the design process to progress, thereby achieving the goal of an
artifact within prescribed time and budgetary constraints (idealized case). The decisions taken also have a direct impact on the quality of the resulting design and offer a source of relative improvement among similar and competing designs.
The aforementioned text characterizes design as an end-state, i.e., the production of an artifact. Characterizing design as a process is also useful because it highlights the fact that design occurs wherever decisions are taken. In this view, it is important to recognize that design occurs at every stage of the design process. Every station on the spiral shown in Figure1.2has some element of design in so much as decisions are taken. For example, designers take decisions concerning the definition of missions, functions or the selection of one system over another. Human inventions, e.g., performance prediction tools, requirements, constraints and criteria can be further defined in each station on this cycle.
Taking decisions is a defining characteristic of design. Design can be interactive or iterative, but ultimately it is a decision process and decisions are based on knowledge. Since not taking decisions is not an option (Erikstad,2004), one of the most important objectives of the designer is to make the best decisions possible. This not only requires
an awareness of the decision itself, but also demands an understanding of the reasoning behind the decision, follow-on impacts and consequences and potential alternatives, i.e.,
the rationale.
1.1.2
What
is design rationale?
The type of knowledge captured in this research is design rationale. The epistemolo-gical roots of knowledge are not provided in this dissertation3. For the purposes of this
research, it is sufficient to recognize that design rationale constitutes one type or clas-sification of knowledge. Other examples of knowledge pertinent to ship design include process knowledge and object knowledge.
One difficulty with design rationale is that it is not immediately obvious what design rationale is. So, what is design rationale? Simply defined:
Design rationale (DR) captures the reasoning behind design decisions
It is also worthwhile to note that because rationales are often based on experience and acquired through the praxis of work they generally contain an element of commercially competitive or sensitive information.
Rationale is valuable because it provides insight into the intent behind the original decisions. Historically, design rationale has been used to support quality assurance as-pects of design. Rationales convinced stakeholders that designers were doing the correct things. As such, the primary motivation to capture design rationale was to make explicit and preserving reasoning that can be lost (Moran and Carroll,1996).
But, the capture of design rationale for documentation purposes only is shortsighted.
MacLean et al.(1991) claim that design rationale is not only a description of the design space but also a means to deliberate design decisions. Similarly,Lee(1997) suggests that design rationales also contain the alternatives considered, the trade-off’s evaluated and the argumentation that led to the decision. These examples suggest another important purpose of design rationale: application. There is no point in capturing rationale unless we are going to do something with it. These descriptions of design rationale are rich and provide further insight into the potential benefits of rationale capture.
Since the capture of all design rationale in the ship design process is beyond the scope of this work, it becomes important to recognize which decisions (and rationales) in the ship design process may be most useful to explicitly express and capture. This is considered in the proceeding sections.
3SeeThe Royal Academy of Engineering(2009) for philosophic discussion of knowledge and the nature of
1.1.3
Rationales in the conceptual design of complex ships
We must first recognize that decisions are taken in all phases of the design process. In good design practice, every decision should be justified by rationale! For example, con-sider the decisions associated with the hypothetical selection of a weapons system for a naval vessel4. First, the functions to meet a particular mission or operation are de-termined. A warship may have the functional requirement to neutralize enemy targets or to protect vessel against enemy attack. Next, the designer transforms the functional requirement of “fight” into some particular kind of combat system. For example, this might require the selection of a missile system as opposed to a gun system. The process continues further whereby detailed requirements are prescribed, “MK 41Vertical Launch System with MK21 SEASPARROWmissile.” The system is then configured with other systems in the design, i.e., specifically given a location. It is important to acknowledge that each of these design tasks has rationale associated with it. In this sense, rationale evolves or develops in parallel with the design process.
While decisions are taken (and rationale are expressed) during all phases of the design process, they are most important during concept design. During the conceptual design phase, an exceptional number of decisions are taken.Andrews et al.(2006) estimate that 90% of the major design decisions have been made when less than 10% of the design effort has been extended. These decisions have a direct influence on the quality of the resulting design. If improper or inferior decisions are taken, the resulting design can be suboptimal, or in the worst case, fail5.
Decisions taken during the concept design phase also have a significant impact on the design cost. Mileham et al.(1993) suggest that 70% to 80% of the life-cycle cost of the product [design] are determined by the designer’s decisions during the early stages of design. Decisions made in concept design are often difficult to change or reverse (at later stages of the design process) and can be financially costly and lead to additional delays in production.
What is conceptual ship design?
Conceptual ship design6 generally involves the definition of the exterior ship, internal subdivisions and development of general arrangement plan. In addition, parallel design development in a number of other areas such as system integration, system design and platform effectiveness also commence during concept design.
To manage the complexities of ship design, designers often choose to adopt a Sys-tems Engineering approach (or similar methodology) to establish dependencies between function and form7. As such, one of the key activities in conceptual ship design in-4The purpose of this example is to illustrate the different rationales that are present in the design process as
decisions are made from function to form to detailed design.
5This presumes a sequential, “no regret” approach in design. 6Often called preliminary design in the commercial maritime industry 7This in itself is a decision (Andrews,2007).
volves the translation of design function to design form. The functional description of the design serves as a basis for the identification of the resources necessary for the sys-tem to accomplish its mission (Blanchard and Fabrycky,2006). Typically, this involves translating design and mission requirements into detailed design criteria and identifica-tion of resources. The objective of this descripidentifica-tion is to specify theWHATSin the design, not theHOWS.
Figure 1.3: System Based Design (SBD). Framework illustrating the relationship between function and form. The combination of function and form result in the over-all performance and effectiveness of the design.
On the other hand, the physical architecture, or form, primarily describes the system structure, the configuration of systems and components as well as both the functional and physical integration of systems. Through application of the systems engineering process, questions ofWHATevolve into descriptions ofHOW8.
This relationship between function and form is illustrated in a contemporary view of the System Based Design (SBD) process shown in Figure1.3. In complex ship design, form typically follows function as naval architects are more concerned with the design of an functional artifact9. In the context of design rationale, this is an improved view of the
design process because it illustrates the complexity of design, especially the relationships and interactions between different activities, systems and objects in the design.
8This serves as the technical response to the functional description of the design
9In other disciplines, especially those which are visually led, e.g., architecture or graphic design, function
Knowledge Types
Dimension Hard Soft
Characterization Explicit Implicit or tacit
(Mistree et al.,1991)
Source Science Experience
(Milton,2007)
Acquisition Taught Observation &
participation
Description10 WHATorTHAT HOWorWHY
Basis Scientific11 Reasoning12
Articulation effort Easy Difficult
(Schreiber et al.,2000)
Capture effort Easy Difficult
Storage effort Easy Moderate
Table 1.1: Generic description of knowledge types in ship design. Knowledge is classi-fied across multiple dimensions.
Knowledge in conceptual ship design
Although countless decisions occur in both the functional and form description of ship design, the type and source of knowledge generally required to support each varies. Table
1.1shows a comparison between different classifications of knowledge in ship design. In ship design, knowledge can be categorized as knowledge about the product, i.e.,
theWHAT,and knowledge about its justification or rationale, i.e., theWHY. Some of the
information used in making a decision may be hard, that is, based on scientific principles and some information may be soft, that is, based in the designers judgement and experi-ence (Mistree et al.,1991).
Knowledge used to support functional decisions, theWHAT, is predominantly sci-entific, quantitative and easily calculable. It is often documented in calculations, models and simulations. In most cases, the static nature and availability of this type of know-ledge supports natural expression and acquisition; therefore, the majority of knowknow-ledge has already been captured, e.g., class rules, industry standards and technical performance measures. In many cases, calculations are documented, stored and often checked by other
10Magee(1987) suggests that knowing HOW distinguishes the expert from the highly educated.
11can be calculated, often the results of an analysis
members of the design team. The additional work to (re)capture them is superfluous. On the other hand, the decision knowledge required to choose proper systems and components, and their resulting configurations, theWHY, is often tacit, qualitative and not explicitly available. Rationales of this type, based on experience and acquired through the praxis of work, are very difficult to capture, structure and store.
Although design rationale appears in nearly all aspects of the design process, it would be particularly valuable during the configuration design of complex vessels. In general arrangements, the decision knowledge required to identify the relationships, i.e., interac-tions, between objects in the design is often tacit, qualitative and not explicitly available. This becomes the focus of this research.
General arrangements in conceptual ship design
This thesis focuses on capturing the rationale in configuration design, i.e., the general arrangements of complex ships. Specifically, ship arrangements require a lot of reasoning and do not often stem from the result of explicit knowledge, e.g., calculations.
Development of a ship arrangement plan is one of the most critical aspects of a ship’s design. It is an integral part of the design development, during each phase of design, due to of three significant factors (Carlson and Fireman,1987):
1. Functional integration. There is increased emphasis on integrating the individual functions of a ship to form an integrated ship system. As ships become more and more complex, the interactions between the different systems or objects become increasingly important. Improper configurations of systems or sub-systems can often result in reduced or impaired functionality.
2. Spatial requirements. Most naval ships are space critical, their size and resulting costs being governed by spatial requirements. Service ships designed to carry out demanding operations at sea, often referred to as complex specials, also tend to be space limited, i.e., configuration driven by their required systems. Examples of these ships include patrol ships, dredgers, pipe-laying vessels and floating produc-tion storage and offloading (FPSO) vessels.
3. Role in design process. The iterative nature of complex ship design requires ship arrangement. It is a necessary input to most other ship design tasks including the calculation of weight centers, structural analysis, etc.
Unfortunately, the task of determining general arrangements for a complex vessel in-cludes many factors that are difficult to capture with conventional engineering methods. The layout of spaces in complex vessels represents unique blend of experience, judgment and tradition. For example, factors such as habitability, operability and convenience are difficult to describe quantitatively; however, without specific consideration in concept design, can result in difficulties for the ship and crew’s overall functioning.
Given a collection of objects in a design, there are two primary categories of ra-tionales in configuration design:
1. Interactions. Interactions describe the spatial relationship between objects in the design and the justification. AsHagen (1993) notes, when researchers discuss design they talk about how things relate. Interactions describe preferred object proximities and the reasons, i.e., rationale, justifying such relationships. Inter-actions help capture the question: “What relationships do designers think about when making configuration decisions?” Interactions stem from the assumption that everything is related to everything else.
2. Compromises or trade-off’s. Given a collection conflicting or competing inter-actions, what is the preferred priority of the interactions?
In order to have a complete picture of design, both types of rationale are required. In the end, the expression of interactions (and their justification) plus the ensuing com-promises, explains why ships look the way the do!
Interactions + Compromises = Why ships look they way they do
In this dissertation, the capture of interactions is tackled first, with peripheral con-sideration given to trade-offs13. In this context, interactions are defined as the reasons
why objects should or shouldnt be located close to one another. Identification of interac-tions between objects is important because they motivate proper analysis in design, e.g., specialists will only perform analysis if interactions between objects exist.
Interactions can be further categorized: structural description of the concept and func-tional expectations, i.e., the roles that these parts fill. This work specifically focuses on the latter, identifying preferred object proximities and rationales on the presumption of functional expectations. To resolve these problems, a systematic approach to capturing configuration rationale should be developed for complex ship design.
1.1.4
Benefits of rationale in conceptual ship design
The potential benefits of configuration rationale are numerous and provide improvements to both the conceptual design process as well as the resulting design, i.e., the ship. Process improvements
First, rationales serve to support the decision making process during concept design. Rationales can help detect interactions, conflicts, “choke points” and gates in general arrangement design. Another added benefit of rationale (knowledge) is that it can help
identify potential problems in the design. Once a problem is detected or suspected, hu-mans can model or simulate it, i.e., gain additional knowledge about it. In the end, this can result in improved efficiency of the ship configuration design process and the human acceptance of ship designs generated by it.
Rationales also have the potential to increase the relative quality of knowledge in the ship design process. The “Knowledge-Cost-Freedom” curve shown in Figure 1.4
illustrates the benefits of increased knowledge during the early stages of design. As knowledge becomes available earlier in the design process, design freedom increases, committed costs can be postponed to a later point in the design cycle and overall design time can be reduced. This is especially important during times of economic uncertainty where fiscal reductions often result in a cutback of new ship orders.
It is important to note that the curves in Figure1.4are not independent; the increased knowledge comes at a cost, i.e., it requires both decisions and capture effort, both of which, in fact, could reduce design freedom. Increases in design freedom are realized as a savings in time once the captured knowledge (a sunk cost) is (re)used in future designs.
Figure 1.4: Distribution of cost, knowledge and design freedom during the early stages of design (Mavris and DeLaurentis,2000)
Design improvements
There are many potential benefits that could result from the application of rationale to the design (Gruber and Russell,1991;Lee,1997; Burge,2005). The most promising applications of design rationale in naval architecture are listed below:
quality assurance and traceability. Documentation supports design work by mak-ing explicit and preservmak-ing reasonmak-ing that can be lost, i.e., institutional memory14. 2. Validation. Design rationale can be used to validate design requirements and pro-ject assumptions. It is extremely important to quantify design assumptions instead of merely accepting conventional wisdom; this is especially important in the cur-rent environment of reduced budgets and increased oversight.
3. Evaluation. Design rationales can be used to evaluate and rank designs. Rationale can also be incorporated into the design process to improve the final design ( Brat-thall et al.,2000;Tang et al.,2008).
4. Communication. Design rationale can support the communication of design de-cisions and their consequences to colleagues, customers and other stakeholders. Rationale also improves the internal communications of the design team by shar-ing discipline-specific knowledge across the design team15. Shum (1991) and
Buckingham-Shum and Hammond(1996) detail additional people-related and psy-chological effects of rationale in communication.
5. Learning. Rationale can be (re)used as a tool to complement the training of junior naval architects. The benefits for both the industry and the naval architect include improved knowledge, increased competence and reduced training time.
The potential benefits of design rationale in the conceptual ship design process are numerous; therefore, rationales should be captured properly. Unfortunately, this is an extremely difficult task and is described in further detailed in Chapter2.
1.2
Research motivation
Although rationale has been studied in other disciplines, e.g., software engineering (Gruber and Russell,1991;Burge,2005) and in the design of mechanical systems (Garcia and Howard,1992), it has not been well researched in naval architecture.
Examples of rationale capturing in naval architecture focus predominately on captur-ing the consequences of rationales, instead of the rationales themselves (Nick,2008;Lee et al.,2003). Other examples in this field capture only “hard” knowledge in the form of rules and regulations (Helvacioglu and Insel,2005;Robb et al.,2002)16.
Despite the growing recognition of the value of rationale in the design process, there is a lack of appropriate support mechanisms, guidelines on the essential elements of
14This is especially important for the ship design community as staffs are shrinking and the number of
retirements are increasing. SeeKeane et al.(2009) andPung et al.(2008) for specific details on trends in Naval Design Staffs.
15Vertical hierarchy of knowledge becomes horizontal.
design rationale, how to capture design rationale, how to store it and how to apply it. Only with explicit expression of design rationale, can the improvements outlined in Sec-tion1.1.4be realized. The current approach of capturing configuration rationale in ship conceptual design is unsatisfactory and inefficient, and leaves much room for improvement.
1.3
Objectives of research
1.3.1
Research questions
In the context of the preceding sections, the main research question is presented:
How can configuration rationales resulting from experience, judgement and preferences be captured in the conceptual design process of com-plex ships?
The main research question outlines the development of a systematic process for rationale capture in complex ship design. In order to answer the main question, several supporting research questions must also be addressed:
1. Expression of DR. In the normal course of design, designers often have difficulty expressing DRs. How do designers express DR’s? What methods can be used to elicit rationale from designers?
2. Structure of DR. Design rationale attributes are often qualitative, inconsistent, and not provided to designers in a format they can easily use. How can rationales be structured so that they are (re)usable in similar ship and novel vessel concept design?
3. Storage of DR. A variety of mediums are available to store DR. Which is the best? How can it be done?
4. Validation of DR. How can rationale be assessed and validated?
5. (Re)use. (Re)use is a primary incentive for capturing DR. How can rationale be (re)used in the design process? How can knowledge about the (re)use of DR influ-ence the methodology or approach used for expression.
These supporting objectives provide a pathway or approach for the reminder of the thesis. For the purpose of clarity, and to accurately define the boundaries of this research, the following recognized limitations are described:
• This emphasis of this research concerns the impetus and methodology for
captur-ing design rationale. Although possible applications of configuration rationale are demonstrated later in this thesis (Chapter7), they serve as an example of potential design benefits and do not constitute the focus of this research.
• There are numerous types of important rationale in the ship design process. The
fo-cus of this research concerns only the capture of configuration rationales, specific-ally, those rationales describing interactions between objects in the ship design.
• Although the rationale elicitation approach developed in this thesis may support
the capture of other types of rationale in ship design process, it is not demonstrated here. Further research is required to determine whether this approach is generic enough to support the elicitation of other types of rationale.
• This research does not form a ship integration or ship synthesis tool, in spite of
the fact that feasible designs are generated as a result of the capture methodology. Nonetheless, we posit that incorporation of the rationale generated by this research may be a substantial improvement to current ship design synthesis models.
• Since system selection is an input to configuration (see Figure1.3), this research assumes that the functional identification of design components is correct. Some of these items offer opportunity for future research and are discussed further in Chapter8(Conclusions & Recommendations).
1.3.2
Originality & contribution
Up to now, research in rationale has focused primarily in software and computer engin-eering (Gruber and Russell,1991;Lee,1997;Burge,2005). This research expands these concepts to complex ship design and results in the following original contributions:
1. The systematic capture of configuration rationale in complex ship design. This results in a collection of relationships, interactions and rules between systems and components in design. A methodology to link specific configuration preferences to ship performance is also presented. To the best of the author’s knowledge, research in this field has never been conducted.
2. The development of a novel rationale capture approach: Reactive Knowledge Cap-turing (RKC). RKC employs reflection as a catalyst to formalize designer reaction to an unsatisfactory and unconventional design experience. By exposing designers to a diverse set of designs, they reflect on whether to accept or reject the design configuration (or parts of it); this triggers the designers to express both the interac-tion and the underlying reasoning for object proximities.
3. As a result of this research, a computer-based Rationale Capture Tool (RCT) is developed. In this approach, the designer is promoted to create a better version of a ship configuration produced by the computer. The tool includes a Graphical User
Interface (GUI) and a dedicated optimization-based feedback mechanism aimed at improving the efficiency of the RKC process.
4. The final component of this research includes comprehensive case studies to demon-strate and evaluate the RCT developed as a product of this research. Rationale capturing test cases are performed with practicing naval architects from the Neth-erlands Defence Materiel Organization (DMO) and United States Coast Guard (USCG) Surface Forces Logistics Center (SFLC). Participants are not only able to use the interface for ship configuration, but are also able to provide feedback on their overall experience using the RCT.
This work also contributes to the field of naval architecture by improving the know-ledge behind computer-generated concept designs. Rationale, in the form of experiences and preferences, can be incorporated in the design process. The ability to critique extern-ally generated designs using some or all of the previously captured rationale, as well as the ability to identify conflicting rationales, is also demonstrated.
1.4
Method
The research approach first describes and analyzes the difficulties in capturing design ra-tionales. The specific focus concerns arrangements in conceptual ship design. Next, the advantages and disadvantages of rationale expression and capture techniques, represent-ation ontologies and storage methods in current literature are analyzed. The impact and applicability of these methods in the field of naval architecture are considered.
Using these results as a guideline, a novel capturing approach is developed. A proof-of-concept is successfully demonstrated and subsequently, a computer-based prototype Rationale Capture Tool is developed.
The tool is then validated by a series of test cases with practicing naval architects. Rationale from the test cases along with an analysis of a usability questionnaire allows an analysis of the work.
1.5
Organization of dissertation
The outline of this thesis is detailed in Figure1.5. The following paragraphs provide an overview of subsequent chapters and appendices.
Chapter2(Difficulties Capturing Rationale in Complex Ship Design) discusses the specific difficulties associated with rationale capturing in conceptual ship design. Pro-cess, methodological and human shortcomings are identified. A practical analysis of these problems and their consequences are addressed. Theoretical and practical strategies for addressing these difficulties are also described for consideration in the following
Figure 1.5: Organization of dissertation by chapters and processes
chapter.
Chapter3 (Relevant Research) presents an overview of the literature in rationale capturing. In this chapter, rationale capturing is defined as a process consisting of the following tasks: expression, structure, storage and (re)use. Current literature approaches to complete these tasks are surveyed.
Next, rationale capturing research in naval architecture is reviewed. Industry-specific requirements, trends, practices and demands are also highlighted. This chapter concludes with recommendations for the most suitable aspects and features of a rationale capture approach for conceptual ship design.
Chapter4(Theoretical basis of a Rationale Capture Tool (RCT)) describes the top level requirements of a rationale system based on previous chapters. It introduces Re-active Knowledge Capturing (RKC), as a novel solution to the expression problem.
Ra-tionale is captured in a design review setting in which the designer reacts to a set of unconventional and unorthodox designs. A simple proof-of-concept demonstrates the ability of this approach to capture implicit design knowledge and rationale from naval architects. Other aspects of the concept solution, such as the structure and storage of design rationale, are also presented.
Chapter5(Design of a Rationale Capture Tool) is the central chapter of this thesis. It describes the detailed implementation of a computer-based prototype Rationale Cap-ture Tool (RCT). The specific architecCap-ture of the RCT is detailed. Modules describing design generation, rationale capture, rationale storage and the implementation of feed-back mechanism are presented.
Chapter6(Rationale Capture Tool Demonstration & Evaluation) describes the test case performed with the Rationale Capture Tool. An overview of the test case goals, participants and testing approach is presented. Practicing naval architects use the tool in practice and respond to their overall experience with it.
Chapter7 (Possible Applications of Design Rationale) demonstrates possible ap-plications of captured configuration rationale. It relies on the rationale database which has been generated in the previous chapter. A graphical user interface is used to generate new designs (incorporating expressed rationale) and to also visualize the dependencies between objects in vessel design.
Chapter8(Conclusions & Recommendations) draws a number of conclusions from experiences in this research and also suggests ideas for future research.
2
Difficulties Capturing Rationale in
Complex Ship Design
Risk comes from not knowing what you’re doing. -Warren Buffett There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say there are some things we do not know. But there are also unknown unknowns; the ones we don’t know we don’t know. -Donald Rumsfeld
The previous chapter described design as a knowledge intensive activity in which the primary role of the designer is to make decisions. As such, improvement to the design process requires a better understanding of design decisions and their attending rationales. Configuration rationales represent one aspect of concept ship design where know-ledge is implicit, generally unavailable and difficult to capture. In spite of this, these rationales have promising applications in the ship design process and, as a result, should be captured; unfortunately, this is easier said than done.
Rationale capturing has not been well studied in ship design. As a result, it is ne-cessary to perform a comprehensive assessment of the problem(s) at hand. This chapter describes the distinct difficulties associated with capturing rationale in ship design. Al-though the specific focus of this thesis is the capture of configuration rationale, the cap-ture problems are ubiquitous across all types of rationale and will be described as such, i.e., for the general case.
Section2.1describes the limited expression of rationale in the ship design process. Current design practices and deliverables do not explicitly demand design rationale; therefore, designers, rarely, if ever, express it. As a result, rationale is not readily
avail-able and therefore requires capture1.
Since rationale is rarely explicitly expressed in the ship design process, a systematic approach to rationale capture in ship design is missing. Section2.2describes common pitfalls of design rationale in the rare instances it is captured. This describes rationale deficiencies in the areas of content, structure and diversity. Design rationale is not always
appropriate or assorted. In addition, the informal and ad-hoc manner in which rationale
is captured contributes to a lack of structure. Without structure, it can be difficult to store rationale; as a result, rationale is not readily accessible.
Given the fact that rationale capture invariably involves interaction with a human, Section2.3explores the human issues of rationale capturing. This includes the role of the designer in the capture process as well as his or her reaction to the process. Additional challenges are also highlighted.
In the preceding sections, careful attention is given to describing the practical con-sequences of these problems and their impact on the design process. Section2.4 sum-marizes these details, and recommends strategies to solve the rationale capture problem in complex ship design. Possible solutions to these problems are considered in Chapter
3(Relevant Research).
2.1
Limited expression of DR in the conceptual design
process
As described previously, the conceptual design of complex vessels typically consists of two processes or descriptions. The functional description of the design aims to under-stand the needs and the requirements of the customer, whether it is a commercial interest or a government entity. In ship design, this involves a clear understanding of the vessel mission and desired performance attributes, such as speed or payload.
The second description concerns the physical architecture of the vessel or form. The form reflects the agreed understanding of the requirements between the naval architects and the customer; resulting in the practical realization of the concept design. The key
Concept Design Deliverables
System Id Calculations Arrangements
Performance specification Cost estimate General arrangement drawings Propulsion plant description Weight estimate Body plan and appendage sketch Description of mission critical systems Area/volume summary Machinery arrangement sketch Payload definition Endurance fuel analysis Topside arrangement sketch
Concept midship section Electric load analysis Speed-power curve Manning estimate Technical risk assessment
Table 2.1: Typical concept design deliverables for U.S. Navy and Government Ships (Lamb,2003)
products of this process usually consist of principal hull dimensions, hull form coef-ficients, area and volume balancing, performance estimates and a general arrangement drawing. A typical list of concept design deliverables for U.S. Naval vessels appears in Table2.1.
The deliverables shown in Table2.1highlight the first challenge of rationale capturing in ship design. Typically, standard design documentation only captures the consequences of design rationales, i.e., descriptions of the design, not the rationales or reasons them-selves. The explicit expression of rationale is required!
Although other outputs from the design process (absent from Table2.1) could the-oretically address the expression problem, practically speaking, they don’t. Common examples in ship design are outlined below2:
• Design guidance. Numerous examples of specific general arrangement guidance
(Brown,1987;Doerry,2006) or organizational general design notes (NAVSEA,
1992) lacks proper expression of design rationale. These examples describe pre-ferred ship configurations, they don’t explain the rationale behind the decisions, i.e., they describe what to do, but fail to explain why it is done. In this regard, they may capture important relationships, but fail to capture the reasoning behind these relationships.
• Design review meetings. Although design review meetings offer a prime
oppor-tunity to discuss reasons behind a design, a useful and mature discussion typically requires an experienced and talented workforce. Unfortunately, the relative in-experience of many design teams prohibits the effective expression of rationale, i.e., inexperienced designers lack the professional exposure necessary to form ra-tionales. As a result, design review meetings in naval architecture tend to focus on processes instead of design content (Brouwer,2010). Standardizing the expressed rationales can also be problematic.
• Design dossiers. While design dossiers can be useful3, they require employee
buy-in and often lack congruence on what should be captured. They are also subject to the limitations described under design review meetings.
In spite of the huge number of decisions they take during concept design, designers are not usually required to express4rationale. Design rationale is not a core deliverable,
and therefore, its explicit expression and capture are overlooked in the design process. Since none of the deliverables appearing in Table2.1demand a detailed expression of design rationale, it is often unavailable.
Compounding the limited expression of DR in the design process is the fact that de-signers are not judged or evaluated on the rationale behind the design, so there is no impetus to explicitly express or capture it. As a result, designers focus on the more tan-gible aspects of ship design, i.e., the physical description of the vessel, not the recording of the justification behind it.
As a result, the formalization, storage, transfer and (re)use of design rationale for a wide range of ship types is impossible. As illustrated by the following design scen-arios, this lack of detail can have a detrimental effect on both the design process and the resulting design:
1. One project, multiple designers. During one project with multiple designers, design rationales are disregarded. Without the expression of design rationale, the reasons behind the decisions of designers (individuals or groups) are isolated from one another. Unfortunately, this results in the formulation of local solutions and prevents naval architects from realizing the follow-on consequences of their de-cisions in a timely manner or at all.
2. Multiple projects, one designer. Over multiple designs, with one designer, the repetitive use of human judgment is forced. Without design rationale, the designer must reformulate many of the same interactions and trade-offs that appeared in earlier designs. For example, consider a hypothetical effort by the U.S Navy to replace its Perry Class Frigate with a similar design. The design rationale for this class of ship, designed in 1970s, primarily resides in the heads of the ori-ginal designers, who have either retired, are not available or cannot remember the specific design rationale. Because the rationale for the original design is unavail-able, designers must spend valuable time and effort rationalizing previous design decisions5.
3. One person, one project, one year on the job. A novice designer working on a single project cannot easily justify design decisions because (s)he lacks the exper-ience necessary to formulate design rationales6.
3See “ship cover” example in (Andrews and Pawling,2003).
4The commonly accepted definition of express is applied in this case: putting thoughts into words. 5This can be a dangerous practice, especially if previous decisions are incorrectly justified. 6For this reason, experience is valued in most organizations.
The ship design process discounts the explicit expression of design rationale. As a result, DR’s are not expressed during the normal course of design and remain invisible to the design process. Yet, this does not mean that designers haphazardly create designs; they certainly design with rationale. Designers use rationale in their designs, they just don’t express it. Consequently, rationale is not readily available, and its absence provides the initial motivation for its expression and capture.
2.2
Pitfalls of existing rationales (when captured...)
The preceding section describes a ship design environment that undervalues the expres-sion of design rationale. As a result, the explicit expresexpres-sion of rationale is rarely realized. Consequently, there has been limited motivation and incentive to develop the domain spe-cific tools, support and guidance necessary to effectively capture design rationale within the field of naval architecture7.
As a result, ship design rationales are typically expressed and captured in an ad-hoc and unstructured manner. This is unsatisfactory because it hinders the practical applica-tion of raapplica-tionale in design, i.e., the raapplica-tionale is not typically usable.
2.2.1
Expressed rationale lacks content
Content generally refers to something that is to be expressed through some medium, such as speech or writing. Due to a lack of standardization and direction, designers often capture the “wrong” content, resulting in irrelevant rationales. Without a disciplined capture method, designers are left to capture whatever they think is necessary, which varies with experience, professional specialty and preference. It is difficult to know the “right” rationale. Numerous examples in literature describe instances where designers, left to their own devices, capture rationales completely unrelated to the problems at hand, e.g., meeting schedules and weather (Shipman and McCall,1997;Magee,1987). This reveals an important quality of rationale: it must be appropriate.
Because there is no consensus on what type of rationales are useful in the ship design process, designers tend to capture “all or nothing.” This inattentive approach results in the capture of superfluous information, wasted time and meaningless content which ulti-mately limits rationale usefulness. Furthermore, designers become frustrated with fruit-less and time-consuming exercises; this creates another barrier to the acceptance of ra-tionale.
2.2.2
Design rationale lacks structure
Structure and representation are also important characteristics of design rationale. Without organization and structure, rationale can be difficult to understand. One of the most
chal-7Other fields, most notably computer and software engineering, have addressed various knowledge
man-agement issues, including rationale. Regli et al.(2000) present a comprehensive survey of design rationale systems.
lenging issues with design rationale concerns the development of an appropriate rationale representation.
An informal representation reduces the effort associated with the capture of rationale. Informal representation of design rationale requires extensive post-capture processing, such as sorting and retrieval, to realize useful benefits (Magee,1987) and also limits useful implementation of design rational in practice (MacLean et al.,1991;Lee and Lai,
1991). Although such inconveniences ultimately impact its (re)use, it is easy to capture and record. In addition, rationale captured in an informal representation is generally understandable by humans but cannot be easily implemented in a computer environment. On the other hand, a formal representation can easily be understood by a computer, but requires that rationale be structured in a rigid format. Burge(2005) notes that trans-lating the designers thoughts into a structured format is both labor intensive and likely to result in lost information and interpretation errors. A formalized structure for rep-resenting DR also enables the storage of it. Rationale accessibility and transferability make it useful and support (re)use in ship design. Semi-formal representations attempt to employ the advantages of both approaches, by capturing some aspects of rationale in a formal structured manner while others are informal.
Since designers don’t often know what they want to do with the rationale a priori, they usually capture it in whatever format seems most convenient at the time.
2.2.3
Expressed design rationale is limited in scope
Ship design has been described as complex and physically large scale design (Andrews,
2007). Given the size and complexities of the design, ships often look a lot a like. There are numerous underlying reasons for this:
1. Risk-avoidance. Risk-avoidance is a practice designers employ to often deal with time and funding limitations. With slim profit margins, designers and shipyard can be over cautious about accepting or developing radical designs. To minimize risk, designs often employ previously successful solutions.
2. Favoritism. Favoritism also perpetuates similar designs. It causes designers to return to the same design feature(s) over and over again. Observation of experts suggests that even when they have a large stock of experience8, they are likely to
have a limited range of favorite cases that they rely on as a basis of new designs (Gilovich,1981). This usually results in a collection of designs with similar or nearly identical design features.
3. Physics. To a lesser extent, first principles govern the principal characteristic of many vessels, especially those vessel which are cargo or speed sensitive. This is less true for system selection and arrangement of those systems on board the ship. 4. Training.Lamb(2004) notes that most practicing ship designers probably do not think too much about why they prepare ship designs the way they do; they do it
out of habit and probably learned it by following a mentor early in their careers. Rules-of-thumb and design traditions can also result from designer training. Although this can be a cost effective approach to ship design, from a rationale capture perspective, it merely perpetuates existing design (Robb et al.,2002). It often restricts creativity and does little to encourage novel and imaginative solutions to conventional problems and ultimately results in the creation of one-off designs9. Repetition and best
practices provide a limited assortment of rationale. These practices limit the diversity of design rationale expressed by naval architects. So even if rationale is available, ap-propriate and accessible it may still be difficult to effectively implement in design. De-signers often forget that best practices are only “best” in certain contexts and to achieve certain objectives. A change in context or the design objective can quickly transform a “best practice” into a sub-optimal approach (Reinertsen,1997), i.e., practice can quickly get disconnected from its intent and context. These, best practices, rules-of-thumb and design traditions, when overused by designers, result in the design of vessels with sim-ilar characteristics and features. In addition, these practices are often applied blindly, without knowing the underlying rationale and without an appreciation for the impact and consequences of these decisions.
On a practical level, the lack of diverse design rationales in ship design is trouble-some:
• It prevents a full and proper application of design rationale to other ship types
be-cause information is missing, i.e., the designer is missing or forgetting something.
• Forgetting relationships have important consequences later in the design cycle
res-ulting in large design changes and additional risk.
Achieving diverse rationale is especially difficult in naval architecture where design-ers don’t have the time or opportunity to consider many designs. In fact, it is not un-common for successful naval architects to only work on a handful of designs during their careers.
2.3
Obstacles to effective rationale capturing
The capture of design rationale invariably requires interaction with a human. While obvi-ous, this is a critical component of successful rationale capturing. At the end of the day, it does not matter how good the rationale capture method is (available and assorted), how well rationale is structured (appropriate) or how quickly it can be retrieved
(access-ible); if the designer is unable or unwilling to express rationale, every other aspect of the
approach is inconsequential.
9A “one-off” design describes a solution by which minor modifications are applied to a previously
