• No results found

1437pres

N/A
N/A
Protected

Academic year: 2020

Share "1437pres"

Copied!
21
0
0

Loading.... (view fulltext now)

Full text

(1)

Rob Bracewell

A Tool for Capturing

Design Rationale

Project Team

Rob Bracewell Ken Wallace

Funding

EPSRC UTP Core BAE SYSTEMS

(2)

A Software Tool Called DRed

• What is DRed?

• What do designers think of it?

• Where did it come from?

• How was it researched?

CAEDR Methodology

(3)

Rob Bracewell

What is DRed?

• Design Rationale (DR) editor

• An aid to designers that also captures DR for future use

• Used by aerospace designers from v0.1 onward

– just 3 weeks’ software development in v0.1

• Novel graph based derivative of the venerable IBIS

– DR captured in series of inter-linked planar graphs – like gIBIS, Questmap, Compendium, n-dim

(4)
(5)
(6)
(7)

Rob Bracewell

What do designers think of it?

• Questionnaire of trial users in Rolls-Royce:

• Found to be easy to use

– 14 out of 19 responses found easy or very easy

• Some immediate improvements to design process:

– 10 out of 10 found improved or slightly improved overall view of design process

– 7 out of 10 found improved or slightly improved keeping track of design process

– 6 out of 10 found improved or slightly improved evaluating and deciding between concepts

– No negative feedback, 0 out of 10 said hindered/slightly hindered design process

• Designers perceive future benefits. Main benefits:

– communicating to others 11 out of 14 designers – monitoring progress 9 out of 14 designers

(8)

A surprisingly positive response!

• DRed has some novel features, but is not unrecognisably

different from a number of earlier IBIS tools

• Consensus view, based on considerable research, has

been that this type of tool is not suitable for designers to

record their work

(9)

Rob Bracewell

How was the research conducted?

CAEDR

Methodology

• Fresh approach to researching software tools for

designers

• Proposed by Bracewell and Shea at ICED’01

• Emphasis on enabling early use and evaluation

of research prototype software in industry

(10)

CRITERIA

DESCRIPTION I

PRESCRIPTION

DESCRIPTION II

Measure

Influences

Methods

Applications Observation &

Analysis

Assumption & Experience

Observation & Analysis

Basic method Results Focus

(11)

Rob Bracewell Prescription Following Step Dependency Rapid Change Decide Visualisation, Interaction & Distribution Requirements Description II Criteria Description I

Define and Justify Measurable Criteria

Choose Knowledge Level Representations

Storyboard Tool in Context of New Design Process Specify Experiment and Data Collection Software Analyse Data Model Existing Design/ Process

Rapid Software Prototyping

S o c ia l S c ie n ce M e th o d o lo g y S u p p o r t E n g in ee ri n g S o ft w a r e D e v e lo p m e n t S u p p o r t Systems Analysis User Interface Design Computer Science/A I Data Analysis Method Selection Interview Techniques Observation Techniques Data Mining Experimental Techniques Interpretation CSCW Choose Knowledge Modelling Tools Choose Methods Knowledge Modelling

(12)

Prescription Criteria

Description I

2 Define and Justify Measurable Criteria (capture more rationale, improve its presentation)

3 Choose Knowledge Level Representations (IBIS-like graphs)

6 Storyboard Tool in Context of New Design Process (Graphs replace text for DDR Requirements, Alternatives & provide scheme folder map)

9 Decide Visualisation, Interaction & Distribution Requirements (Standard UI conventions, no info

lost in b/w print; paste into Word, cope with large projects,

run direct from CD)

13 Specify Experiment

and Data Collection Software

5 Model Existing Design/ Process (Structure design definition reports (DDRs) graphically)

Rapid Software Prototyping

4Choose Knowledge Modelling Tools

(Graphlet)

8 Choose Methods (Graphscript Tcl bindings

of GTL procedures)

11 Rapid Software Prototyping (8 releases in 8 months)

12 Formative evaluation (core team 6 designers in RR, 1 in BAE)

7 Choose Implementation

Level Representations

(GTL graphs, gml files)

1 Overall Success Criteria (Identify/solvecritical problems

faced by designers in KCSR)

10 Choose Development Tools

and Components

(Graphlet, TclPro, Ghostscript/GSView, BLT, Img, Schwartz)

(13)

Rob Bracewell

CAEDR

: Issues Crucial to DRed

Description I Stage

• Choice of knowledge level representation

(IBIS-like graphs), knowledge modelling tool

(Graphlet), and iterative use modelling rationale

from real designs (RR design reports)

– Found effective way of structuring/presenting rationale – Effective demonstration of potential of research to

(14)
(15)

Rob Bracewell

CAEDR

: Issues Crucial to DRed

Description I Stage

• In choosing Graphlet, looking forward to the

Prescription Stage, for

– ability to provide suitable implementation level representations and methods

(16)

Description I

3 Choose Knowledge Level Representations

(IBIS-like graphs)

6 Storyboard Tool in Context of New Design Process (Graphs replace text for DDR Requirements, Alternatives & provide scheme folder map)

5 Model Existing Design/ Process

(Structure design definition reports (DDRs) graphically)

Rapid Software Prototyping

4 Choose Knowledge Modelling Tools

(Graphlet)

8 Choose Methods (Graphscript

Tcl bindings of GTL procedures)

(17)

Rob Bracewell

CAEDR

: Issues Crucial to DRed

Prescription Stage

• Develop tool by incremental modification of an existing

general purpose tool (Graphlet)

– deliver usable software to industrial users, albeit of limited functionality, very early (3 weeks)

• Storyboarding the use of the tool

– must export to MS Office for inclusion as design report figures – designers not worried time spent using tool will be wasted

• Graphlet employs the “2 language” compiled+scripting

approach advocated by

CAEDR

(18)

CAEDR

: Issues Crucial to DRed

Prescription Stage

• Software development by the researcher using a very

high level interpreted scripting language (Tcl/Tk)

– no need for time consuming software specification

– research ideas, user suggestions and feedback on problems rapidly transformed into working software

(19)

Rob Bracewell

Prescription

6 Storyboard Tool in Context of New Design Process (Graphs replace text for DDR Requirements, Alternatives & provide scheme folder map)

9 Decide Visualisation, Interaction & Distribution Requirements (Standard UI conventions, no info

lost in b/w print; paste into Word, cope with large projects,

run direct from CD)

13 Specify Experiment

and Data Collection

Software

Rapid Software Prototyping

8 Choose Methods (Graphscript

Tcl bindings of GTL procedures)

11 Rapid Software Prototyping (8 releases in 8 months)

12 Formative evaluation (core team 6 designers in RR, 1 in BAE)

7 Choose Implementation Level Representations (GTL graphs, gml files) 10 Choose Development Tools and Components (Graphlet, TclPro, Ghostscript/GSView,

BLT, Img, Schwartz)

(20)

CAEDR

: Issues Crucial to DRed

Description II Stage

• Expand storyboard for use of tool

– No installation required - software to run direct from CD. Vital to run in companies with out-sourced IT. Eased by CAEDR

emphasis on producing platform-independent software – Appropriate training for new users

– Careful consideration of how existing procedures for design reports and folders should be modified when using DRed – Reduced effort writing design report at end of project

– Use of DRed to provide map to other computer files in an electronic design folder

(21)

Rob Bracewell

What future plans?

• Further evaluation - analysis of captured rationale

• Patent application submitted

• Aim to expand use in industry and education

• Use with Tablet PC or portable scanner for sketch input

as a designers’ notebook

• Link to Ascend or Modelica for representation and

solution of parameters, equations and constraints

• Link to parametric CAD

References

Related documents