Agenda for design activity

Agenda for design activity • 1. Objective • 2. Disclaimer • 3. Solutions • 4. Design process • 5. Other design processes

1. Objective • Design activity • Design tasks • Completion criteria • Pseudo-completion criteria 1. Objective

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. • In other words, the design activity starts with a problem and creates a plan for 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

Design process customers users enterprise developers other stakeholders CR PDR CDR Create idea • design • lower specs & I/Fs • reviews Define additional needs List lower products Complete design Define lower specs & I/Fs Document design spec & I/Fs 1. Objective

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

Pseudo-completion criteria • Critical design review is complete 1. Objective

PBDA block diagram External: higher product teams contracts, specs, interfaces people, facilities, tools, capital, communications, library schedule, budget, risks, TPPs, issues, AIs, plans, timeline, changes, problems, legal status 1. Manage MR contracts specs, I/Fs RR control, status design 3. Design CR PDR CDR lower specs & I/Fs build proc 4. Acquire lower contracts, specs, interfaces lower products product 5. Build test results test spec lower test results lower product, test results, test spec 6. Verify status agree agree TRR VR test proc External: lower product teams 7. Sell off FCA PCA 2. Understand req

2. Disclaimer Radio House Airplane Telephone Car Design is difficult to describe as a process because details depend upon the nature of the product, and there’s a wide variety of products. 2. Disclaimer

3. Solutions • Design as a set of solutions • Solution process • Generating solutions 3. Solutions

Design as a set of solutions reviews spec & I/Fs design design process lower specs & I/Fs solution solution solution solution solution solution solution solution Completion criteria • meets requirements • complete • risks are low optimized • consensus that design is done • documented The design process converts inputs into outputs by making a set of solutions 3. Solutions

Solution process (1 of 7) implemented solution problem solution solutions choose solution define problem quantify solutions evaluate solution models & analysis knowledge to generate solutions knowledge to choose solution models & analysis criteria implement solution generate solutions Solutions can be created for problems using any one of several paths 3. Solutions

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 • Consultants • Look at problem in person • Confirm information • Determine what caused the problem • Determine if problem should be solved 3. Solutions

Solution process (3 of 7) • Quantify solutions • Add numerical values to attributes that describe each solution 3. Solutions

Solution process (4 of 7) • Generate solutions • Ad hoc • Analogy or prior experience • Research • Brainstorming • Analysis • Graphical modeling • Mathematical modeling • Physical modeling • Prototyping 3. Solutions

Solution process (5 of 7) • Choose solution • Ad hoc • Trade study • Define must-have criteria • Define want criteria • Define adverse criteria and risk-mitigation strategies • Perform trade study 3. Solutions

Solution process (6 of 7) • Implement solution • Plan • Execute • Gather additional information; e.g. observation and experiments 3. Solutions

Solution process (7 of 7) • Evaluate solution • Validate by analysis • Model 3. Solutions

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 3. Solutions

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 3. Solutions

Generating solutions (3 of 3) customer contractor reviews customer design contractor design spec & I/Fs design problem lower specs & I/Fs There’s a customer design in addition to the contractor design 3. Solutions

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

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 4. Design process

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 4. Design process

B. Define additional needs (1 of 6) • Definition • The process of identifying functions non-functions in addition to ones implied by the product requirements • Approach • Use the solution process to define functional and non-functional needs in addition to requirements • Completion criteria • Has obtained consensus among design team that needs are defined 4. Design process

B. Define additional needs (2 of 6) satisfy functional needs satisfy non- functional needs make-work viewpoint functional viewpoint make product work satisfy potential requirements satisfy other features requirements viewpoint Defining additions needs involves looking from different viewpoints 4. Design process

B. Define additional needs (3 of 6) make buildable make disposable make verifiable make improvable make trainable make producible make usable make supportable make maintainable satisfy functional needs Satisfying functional needs 4. Design process

B. Define additional needs (4 of 6) provide quality make reliable make profitable make survivable satisfy non- functional needs Satisfying non-functional needs 4. Design process

B. Define additional needs (5 of 6) physical constraints performance IFs electromagnetic radiation 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 4. Design process

B. Define additional needs (6 of 6) turn on & off heat & cool initialize provide power load provide structure test reconfigure make product work Satisfying make-work needs 4. Design process

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 4. Design process

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 4. Design process

D. Complete design (1 of 3) • Definition • The process of completing design to point some else can build • Approach • Use solution process • Make system meet requirements • Make system meet additional needs • Include architecture and other drawings • Completion criteria • Has completed to the point that someone else can acquire lower-products, build, test, and sell off the product 4. Design process

D. Complete design (2 of 3) Higher Product design Product of Interest design Lower Product 1 Lower Product 2 Lower Product N design design design Interfaces among products allow designs to proceed in parallel Design of all products, driven by interfaces among the products, proceeds in parallel 4. Design process

D. Complete design (3 of 3) 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 4. Design process

E. Define lower specs and I/Fs (1 of 6) • 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 don’t impose requirements on the interfaces at that level unless they are already developed products 4. Design process

E. Define lower specs and I/Fs (2 of 6) • 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 4. Design process

E. Define lower specs and I/Fs (3 of 6) • 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 4. Design process

E. Define lower specs and I/Fs (4 of 6) Product requirements requirement Product design requirements requirements requirements Lower product A requirements Lower product B requirements Interface requirements requirements Lower specs and interfaces evolve from design and impose requirements on products at the same level in the hierarchy. 4. Design process

E. Define lower specs and I/Fs (5 of 6) Level N Spec Level N+1 Interfaces Flow down Level N Design Pseudo customers Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N+1 Test Equip contracts Flow down from requirements to design to lower specs, interfaces, and contracts 4. Design process

E. Define lower specs and I/Fs (6 of 6) • 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 4. Design process

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 4. Design process

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 4. Design process

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 4. Design process

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 4. Design process

G. Document design (1 of 6) • 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 the parts, build the product, justify why the design is as it is, and support analysis 4. Design process

G. Document design (2 of 6) design design description supporting analysis management including tracing Design is documented as (1) design description, (2) supporting analysis, and (3) management including tracing 4. Design process

G. Document design (3 of 6) design description idea lower specs and interfaces The (1) idea and (2) lower specs and interfaces are elements of the design description 4. Design process

G. Document design (4 of 6) • 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 4. Design process

G. Document design (5 of 6) spec Verification by analysis 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 4. Design process

G. Document design (6 of 6) • 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 4. Design process

Agenda for design activity