1. 1. Introduction1 Agenda for introduction q1. Course details q2. Basic approach q3. Products q4. Cycles, phases, and activities q5. Product-based development approach (PBDA) q6. Management by WPs (WPs) q7. Value of PBDA q8. System engineering q9. CMMI q10. Homework

2. 1. Introduction2 1. Course details qCourse and instructor qCourse content qTextbook and time qSchedule qGrading qFormats 1. Course details

3. 1. Introduction3 Course and instructor qSMU -- EMIS 7301 Systems Engineering Processes qInstructor -- Jim Hinderer qWork phone number -- (972) 344 7410 qHome phone number -- (972) 359 1559 qE-mail address -- j-hinderer@mindspring.com qClass material l http://www.engr.smu.edu/sys/Hinderer 1. Course details

4. 1. Introduction4 Course content rShow how to develop a system from start to delivery rIllustrate a product-based development approach (PBDA) rShow applications to r commercial and military systems r large and small systems r hardware and software systems r people systems 1. Course details

5. 1. Introduction5 Textbook and time rTextbook l Systems Engineering Fundamentals l http://www.meicompany.com/text/tut orials/fundamentals_of_systems_en gineering.pdf rClass time -- 8:00 l Start -- 8:00 l Lunch -- 12:00 l Finish -- 5:00 1. Course details

6. 1. Introduction6 Schedule (1 of 2) r1/18 l Modules - 01-03 l Textbook -- chapters 1-2 l Homework for 2/1 - -module 01 l Homework for 2/8 -- module 02 r2/15 l Modules - 04-06 l Textbook -- chapters 3-8 l Homework for 3/1 -- module 05 l Homework for 3/8 -- module 06 1. Course details

7. 1. Introduction7 Schedule (2 of 3) r3/15 r Modules - 07-09 r Textbook -- chapters 9-15 r Homework for 3/22 -- module 07 r Homework for 3/29 -- module 08 r Homework for 4/5 -- module 09

8. 1. Introduction8 Schedule (3 of 3) r4/12 r Modules - 10-11 r Textbook -- chapters 16-20 r Homework for 4/19 r Project 4/26 r5/10 rModules - 12-13 rFinal 5/17

9. 1. Introduction9 Grading qHomework 30% qProject30% qFinal 40% 1. Course details

10. 1. Introduction10 Formats qNon-electronic: Pencil and paper qElectronic: Word, Excel, PowerPoint qPC and not Macintosh 1. Course details

11. 1. Introduction11 2. Basic approach qThe approach qExecution of the approach qEmphasis on executing the approach qApplication of the approach qName for the approach qReason for the approach qReasons systems fail qDisclaimer for the approach qGoal of this course 2. Basic approach

12. 1. Introduction12 The approach Determine what customer wants Decide what to do Get what it takes to do it Do it Check it out Convince customer it’s what he or she wanted Make it happen 2. Basic approach Approach consists of applying these seven activities to each product in the system Approach consists of applying these seven activities to each product in the system

13. 1. Introduction13 Execution of the approach qExecution of the approach consists of completing a small number of tangible objects called work products (WPs) for each product in the system 2. Basic approach

14. 1. Introduction14 Emphasis on executing the approach 2. Basic approach qEmphasis on executing this approach is on l Wisdom -- we don’t want to do stupid things l Simplicity -- we don’t want to lose the forest in all the trees

15. 1. Introduction15 Application of the approach qApply same set of activities to each product in the system 2. Basic approach

16. 1. Introduction16 Name for the approach qThis approach deals with development of products from conception to sell-off qIt’s called the product-based development approach (PBDA) 2. Basic approach

17. 1. Introduction17 Reason for the approach qThe approach brings discipline to the development by accommodating all aspects of the product and its life cycle in a way that the product comes together smoothly qHaving a disciplined approach to developing products makes cost, schedule, and quality predictable qHaving a disciplined approach reduces the likelihood of system failure 2. Basic approach

18. 1. Introduction18 A few reasons systems fail after delivery before delivery lack of qualified people unmanaged risks wrong requirements failure to execute other didn’t meet requirements overlooked something failed failed to impress customer 2. Basic approach

19. 1. Introduction19 Disclaimer for the approach qSystem engineering is more of an art than a science. qAlmost any approach to system engineering will work if someone takes ownership of success qNo one approach is better than all the others qThe reasons for applying any system engineering approach are the same as for the PBDA 2. Basic approach

20. 1. Introduction20 Goal of this course qThe goal of this course is to explain one approach for developing systems and to indicate how this approach relates to other approaches. 2. Basic approach

21. 1. Introduction21 3. Products qProduct definition qProducts composed of products qTypes of products qNeed for products qNeed for lower-level products qExamples 3. Products

22. 1. Introduction22 Product definition (1 of 2) qA product is something produced qA product is something we can procure -- hardware, software, data, services. 3. Products

23. 1. Introduction23 Product definition (2 of 2) qExamples l Hardware -- space shuttle, house, circuit card, resistor l Software -- program, firmware l Data -- documents, work products l Services -- activities qThe concept of a product makes explaining system engineering easier. 3. Products

24. 1. Introduction24 Products composed of products Level 1 Product Level 2 Product 1 Level 2 Product 2 Level 3 Product 1 Level 3 Product 2 Level 4 Product 2 Higher-level products Lower-level products Level 4 Product 1 Level 4 Product 3 3. Products

25. 1. Introduction25 Types of products (1 of 2) Level N product Products can be divided into two types of products -- delivered products and support products Products can be divided into two types of products -- delivered products and support products 3. Products Delivered products Support products

26. 1. Introduction26 q Delivered products -- part of the delivered product q Support products -- other products in support of delivered product q Either type of product may be l Hardware l Software l Data l Service Types of products (2 of 2) 3. Products

27. 1. Introduction27 Need for products qWe need products to describe what we’re controlling qProducts may be developed or procured without development 3. Products

28. 1. Introduction28 Need for lower-level products qWe need lower-level products if we’re going to procure something needed for doing the development 3. Products

29. 1. Introduction29 Example 1 -- model airplane Model airplane FuselageWingStabilizerRudderGlue Good example -- We can use the lower-level products to make the higher-level product 3. Products

30. 1. Introduction30 House KitchenBathroomBedroom 1Bedroom 2Garage Bad example -- We wouldn’t use the lower-level products to make the higher-level product Example 2 -- house, bad example 3. Products

31. 1. Introduction31 Example 3 -- house, good example House Plumbing FramingRoofElectrical Good example -- We can use the lower-level products to make the higher-level product FoundationDry wall 3. Products

32. 1. Introduction32 4. Cycles, phases, and activities qDefinitions qProduct life cycle qPre-develop-phase activities qDevelop-phase activities qPost-develop-phase activities qNotes on activities qExample 4. Cycles, phases, and activities

33. 1. Introduction33 Definitions qCycle -- a complete set of events occurring in the same sequence l Product life cycle l Contract life cycle qPhase -- part of a cycle; the period of time the activities take qActivity -- execution of a set of tasks qProcess -- steps used to accomplish an activity 4. Cycles, phases, and activities

34. 1. Introduction34 Product life cycle Phases Time Pre-develop Post-develop Develop 4. Cycles, phases, and activities

35. 1. Introduction35 Pre-develop-phase activities Sub phases or activities Time Meet the customer Discuss the work Respond to RFP Sub phases overlap Identify opportunity 4. Cycles, phases, and activities

36. 1. Introduction36 Develop-phase activities (1 of 2) Determine what customer wants Decide what to do Get what it takes to do it Do it Check it out Convince customer it’s what he or she wanted Make it happen Manage Understand requirements Design Acquire products Build Verify Sell-off 4. Cycles, phases, and activities

37. 1. Introduction37 Develop-phase activities (2 of 2) Sub-phases or activities Time Understand requirements Design Acquire products Build Verify Sell off Sub-phases overlap Manage 4. Cycles, phases, and activities

38. 1. Introduction38 Post-develop-phase activities Sub-phases Time Train Produce Upgrade Maintain Operate Dispose Sub-phases overlap Field test and validate Support 4. Cycles, phases, and activities

39. 1. Introduction39 Notes on activities qNot every product has the same activities l Developing software may not require acquiring products l Integration or verification may be deferred to another level qSome products may be so simple that they don’t require formal management. 4. Cycles, phases, and activities

40. 1. Introduction40 Example -- build a house Activities Time Learn what buyer wants Have architect make blueprint Get land and lumber Build See if the house is OK Close Supervise 4. Cycles, phases, and activities

41. 1. Introduction41 5. PBDA (1 of 2) qPBDA block diagram qApplication of PBDA to products qExample qWork products (WPs) qWPs for management qWPs for other activities qWPs vs inputs qOptimizing WPs qPareto of WPs by likely use 5. PBDA

42. 1. Introduction42 PBDA (2 of 2) qAlternative approaches qMeasuring usefulness of WPs qValue of PBDA qWhen to use PBDA 5. PBDA

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

44. 1. Introduction44 PBDA block diagram (2 of 2) q Abbreviations l MM -- management review l RR - requirements review l CR -- concept review l PDR -- preliminary design review l CDR -- critical design review l TRR -- test readiness review l VR -- verification review l FCA -- functional configuration audit l PCA -- physical configuration audit

45. 1. Introduction45 Application of PBDA to products Higher Product Lower Product 1 Lower Product 2 Lower Product N Product of Interest PBDA is applied to each product separately 5. PBDA

46. 1. Introduction46 Example with 10 products System Subsystem HWCI Unit CSCI HWCIUnit CSCI Example (1 of 2) 5. PBDA

47. 1. Introduction47 Developing the example with 10 instantiations of PBDA 1 23 67 8 9 10 5 Example (2 of 2) 5. PBDA

48. 1. Introduction48 6. Management by WPs qDefinition qDelivered products qWPs for management qWPs other activities qInput WPs qOptimizing WPs qPareto of WPs by likely use qMeasuring usefulness of WPs 6. Management by WPs

49. 1. Introduction49 Definition qA work product (WP) is a tangible object that is used to control the PBDA l Documents l Elements of environment to support engineering qMuch of the execution of the PBDA can be thought of as completing the associated WPs PBDA executed by completing WPs 6. Management by WPs

50. 1. Introduction50 Delivered products qDelivered products (2) -- product and lower products qThe goal of PDBA is to transform lower products into the product qLower products may be l Delivered products l Support products l Services qWork products aid in the transformation PBDA transforms lower products into higher product 6. Management by WPs

51. 1. Introduction51 WPs for management rEnvironment (6) -- people, facilities, tools, capital, communications, library [support products] rControl (11) -- schedule, budget, risks, TPPs, issues, AIs, timeline, plans, changes, problems, legal rReviews and audits (9) --MR, RR, CD, PDR, CDR, TRR, VR, PCA, FCA 26 WPs support products used for managing each product in PBDA. 26 WPs support products used for managing each product in PBDA. 6. Management by WPs

52. 1. Introduction52 WPs for other activities rUnderstand (0) -- rDesign (3) -- design, lower specs, lower interfaces rAcquire (1) -- lower contracts rBuild (1) -- build procedure rVerify (3) -- test spec, test procedure, test results rSell off (1) -- agreement 9 WPs used for developing each product in PBDA. 6. Management by WPs

53. 1. Introduction53 Inputs WPs rHigher inputs (3) -- contracts, specs, interfaces rLower inputs (3) -- lower test results, lower test spec, status rLower product (1) -- output from lower level Inputs are monitored but don’t belong to the product of interest Inputs are monitored but don’t belong to the product of interest 6. Management by WPs

54. 1. Introduction54 Optimizing WPs qSome work products can be shared between levels qNot all work products are needed at each level. Not all WPs must always be used 6. Management by WPs

55. 1. Introduction55 Pareto of products by likely use An example pareto of support products by likely use decreasing likelihood of use product (1) lower products (1) higher inputs (3) budget & schedule (2) environment (6) design (3) build proc (1) problems and changes (2) risks & TPPs (2) verify (3) plan and timeline (2) lower inputs (3) reviews and audits (9) agreement (1) acquire (1) issues and AIs (2) legal (1) 6. Management by WPs

56. 1. Introduction56 Measuring usefulness of WPs q-1 -- maintained but an obstacle q 0 -- not maintained q 1 -- maintained but not used q 2 -- maintained and used to monitor q 3 -- maintained and used to control q 4 -- maintained and used to optimize Value of an WP can be positive or negative 6. Management by WPs

57. 1. Introduction57 7. Value of PBDA qSimplicity qGenerality qUse of PBDA 7. Value of PBDA

58. 1. Introduction58 Simplicity (1 of 3) qMakes explaining system engineering easier 7. Value of PBDA

59. 1. Introduction59 Simplicity (2 of 3) qAn alternate approach has l 106 activities l 966 WPs l Result of many overlapping perspectives Alternate approaches have a lot of activities to manage 7. Value of PBDA

60. 1. Introduction60 Simplicity (3 of 3) qPBDA has l 7 activities l 43 items to manage 1 product, 35 WPs, 1 lower product & 6 WPs from other products total of 36 + 7N for a product with N lower products l Result of applying same approach at all levels PBDA is simpler 7. Value of PBDA

61. 1. Introduction61 Generality qHandles other disciplines l System engineering has evolved slowly Many disciplines such as software and electrical engineering could not identify where they fit within system engineering, so they defined what they needed independently As a result, there are many overlapping concepts Other disciplines fit in as developers of products using PBDA 7. Value of PBDA

62. 1. Introduction62 Use of PBDA complexity requirementssize hostility use no WPs use all WPs When to use PBDA is determined by size, complexity, requirements, and level of hostility When to use PBDA is determined by size, complexity, requirements, and level of hostility 7. Value of PBDA

63. 1. Introduction63 8. System engineering qDefinition of RAA qDefinition of a system qRelationship of products and systems qDefinition of system engineering qDefinition of a product engineer qDefinition of a project manager qDefinition of a system engineer qSystem engineering references 8. System engineering

64. 1. Introduction64 Definition of RAA (1 of 2) qR -- Responsibility: Who is supposed to do the task qA -- Authority : Who has the authority to do the task qA -- Accountability : Who gets blamed if something goes wrong 8. System engineering

65. 1. Introduction65 Definition of RAA (2 of 2) qThe goal is to l Give authority to people who are responsible and accountable l Make people with authority responsible and accountable 8. System engineering

66. 1. Introduction66 Definition of a system qA system is a set of things connected to form a whole thing 8. System engineering

67. 1. Introduction67 Relationship of products and systems qDefinition used here l Each product is a system qDefinitions used by others l System is the highest level product l System is the highest level product within a company or an enterprise 8. System engineering

68. 1. Introduction68 Definition of system engineering qSystem engineering -- Engineering that deals with systems qComponents of system engineering l Management -- more common l Technical -- more interesting qDifferent but identical names l System engineering l Systems engineering qWay of thinking -- all engineering approached in same way 8. System engineering

69. 1. Introduction69 Definition of a product engineer (1 of 2) qTerm invented to define a person who performs the roles of both the project manager and the system engineer qTerm almost never used in practice -- used here to avoid having to distinguish between the roles of a project manager and a system engineer 8. System engineering

70. 1. Introduction70 Definition of a product engineer (2 of 2) 8. System engineering project manager system engineer product engineer Term invented to define a person who performs the roles of both the project manager and the system engineer Term invented to define a person who performs the roles of both the project manager and the system engineer

71. 1. Introduction71 Definition of a project manager qThe person who has RAA for the product qManages project qProvides the environment to develop the product qGenerally has a significant level of technical depth 8. System engineering

72. 1. Introduction72 Definition of a system engineer (1 of 8) qA system engineer is someone who develops a system l Looks at big picture to improve probability of success l Carries product from concept to disposal l Creates requirements before the requirements are needed in the design 8. System engineering

73. 1. Introduction73 Definition of a system engineer (2 of 8) qDefinition used here l The person who has RAA for the technical part of the product and the administrative duties associated with the technical part l Reports to project manager 8. System engineering

74. 1. Introduction74 Definition of a system engineer (3 of 8) qDefinitions used by others l Customer advocate and system auditor l Technical leader l Developer of the system front end l Requirements keeper 8. System engineering

75. 1. Introduction75 Definition of a system engineer (4 of 8) qPerceptions of system engineer vary from technical leader to clerk qProblems with perception of system engineer l Not technical l Role not understood by management l Doesn’t get done in time l Overcome by events 8. System engineering

76. 1. Introduction76 Definition of a system engineer (5 of 8) qSystem engineer should lead the parade rather than clean up behind it qA problem the system engineer must overcome is being passed by the design, acquire-products, build, and verify activities qAnother problem is that system engineer must start with what’s given rather than from a clean sheet 8. System engineering

77. 1. Introduction77 Definition of a system engineer (6 of 8) qLeadership involves finding the leaders and being a leader among the leaders qLeadership involves finding the most active part of a project and leading at that point qA system engineer can become absorbed in processes to the point of abdicating leadership 8. System engineering

78. 1. Introduction78 Definition of a system engineer (7 of 8) system manager system technical contributor system engineer System engineer is both system manager and system technical contributor System engineer is both system manager and system technical contributor 8. System engineering

79. 1. Introduction79 Definition of a system engineer (8 of 8) modifiersynthesizer challenger reproducer dreamer innovator planner practicalizer risk creativity A challenge is to be recognized as an innovator 8. System engineering

80. 1. Introduction80 SE references (1 of 3) qSystems Engineering Manual Guidebook -- A Process for Developing Systems and Procedures l Author -- James N. Martin l Publisher -- CRC Press l Date -- 1997 l Cost -- $70-80 l Comment -- Approach similar to PBDA. Use to be textbook for EMIS 7301, but we didn’t follow it closely enough to warrant people buying it 8. System engineering

81. 1. Introduction81 SE references (2 of 3) qINCOSE Systems Engineering Handbook l Author -- International Council of Systems Engineering l Address -- INCOSE 2033 6 th Avenue Suite 804, Seattle, Washington l Date -- 1998 l Web address -- http://www.incose.org l Comment -- A good collection of material, but oriented toward non-PBDA approach 8. System engineering

82. 1. Introduction82 SE references (3 of 3) qSystems Engineering Fundamentals qAuthor -- Defense Science Management College (DSMC) qDate -- 2001 qWeb address l http://www.meicompany.com/text/tutorials /fundamentals_of_engineering.pdf qWarning Web site may require subscription qComment -- A good collection of material but oriented toward a non-PBDA approach. Oriented toward military system engineering qCost -- Unknown, paperback 8. System engineering

83. 1. Introduction83 9. CMMI qDefinition qObjectives qMaturity levels qProcess areas qGoals and practices qGeneric goals and practices qSpecific goals and practices qContinuous vs staged models qEditorial concerns 9. CMMI

84. 1. Introduction84 Definition qA collection of best practices that address l Productivity l Performance l Cost l Stakeholder satisfaction qAn integrated view of process improvement across disciplines qA follow on to SEI by Carnegie Mellon qA standard by which Government selects contractors qhttp://www.sei.cmu.edu/cmmi/products/models.html 9. CMMI

85. 1. Introduction85 Objectives (1 of 2) qImprove performance, cost, and schedule qImprove collaboration among stakeholders qProvide competitive world-class products and services qProvide common business and engineering perspective qHandle systems-of-systems qUse common processes for systems and software qEnsure management support 9. CMMI

86. 1. Introduction86 Objectives (2 of 2) qEncourage looking ahead rather than behind qDevelop staff that uses best practices qAllow moving staff among projects without changing processes qImprove processes 9. CMMI

87. 1. Introduction87 Maturity levels 1. Initial Process unpredictable, poorly controlled, and reactive 2. Managed Process characterized for projects and is often reactive 3. Defined Process characterized for the organization 4. Quantitatively managed Process measured & statistically controlled 5. Optimizing Emphasis on continuing improvement 9. CMMI

88. 1. Introduction88 Process areas (1 of 6) Focus: none 1. INITIAL (0) 9. CMMI

89. 1. Introduction89 Process areas (2 of 6) Focus: basic project management 2. MANAGED (7) requirements management project planning project monitoring and control supplier agreement management measurement and analysis process and product quality assurance configuration management 9. CMMI

90. 1. Introduction90 Process areas (3 of 6) Focus: process standardization 3. DEFINED (14) requirements development technical solution product integration verification validation 9. CMMI

91. 1. Introduction91 Process areas (4 of 6) Focus: process standardization 3. DEFINED (CONTINUED) organization process focus organizational training integrated product management integrated supplier management risk management decision and analysis resolution organizational environment for integration 9. CMMI

92. 1. Introduction92 Process areas (5 of 6) Focus: quantitative management 4. QUANTITATIVELY MANAGED (2) organizational process performance quantitative project management 9. CMMI

93. 1. Introduction93 Process areas (6 of 6) Focus: continuous process improvement 5. OPTIMIZING (2) organizational innovation and deployment causal analysis and resolution 9. CMMI

94. 1. Introduction94 Goals and practices GG SG Generic goals (GG) Apply to each process area within a maturity levels Have required generic practices (GP) Specific goals (SG) Apply to process areas Have required specific practices (SP) 9. CMMI

95. 1. Introduction95 Generic goals and practices (1 of 2) qGG 1: None qGG 2: Institutionalize a managed process l GP 2.1 Establish an organizational policy l GP 2.2 Plan the process l GP 2.3 Provide resources l GP 2.4 Assign responsibility l GP 2.5 Train people l GP 2.6 Manage configurations l GP 2.7 Identify and involve relevant stakeholders 9. CMMI

96. 1. Introduction96 Generic goals and practices (2 of 2) l GP 2.8 Monitor and control the process l GP 2.9 Objectively evaluate adherence l GP. 2.10 Review status with higher-level management qGG 3: Institutionalize a defined process l All GG 2 GPs l GP 3.1 Establish a defined process l GP 3.2 Collect improvement information qGG 4: Same as GG 3 qGG 5: Same as GG 4 9. CMMI

97. 1. Introduction97 Specific goals and practices (1 of 3) qSG 1 Establish estimates l SP 1.1 Estimate the scope of the requirements l SP 1.2 Establish estimates of work products and task attributes l SP 1.3 Define project life cycle l SP 1.4 Determine estimates of effort and cost Example for project monitoring and control 9. CMMI

98. 1. Introduction98 Specific goals and practices (1 of 3) qSG 2 Develop a project plan l SP 2.1 Establish the budget and schedule l SP 2.2 Identify project risks l SP 2.3 Plan for data management l SP 2.4 Plan for project resources l SP 2.5 Plan for needed knowledge and skills l SP 2.6 Plan stakeholder involvement l SP 2.7 Establish the project plan Example for project monitoring and control 9. CMMI

99. 1. Introduction99 Specific goals and practices (1 of 3) qSG 3 Obtain commitment to the plan l SP 3.1 Review plans that affect the project l SP 3.2 Reconcile work and resource levels l SP 3.3 Obtain pan commitment Example for project monitoring and control 9. CMMI

100. 1. Introduction100 Continuous vs staged models (1 of 2) qContinuous model l Process areas may have different levels of maturity l Same GGs, GPs, SGs and SPs as staged l 729 page document; different than staged 9. CMMI

101. 1. Introduction101 Continuous vs staged models (2 of 2) qStaged model l All process areas must have the same level of maturity l Same GGs, GPs, SGs and SPs as continuous l 729 page document; different than continuous 9. CMMI

102. 1. Introduction102 Editorial concerns (1 of 2) qNot focused on immediate problem l What are we doing? l Why is what we’re doing bad? qContains some practices with low benefit compared to cost l Tracing qContains some practices that are difficult to measure l Obtain commitment 9. CMMI

103. 1. Introduction103 Editorial concerns (2 of 2) qContains a large number of requirements l 25 process areas * ( 10 generic practices + 10 specific practices) > 500 qDoesn’t clearly address multiple lower products within a product l Appears focused on single product qRequires verifiability data beyond normal work products qIs susceptible to additional requirements imposed by auditors qIs going to grow; e.g. certification 9. CMMI

104. 1. Introduction104 10. Homework (1 of 2) q1. What is the best method for developing products: (a) product-based-development approach (PBDA), (b) object-oriented development, (c) clean room, (d) no one method of system engineering is better than all the others? q2. How many products are shown in “Example 3 -- house, good example”: (a) 0, (b) 1, (c) 6, (d) 7? q3. How many design activities are associated with the products in example “Example 3 -- house, good example” : (a) 0, (b) 1, (c) 6, (d) 7? 10. Homework

105. 1. Introduction105 Homework (2 of 2) q4. The activity of getting land and lumber in “Example -- build a house” is which one of the following PBDA activities: (a) manage, (b) design, (c) acquire products, (d) build? q5. An interface document between subsystems is an example of (a) development product, (b) engineering product, (c) environment product, (d) activity? q6. Which of the following has RAA for the product: (a) project manager, (b) system engineer, (c) all people on the project, (d) all have the same RAA? 10. Homework