1. 1. Introduction1 Agenda for introduction q1. Course details q2. Basic approach q3. Products q4. Cycles, phases, and activities q5. Control q6. System engineering q7. 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 Course -- 7301 Systems Engineering Process Room -- 125 Caruth Hall Instructor -- Jim Hinderer Work phone number -- (972) 344 7410 Home phone number -- (972) 596 2693 E-mail address -- j-hinderer@raytheon.com 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 commercial and military systems, large and small systems, hardware and software systems, and people systems 1. Course details

5. 1. Introduction5 Textbook and time rTextbook -- none rClass time -- 6:30 - 9:20 l 6:30 - 7:50 first lecture period l 7:50 - 8:00 break l 8:00 - 9:20 second lecture period 1. Course details

6. 1. Introduction6 Schedule r8/28 Introduction r9/4Labor Day, no class r9/11, 18Understanding-customer r9/25, 10/2, 9, 16Design q10/23Acquisition and build r10/30Verification and sell-off r11/6, 13Management r11/20Processes r11/27Report, no class r12/4Implementation r12/11Final, take home 1. Course details

7. 1. Introduction7 Grading qHomework 30% qExam30% qFinal 40% 1. Course details

8. 1. Introduction8 Formats qNon-electronic: Pencil and paper qElectronic: Office 97 Word, Excel, PowerPoint qPC and not Macintosh 1. Course details

9. 1. Introduction9 2. Basic approach qSystem engineering qGuidelines qActivities qApplication 2. Basic approach

10. 1. Introduction10 System engineering qSystem engineering is more of an art than a science. qAlmost any method of system engineering will work if someone takes ownership of success qNo one method of system engineering is better than all the others qThe goal of this course is to explain one method for developing systems and to indicate how this method relates to other methods. 2. Basic approach

11. 1. Introduction11 Guidelines qWisdom qSimplicity 2. Basic approach

12. 1. Introduction12 Activities 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

13. 1. Introduction13 Application qApply same set of activities to each product 2. Basic approach

14. 1. Introduction14 3. Products qProduct definition qProducts composed of products qNeed for lower-level products qExamples 3. Products

15. 1. Introduction15 Product definition (1 of 2) qA product is something produced by nature or by human industry or art qA product is something we can procure -- hardware, software, data, services. 3. Products

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

17. 1. Introduction17 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

18. 1. Introduction18 Need for lower-level products qA product that doesn’t need development or support does not need lower-level products qWhether a product needs lower-level products depends upon whether we care about it. l A stone has no lower level components l A light bulb has lower level components, but purchasers don’t care l A personal computer has lower level components, and some people may care qWhether we want to put effort into it 3. Products

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

20. 1. Introduction20 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

21. 1. Introduction21 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

22. 1. Introduction22 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

23. 1. Introduction23 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

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

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

26. 1. Introduction26 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

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

28. 1. Introduction28 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

29. 1. Introduction29 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

30. 1. Introduction30 Example 1-- 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

31. 1. Introduction31 5. Control qControl by engineering products qControl by product-based development approach (PBDA) 5. Control

32. 1. Introduction32 Control by engineering products (1 of 2) Level N Product Deliverable Products Environment Products Engineering Products Products can be divided into three delivered products. Environment products, and engineering products. Products can be divided into three delivered products. Environment products, and engineering products. 5. Control

33. 1. Introduction33 qDeliverable products -- part of level-N product q Environment products -- physical products that interact physically with the level-N product throughout its life, such as manufacturing, test, and maintenance equipment q Engineering products -- other products that enable development of the level-N product, such as specifications Control by engineering products (2 of 2) Engineering products support the development of delivered products and environment products Engineering products support the development of delivered products and environment products 5. Control

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

35. 1. Introduction35 Control by PBDA (2 of 15) Higher Product Lower Product 1 Lower Product 2 Lower Product N Product of Interest PBDA is applied to each product separately 5. Control

36. 1. Introduction36 Example with 10 products System Subsystem HWCI Unit CSCI HWCIUnit CSCI Control by PBDA (3 of 15) 5. Control

37. 1. Introduction37 Developing the example with 10 instantiations of PBDA 1 23 67 8 9 10 5 Control by PBDA (4 of 15) 5. Control

38. 1. Introduction38 Control by PBDA (5 of 15) rEnvironment (6) -- people, facilities, tools, capital, communications, library 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 management activities for each product in PBDA 5. Control

39. 1. Introduction39 Control by PBDA (6 of 15) rUnderstand (0) -- rDesign (3) -- design, lower specs, lower interfaces rAcquire (1) -- lower contracts rBuild (2) -- build procedure, product rVerify (3) -- test spec, test procedure, test results rSell off (1) -- agreement 10 management activities for each product in PBDA 5. Control

40. 1. Introduction40 Control by PBDA (7 of 15) rHigher inputs (3) -- contracts, specs, interfaces rLower inputs (4) -- lower product, lower test results, lower test spec, status Inputs are monitored by aren’t MOs

41. 1. Introduction41 Control by PBDA (8 of 15) qSome management objects can be shared between levels qNot all management objects are needed at each level. Not all management objects must always be used 5. Control

42. 1. Introduction42 Control by PBDA (9 of 15) qSystem engineering has evolved slowly qMany disciplines such as software and electrical engineering could not identify where they fit within system engineering, so they defined what they needed independently qAs a result, there are many overlapping concepts qOther disciplines fit in as developers of products using PBDA PBDA helps understand where other disciplines fit 5. Control

43. 1. Introduction43 Control by PBDA (10 of 15) qMakes explaining system engineering easier qAllows these disciplines to be parallel rather than randomly aligned system engineering software supportabilityelectrical engineering maintainability configuration management PBDA allows disciplines to use similar approaches 5. Control

44. 1. Introduction44 Control by PBDA (11 of 15) qAlternate approach l 106 activities l 966 management objects l Result of many overlapping perspectives Alternate approaches have a lot of activities to manage 5. Control

45. 1. Introduction45 Control by PBDA (12 of 15) qPBDA l 7 activities l 43 items to manage 36 management objects 7 inputs total of 35 + 8N for a product with N lower products l Result of applying same approach at all levels PBDA is simpler 5. Control

46. 1. Introduction46 Control by PBDA (13 of 15) complexity requirementssize hostility use no MOs use all MOs When to use PBDA is determined by several factors 5. Control

47. 1. Introduction47 Control by PBDA (14 of 15) 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 management object can be positive or negative 5. Control

48. 1. Introduction48 Control by PBDA (15 of 15) An example pareto of management objects by likely use 5. Control decreasing likelihood of use product (1) lower products (1) higher inputs (3) budget & schedule (2) environment (6) design (3) build (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) physical paper external paper

49. 1. Introduction49 6. System engineering qDefinition of RAA qDefinition of a system qDefinition of a product engineer qDefinition of a project manager qDefinition of a system engineer 6. System engineering

50. 1. Introduction50 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 RAA has three parts 6. System engineering

51. 1. Introduction51 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 The goal of RAA is to assign duty and power to get the job done The goal of RAA is to assign duty and power to get the job done 6. System engineering

52. 1. Introduction52 Definition of a system 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 Each product is a system 6. System engineering

53. 1. Introduction53 Definition of a product engineer qThe person who has RAA for the product qPerforms the roles of the project manager and the system engineer The product engineer has RAA for the product 6. System engineering

54. 1. Introduction54 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 The project manager is a product engineer who concentrates on management The project manager is a product engineer who concentrates on management 6. System engineering

55. 1. Introduction55 Definition of a system engineer (1 of 6) 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 As used here, system engineering does a subset of the product engineer tasks As used here, system engineering does a subset of the product engineer tasks 6. System engineering

56. 1. Introduction56 Definition of a system engineer (2 of 6) qDefinitions used by others l Customer advocate and system auditor l Technical leader l Developer of the system front end l Requirements keeper There are many other definitions of system engineer used in practice There are many other definitions of system engineer used in practice 6. System engineering

57. 1. Introduction57 Definition of a system engineer (3 of 6) qPerceptions of system engineer vary from technical leader to clerk qProblems l Not technical l Role not understood by management l Doesn’t get done in time l Overcome by events The perception of the system engineering job varies from technical leader to clerk The perception of the system engineering job varies from technical leader to clerk 6. System engineering

58. 1. Introduction58 Definition of a system engineer (4 of 6) 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, product acquisition, build, and verification activities The ideal system engineer is a leader 6. System engineering

59. 1. Introduction59 Definition of a system engineer (5 of 6) 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 Becoming a leader takes a lot of work and there are many pitfalls Becoming a leader takes a lot of work and there are many pitfalls 6. System engineering

60. 1. Introduction60 Definition of a system engineer (6 of 6) modifiersynthesizer challenger reproducer dreamer innovator planner practicalizer risk creativity A challenge is be recognized as an innovator 6. System engineering

61. 1. Introduction61 7. 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 1.3-3: (a) 0, (b) 1, (c) 6, (7)? q3. How many design activities are associated with the products in example 1.3-3: (a) 0, (b) 1, (c) 6, (7)? 7. Homework

62. 1. Introduction62 Homework (2 of 2) q4. The activity of getting land and lumber in example 1.4-1 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 the greatest RAA: (a) product engineer, (b) system engineer, (c) project manager, (d) all have the same RAA? 7. Homework