1 / 62

Agenda for introduction

Agenda for introduction. 1. Course details 2. Basic approach 3. Products 4. Cycles, phases, and activities 5. Control 6. System engineering 7. Homework. 1. Course details. Course and instructor Course content Textbook and time Schedule Grading Formats. 1. Course details.

marged
Download Presentation

Agenda for introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agenda for introduction • 1. Course details • 2. Basic approach • 3. Products • 4. Cycles, phases, and activities • 5. Control • 6. System engineering • 7. Homework

  2. 1. Course details • Course and instructor • Course content • Textbook and time • Schedule • Grading • Formats 1. Course details

  3. 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. Course content • Show how to develop a system from start to delivery • Illustrate a product-based development approach (PBDA) • Show applications to commercial and military systems, large and small systems, hardware and software systems, and people systems 1. Course details

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

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

  7. Grading • Homework 30% • Exam 30% • Final 40% 1. Course details

  8. Formats • Non-electronic: Pencil and paper • Electronic: Office 97 Word, Excel, PowerPoint • PC and not Macintosh 1. Course details

  9. 2. Basic approach • System engineering • Guidelines • Activities • Application 2. Basic approach

  10. System engineering • System engineering is more of an art than a science. • Almost any method of system engineering will work if someone takes ownership of success • No one method of system engineering is better than all the others • The 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. Guidelines • Wisdom • Simplicity 2. Basic approach

  12. Activities Determine what customer wants Make it happen 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 2. Basic approach

  13. Application • Apply same set of activities to each product 2. Basic approach

  14. 3. Products • Product definition • Products composed of products • Need for lower-level products • Examples 3. Products

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

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

  17. 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 1 Level 4 Product 2 Level 4 Product 3 Lower-level products 3. Products

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

  19. Example 1 -- model airplane Model airplane Fuselage Wing Stabilizer Rudder Glue Good example -- We can use the lower-level products to make the higher-level product 3. Products

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

  21. Example 3 -- house, good example House Plumbing Foundation Framing Roof Electrical Dry wall Good example -- We can use the lower-level products to make the higher-level product 3. Products

  22. 4. Cycles, phases, and activities • Definitions • Product life cycle • Pre-develop-phase activities • Develop-phase activities • Post-develop-phase activities • Notes on activities • Example 4. Cycles, phases, and activities

  23. Definitions • Cycle -- a complete set of events occurring in the same sequence • Product life cycle • Contract life cycle • Phase -- part of a cycle; the period of time the activities take • Activity -- execution of a set of tasks • Process -- steps used to accomplish an activity 4. Cycles, phases, and activities

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

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

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

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

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

  29. Notes on activities • Not every product has the same activities • Developing software may not require acquiring products • Integration or verification may be deferred to another level • Some products may be so simple that they don’t require formal management. 4. Cycles, phases, and activities

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

  31. 5. Control • Control by engineering products • Control by product-based development approach (PBDA) 5. Control

  32. 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. 5. Control

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

  34. External: higher product teams contracts, specs, interfaces Control by PBDA (1 of 15) 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 2. Understand req RR control, status design 3. Design CR PDR CDR lower specs & I/Fs build proc test results test spec 4. Acquire lower contracts, specs, interfaces lower products product 5. Build 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

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

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

  37. Control by PBDA (4 of 15) 1 2 3 5 8 6 7 10 9 Developing the example with 10 instantiations of PBDA 5. Control

  38. Control by PBDA (5 of 15) • Environment (6) -- people, facilities, tools, capital, communications, library • Control (11) -- schedule, budget, risks, TPPs, issues, AIs, timeline, plans, changes, problems, legal • Reviews and audits (9) --MR, RR, CD, PDR, CDR, TRR, VR, PCA, FCA 26 management activities for each product in PBDA 5. Control

  39. Control by PBDA (6 of 15) • Understand (0) -- • Design (3) -- design, lower specs, lower interfaces • Acquire (1) -- lower contracts • Build (2) -- build procedure, product • Verify (3) -- test spec, test procedure, test results • Sell off (1) -- agreement 10 management activities for each product in PBDA 5. Control

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

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

  42. Control by PBDA (9 of 15) • 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 PBDA helps understand where other disciplines fit 5. Control

  43. Control by PBDA (10 of 15) • Makes explaining system engineering easier • Allows these disciplines to be parallel rather than randomly aligned supportability electrical engineering system engineering software maintainability configuration management PBDA allows disciplines to use similar approaches 5. Control

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

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

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

  47. Control by PBDA (14 of 15) • -1 -- maintained but an obstacle • 0 -- not maintained • 1 -- maintained but not used • 2 -- maintained and used to monitor • 3 -- maintained and used to control • 4 -- maintained and used to optimize Value of management object can be positive or negative 5. Control

  48. Control by PBDA (15 of 15) product (1) problems and changes (2) lower products (1) verify (3) higher inputs (3) legal (1) design (3) reviews and audits (9) plan and timeline (2) issues and AIs (2) budget & schedule (2) lower inputs (3) physical environment (6) acquire (1) paper risks & TPPs (2) agreement (1) external paper build (1) decreasing likelihood of use An example pareto of management objects by likely use 5. Control

  49. 6. System engineering • Definition of RAA • Definition of a system • Definition of a product engineer • Definition of a project manager • Definition of a system engineer 6. System engineering

  50. Definition of RAA (1 of 2) • R -- Responsibility: Who is supposed to do the task • A -- Authority : Who has the authority to do the task • A -- Accountability : Who gets blamed if something goes wrong RAA has three parts 6. System engineering

More Related