1 / 32

Ch 4 System Engineering Management

Ch 4 System Engineering Management. Prepared by Bassam Odeh. Introduction. System Engineering is a part of project management - Provide technical guidelines, system integration, and technical coordination - Contribute to resource allocation, task definition, and customer interaction.

ulf
Download Presentation

Ch 4 System Engineering Management

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. Ch 4System Engineering Management Prepared by Bassam Odeh Bassam Odeh

  2. Introduction • System Engineering is a part of project management - Provide technical guidelines, system integration, and technical coordination - Contribute to resource allocation, task definition, and customer interaction Bassam Odeh

  3. Project Management Project Management = System Engineering + Project Planning and Control - Work Breakdown Structure - Project Organization - System Engineering Management Plan - Risk Management - Capability Maturity Model Integrated - Planning, Scheduling, Costing, Configuration Control Bassam Odeh

  4. Project Management “System Engineering is a Management Technology”. Bassam Odeh

  5. Work Breakdown Structure (WBS) • WBS : Hierarchical Task Organization - Subdivides total effort into successively smaller work elements - Provide basis of scheduling, costing, and monitoring - Often contractual requirement in competitive system development • Elements of a Typical WBS - System Project (Level 1) - Level 2 Category: - 1.1. System product - 1.2. System support - 1.3. System testing - 1.4. Project management - 1.5 Systems engineering Bassam Odeh

  6. WBS - 1.1 System Product Total effort required to develop, produce, and integrate the system itself. Bassam Odeh

  7. WBS – 1.2 System Support • Integrated Logistic Support : - equipment, facilities, and services for development &operation • Level 3 categories: - 1.2.1 Supply support - 1.2.2 Test equipment - 1.2.3 Transport and handling - 1.2.4 Documentation - 1.2.5 Facilities - 1.2.6 Personnel and training Bassam Odeh

  8. WBS – 1.3 System Level Test • Level 3 Category: • 1.3.1 Integration testing: - To support the step-wise integration of components and subsystems to achieve a total system • 1.3.2 System testing: - To provide for overall system tests and the evaluation of test results • 1.3.3 Acceptance testing: - To provide for factory and installation tests of delivered systems • 1.3.4 Operational testing and evaluation: - To test the effectiveness of the entire system in a realistic operational environment Bassam Odeh

  9. WBS - Project Mgmt and Systems Eng. • 1.4 Project management tasks: - To include all activities associated with project planning and control, including the management of the WBS, costing, scheduling, performance measurement, project reviews and reports, and associated activities • 1.5 System engineering tasks: - To include activities such as requirements analysis, trade-off studies, test requirements and evaluations, system design requirements, configuration management, and so on. - Concurrent engineering: • Integration of specialty engineering into the early phases of the engineering effort Bassam Odeh

  10. Cost Control and Critical Path Method • Project Cost Control: Forecasts and Collect the Cost • To be exercised by comparing actual reported costs against estimated costs, identifying and focusing attention on those work packages that deviate seriously from initial estimates • Critical Path Analysis: • Essential project management tool that traces each major element of the system back through the engineering of its constituent parts. • Particular path that is estimated to require the longest time to complete its constituent steps • Critical Path Method (CPM): - Based on WBS work element - Creates network of sequential activities - Identifies paths that take the longest to complete Bassam Odeh

  11. Systems Eng. Management Plan (SEMP ) • Plans implementation of all system engineering tasks • Defines Roles and Responsibilities of all participants • all of the many active participants (subsystem managers, component design engineers, test engineers, etc.) know their responsibilities to one another. Bassam Odeh

  12. Place of SEMP in Program Management Plan all of the many active participants (subsystem managers, component design engineers, test engineers, etc.) know their responsibilities to one another. Bassam Odeh

  13. Elements of a Typical SEMP • Development Program Planning and Control - Statements of work (SOW) - Organization (OBS), - Scheduling - Risk management - Technical performance measurement • Systems Engineering Process - Operational requirements - Functional analysis - Sys. Analysis and trade-off strategy - Sys. Test and evaluation strategy • Engineering Specialty Integration - Reliability, maintainability, and availability (RMA) engineering - Producibility engineering - Safety engineering - Human factors engineering Bassam Odeh

  14. Risk Management • Risk Management is a major challenge to system engineering since: - all new system developments present uncertainties and risks - reducing the program risk is a continual process throughout L.C - risk must be reduced as program investment rises • System Engineering’s Challenges and Goal: - to steer a course that poses minimum risks while achieving maximum results - “ Is perceived operational requirement realistic ?” - “Will they remain valid throughout the new systems’s life ?” - “Will resource required to develop the system be available?” - “Will the advanced technology necessary to achieve the goal?” - “Will the anticipated advances in production materialize ?” - “Will the development organization to be free from work stop?” Bassam Odeh

  15. Variation of Program Risk Reduction Effort RISK Reduction Effort Risk eliminated or reduced by - Analysis - Experiment - Test - Change in course Risk Mitigation Waterfall Bassam Odeh

  16. Risk Mitigation Waterfall Chart • Concept Exploration and Advanced Development Bassam Odeh

  17. Components of Risk Management • DoD Risk Management Guides: Risk Assessment & Mitigation • Risk planning, Risk Assessment, Risk Prioritization • Risk Handling, Risk Monitoring • Risk Planning is a part of SEMP • Risk Assessment • To eliminate the immature tech., unproven tech. approach, ambiguous advances- uncertainty of their realization • In advanced dev. phase, approach to identification & characterization of proposed design feature - two risk components: . A) Risk Likelihood : given component will fail to meet its goal . B) Risk Criticality : impact of such a failure to the success Bassam Odeh

  18. Risk Assessment – Risk Likelihood Risk Likelihood : Probability of Failure - Many uncertainties → To be able to compute a numerical value - Unproven technology → estimate the relative degree of maturity: . Risk likelihood : High, Medium, Low Risk scale - Rank ordering of relative complexity →Prioritizing the effort required - Prioritizing of software engineering → Concurrent process Bassam Odeh

  19. Risk Likelihood Bassam Odeh

  20. Risk Assessment – Risk Criticality Risk Criticality : Impact of Failure - System Impact : if the system component at risk failed to perform its function - Program Impact : if the system component was discovered to be faulty later - Criticality → assigning the numerical values to the estimate of risk likelihood and risk criticality, and taking their product → disadvantage ? Bassam Odeh

  21. Risk Criticality Bassam Odeh

  22. Risk Management - Risk Mitigation Risk Mitigation Method • Listed in order of increasing seriousness of the perceived risk (1) Intensified Technical & management review (2) Oversight of designated component engineering (3) Special analysis & testing of critical design item (4) Rapid prototyping & test feedback (5) Consideration of Relieving critical design requirements (6) Initialization of fallback parallel development Bassam Odeh

  23. Risk Mitigation Method (1) Intensified Technical & management review → SRR, SDR, PDR, CDR, TRR detailed in Ch.9 . Significant risk items are fully presented and discussed for special action (2) Oversight of designated component engineering → Special engineering oversight frequently . Risk mitigation plan should be prepared and tracked until resolved (3) Special analysis & testing of critical design items → Special analysis and tests . For component not resolved in the first phase, additional fabrication & test (4) Rapid prototyping & test feedback → Rapid prototyping for unproved components . Construct and test prototypes for validity in advanced technology phase (5) Consideration of Relieving critical design requirements → Retry of rigorous requirement, and when complex, costly, unreliable, undesirable (6) Initialization of fallback parallel development → Fallback development or alternative design approach should be in the advanced development phase Bassam Odeh

  24. Risk Management -Risk Mitigation Plan • Risk Mitigation Plan should be developed and progressively updated for minimum impact; Cost, Performance, Schedule • Risk Mitigation Plan → Mitigation Waterfall Chart, example Bassam Odeh

  25. Risk Mitigation Plan Bassam Odeh

  26. Organization of Systems Engineering • Why is the Organization of SE important ? - System Engineering function need to adapt to pre-existing organizational structure. - Organizational form of company : contract team • System Integration (Prime Contractor) • Participating subsystem (Subcontractor) - Organizational structure of prime contractor → form of “Matrix” organization in discipline or in technology-oriented groups • Systems Engineering Organization - Spans disciplines and participating organizations - Adapts to company organizational structure - Most communicate effectively “What, when, and why” - Provides technical reviews for all participants - Should be supported by a system analysis staff. Bassam Odeh

  27. Effective Technical Communication Communication need to be exercised as appropriate • Participants need to know what they are expected to do, when, and why. • What → Task Assignment and WBS • When → Schedule, milestone, and critical path network • Why → Requirement and Specification • Participants must be aware of how their portions of system interact with other key elements, and the nature of their mutual interdependence: • Not by document, by Periodic personal communication with • Interface working group and Interface control document • Subcontractors and other key participants at remote sites must be integrated into the project communication framework: • Task of system project manager, Responsibility of SE staff • The principal leaders of the system design effort must have a regular and frequent means of communication with one another to keep the program closely coordinated and to react quickly to programs. • Periodic Program Management Review, • Frequent Tech. Coordination Meeting Bassam Odeh

  28. System Design Team –Leadership SDT requires the following membership as a minimum: - Systems engineer – Team leader requires “energetic leadership” - Lead engineers for major subsystems - Software systems engineering - Support engineering (Logistics) - Test engineering - User representatives - Specialty and concurrent engineering members (as appropriate). Large programs require formal system design teams - Integrate major subsystems and subcontractors - Integrate software systems engineering - Contain members from support engineering and the test organization - Contain specialty members as appropriate - Include user representation when called for - Focuses on success of the entire enterprise - Are becoming the norm for industry, especially in defense programs. Bassam Odeh

  29. SE Capability Maturity Assessment • CMM: Capability Maturity Model • Developed by SEI (Software Engineering Institute) see Ch.13 and by EIA (Electronics Association) – EIA/IS 173 in 1991 • CMM Integration • Developed for integrated capability maturity assessment standard bridging S/W engineering and System engineering • To be certified at a given level, all of the PA’s for that level to be achieved. - 24 CMMI PA (Process Area) grouped under 4 categories: . Process Management Category . Engineering Category . Project Management Category . Support Category Bassam Odeh

  30. CMMI Process Area (1/2) 24 CMMI PAs – 4 Categories : • Process Management Category - Organization process focus - Organizational process definition - Organizational training - Organizational process performance - Organizational innovation and deployment • Engineering Category - Requirements management - Requirements development - Technical solution - Provide integration - Verification - Validation Bassam Odeh

  31. CMMI Process Area (2/2) • Project Management Category - Project planning - Project monitoring and control - Supplier agreement management - Risk Management - Quantitative project management • Support Category - Configuration management - Process & product quality assurance - Measurement and analysis - Decision analysis and resolution - Casual analysis and resolution Bassam Odeh

  32. Systems Engineering Standards • DoD standard 499B →EIA/IS 632 • General principles of systems engineering as applied to the development of complex defense system • In the mid 1990s, DoD stop developing military standard, and adopt the industrial professional standard: DoD 499B → EIA/IS 632 • ISO/IEC 15288 • Combination of ISO and IEC have developed the new system engineering standard ISO/IEC 15288Is expected to supersede prior standards • Emphasizes broad enterprise view of system as a common definition of system engineering methodology END of Chapter 4 Bassam Odeh

More Related