Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Improving Defence Program Execution


Published on

Track 2 a improving defence program execution - barclay brown

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Improving Defence Program Execution

  1. 1. Barclay Brown, ESEP – Global Solution Executive5 October 2012Advanced Systems Engineering:Improving Defense Program Execution © 2009 IBM Corporation
  2. 2. Systems Engineering has both a breadth and depth perspective. Systems Engineering Breadth Perspective Cross-discipline analysis, system-of-systems modeling System SubSystem SubSystem SubSystem Electrical Software Mechanical Software Component Component Component Component2 © 2009 IBM Corporation
  3. 3. Systems Engineering has both a breadth and depth perspective. Systems Engineering Breadth Perspective Cross-discipline analysis, system-of-systems modeling System Systems Engineering is a profession, a role, even a job title, for those who work exclusively at a SubSystem SubSystem SubSystem Systems Engineering also system-of-systems level. names a set of methods, skills and techniques that can be applied both at a Electrical Software system-of-systems level Mechanical Software Component Component and within specific Component Component engineering disciplines.3 © 2009 IBM Corporation
  4. 4. Value of Systems Engineering: Cost and ScheduleApplying the right amount of systems engineering is critical tomeeting cost and schedule targets.Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p9 4 © 2009 IBM Corporation
  5. 5. Value of Systems Engineering: Success and QualityApplying the right amount of systems engineering is critical toprogram success.Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p9 5 © 2009 IBM Corporation
  6. 6. Today’s reality: for integrated device andsoftware of systems development Device software designs completed over 66% budget EMF 2003 Projects canceled due to unrecoverable 24% slip in schedule EMF 2003 Produced devices do not meet 33% XX% performance or functionality requirements EMF 2003 Software content in devices is doubling 2x every two years IDC 20026 © 2009 IBM Corporation
  7. 7. Many notable system failures have been failures in subsysteminterfaces, requirements fidelity and system engineering. Systems have become more complex through integration – E.g. automobiles with multiple ECUs are more like a network of general purpose computers with large network software Projects with 700-2000 requirements cannot be held in mind at full detail – Models with varied levels of abstraction must be used Managing change and understanding impact of change is a $$$ million problem – Requirements models and automated tools must be used to be effective Interestingly, these are failures of knowledge and communication, not of engineering.7 © 2009 IBM Corporation
  8. 8. What do each of these have to teach us about Advanced SystemsEngineering?8 © 2009 IBM Corporation
  9. 9. The Philosophy of Advanced Systems Engineering Models are better than documents (but documents are needed too) Collaborate and share information across functions Build Shared Understanding as hedge against risks Automate as much as possible Insurance: Invest a little now to avoid large risk later Optimize for change (not for stability) Be able to trace everything, but only trace what adds value ABC: Adopt before Buy, Buy before Create Measure and improve; closed-loop governance Start early: what can we do NOW?9 © 2009 IBM Corporation
  10. 10. Advanced RequirementsManagement Derivation Traceability Requirements are no longer “one kind of thing” Recognize levels and types and their relationships Implement “live” traceability between all kinds of requirements, including architecture and design Link requirements to design, implementation, verification and validation, user training, etc. © 2009 IBM Corporation 10
  11. 11. The changing role ofrequirements Text requirements give rise to models which elaborate and elucidate Models give rise to additional text requirements which specify and constrain Text Text and models are useful at all levels of system abstraction Models Capture rationale and thinking at each level to differentiate requirements from design choices11 © 2009 IBM Corporation
  12. 12. What makes a model a model? The Dumb Way The Smart(er) Way =-A11*4*(1- B11)+4*C11 =NORMDIST(A11, 0,1,FALSE) Smarter or Dumber?=100+3*50+2*3*70+3*3*40+4*3*100 Requirements+5*3*125 Trade Studies Flowdown / Allocation Designs The relationships are baked-in Component Specifications TPMs Optimized for change12 © 2009 IBM Corporation
  13. 13. Model Philosophy I: What are models for? Models can –Document. Derived from already existing reality or agreement. –Represent. Help people communicate and agree. –Hold thought. Be a shared mental space for collaborative thinking. –Illustrate. A picture is worth a thousand words. –Calculate. Both show and quantify relationships. –Evaluate. Show alternatives and criteria for trade-off analysis. –Build. Translate models into real things. It is important to be clear on the purpose for a model you are creating (and maintaining.)13 © 2009 IBM Corporation
  14. 14. Model Philosophy II: Model relationships Models and model elements have relationships with other model elements and with other information relevant to the system. Important relationships – Derivation – Fulfillment (coverage) – Decomposition – Dependency For instance, – A model element may fulfill (fully or partially) a requirement. – A requirement may be derived from another requirement. – A requirement may arise from a model element. – A model element may decompose into another model element. – A model element, or requirement, may depend on another model element. It is important to figure out how your model elements and requirements relate to each other.14 © 2009 IBM Corporation
  15. 15. Model Philosophy III: Dangers in Adopting ModelingAll models are good. Causes model proliferationwithout meaning and purpose.Method-centric. We do these models because themethod says so.Tool-centric. We do these models because the toolis good at it.Dead models. Non-executable models risk being un-implementable.Doing documentation models exclusively. Limitsbenefits of modeling (where are the real models?) M.C. Escher, 1961 © 2009 IBM Corporation
  16. 16. Model-driven system development models a system-of-systems in four recursive stages. Context describes the system and the people and systems who interact with it Context (actors). Usage describes how the actors use the system is used to produce the results and Usage purposes of the system. Realization describes how each usage is accomplished by a collaboration of system Realization elements using various viewpoints. and Joint Realization Execution enables demonstration and proof of the model through execution. Execution16 © 2009 IBM Corporation
  17. 17. Integrated system / embedded software developmentDesign iterations in the “V” development lifecycle Change Request Stakeholder SystemsRequirements Engineering System Validation Scenarios (ConOps) Requirements Plan System Model / Requirements Repository Analysis Acceptance Embedded RT Test Development Scenarios System Functional Analysis System Verification Plan (Sub-)System Design Synthesis Integration & Test System Component Architecture Verification Baseline Procedure SW Module Analysis & Design Integration & Test HW HW Component Analysis & Design Verification SW Implementation & Unit Test HW Build © 2009 IBM Corporation
  18. 18. Asset-Based Systems Engineering Reuse: doing more with less Moving from documentation to re- creation Capture engineering and business value Engineering asset – What, How and Why – Tailor and reuse – Contribute back to library Precursor to full product line approach © 2009 IBM Corporation
  19. 19. Technical Work Management:Collaboration and Communication Communication among teams facilitated by Systems Engineering Reduce wasted time / error associated with misunderstandings and incomplete mental pictures of system requirements Why are small teams so effective? Build common, shared work products among cross-functional teams – Model-based – Shared repositories (requirements, change requests, issues, defects, configurations) Coordinated, automated workflow tied to shared work products – Avoid email exchange of work products, multiple versions, confusion Build on integrated tooling infrastructure – Limitations of point-to-point integration – Jazz Platform and OSLC Vision19 © 2009 IBM Corporation
  20. 20. Technical Work Management: Enabling Effective Collaboration (Why better than email?) Capture customer requests & market Manage driven enhancements ExecutePortfolio & Tests Product Testing Eco-system Priorities Collaboration, Process, Workflow Integrated Capture & Change manage Managementrequirements Configuration Management Develop - Model-Driven Collaborate across System Engineering Development Disciplines Software Engineering Electrical Engineering Software Mechanical Engineering Electrical Shared Repository Mechanical 20 © 2009 IBM Corporation
  21. 21. Collaboration in Action Team Awareness • Shows team members and their online status • Shows what they are working on Change Awareness • Automatically links to changes if mentioned in chat • Drag and drop any work item or query into chat © 2009 IBM Corporation21
  22. 22. Enabling Collaboration with Models Collaborate with stakeholders View design with commenting over webBrowse Mark-up diagrams todesign elaborate commentsinformation © 2009 IBM Corporation
  23. 23. Systems Engineering traditionally floats on a sea of documentation Missing Format information inconsistency Document-centric approach results in information dead- ends Document No access to source disparate Changes make products documents obsolete application before they are approved Overwhelmed Engineers working off engineers & Documents remain misinformed old versions necessary for of specs managers contractual management and Document agreement Documentation preparation for not up-to-date reviews23 © 2009 IBM Corporation
  24. 24. Automated Document Production Treat documents as reports of live information Facilitate re-use and consistency24 © 2009 IBM Corporation
  25. 25. One innovative organization made their models visible toeveryone in the company! Models first developed on flip charts Later maintained in automated modeling tools Finally, produced on large wall charts for increased visibility, communication, collaboration Became center for discussion across all teams. © 2009 IBM Corporation
  26. 26. Learn more at: IBM Rational software Rational trial downloads IBM Rational Software Delivery Platform Leading Innovation Web site Process and portfolio management developerWorks Rational Change and release management IBM Rational TV Quality management IBM Business Partners Architecture management IBM Rational Case Studies© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied.IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warrantiesor representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs,or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based onmarket opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services aretrademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. © 2009 IBM Corporation
  27. 27. Copyright information © Copyright IBM Corporation 2011 IBM Corporation Software Group Route 100 Somers, NY 10589 Produced in the United States of America 03-07 All Rights Reserved. Build Forge, ClearCase, ClearQuest, IBM, the IBM logo, PurifyPlus, Rational, Rational Rose, Rational Test RealTime, Rational Unified Process, RUP, SoDA, XDE and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft is a trademark of Microsoft Corporation in the United States, other countries, or both. Other company, product and service names may be trademarks or registered trademarks or service marks of others. The information contained in this documentation is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this documentation, it is provided “as is” without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this documentation or any other documentation. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing the use of IBM software.27 © 2009 IBM Corporation