3. Design1 Agenda for Design Activity r1. Objective r2. Design concepts r3. A design process r4....

3. Design 1

Agenda for Design Activity

1. Objective 2. Design concepts 3. A design process 4. Optimizing design 5. Example 6. Other design processes 7. Homework

3. Design 2

1. Objective

Design activity Product-based activities Products used to manage Completion criteria

1. Objective

3. Design 3

Design Activity

The design activity produces a plan defining how the product is to be built and specifying the lower products from which the product is to be constructed.

1. Objective

3. Design 4

Design Tasks

Preliminarydesignreview

Criticaldesignreview

Develop product concept

Develop product design

concept design

spec &

I/Fs

lower specs & I/FsDevelop

lower specs & interfaces

approval approval

1. Objective

3. Design 5

Completion Criteria

Design documented to the point that someone else can acquire lower parts, build, test, and sell off the product

1. Objective

3. Design 6

Pseudo Completion Criteria

Critical design review is complete

1. Objective

3. Design 7

2. Design Concepts

Source of requirements Goal of design

2. Design concepts

3. Design 8

Source of Requirements

Design context Design Vs requirements Pseudo customers guiding design Example pseudo customers

2. Design concepts

3. Design 9

Design Context

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

Level N+2 Spec 1

Level N+2 Spec 2

Level N+2 Spec P

Level N+1Design 2

Level N+1Design 1

Level N+1Design M

Design occurs at each level and produces lower specs2. Design concepts

3. Design 10

Design Vs Requirements

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

Design at level N becomes requirements at level N+1

Requirements as seen by level N+1

Design as seen by level N

2. Design concepts

3. Design 11

Pseudo Customers Guiding Design

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

Pseudo customers guide design in addition to higher-level requirements.

Pseudo Customers

2. Design concepts

3. Design 12

Pseudo Customers

Enterprise Other customers Development process Other stakeholders

2. Design concepts

3. Design 13

Goal of Design

Meeting all customer requirements Meeting all pseudo customer requirements Making the product work

2. Design concepts

3. Design 14

Meeting All Customer Requirements

Customer requirements documented in the spec & interfaces from the higher product

Work is guided by the SOW from the higher product

2. Design concepts

3. Design 15

Meeting All Pseudo-Customer Requirements

Documented as part of design Imposed on the product as a black box

2. Design concepts

3. Design 16

Making the Product Work

Making the product work includes adding all those features necessary to make the system work including such things as

Form and fit Turning the product on Loading the product Testing the product Providing build and test features Interacting with operators

2. Design concepts

3. Design 17

3. A Design Process

Conceptualization Characterization Preliminary Design Review (PDR) Critical Design Review (CDR) Documenting the design

3. A design process

3. Design 18

Conceptualization

CDRPDR

Design Tasks





concept design

spec &

I/Fs



approval approval

Characterization

3. Design 19

Conceptualization

The act of conceiving a notion of what the product is and how it will be built.

Output is the concept, which gives a high-level description of the product sufficient for planning and guiding the design.

3. A design process

3. Design 20

Variety of Design

Design is difficult to describe as a process because details depend upon many factors such as experience and nature of product

House

Telephone

Radio

Car

Airplane

3. A design process

3. Design 21

Characterization

Converting the concept into the design. Output is the documented design, which

specifies lower products and guides building the product.

Goal to ensure requirements are met & product works

3. A design process

3. Design 22

Parallel Characterization Tasks

Partitioning Making the product work Allocating design requirements

Partitioning

Making the product work

Allocating design requirements

customer & pseudo

customer black-box

requirements

characterization

3. A design process

3. Design 23

Partitioning

Dividing the product into lower products Many reasons for dividing the product may exist

3. A design process

3. Design 24

Partitioning Requirements

Need to build Feasibility Contractual arrangements

3. A design process

3. Design 25

Partitioning Criteria

Similarity to something done before Cost Schedule Performance Reusability and COTS Functional cohesion and uncoupling

3. A design process

3. Design 26

Partitioning Completion Criteria

Partitioning criteria satisfied Team consensus Preliminary design review (pseudo criteria)

3. A design process

3. Design 27

Making Product Work

Other techniques

Life cycle use

Theory of operation

Requirements

Physical diagram

Functional diagram

Data diagram

Performance

Control

Making product

work

Making the product work is the result of applying several techniques in parallel.

Concept

3. Design 28

Requirements

PerformancePhysical

constraints

Reliability

Maintainability

Deployability

Availability

Environmental conditions

Transportability

Materials, processes,

parts

Electromagnetic radiation

Workmanship

Interchangeability

Safety

Human factors

System security

Computer resources

Logistics

Personnel & training

Producibility

Requirements

3. Design 29

Physical Diagram

Sensor

Navigation

GPS

ProcessorWarheadMotor

Airframe

Fin

Fin

3. A design process

3. Design 30

Functional Diagram

Collect imagery

Extracttarget from

image

Predict target

location

Steer missile

Determine missile position

Determine attitude

attitude

position

imagerytarget locationprediction

3. A design process

3. Design 31

Functional Flow Block Diagrams

Start motor

2.0

Initialize

1.0

Guide during initial phase

3.0

Guide during midcourse

4.0

Guide during terminal

5.0

Impact

6.0

Functional flow block diagrams (FFBDs)provide time sequences. FFBDs can be hierarchical and many FFBDs are needed to define

a product3. A design process

3. Design 32

Data Diagram

Collect imagery

Extracttarget from

image

Predict target

location

Steer missile

Determine missile position

Determine attitude attitude

position

imagerytarget

locationprediction

3. A design process

3. Design 33

Performance

Launch

Initial

MidcourseTerminal

Impact

Range

Accuracy

Range

Accuracy

Weight & cost

Performance parameters may influence design

3. A design process

3. Design 34

Logical Control

Selects from among a finite set of discrete options

Power control Initialization Loading control Configuration control Test Vs operation selection Control of operation

3. A design process

3. Design 35

State Variable Control

Continuous within the bounds of measurement resolution

Flight control Process control

3. A design process

3. Design 36

State and Status

State -- a condition the system is in Status -- another word for “state”, often used to

indicate health If the words “state” and “status” are both used in

a design, a clear definition of when each word applies reduces confusion

Using the words “state” or “status” with an adjective also reduces confusion; e.g., power state, failure status

3. A design process

3. Design 37

Modes

Mode -- a manner of acting; often used interchangeably with the word “state”

If the words “state” and “mode” are both used in a design, a clear definition of when each word applies reduces confusion

Using the words “state” or “mode” with an adjective also reduces confusion; e.g., power state, transmit mode

3. A design process

3. Design 38

Reconfiguration

Choosing from redundant elements; e.g.., transmit channels, power supplies, engines

Increases the operation time between repairs

3. A design process

3. Design 39

Reconfiguration Justification

Need reason for expensive in design and test Customer requirements such as preference or

mean time between critical failure We can, it’s more elegant, or we can’t say no

to ourselves

3. A design process

3. Design 40

Other Techniques

Theory of Operation -- A tutorial description of the way the product operates. This tutorial should describe operation during the complete life cycle

Life Cycle Use -- A timeline showing the most common use of the product in each phase of its life.

3. A design process

3. Design 41

Allocating Design Requirements

Flowdown Flowdown and design studies

3. A design process

3. Design 42

Flowdown

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

Pseudo Customers

Level N+1 Interfaces

Level N+1 Test Equip

SOWS

Flow down from requirements to design to lower specs, interfaces, and SOWs

Flowdown

3. A design process

3. Design 43

Flowdown and Design Studies

Design

spec

lower spec 1

lower spec 2

design study

Verification by analysis

Verification

FCA

Design studies used to expand requirements or to handle requirements verified by analysis need to be captured for use in

verification by analysis, verification, and PCA

capture

configuration management

3. A design process

3. Design 44

PDR

Performed when approach is established Objective -- design headed in right direction Determines

Approach will work Designers understand customer & requirements Top-level diagrams available Theory of operation understood Design covers all program phases Risk

3. A design process

3. Design 45

CDR

Performed when product is ready for build Objective -- design complete Determines

Design covers all program phases Risk Design can be tested Lower products & I/Fs specified and compatible

3. A design process

3. Design 46

Design Documentation

Paper

Files within a

file manager

Data base

Files within an intranet

Understandable 10 9 7 8Electronic no yes yes yesEasy to enter data 7 10 7 10Easy to view data 10 9 3 10Easy to keep current 3 10 7 9Easy to correct 3 10 7 10Easy to navigate 6 8 3 10Easy to capture design 5 10 3 10Acceptability 10 9 5 8

Design needs to be documented to the point the product can be built and tested. Several method exist. Intranet is becoming popular

Method

3. Design 47

4. Optimizing Design

Waterfall process Modified waterfall process Providing information when needed

4. Optimizing design

3. Design 48

Waterfall Process

System design

Box design

Software design

Softwarei&t

Boxi&t

Systemi&t

Waterfall process has classic V pattern. Steps are serial with each step finishing before the next starts


3. Design 49

Modified Waterfall Process

System design

Box design

Software design Software

i&t

Boxi&t

Systemi&t

Modified waterfall process has shorter cycle time because it starts tasks earlier and allows tasks to develop in parallel through

techniques such as multiple builds.

Tasks start earlier

Software and box developed in multiple builds


3. Design 50

Providing Information when NeededPercent of requirements

complete

0

100

Concept Functions I/Fs Mechanical Test

Percent of tasks to be developed0 100

Development can start before requirements are complete


3. Design 51

5. Example

Understand customer process Customer requirements Design process Concept Spec tree Development of requirements Requirements

5. Example

3. Design 52

Understand Customer Process

Productrequirements

review

Assist customer in developing

product requirements and

interfaces

initial SOW, spec, & I/Fs

final SOW, spec, & I/Fs

approval

5. Example

3. Design 53

Customer Wants

W1: Live in a quiet place W2: Have low maintenance costs W3: Raise a garden W4: Have room for family to visit W5: Have adequate electricity W6: Have a garage W7: Cool in the evenings W8: Pay $100,000 W9: Obtain 6/1/99

5. Example

3. Design 54

Converting Wants to Spec and SOW

W1: quiet

W2: low costs

S01: <3yrsS04: no floodS05: low maintS12: equip works

S02: miles

W3:garden

S03: 1/2 acreS11: water

W4: family

W5: electric

W6: garage

W7: cool

W8: $100K

W9: close

S06: 1800S07: 3 bdr

S10: 100 amps

S09: garage

S08:east

C2:$100K

C3:close

Wants

Spec SOW

Wants flow to spec and SOW either directly or through studies. It is desirable to document these studies.

S S S S S S

C1: house & lot

3. Design 55

Product SOW

C1: Provide house and lot that meet spec (ANA) C2: Pay $100,000 (INS) C3: Close on sale by 6/1/99 (INS)

5. Example

3. Design 56

Product Spec

S01: <3 years old (ANA) S02 <10 & > 3 miles from town of 5000 people (INS) S03 > 1/2 acre lot (INS) S04 Does not flood (ANA) S05 Low maintenance construction (INS) S06: >1800 feet in air conditioning (INS) S07: At least 3 bedrooms (INS) S08: Master bedroom on east side (INS) S09: Attached two-car garage (INS) S10: >100 amperes electrical service (INS) S11: > 11 gal/min from at least one faucet (TEST) S12: Equipment works (DEMO)

5. Example

3. Design 57

Contractor Wants

Customer wants Contractor wants

Profit Pride Law

20% Happy buyer Meets code

Contractor requirements

Contractor wants create pseudo requirements in addition to customer requirements. These pseudo requirements can be

considered to be part of the design. In this example, they don’t flow from the customer wants.

5. Example

3. Design 58

Contractor Requirements

Wants Ds1: 20 percent profit (INS) Ds2: Make buyer happy (INS)

Other Dr1: Meets code (INS, DEMO)

5. Example

3. Design 59

Design Process





concept design

spec &

I/Fs



approval approval

5. Example

3. Design 60

Concept

Garage

Storage Utility

Living

KitchenBedroom Bedroom

MasterBedroom

Bath

Bath

N

5. Example

3. Design 61

Spec Tree

House and lot

Real estate Structure Electrical Plumbing

5. Example

3. Design 62

Contractor Design

Dd1: Plans Floor plan Elevations Plumbing plan Electrical plan Foundation plan Lot layout

Dd2: Flood analysis Dd3: Cost and schedule

5. Example

3. Design 63

Real Estate Flowdown

C2: $100,000C3: close by 6/1/99Ds1: 20%

Dd3: Cost/sched study

Rs2: <$15,000Rs3: close by 1/1/99

Dd1: Plans Dd2: flood analysis

Rr1: milesRr3: 1/2 acreRs1: land

Rr2: doesn’t floodRs4: provide analysis

S02: milesS03: 1/2 acre

S04: doesn’t flood

Product spec, product SOW, and contractor wants flowdown directly and through studies to become the real estate spec and SOW

5. Example

3. Design 64

Real Estate Spec

Rr1: <10 & > 3 miles from town of 5000 people (INS) Rr2: Does not flood (ANA) Rr3: > 1/2 acre (INS)

5. Example

3. Design 65

Real Estate SOW

Rs1: Provide land Rs2: < $15,000 Rs3: Close by 1/1/99 Rs4: Provide flood analysis

5. Example

3. Design 66

Structure FlowdownC2: $100,000C3: close by 6/1/99Ds1: 20%


Ss2: <$53,000Ss3: close by 5/1/99Ss4: coordinate


Product spec, product SOW, and contractor wants flowdown through studies to become the structure spec and SOW

Ss1: structureSr1: meets designSr2: brickSr3: roofSr4: paintSr5: carpet

S11: electricalS12: worksDr1: meets codeDs2: buyer happy

Sr6: tileSr7: colorsSr8: tile colorSr9: meets code

5. Example

3. Design 67

Structure Spec

Sr1: Meets design (INS) Sr2: Brick (INS) Sr3: 30-yr composition (INS) Sr4: Long-lasting paint (INS) Sr5: Nylon carpet except bath and kitchen (INS) Sr6: Ceramic tile on all other interior floors (INS) Sr7: White exterior paint, beige interior paint,

beige carpet (INS) Sr8: White tile (INS) Sr9: Meets code (INS)

5. Example

3. Design 68

Structure SOW

Ss1: Provide structure Ss2: <$53,000 Ss3: Compete by 5/1/99 Ss4: Coordinate with plumber and electrician

5. Example

3. Design 69

Electrical Flowdown

C2: $100,000C3: close by 6/1/99Ds1: 20%


Es2: <$4,000Es3: close by 5/1/99Es4: coordinate


Product spec, product SOW, and contractor wants flowdown through studies to become the electrical spec and SOW

Es1: electricalEr1: meets designPr2: electricalPr3: meets code

S11: electricalS12: worksDr1: meets code

5. Example

3. Design 70

Electrical Spec

Er1: Meets design (INS) Er2: >100 amperes electrical service (INS) Er3: Meets code (INS)

5. Example

3. Design 71

Electrical SOW

Es1: Provide electrical Es2: <$4,000 Es3: Complete by 5/1/99 Es4: Coordinate with structure

5. Example

3. Design 72

Plumbing Flowdown

C2: $100,000C3: close by 6/1/99Ds1: 20%


Ps2: <$8,000Ps3: close by 5/1/99Ps4: coordinate


Product spec, product SOW, and contractor wants flowdown through studies to become the plumbing spec and SOW

Ps1: plumbingPr1: meets designPr2: waterPr3: meets code

S11: waterS12: worksDr1: meets code

5. Example

3. Design 73

Plumbing Spec

Pr1: Meets design (INS) Pr2: >100 gal/min from one faucet (TEST) Pr3: Meets code (INS)

5. Example

3. Design 74

Plumbing SOW

Ps1: Provide plumbing Ps2: <$8,000 Ps3: Complete by 5/1/99 Ps4: Coordinate with structure

5. Example

3. Design 75

6. Other Design Processes

Defense Management College (DMC) design process

James Martin design process EIA-632 design process

6. Other design processes

3. Design 76

DMC Design Process

Requirements analysis

Functional analysis and

allocation

Synthesis

System analysis and

control

requirements loop

design loop

verification

process inputs

process outputs

Systems Engineering Process


3. Design 77

James Martin Design Process

Requirements Analysis

Functional Analysis and

Allocation

Synthesis

Requirements loop Design loop

Requirements and architecture

documentation

Verification loop

System analysis and optimization

Specs, interfaces, design

RequirementsProduct characteristics

3. Design 78

EIA 632

Requirements relationship Design Process

Logical solution definition Physical solution definition Specified requirements generation


3. Design 79

Requirements Relationship

User or customer requirements

System technical requirements

Logical solution

Physical solution

Derived technical

requirements

Design solution

Specified requirements

Other stakeholder

requirements

TRACE TO

Assigned requirementsTRACE TO

TRACE TO

ASSIGNED TO ASSIGNED TO

ASSIGNED TO

DRIVE

SOURCE OF

SPECIFIED BY

BECOME

The EIA 632 entity relationship is similar to the PBA approach but is more complex.


3. Design 80

Design Process

Logical Solution

Definition

Specified Requirements

Generation

Physical Solution

Definition

Specifications, drawings, models

System technical requirements

The EIA 632 design process is quite similar to the product basedapproach given earlier, but it is more serial in description

EIA 632 Figure 4.3.2


3. Design 81

Logical Solution Definition (1 of 3)

Analyze functions, objects, data flow, data structures Define subfunctions Perform trade studies Assign performance requirements & constraints Analyze behaviors


3. Design 82


Identify and define interfaces, states and modes, timelines, data, & and control

Analyze failure modes and define effects


3. Design 83


Establish set of logical solutions Validate logical solutions Record logical solutions Identify and define derive technical requirements Record derived technical requirements


3. Design 84

Physical Solution Definition

Perform system analysis

Define I/Fs

ID & analyze critical

parameters

ID & assess physical solution

options

ID and define technical

requirements

Group requirements & solutions

Assign groups to physical solutions

Generate alternative solutions

Select solution

The physical solution definition is more serial than the PBA.


3. Design 85

Specified Requirements Generation

Fully characterize design solution Verify design solution Record design solution Generate and record specified requirements Initiate development of enabling processes


3. Design 86

7. Homework

A customer wants to sell a line of lawn mowers that can cut Texas lawn grasses, requires partial assembly, and that costs less than $300

Develop a design that satisfies the customer 1. List the customer requirements (>0, <10) 2. List pseudo customer requirements (0, <20) 3. List the key items in the concept (>0, <20) 4. List the key items in the design (>0, <20) 5. List key items in documentation (>0, <20) 6. List the key items in the CDR (>0, <20) 7. List items shall be (>0, <30 words); no pictures

7. Homework

3. Design1 Agenda for Design Activity r1. Objective r2. Design concepts r3. A design process r4....

Documents

Transcript of 3. Design1 Agenda for Design Activity r1. Objective r2. Design concepts r3. A design process r4....