Agenda for design activity

1
Agenda for design activity

• 1. Objective
• 2. Disclaimer
• 3. Design context
• 4. Solutions
• 5. Design process
• 6. Other design processes

2
1. Objective

• Design activity
• Design process
• Completion criteria
• Pseudo-completion criteria
• Products composed of products

1. Objective
3
Design activity

• The design activity produces a vision of the
  product is to be built and specifies the lower
  products from which the product is to be
  constructed
• In other words, the design activity starts with a
  problem and creates a vision of the solution to
  that problem
• The design is a description of the parts and how
  the parts go together
• Design works for physical products, documents,
  and processes

1. Objective
4
Design process

• design
• reviews

create idea
define additional wants
list lower products
complete design
define lower specs I/Fs
document design
spec I/Fs
1. Objective
5
Completion criteria

• Works
• Meets requirements
• Has consensus that design is done
• Is documented to the point that someone else can
  acquire lower-products, build, test, and sell off
  the product

1. Objective
6
Pseudo-completion criteria

• Critical design review is complete

1. Objective
7
Products composed of products
level 1 product
Higher-level products
level 2 product 1
level 2 product 2
level 3 Product 1
level 3 Product 2
level 4 product 2
level 4 product 1
level 4 product 2
Lower-level products
1. Objective
8
2. Disclaimer
Design is difficult to describe as a process
because details depend upon the nature of the
product, and theres a wide variety of products.

2. Disclaimer
9
3. Design context

• Context
• Design vs requirements
• Other customers
• Flow down
• Studies

3. Design context
10
Context
level N spec
level N design
level N1 spec 1
level N1 spec 2
level N1 spec M
level N1 design 2
level N1 design 1
level N1 design M
level N2 spec 1
level N2 spec 2
level N2 spec P
Design occurs at each level and produces lower
specs
.
3. Design context
11
Design vs requirements
level N spec
Design as seen by level N
level N design
level N1 spec 1
level N1 spec 2
level N1 spec M
Requirements as seen by level N1
Design at level N becomes requirements at level
N1
3. Design context
12
Other customers
level N spec
level N design
other customers
level N1 spec 1
level N1 spec 2
level N1 spec M
In addition to higher-level requirements, pseudo
customers guide design
3. Design context
13
Lower specs and interfaces
product requirements
requirement
product design
requirements
requirements
requirements
lower product B requirements
lower product A requirements
interface
requirements
requirements
Lower specs and interfaces evolve from design
and impose requirements on products at the
same level in the hierarchy.
3. Design context
14
Flow down
Flow down
level N spec
level N design
other customers
level N1 s 1
level N1 spec 2
level N1 spec M
level N1 STE
contracts
Flow down from requirements to design to lower
specs, interfaces, and contracts
3. Design context
15
Studies
verification by analysis
spec
design study
design
verification
capture
FCA
lower spec 1
lower spec 2
configuration management
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 FCA
3. Design context
16
4. Solutions

• Design as a set of solutions
• Solution process
• Generating solutions

4. Solutions
17
Design as a set of solutions
reviews
design process
solution
solution
solution
design
solution
lower specs I/Fs
solution
solution
solution
solution
Completion criteria

• works
• meets requirements
• has consensus that design is done
• is documented

The design process converts inputs into
outputs by making a set of solutions
4. Solutions
18
Solution process (1 of 7)
implemented solution
problem
solution
implement solution
generate solutions
solutions
choose solution
evaluate solution
define problem
quantify solutions
models analysis
knowledge to generate solutions
knowledge to choose solution
models analysis
criteria
Solutions can be created for problems using any
one of several paths
4. Solutions
19
Solution process (2 of 7)

• Problem definition
• Collect and understand printed information
• Similar designs and lessons learned, design
  guides, literature
• Talk with people who know the problem
• Customers and consultants
• Look at problem in person
• Confirm information
• Determine what caused the problem
• Determine if problem should be solved

4. Solutions
20
Solution process (3 of 7)

• Generate solutions
• Ad hoc
• Analogy or prior experience
• Research
• Brainstorming
• Analysis
• Graphical modeling
• Mathematical modeling
• Physical modeling
• Prototyping

4. Solutions
21
Solution process (4 of 7)

• Quantify solutions
• Add numerical values to attributes that describe
  each solution

4. Solutions
22
Solution process (5 of 7)

• Choose solution
• Ad hoc
• Trade study
• Define must-have criteria
• Define want criteria
• Define adverse consequences and risk-mitigation
  strategies
• Perform trade study

4. Solutions
23
Solution process (6 of 7)

• Implement solution
• Plan
• Execute
• Gather additional information e.g. observation
  and experiments

4. Solutions
24
Solution process (7 of 7)

• Evaluate solution
• Validate by analysis
• Model

4. Solutions
25
Generating solutions (1 of 3)

• Design is like working a cross-word puzzle
• A cross-word puzzle can be described as an
  orderly process of incrementing through the rows
  and then through the columns
• In practice, a cross-word puzzle is a lot more
  random
• Solutions are not created serially, and they are
  not created independently
• Many solutions may proceed in parallel
• Design is like a cross-word puzzle. No single
  solution path applies to all of design

4. Solutions
26
Generating solutions (2 of 3)

• Design can be thought of as a process of
  zig-zagging back and forth between asking
• what to do and
• how to do it

4. Solutions
27
Generating solutions (3 of 3)
reviews
contractor design
customer design
spec I/Fs
design
problem
lower specs I/Fs
Theres a customer design in addition to
the contractor design
4. Solutions
28
5. Design process

• A. Create idea
• B. Define additional wants
• C. Define lower products
• D. Complete design
• E. Create lower specs and I/Fs
• F. Hold reviews
• G. Document design

5. Design process
29
A. Create idea (1 of 2)

• Definition
• The portion of the design that gives general
  direction to the design
• Not a separate work product (WP)
• Approach
• Use the solution process to generate ideas
• Completion criteria
• Has obtained enough detail to give general
  direction

5. Design process
30
A. Create idea (2 of 2)

• Example
• Problem
• Move a person between two floors of a building
• Basic ideas
• Elevator
• Escalator
• Chair-lift
• Hoist
• Donkey
• Movable floors
• Helicopter

5. Design process
31
B. Define additional wants (1 of 6)

• Definition
• The process of identifying functions and
  non-functions in addition to ones implied by the
  product requirements
• Approach
• Use the solution process to define functional
  and non-functional wants in addition to
  requirements
• Completion criteria
• Has obtained consensus among design team that
  wants are defined

5. Design process
32
B. Define additional wants (2 of 6)
satisfy non- functional wants
satisfy functional wants
make-work viewpoint
functional viewpoint
make product work
satisfy other features
satisfy potential requirements
requirements viewpoint
Defining additions wants involves looking from
different viewpoints
5. Design process
33
B. Define additional wants (3 of 6)
make buildable
make verifiable
make disposable
satisfy functional wants
make trainable
make improvable
make usable
make producible
make supportable
make maintainable
Satisfying functional wants
5. Design process
34
B. Define additional wants (4 of 6)
provide quality
satisfy non- functional wants
make profitable
make reliable
make survivable
Satisfying non-functional wants
5. Design process
35
B. Define additional wants (5 of 6)
performance
IFs
electromagnetic radiation
physical constraints
workmanship
reliability
interchangeability
maintainability
safety
meet requirements
deployability
human factors
availability
producibility
environmental conditions
system security
transportability
computer resources
personnel training
materials, processes, parts
logistics
5. Design process
36
B. Define additional wants (6 of 6)
turn on off
initialize
heat cool
make product work
load
provide power
test
provide structure
reconfigure
Satisfying make-work wants
5. Design process
37
C. List lower products (1 of 2)

• Definition
• The process of listing the lower products to use
  in the development of the product of interest
• Approach
• Use solution process to partition system
• Completion criteria
• Has obtained a list of lower products

5. Design process
38
C. List lower products (2 of 2)

• Chose partitioning criteria
• Similarity to something done before
• Customer satisfaction
• Cost
• Risk
• Schedule
• Performance
• Reusability and COTS
• Functional cohesion and uncoupling
• Other

5. Design process
39
D. Complete design (1 of 4)

• Definition
• The process of completing design to point some
  else can build
• Approach
• Use solution process
• Make system meet requirements
• Make system meet additional wants
• Include architecture and other drawings

5. Design process
40
D. Complete design (2 of 4)

• Completion criteria
• Has completed to the point that someone else can
  acquire lower-products, build, test, and sell off
  the product

41
D. Complete design (3 of 4)
higher product
Interfaces among products allow designs to
proceed in parallel
design
product of interest
design
lower product 1
lower product 2
lower product N
design
design
design
Design of all products, driven by interfaces
among the products, proceeds in parallel
5. Design process
42
D. Complete design (4 of 4)
product requirement space
trash
Impress customer
Improve probability of using COTS
design space
lower-product requirement space
May move design to requirements to impress
customer. May limit design to improve probability
of using COTS
5. Design process
43
E. Define lower specs and I/Fs (1 of 4)

• Definition
• Lower specs -- The specs defining the parts from
  which the product is to be made
• Lower interfaces -- The I/Fs among the parts
• Interfaces connect products
• They may be functional or physical
• They evolve from design and impose requirements
  on products.
• Products at the same level in the hierarchy dont
  impose requirements on the interfaces at that
  level unless they are already developed products

5. Design process
44
E. Define lower specs and I/Fs (2 of 4)

• Approach
• Allocate design to lower parts and document
• Completion criteria --
• Has defined specs and interfaces defined to point
  someone else can purchase lower products from an
  outside vendor

5. Design process
45
E. Define lower specs and I/Fs (3 of4)

• Value of lower specs and interfaces
• Controlling documentation and especially
  documentation of the lower specs interfaces is
  one of the strongest influences a product
  engineer has on the development of a product

5. Design process
46
E. Define lower specs and I/Fs (4 of 4)

• Interface development technique
• Use the results of modeling done to make product
  work and meet requirements to determine what
  requirements need to be allocated to each
  sub-product
• Define interfaces among sub-products to ensure
  each sub-product receives information and has
  physical support to operate
• Documenting interfaces
• Excel spreadsheet
• Data bases e.g. TeamWork

5. Design process
47
F. Hold reviews (1 of 4)

• Definition
• Reviews of concept, initial design, and final
  design
• Approach
• Compare against checklist to ensure all design
  guidelines met
• Completion criteria
• Checklist satisfied

5. Design process
48
F. Hold reviews (2 of 4)

• 1. Concept review (CR)
• Performed when concept is established
• Objective -- design is feasible and an and list
  of lower products exists that can be used for
  management planning and costing
• Determines
• Design feasible
• Design is adequate for management and costing

5. Design process
49
F. Hold reviews (3 of 4)

• 2. Preliminary design review (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

5. Design process
50
F. Hold review (4 of 4)

• 3. Critical design review (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

5. Design process
51
G. Document design (1 of 5)

• Definition
• The documentation necessary to build to procure
  the parts, build the product, justify why the
  design is as it is, and support verification by
  analysis
• Approach
• Capture configured design as shown in following
  figures
• Completion criteria
• Documented to procure, build, justify, and
  analize

5. Design process
52
G. Document design (2 of 5)
design
design description
supporting analysis
management including tracing
Design is documented as (1) design description,
(2) supporting analysis, and (3) management
including tracing
5. Design process
53
G. Document design (3 of 5)
design description
idea
lower specs and interfaces
The (1) idea and (2) lower specs and
interfaces are elements of the design description
5. Design process
54
G. Document design (4 of 5)

• Need for documentation
• Design (what)
• Define the design including the lower specs and
  interfaces
• Supporting analysis (why)
• Provide tutorials for the design
• Manage requirements
• Support verification by analysis
• Support verification
• Support FCA
• Management (where)
• Justify the design

5. Design process
55
G. Document design (5 of 5)

• Suggestions
• Control design by controlling documentation
• Document and maintain design in format of the
  tool that produced it
• Make documentation easy to navigate
• Avoid letting documentation become obsolete
• Avoid duplication
• Document so that someone of similar training can
  implement

5. Design process
56
6. Other design approaches

• DSMC
• James Martin
• EIA 632
• James Garratt
• PBDA

6. Other design approaches
57
DSMC
process inputs
Defense System Management College (DSMC)
Systems engineering process
system analysis control
requirements analysis
requirements loop
functional analysis and allocation
design loop
synthesis
verification
process outputs
6. Other design approaches
58
James Martin
system analysis and optimization
functional analysis and allocation
synthesis
requirements analysis
Design loop
Requirements loop
Verification loop
requirements and architecture documentation
design process
6. Other design approaches
59
EIA 632
requirements relationship
user or customer requirements
assigned requirements
other stakeholder requirements
system technical requirements
physical solution
logical solution
design solution
derived technical requirements
The EIA 632 requirements relationship is similar
to the PBDA approach but is more complex.
specified requirements

6. Other design approaches
60
James Garratt
identify situation
analyze the situation
write a brief
carry out research
write a specification
work out possible solutions
select a preferred solution
plan working drawings and plan ahead
construct a prototype
test and evaluate the design
write a report
6. Other design approaches
61
PBDA

• Simple
• Only three management objects
• Parallel process
• Allows parallel product development
• Allows multiple customers
• Can be used to explain other design methods

6. Other design approaches