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.

Systems Engineering - a smarter way

5,194 views

Published on

A brief introduction to emerging trends in systems engineering and how collaborative tools are make engineers more productive.

Published in: Technology
  • Be the first to comment

Systems Engineering - a smarter way

  1. 1. Smarter Systems EngineeringPittsburgh INCOSEMark BorowskiClient Technical Professional and Enablement ExecutiveIBM Software, Rational
  2. 2. What was Next… is NOW! MINORITY STAR IRON MAN REPORT TREK Exoskeleton Vehicle-to-vehicle Sensory Robotic Suit Communication Substitution Device2 © 2012 IBM Corporation
  3. 3. Today’s innovations are enabled by software …this shift is changing the world in which we live Global Networked Bandwidth Integration Technologies Explosion3 © 2012 IBM Corporation
  4. 4. In many ways, the world is becoming smaller Enabling new levels of integration and collaboration Global Networked Bandwidth Integration Technologies Explosion4 © 2012 IBM Corporation
  5. 5. In other ways, the world is also becoming smarter Enabling new levels of customization, functionality and client value INTELLIGENT INSTRUMENTED INTERCONNECTED5 © 2012 IBM Corporation
  6. 6. Smarter products are the building blocks of today’s smarter planet6 © 2012 IBM Corporation
  7. 7. Yet with this new reality comes challenges and opportunities for systems engineers BEST-IN-CLASS “I need to better understand my design alternatives Improve ability to predict 88% earlier in the development process” system behavior “I need a level of traceability that allows me 39% Link requirements to to verify what was specified was delivered” specific test cases “I need to manage change across mechanical, 1 of 4 Involve multiple electrical, and software engineering” engineering disciplines in design reviews Aberdeen Group: “System Design: Get it Right the First Time”, August, 20117 © 2012 IBM Corporation
  8. 8. Added Capability Creates Complexity Many notable system failures have been failures in subsystem interfaces, requirements fidelity and systems 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. 88 © 2012 IBM Corporation
  9. 9. “Test-in Quality” is a Non-Starter Bugs and flaws are often expected to be caught and fixed during testing phase – Follows the waterfall, but often stalls testing (or worse, overloads the Test Team by making them forensic developers) Goal is to move to “Design-in Quality” – Quality checks performed at each development iteration – Testing directly linked to all development process stages – Stakeholders aligned through linked work items9 © 2012 IBM Corporation
  10. 10. And with this new reality also comes challenges and opportunities for software engineers “I need to know what I need to develop — 1 of 2 Challenged with scope nothing more, nothing less” creep and changing requirements “I need to show that I am compliant with 2x Need for standards the standards required by my industry” compliance doubled since 2009 “I need to know when changes are made to the 45% Use hardware/software hardware to avoid unpleasant ‘surprises’ later” dependency management10 © 2012 IBM Corporation
  11. 11. Today’s reality: for integrated device andsoftware of systems development Device software designs completed 66% over budget EMF 2003 Projects canceled due to 24% unrecoverable slip in schedule EMF 2003 Produced devices do not meet 33% XX% performance or functionality requirements EMF 2003 Software content in devices is 2x doubling every two years IDC 2002 1111 © 2012 IBM Corporation
  12. 12. New and enhanced solutions for systems and software engineers Design, deliver, Accelerate development Access and manage smarter with industry specific a growing products from planning complex software and extensive to development through and systems business partner product support development solution ecosystem12 © 2012 IBM Corporation
  13. 13. System-of-Systems modelingintegrates software, hardware, people and Softwareinformation into a cohesive, comprehensive model Hardware  A “system” regardless of its size or function is made up of some combination of these four elements. Workers  A large, complex system can be modeled as a system Information of systems.  This kind of model has great flexibility and can apply to machines, devices, business organizations or enterprises. Software Software Software Software Hardware Hardware Hardware Hardware Workers Workers Workers Workers Information Information Information Information13 © 2012 IBM Corporation
  14. 14. Advanced RequirementsManagement Derivation  Requirements are no longer “one kind of thing”  Recognize levels and types and y ili baecar T their relationships  Implement “live” traceability between all kinds of requirements, t including architecture and design  Link requirements to design, implementation, verification and validation, user training, etc.14 14 © 2012 IBM Corporation
  15. 15. The Changing Role of Requirements  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 Models levels of system abstraction  Capture rationale and thinking at each level to differentiate requirements from design choices 1515 © 2012 IBM Corporation
  16. 16. What Makes a Model a Model? The Dumb Way The Smart(er) Way =-A11*4*(1-B11)+4*C11 =NORMDIST(A11,0,1, Smarter or Dumber? FALSE) =100+3*50+2*3*70+3*3*40+4*3*100 Requirements Trade Studies +5*3*125 Flowdown / Allocation Designs Component The relationships are baked-in Specifications TPMs Optimized for change16 © 2012 IBM Corporation
  17. 17. Model-Driven System Developmentmodels a system-of-systems in four recursive stages  Context describes the system and the Context people and systems who interact with it (actors).  Usage describes how the actors use the Usage system is used to produce the results and purposes of the system. Realization  Realization describes how each usage is and Joint Realization accomplished by a collaboration of system elements using various viewpoints. Execution  Execution enables demonstration and proof of the model through execution.17 © 2012 IBM Corporation
  18. 18. Example: GPS-Guided Travel  GPS Features – Set destination (address, point of interest, etc.) – Navigate to destination – Retrace route – Get back on track  GPS Usage Model – Find me a gas station on my way – What’s the nearest McDonald’s? – Is there a Hilton Hotel I can reach in about 5 hours? – Let’s avoid freeways 1818 © 2012 IBM Corporation
  19. 19. V-Diagram of Systems Engineering Work  Shows progressive decomposition of requirements/ design (left side)  Shows progressive integration and verification of subsystems (right side) Source: Systems Engineering for Intelligent Transportation Systems Washington State Department of Transportation, December 30, 2005 19 02/12/13 Template Documentation19 © 2012 IBM Corporation
  20. 20. Time progression in V Diagram Source: INCOSE Handbook, p3.6 02/12/13 Template Documentation20 © 2012 IBM Corporation
  21. 21. Source: INCOSE Handbook, p3.8 Template Documentation21 © 2012 IBM Corporation
  22. 22. Integrated System/Embedded Software DevelopmentDesign iterations in the “V” development lifecycle22 22 © 2012 IBM Corporation
  23. 23. Technical Work Management:Collaboration and Communication Communication among teams facilitated by Systems Engineering Reduce wasted time / error associated with misunderstandings and incomplete mental pictures Why are small teams so effective? of system requirements 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 Vision 2323 © 2012 IBM Corporation
  24. 24. 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 Management managerequirements Configuration Management Develop - Model-Driven Collaborate across• System Engineering Development Disciplines• Software Engineering Software• Electrical Engineering• Mechanical Engineering Electrical Shared Repository Mechanical24 © 2012 IBM Corporation
  25. 25. 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 2525 © 2012 IBM Corporation
  26. 26. Enabling Collaboration with Models Collaborate with stakeholders with View design commenting over web Browse Mark-up diagrams to design elaborate comments information26 © 2012 IBM Corporation
  27. 27. Systems Engineering Traditionally Floatson a Sea of Documentation Missing Format information inconsistency Document-centric approach results in information dead- ends No access to Document source disparate products Changes make application documents obsolete before they are Engineers Overwhelmed engineers & approved working off misinformed old versions of specs managers Documents remain necessary for Document contractual Documentation preparation for not up-to-date reviews management and agreement 2727 © 2012 IBM Corporation
  28. 28. Automated Document Production  Treat documents as reports of live information  Facilitate re-use and consistency Clients Source Apps Publishing Composite Documents System requirements DOORS Reqts Templates models test() Models tes t() test() actor XML Sources Data other sources REST Sources 2828 © 2012 IBM Corporation
  29. 29. Closed Loop Governance: Measure and Improve Performance Measurement (IBM Rational Insight) Business Level Value Metrics Business Objectives feedback e.g., ROI, ROA for SSD 0% 100% Operational Level Operational Effectiveness Metrics Feedback Operational Objectives feedback e.g., Time to market, productivity 0% 100% Practice Practice Level Process Definition / Practices feedback Adoption/Maturity Practice Rational Method Composer Subjective Artifacts IBM Rational Objective Self-Check Process Enactment / Governance Enforcement / Process Awareness 0% 100% 2929 © 2012 IBM Corporation
  30. 30. www.ibm.com/software/rational© Copyright IBM Corporation 2012. 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 havethe 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 IBMsoftware. 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 capabilitiesreferenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or featureavailability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business MachinesCorporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 30 © 2012 IBM Corporation

×