1 / 27

How A Systems Engineer Starts……?

How A Systems Engineer Starts……?. Two Practitioners Speaking for Themselves, ergo the ‘A’. Herm Migliore Portland State University International Council on Systems Engineering (INCOSE) 1977 - 1997 Mechanical Engineering Senior Design Projects

Download Presentation

How A Systems Engineer Starts……?

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. How A Systems Engineer Starts……?

  2. Two PractitionersSpeaking for Themselves, ergo the ‘A’ • Herm Migliore Portland State University • International Council on Systems Engineering (INCOSE) • 1977 - 1997 Mechanical Engineering Senior Design Projects • 1997 – Present Advisor to Systems Engineering Masters Projects • Small to Medium Sized, Wide Variety of Companies & Agencies • Often Not an End -- Always a Beginning • John Blyler Editorial Director at Extension Media • Editor in Chief, ‘Chip Design’ and ‘Embedded Intel ‘ magazines • IEEE • 1993 – 1996 Systems Engineer, Hanford • Advisor & Prof Hardware-Software Integration • Systems Engineering Management

  3. Starts…? What ? • Project? consisting of a team and project manager? • systems engineer is part of team • or, may not be a ‘systems engineer’ on team • Process? what steps for developing an engineered system • includes implementation • development of product, process, or service • Method? how do we perform steps in development process • tailored to the project/product • Thinking? about Fuzzy-Front-End • ‘as-is’ situation is troubling • stakeholders vision on use of new system • before functions, before requirements

  4. Systems Engineering? What’s That? • is the practice of creating • the means of performing useful functions through • the combination of two or more interacting elements • Norm Augustine • retired Chairman and CEO, Lockheed Martin Corp • INCOSE “INSIGHT” Oct 2009 Vol 12 Issue 3

  5. Systems Engineering • Systems Engineering focuses is an interdisciplinary approach and means to enable • the realization of successful systems. It focuses on defining customer needs and • required functionality early in the development cycle, documenting requirements, • then proceeding with design synthesis and system validation while considering the • complete problem: Operations --Performance -- Test-- Manufacturing -- Cost & • Schedule--Training & Support--Disposal. Systems Engineering integrates all the • disciplines and specialty groups into a team effort forming a structured development • process that proceeds from concept to production to operation. Systems Engineering • considers both the business and technical needs of all stakeholders with the goal of • providing a quality product that meet the users needs. • International Council on Systems Engineering (INCOSE)

  6. Twelve Systems Engineering RolesSarah Sheard • Requirements Owner • System Designer • System Analyst • Validation/Verification Engr. • Logistics/Ops Engineer • Glue Among Subsystems • Customer Interface • Technical Manager • Information Manager • Process Engineer • Coordinator of Disciplines • Classified Ads SE – software systems

  7. Systems Engineering Principles and Practice • Kossiakoff and Sweet Wiley Interscience 2003

  8. Project Management Cost Control • Stakeholders????? • Customer • Sponsor • User • All Responsible and Affected Parties Systems Engineering THE INTERFACE between PM and Engineers Technical Specialties

  9. Cost Control Science • Sponsor Project Management Systems Engineering Technical Support

  10. User Need Product Release system test plan System Requirements System Testing HW-SW test plan HW-SW Requirements HW-SW Testing integration plan HW-SW Design Integration Testing unit plan HW-SW Implementation Unit Testing time Program Life Cycle – Vee Model

  11. CUSTOMER REQUIREMENTS Analyze Assess Outcomes and Problem & Select Decisions Synthesize Architecture Verify Architecture Technical Process Specification-Requirements Product System Assess Analyze and Organization Select Plans & Synthesize Verify Direction Activities Planning Management Process SEMP –Systems Engineering Management Plan Process System PRODUCT DEFINITION Brian W. Mar, Emeritus Professor UofW Bernard G. Morais, Synergistic Applications

  12. Differences Between PM and Systems Engineering • Program/Project Management • Cost, schedule, organization, business-side • Policy decisions • Program risk management • Allocate programmatic resources • Trained in Organization/Management Theory • Project Management Institute, Etc • Systems Engineering • Owner of Requirements and Architecture (high level design) • Interface between PM-technical specialists • Uses process to design, build, test and other product life cycle activities • Technical resource allocation • Technical risk management • Trained as an Engineer • INCOSE, IEEE, NASA, DOD, Etc

  13. Function-Requirements-Architecture-Test • “The Engineering of Complex Systems”, Morais and Mar, 1997

  14. FRAT Method May Be Combined with Other Process Models Heading Down Pyramid – Maturity of Development Proposal / Marketing Development Objectives Preliminary Design Detailed Design / Manufacturing

  15. One Level: F  R  A  T and FR  A Next Level: F  F1, F2, F3; Differences in Timing, Dependencies and Utility R  R1, R2, allocate/assign to A Eye of the Stakeholder? Upper Level FRAT Data Provides Scope For Next Level Lower Level Must Roll - Up and Map to Upper Level Each Level of FRAT Establishes a BASELINE

  16. Community Has Problem Symptoms from As-Is Situation: Unacceptable and Preferable Aspects ConOps jack.ring @incose.org Value Generated by Developed/Operational system • Consensus on: • Problem System • Intervention Strategy • Stimulus:Response Scenario(s) • Accountabilities Assay and Adaptation Assembly/ Deploy Design and Architecture Components Buy/Make Measures of Effectiveness effects that suppression system must exhibit Standards of Acceptance value of as-is and could-be

  17. Unacceptable Discomfort felt by Stakeholders • Consensus of All Responsible and Affected Parties: • Problem System – generates problem symptoms • Intervention Strategy - comprehensive view of intended use • Stimulus:Response – all possible scenarios of ‘To Be’ system, • that suppress (amplify?) problem symptoms, intervention system • Accountabilities- what are we/you willing to do to make problem go away Eye of Stakeholders Problem & Intervention Systems Will Change

  18. Tom • As-Is Situation • Viable recycling - Legacy hospitals • Contacts with suppliers/recyclers • Active recycling in Portland • Cost gasoline -up $4.25 down $2.50 • Tom wants help with promotion • Masters student, Neil interested in • - Fuzzy Front End • - ConOps

  19. Urine Bottles and Sorting Operation

  20. Blue wrap polypropylene film used for sterilizing surgical instruments Recycling Bags

  21. Existing Benefit to Legacy Hospital – Cost Avoidance Labor Costs were small

  22. Problem Suppression Systems – Intervention System • Neil’s Guidelines for Starting a Healthcare Recycling Center • Motivate Other Hospitals, Recyclers and Manufacturers • Tom Now a Consultant • Neil Earns Masters Degree • Synthesis - Write the story – ConOps For Stakeholders to Use • Accept , Don’t Accept, Start of New Systems, But ConOps Not Same Structure as IS

  23. System performance upgrade • Minimize force outages • Address the concern of the End-Users • Meet and exceed the various Standards set by the industry • Meet the needs of the organizations that regulate the day to day system operations • Address the public outcry for loss revenue and inadequate system performance • Address the findings from an independent Technical Audit Review group • Make the evolutionary changes that will allow the system to evolve with time, such as • Human to Man Interfaces (HMI) • Machine to Man Interface (MMI) • Programmable logic controller (PLC) • Maximize the system output capacity in Megawatts and revenue • Extend the Life Cycle of the system

  24. The tests & controls that were used to deliver the forecasted benefits are: • Boiler nozzle calibration test & gross boiler efficiency test • Thermal Heat Rate (THR) Test • Supervisory Control and Data Acquisition (SCADA) • Programmable Logic Controller & Machine to Man Interface (MMI)

  25. Systems Engineering • Traditional • Body of Knowledge, Handbooks, Publications, Certification • Structured and experienced development processes • Technical and Organizational • Requirements and Interface management • Tailored development processes, adaptive • Stakeholders part of development and use • Thinking • Describe not Prescribe (Herm needs a mnemonic , FRAT) • Stakeholders part of problem-system-use (Jack Ring’s ConOps) • Stakeholders’ knowledge and motivation will change • Combination of established and other perspectives • Uncertainty and risk • Change and evolution

More Related