1. 3. Design1 Agenda for Design Activity r1. Objective r2. Design concepts r3. A design process r4. Optimizing design r5. Example r6. Other design processes r7. Homework

2. 3. Design2 1. Objective rDesign activity rProduct-based activities rProducts used to manage rCompletion criteria 1. Objective

3. 3. Design3 Design Activity rThe 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

4. 3. Design4 Design Tasks Preliminary design review Critical design review Develop product concept Develop product design conceptdesign spec & I/Fs lower specs & I/Fs Develop lower specs & interfaces approval 1. Objective

5. 3. Design5 Completion Criteria rDesign documented to the point that someone else can acquire lower parts, build, test, and sell off the product 1. Objective

6. 3. Design6 Pseudo Completion Criteria rCritical design review is complete 1. Objective

7. 3. Design7 2. Design Concepts rSource of requirements rGoal of design 2. Design concepts

8. 3. Design8 Source of Requirements rDesign context rDesign Vs requirements rPseudo customers guiding design rExample pseudo customers 2. Design concepts

9. 3. Design9 Design Context Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design Level N+2 Spec 1 Level N+2 Spec 2 Level N+2 Spec P Level N+1 Design 2 Level N+1 Design 1 Level N+1 Design M Design occurs at each level and produces lower specs 2. Design concepts

10. 3. Design10 Design Vs Requirements Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design 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

11. 3. Design11 Pseudo Customers Guiding Design Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design Pseudo customers guide design in addition to higher-level requirements. Pseudo Customers 2. Design concepts

12. 3. Design12 Pseudo Customers rEnterprise rOther customers rDevelopment process rOther stakeholders 2. Design concepts

13. 3. Design13 Goal of Design rMeeting all customer requirements rMeeting all pseudo customer requirements rMaking the product work 2. Design concepts

14. 3. Design14 Meeting All Customer Requirements rCustomer requirements documented in the spec & interfaces from the higher product rWork is guided by the SOW from the higher product 2. Design concepts

15. 3. Design15 Meeting All Pseudo-Customer Requirements rDocumented as part of design rImposed on the product as a black box 2. Design concepts

16. 3. Design16 Making the Product Work rMaking the product work includes adding all those features necessary to make the system work including such things as l Form and fit l Turning the product on l Loading the product l Testing the product l Providing build and test features l Interacting with operators 2. Design concepts

17. 3. Design17 3. A Design Process rConceptualization rCharacterization rPreliminary Design Review (PDR) rCritical Design Review (CDR) rDocumenting the design 3. A design process

18. 3. Design18 Conceptualization CDRPDR Design Tasks Preliminary design review Critical design review Develop product concept Develop product design conceptdesign spec & I/Fs lower specs & I/Fs Develop lower specs & interfaces approval Characterization

19. 3. Design19 Conceptualization rThe act of conceiving a notion of what the product is and how it will be built. rOutput is the concept, which gives a high-level description of the product sufficient for planning and guiding the design. 3. A design process

20. 3. Design20 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

21. 3. Design21 Characterization rConverting the concept into the design. rOutput is the documented design, which specifies lower products and guides building the product. rGoal to ensure requirements are met & product works 3. A design process

22. 3. Design22 Parallel Characterization Tasks rPartitioning rMaking the product work rAllocating design requirements Partitioning Making the product work Allocating design requirements customer & pseudo customer black-box requirement s characterization 3. A design process

23. 3. Design23 Partitioning rDividing the product into lower products rMany reasons for dividing the product may exist 3. A design process

24. 3. Design24 Partitioning Requirements rNeed to build rFeasibility rContractual arrangements 3. A design process

25. 3. Design25 Partitioning Criteria rSimilarity to something done before rCost rSchedule rPerformance rReusability and COTS rFunctional cohesion and uncoupling 3. A design process

26. 3. Design26 Partitioning Completion Criteria rPartitioning criteria satisfied rTeam consensus rPreliminary design review (pseudo criteria) 3. A design process

27. 3. Design27 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

28. 3. Design28 Requirements Performance Physical 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

29. 3. Design29 Physical Diagram Sensor Navigation GPS ProcessorWarheadMotor Airframe Fin 3. A design process

30. 3. Design30 Functional Diagram Collect imagery Extract target from image Predict target location Steer missile Determine missile position Determine attitude attitude position imagery target locationprediction 3. A design process

31. 3. Design31 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 product 3. A design process

32. 3. Design32 Data Diagram Collect imagery Extract target from image Predict target location Steer missile Determine missile position Determine attitude attitude position imagery target location prediction 3. A design process

33. 3. Design33 Performance Launch Initial Midcourse Terminal Impact Range Accuracy Range Accuracy Weight & cost Performance parameters may influence design 3. A design process

34. 3. Design34 Logical Control rSelects from among a finite set of discrete options l Power control l Initialization l Loading control l Configuration control l Test Vs operation selection l Control of operation 3. A design process

35. 3. Design35 State Variable Control rContinuous within the bounds of measurement resolution l Flight control l Process control 3. A design process

36. 3. Design36 State and Status rState -- a condition the system is in rStatus -- another word for “state”, often used to indicate health rIf the words “state” and “status” are both used in a design, a clear definition of when each word applies reduces confusion rUsing the words “state” or “status” with an adjective also reduces confusion; e.g., power state, failure status 3. A design process

37. 3. Design37 Modes rMode -- a manner of acting; often used interchangeably with the word “state” rIf the words “state” and “mode” are both used in a design, a clear definition of when each word applies reduces confusion rUsing the words “state” or “mode” with an adjective also reduces confusion; e.g., power state, transmit mode 3. A design process

38. 3. Design38 Reconfiguration rChoosing from redundant elements; e.g.., transmit channels, power supplies, engines rIncreases the operation time between repairs 3. A design process

39. 3. Design39 Reconfiguration Justification rNeed reason for expensive in design and test l Customer requirements such as preference or mean time between critical failure l We can, it’s more elegant, or we can’t say no to ourselves 3. A design process

40. 3. Design40 Other Techniques rTheory of Operation -- A tutorial description of the way the product operates. This tutorial should describe operation during the complete life cycle rLife Cycle Use -- A timeline showing the most common use of the product in each phase of its life. 3. A design process

41. 3. Design41 Allocating Design Requirements rFlowdown rFlowdown and design studies 3. A design process

42. 3. Design42 Flowdown Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design 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

43. 3. Design43 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

44. 3. Design44 PDR rPerformed when approach is established rObjective -- design headed in right direction rDetermines l Approach will work l Designers understand customer & requirements l Top-level diagrams available l Theory of operation understood l Design covers all program phases l Risk 3. A design process

45. 3. Design45 CDR rPerformed when product is ready for build rObjective -- design complete rDetermines l Design covers all program phases l Risk l Design can be tested l Lower products & I/Fs specified and compatible 3. A design process

46. 3. Design46 Design Documentation Paper Files within a file manager Data base Files within an intranet Understandable 10 9 7 8 Electronic no yes yes yes Easy to enter data 7 10 7 10 Easy to view data 10 9 3 10 Easy to keep current 3 10 7 9 Easy to correct 3 10 7 10 Easy to navigate 6 8 3 10 Easy to capture design 5 10 3 10 Acceptability10 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

47. 3. Design47 4. Optimizing Design rWaterfall process rModified waterfall process rProviding information when needed 4. Optimizing design

48. 3. Design48 Waterfall Process System design Box design Software design Software i&t Box i&t System i&t Waterfall process has classic V pattern. Steps are serial with each step finishing before the next starts 4. Optimizing design

49. 3. Design49 Modified Waterfall Process System design Box design Software design Software i&t Box i&t System i&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 4. Optimizing design

50. 3. Design50 Providing Information when Needed Percent of requirements complete 0 100 ConceptFunctionsI/FsMechanicalTest Percent of tasks to be developed 0100 Development can start before requirements are complete 4. Optimizing design

51. 3. Design51 5. Example rUnderstand customer process rCustomer requirements rDesign process rConcept rSpec tree rDevelopment of requirements rRequirements 5. Example

52. 3. Design52 Understand Customer Process Product requirements review Assist customer in developing product requirements and interfaces initial SOW, spec, & I/Fs final SOW, spec, & I/Fs approval 5. Example

53. 3. Design53 Customer Wants rW1: Live in a quiet place rW2: Have low maintenance costs rW3: Raise a garden rW4: Have room for family to visit rW5: Have adequate electricity rW6: Have a garage rW7: Cool in the evenings rW8: Pay $100,000 rW9: Obtain 6/1/99 5. Example

54. 3. Design54 Converting Wants to Spec and SOW W1: quiet W2: low costs S01: <3yrs S04: no flood S05: low maint S12: equip works S02: miles W3:garden S03: 1/2 acre S11: water W4: family W5: electric W6: garage W7: cool W8: $100K W9: close S06: 1800 S07: 3 bdr S10: 100 amps S09: garage S08:east C2:$100K C3:close Wants SpecSOW Wants flow to spec and SOW either directly or through studies. It is desirable to document these studies. SSSSSS C1: house & lot

55. 3. Design55 Product SOW rC1: Provide house and lot that meet spec (ANA) rC2: Pay $100,000 (INS) rC3: Close on sale by 6/1/99 (INS) 5. Example

56. 3. Design56 Product Spec rS01: <3 years old (ANA) rS02 3 miles from town of 5000 people (INS) rS03 > 1/2 acre lot (INS) rS04 Does not flood (ANA) rS05 Low maintenance construction (INS) rS06: >1800 feet in air conditioning (INS) rS07: At least 3 bedrooms (INS) rS08: Master bedroom on east side (INS) rS09: Attached two-car garage (INS) rS10: >100 amperes electrical service (INS) rS11: > 11 gal/min from at least one faucet (TEST) rS12: Equipment works (DEMO) 5. Example

57. 3. Design57 Contractor Wants Customer wantsContractor wants ProfitPrideLaw 20%Happy buyerMeets 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

58. 3. Design58 Contractor Requirements rWants l Ds1: 20 percent profit (INS) l Ds2: Make buyer happy (INS) rOther l Dr1: Meets code (INS, DEMO) 5. Example

59. 3. Design59 Design Process Preliminary design review Critical design review Develop product concept Develop product design conceptdesign spec & I/Fs lower specs & I/Fs Develop lower specs & interfaces approval 5. Example

60. 3. Design60 Concept Garage StorageUtility Living Kitchen Bedroom Master Bedroom Bath N 5. Example

61. 3. Design61 Spec Tree House and lot Real estateStructureElectricalPlumbing 5. Example

62. 3. Design62 Contractor Design rDd1: Plans l Floor plan l Elevations l Plumbing plan l Electrical plan l Foundation plan l Lot layout rDd2: Flood analysis rDd3: Cost and schedule 5. Example

63. 3. Design63 Real Estate Flowdown C2: $100,000 C3: close by 6/1/99 Ds1: 20% Dd3: Cost/sched study Rs2: <$15,000 Rs3: close by 1/1/99 Dd1: PlansDd2: flood analysis Rr1: miles Rr3: 1/2 acre Rs1: land Rr2: doesn’t flood Rs4: provide analysis S02: miles S03: 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

64. 3. Design64 Real Estate Spec rRr1: 3 miles from town of 5000 people (INS) rRr2: Does not flood (ANA) rRr3: > 1/2 acre (INS) 5. Example

65. 3. Design65 Real Estate SOW rRs1: Provide land rRs2: < $15,000 rRs3: Close by 1/1/99 rRs4: Provide flood analysis 5. Example

66. 3. Design66 Structure Flowdown C2: $100,000 C3: close by 6/1/99 Ds1: 20% Dd3: Cost/sched study Ss2: <$53,000 Ss3: close by 5/1/99 Ss4: coordinate Dd1: PlansDd2: flood analysis Product spec, product SOW, and contractor wants flowdown through studies to become the structure spec and SOW Ss1: structure Sr1: meets design Sr2: brick Sr3: roof Sr4: paint Sr5: carpet S11: electrical S12: works Dr1: meets code Ds2: buyer happy Sr6: tile Sr7: colors Sr8: tile color Sr9: meets code 5. Example

67. 3. Design67 Structure Spec rSr1: Meets design (INS) rSr2: Brick (INS) rSr3: 30-yr composition (INS) rSr4: Long-lasting paint (INS) rSr5: Nylon carpet except bath and kitchen (INS) rSr6: Ceramic tile on all other interior floors (INS) rSr7: White exterior paint, beige interior paint, beige carpet (INS) rSr8: White tile (INS) rSr9: Meets code (INS) 5. Example

68. 3. Design68 Structure SOW rSs1: Provide structure rSs2: <$53,000 rSs3: Compete by 5/1/99 rSs4: Coordinate with plumber and electrician 5. Example

69. 3. Design69 Electrical Flowdown C2: $100,000 C3: close by 6/1/99 Ds1: 20% Dd3: Cost/sched study Es2: <$4,000 Es3: close by 5/1/99 Es4: coordinate Dd1: PlansDd2: flood analysis Product spec, product SOW, and contractor wants flowdown through studies to become the electrical spec and SOW Es1: electrical Er1: meets design Pr2: electrical Pr3: meets code S11: electrical S12: works Dr1: meets code 5. Example

70. 3. Design70 Electrical Spec rEr1: Meets design (INS) rEr2: >100 amperes electrical service (INS) rEr3: Meets code (INS) 5. Example

71. 3. Design71 Electrical SOW rEs1: Provide electrical rEs2: <$4,000 rEs3: Complete by 5/1/99 rEs4: Coordinate with structure 5. Example

72. 3. Design72 Plumbing Flowdown C2: $100,000 C3: close by 6/1/99 Ds1: 20% Dd3: Cost/sched study Ps2: <$8,000 Ps3: close by 5/1/99 Ps4: coordinate Dd1: PlansDd2: flood analysis Product spec, product SOW, and contractor wants flowdown through studies to become the plumbing spec and SOW Ps1: plumbing Pr1: meets design Pr2: water Pr3: meets code S11: water S12: works Dr1: meets code 5. Example

73. 3. Design73 Plumbing Spec rPr1: Meets design (INS) rPr2: >100 gal/min from one faucet (TEST) rPr3: Meets code (INS) 5. Example

74. 3. Design74 Plumbing SOW rPs1: Provide plumbing rPs2: <$8,000 rPs3: Complete by 5/1/99 rPs4: Coordinate with structure 5. Example

75. 3. Design75 6. Other Design Processes rDefense Management College (DMC) design process rJames Martin design process rEIA-632 design process 6. Other design processes

76. 3. Design76 DMC Design Process Requirement s analysis Functional analysis and allocation Synthesis System analysis and control requirements loop design loop verification process inputs process outputs Systems Engineering Process 6. Other design processes

77. 3. Design77 James Martin Design Process Requirements Analysis Functional Analysis and Allocation Synthesis Requirements loopDesign loop Requirements and architecture documentation Verification loop System analysis and optimization Specs, interfaces, design Requirements Product characteristics

78. 3. Design78 EIA 632 rRequirements relationship rDesign Process l Logical solution definition l Physical solution definition l Specified requirements generation 6. Other design processes

79. 3. Design79 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 requirements TRACE TO ASSIGNED TO DRIVE SOURCE OF SPECIFIED BY BECOME The EIA 632 entity relationship is similar to the PBA approach but is more complex. 6. Other design processes

80. 3. Design80 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 based approach given earlier, but it is more serial in description EIA 632 Figure 4.3.2 6. Other design processes

81. 3. Design81 Logical Solution Definition (1 of 3) rAnalyze functions, objects, data flow, data structures rDefine subfunctions rPerform trade studies rAssign performance requirements & constraints rAnalyze behaviors 6. Other design processes

82. 3. Design82 Logical Solution Definition (2 of 3) rIdentify and define interfaces, states and modes, timelines, data, & and control rAnalyze failure modes and define effects 6. Other design processes

83. 3. Design83 Logical Solution Definition (3 of 3) rEstablish set of logical solutions rValidate logical solutions rRecord logical solutions rIdentify and define derive technical requirements rRecord derived technical requirements 6. Other design processes

84. 3. Design84 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. 6. Other design processes

85. 3. Design85 Specified Requirements Generation rFully characterize design solution rVerify design solution rRecord design solution rGenerate and record specified requirements rInitiate development of enabling processes 6. Other design processes

86. 3. Design86 7. Homework rA customer wants to sell a line of lawn mowers that can cut Texas lawn grasses, requires partial assembly, and that costs less than $300 rDevelop a design that satisfies the customer l 1. List the customer requirements (>0, <10) l 2. List pseudo customer requirements (0, <20) l 3. List the key items in the concept (>0, <20) l 4. List the key items in the design (>0, <20) l 5. List key items in documentation (>0, <20) l 6. List the key items in the CDR (>0, <20) l 7. List items shall be (>0, <30 words); no pictures 7. Homework