1 / 42

Managing the Engineering of Systems

Managing the Engineering of Systems. Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Brian P. Gallagher, Director Acquisition Support 29 October, 2007. Contents. Engineering Management Software Engineering is Systems Engineering

alden-pennington
Download Presentation

Managing the Engineering of Systems

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. Managing the Engineering of Systems Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Brian P. Gallagher, Director Acquisition Support 29 October, 2007

  2. Contents Engineering Management Software Engineering is Systems Engineering Software Engineering is Different Back to Basics: Principles of Effective Engineering Management Three Important Things Conclusion

  3. Engineering Management Managing complex engineering projects requires: • Ability to manage customers • Ability to understand technical complexities • Ability to understand team complexities • Ability to inspire and lead • Ability to negotiate • Ability to deliver • Ability to plan, re-plan, re-start, and close-out • Situational awareness • Luck

  4. AoA Plan MS B Acq. Strategy v1.0 Acq. Strategy v2.0 Tech Devel Strat RefineAcquisition Strategy DevelopAcquisition Strategy RefineAcquisition Strategy Stakeholders Stakeholders Stakeholders Stakeholders Stakeholders Stakeholders Improve Process Improve Process Execute Refined Acquisition Strategy Evaluate Incremental Progress Evaluate Incremental Progress Execute Acquisition Strategy Knowledge Evolves: Acquirer’s View

  5. System Context System Context Simultaneous Definition and Tradeoffs Architecture & Design Architecture & Design Marketplace, Re-use Implementation Knowledge Evolves: Developer’s View Traditional Approach (Waterfall Development) Evolutionary Approaches • requirements • cost • schedule • business processes • operational procedures, etc. • COTS products • NDI • Strongly influenced by products and standards Known Rqmnts Buy, Re-use, Build, Integrate, Refresh

  6. Complex Operational Environments

  7. Require Complex System Solutions Manned Ground Vehicles (MGV) Unmanned Aerial Systems (UAS) Mounted Combat System (MCS) XM1202 Infantry Carrier Vehicle (ICV) XM1206 Command and Control Vehicle (C2V) XM1209 Class I UAV (XM156) Class IV UAV (MQ-8B) Notional Centralized Controller Reconnaissance And Surveillance Vehicle (RSV)XM1201 Unattended Ground Systems (UGS) APS U-UGS(AN/GSR-10 (T)) U-UGS(AN/GSR-9 (U)) Common Chassis Common Chassis Non-Line of Sight Mortar (NLOS-M) XM1204 Non-Line of Sight Launch System (NLOS-LS) XM501 Tactical and Urban Unattended Ground Sensors Non-Line of Sight Cannon (NLOS-C) XM1203 Unmanned Ground Vehicles (UGV) MULE-T MULE-C Medical Vehicle Treatment (MV-T)XM1208 Small UGV (SUGV) FCS Recovery and Maintenance Vehicle (FRMV) XM1205 Multifunction Utility/ Logistics and Equipment Countermine and Transport Armed Robotic Vehicle – Assault (Light) (ARV-A-L) Medical Vehicle Evacuation (MV-E) XM1207 17 Jul 07

  8. Voyages of Discovery, not Well-Defined Programs

  9. Software Engineering is Systems Engineering

  10. What is a System? … a collection of different things which together produce results unachievable by the elements alone • The Art of System Architecting, 2nd edition, Maier and Rechtin … an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective • Systems Engineering Fundamentals, Defense Acquisition University Press … a set of complementary, interacting parts with properties, capabilities and behaviors emerging both from the parts and from their interactions • Hitchins, Derek, http://www.hitchins.co.uk/WCES.html

  11. Systems Engineering is … …an interdisciplinary, collaborative approach that derives, evolves, and verifies a life-cycle balanced system solution which satisfies customer expectations and meets public acceptability • (Reference: IEEE P1220)

  12. Software Engineering is … …the design, development, and documentation of software by applying technologies and practices from computer science, project management, engineering, application domains, interface design, digital asset management and other fields • (Reference: Wikipedia)

  13. Systems Engineering: “I want” to “I got” Operational Need Systems Engineering

  14. Software Engineering: “I want” to “I got” Operational Need Software Engineering

  15. Effective Engineering Managers Employ Software-Aware Systems Engineering: “I want” to “I got” Operational Need Software-Aware Systems Engineering

  16. Software as a “Product”; Software Engineering as a “Discipline” Software-Aware Systems Engineering Software Products Software Engineering

  17. Software is Different

  18. Realities of Software The flowchart might correspond to a 100 LOC module with a single loop that may be executed no more than 20 times. There are approximately 1014 possible paths that may be executed! For any but the smallest programs, complete path coverage for defect detection is impractical. Adapted from Pressman, R.S., Software Engineering: A Practitioner’s Approach, Third Edition, McGraw Hil, 1992

  19. Challenges of Software Typical Industry Software Quality at Delivery • A 1,000 line-of-code (1 KLOC) program listing has about 20 pages of executable code • For industrial software, typical shipped quality levels are 5 to 10 defects per KLOC or 1 defect in 2 – 4 pages • A 1 million line-of-code (1 MLOC) printed listing stands roughly 5’7” and contains between 5,000 to 10,000 defects when shipped For DoD acquisition programs, these realities are often ignored resulting in unrealistic schedules and unplanned test/fix cycles inserted to grow the reliability of low quality software.

  20. What Does 17M ESLOC Look Like?

  21. How do we Grow the Reliability? Do we expect between 85,000 and 170,000 defects to still be present after FQT? Do we plan to discover, fix, re-test or do we plan to “prove functionality” (Green Light Integration and Test)? Do systems engineers without a foundation in software engineering understand this unique aspect of the complexities of software-intensive systems and latent defects that will be present? What are the consequences?

  22. V-22 Osprey A V-22 Osprey crashed on December 11, 2000. • Four marines were killed. • The problem was traced to a software defect. V-22 software had been exhaustively tested.

  23. Software is Challenging The complexities, the interactions, the flexibility, and our inability to grasp how difficult building software-intensive systems places us at a cross-roads New techniques are needed but are years away We refuse to accept this and grasp at “Silver Bullets”

  24. Back to Basics:Principles of Effective Management

  25. The Buzzword Quagmire and Quest for the “Silver Bullet” Open Systems DoDAF Interoperability FEAF ATAM Acquisition Reform Total System Performance Responsibility Time-Certain Development Agile Acquisition Win-Win Spiral Evolutionary Acquisition Extreme Programming Capability-Based Acquisition Lean Six Sigma CMMI Team Software Process Insight versus Oversight Net-Centric Warfare Service-Based Acquisition Open Architecture Service-Oriented Architecture Incremental Commitment Model Earned-Value Architecture-based Development Lean Acquisition Systems Engineering Revitalization

  26. How to make sense? Principle-Based Decisions “Principle” Defined: The collectivity of moral or ethical standards or judgments: a decision based on principle rather than expediency. Decisions to pursue a given management approach should be grounded on underlying principles designed to increase the effectiveness of acquiring, developing, and deploying systems to the end user The following describes the Seven Principles of Effective Engineering Management

  27. Seven Principles of Effective Engineering Management

  28. The Core Principle: Open Communication Encouraging free flowing information at and between all stakeholders. Enabling formal, informal, and impromptu communication. Using consensus-based processes that value the individual voice (bringing unique knowledge and insight to evolving mission capabilities).

  29. The Three Sustaining Principles Team Risk Management Continuous Process Improvement Continuous Product Improvement

  30. Team Risk Management Evolving the warfighter’s capabilities by continuously mitigating operational, development, and acquisition risks. All stakeholders participating in managing the project by managing the risks.

  31. Continuous Process Improvement Maturing the acquisition, development, and operational processes to meet the warfighter’s objectives. Employing a common process improvement framework and language to align and enhance process capability.

  32. Continuous Product Improvement Enhancing the warfighter’s mission through evolutionary delivery of enhanced capabilities. Delivering an initial capability on the first promise date, with the demonstrated capability to deliver improved or updated capability on a regular, dependable schedule.

  33. The Three Defining Principles Forward-Looking View Global Perspective Shared Product Vision

  34. Forward-Looking View Seeing a common tomorrow against which all stakeholders can measure potential breakthroughs and risks. Managing project resources and activities while anticipating uncertainties.

  35. Global Perspective Sharing a single mental model of project success that crosses all boundaries between acquirer, developer, and operator. Viewing enhancements within the context of the operational mission. Recognizing both the potential value of opportunity and the potential impact of adverse effects.

  36. Shared Product Vision Developing and sustaining a common conception of the product being built - one that can be stated simply and briefly, and is founded on common purpose, shared ownership, and collective commitment among the stakeholders. Focusing on results.

  37. Three Important Things: Scope, Focus, Deliver!

  38. Three Important Things Scope the problem – “What” Focus the team – “How” Deliver value – “When and Where” Everything else is just noise!

  39. RUP/ICM Anchor Points Enable Concurrent Engineering Scope Focus Deliver

  40. Conclusions Management of engineering project has become more complex as demand grows and technology tries to keep up Software and Systems Engineering employ defined processes to get from “I want” to “I got” Managers need to ensure their early Systems Engineering efforts are informed by Software Engineering issues (Software-Aware Systems Engineering) Software has some unique properties including logical complexities that lead to an inherently defect laden product Software and Systems Engineering professionals need to be wary of “Buzzwords” and “Silver Bullets” All effort should help Scope the problem, Focus the team, and Deliver value

  41. Contact Information Air Force John Foreman, jtf@sei.cmu.edu Army Cecilia Albert, cca@sei.cmu.edu Navy Rick Barbour, reb@sei.cmu.edu Intelligence Community Rita Creel, rc@sei.cmu.edu Civil Agencies Steve Palmquist, msp@sei.cmu.edu http://www.sei.cmu.edu/programs/acquisition-support Brian Gallagher Director, Acquisition Support Program Software Engineering Institute 4500 Fifth Ave. Pittsburgh, PA 15213-3890 (412) 268-7157 bg@sei.cmu.edu

More Related