IBM Software Group Advanced Systems Engineering and Model

® IBM Software Group Advanced Systems Engineering and Model Philosophy Barclay Brown, ESEP Global Solution Executive IBM Rational barclayb@us. ibm. com Innovation for a smarter planet © 2013 IBM Corporation

Software and Systems Engineering | Rational Systems Engineering Addresses Broad Concerns … Aeronautical Engineering Civil Engineering Software Engineering 2 Mechanical Engineering § What concerns are independent of the specific engineering disciplines? Systems Engineering Electrical Engineering § What concerns fall squarely into a specific engineering discipline? © 2011 IBM Corporation

Software and Systems Engineering | Rational Systems Engineering has both a breadth and depth perspective. 3 Requirements engineering, configuration management… Depth Perspective Systems Engineering Breadth Perspective Cross-discipline analysis, system-of-systems modeling… System Sub. System Electrical Component Sub. System Software Component Sub. System Mechanical Component Software Component © 2011 IBM Corporation

Software and Systems Engineering | Rational Systems Engineering has both a breadth and depth perspective. 4 Requirements engineering, configuration management… Depth Perspective Systems Engineering Breadth Perspective Cross-discipline analysis, system-of-systems modeling… System Sub. Systems Engineering also names a set of methods, skills and techniques that can be applied both at a Electrical Software system-of-systems level Component and within specific engineering disciplines. Systems Engineering is a profession, a role, even a job title, for those who work exclusively at a Sub. System system-of-systems level. Mechanical Component Software Component © 2011 IBM Corporation

Software and Systems Engineering | Rational Value of Systems Engineering: Cost and Schedule Applying the right amount of systems engineering is critical to meeting cost and schedule targets. Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p 9 5 © 2011 IBM Corporation

Software and Systems Engineering | Rational Value of Systems Engineering: Success and Quality Applying the right amount of systems engineering is critical to program success. Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p 9 6 © 2011 IBM Corporation

Software and Systems Engineering | Rational Today’s reality: for integrated device and software of systems development 7 66% Device software designs completed over budget EMF 2003 24% Projects canceled due to unrecoverable slip in schedule 33% XX% Produced devices do not meet performance or functionality requirements 2 x Software content in devices is doubling every two years EMF 2003 IDC 2002 © 2011 IBM Corporation

Software and Systems Engineering | Rational Many notable system failures have been failures in subsystem interfaces, 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. 8 © 2011 IBM Corporation

Software and Systems Engineering | Rational What do each of these have to teach us about Advanced Systems Engineering? Social Media 9 © 2011 IBM Corporation

Software and Systems Engineering | Rational The Philosophy of Advanced Systems Engineering § Models are better than documents (but documents are needed too) § Collaborate and share information across functions § Seamless flow of information and action § 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? 10 © 2011 IBM Corporation

Software and Systems Engineering | Rational Advanced Requirements Management Traceability Safety-Critical Regulatory / Industry Data Interface Service Specifications Business Processes Functional Use Cases / CONOPS System / Subsystem Requirements § Implement “live” traceability between all kinds of requirements, including architecture and design § Link requirements to design, implementation, verification and validation, user training, etc. Business / Mission Requirements Non-Functional § Recognize levels and types and their relationships Derivation § Requirements are no longer “one kind of thing” Source / Given Requirements © 2011 IBM Corporation 11

Software and Systems Engineering | Rational 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 and models are useful at all levels of system abstraction Enterprise System-of-Systems System Text Subsystem Component Models § Capture rationale and thinking at each level to differentiate requirements from design choices 12 © 2011 IBM Corporation

Software and Systems Engineering | Rational One more jab at the waterfall process § Extremely optimistic § Assumes no “disruptive learning” § More realistic is a growing body of information § Track maturity and confidence of information – Requirements – Models – Designs – Changes – Performance Measures © 2011 IBM Corporation

Software and Systems Engineering | Rational Building a house: A parable of requirements § Builder asks homeowner – How many square feet? § Is this the best time to define this requirement? § Define “incomplete” requirements § Use ranges – 1500 -2200 sq. ft. § Each bit of information has a maturity process – Drafted – Reviewed – Confirmed – Signed § Move away from requirements as a single body of information © 2011 IBM Corporation

Software and Systems Engineering | Rational A little background philosophy… § “We picture facts to ourselves. § A picture presents a situation in logical space, the existence and non-existence of states of affairs. § A picture is a model of reality. In a picture, the elements of the picture are the representatives of objects. § A logical picture of facts is a thought. § A state of affairs is thinkable’: what this means is that we can picture it to ourselves. § The totality of true thoughts is a picture of the world. ” …who said this and when? © 2011 IBM Corporation

Software and Systems Engineering | Rational Source: Wikipedia (http: //en. wikipedia. org/wiki/Ludwig_Wittgenstein) Source: amazon. com (http: //www. amazon. com/gp/product/1440424217/ref=s 9_simh_gw_p 14_d 0_i 2? pf_rd_m=ATVPDKIKX 0 DER&pf_rd_s=center 2&pf_rd_r=1 TD 6 G 6 SJM 3 E 9 TFFE 1 ZDA&pf_rd_t=101&pf_rd_p=470938631&pf_rd_i=507846) (1921) © 2011 IBM Corporation

Software and Systems Engineering | Rational What makes a model? The Dumb Way The Smart(er) Way =-A 11*4*(1 -B 11)+4*C 11 =100+3*50+2*3*70+3*3*40+4*3*100+5 *3*125 § The relationships are baked-in § Optimized for change 17 =NORMDIST(A 11, 0, 1, FALSE) Smarter or Dumber? Requirements Trade Studies Flowdown / Allocation Designs Component Specifications TPMs © 2011 IBM Corporation

Software and Systems Engineering | Rational 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. ) 18 © 2011 IBM Corporation

Software and Systems Engineering | Rational 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. 19 © 2011 IBM Corporation

Software and Systems Engineering | Rational Model Philosophy III: Dangers in Adopting Modeling § All models are good. Causes model proliferation without meaning and purpose. § Method-centric. We do these models because the method says so. § Tool-centric. We do these models because the tool is good at it. § Dead models. Non-executable models risk being unimplementable. § Doing documentation models exclusively. Limits benefits of modeling (where are the real models? ) M. C. Escher, 1961 © 2011 IBM Corporation

Software and Systems Engineering | Rational Model-driven system development models a system-ofsystems in four recursive stages. § Context describes the system and the people and systems who interact with it (actors). Context § Usage describes how the actors use the system is used to produce the results and purposes of the system. Usage § Realization describes how each usage is accomplished by a collaboration of system elements using various viewpoints. Realization § Execution enables demonstration and proof of the model through execution. and Joint Realization Execution 21 © 2011 IBM Corporation

Software and Systems Engineering | Rational Modeling context allows, even forces reasoning about system boundaries high-level interactions. § To understand systems, understand the context of the broader Enterprise § Context Diagram treats Enterprise as a black box § Shows scope, boundaries, operations, i/o entities § Ultimately add operations when they are discovered through flowdown § Add actors and i/o entities § Shows only one level of abstraction (e. g. Enterprise) 22 © 2011 IBM Corporation

Software and Systems Engineering | Rational Modeling usage as the foundation for architecture ensures that all design serves the system’s intended purposes. § Use case: a sequence of events that yields a meaningful result of value. § Enterprise Use Case diagram – “System” is the Enterprise – Actors same as on context diagram – Identify use cases: What do they use the system for? § Detailed in a Use Case Specification § Remember to treat Enterprise as a black box; no implementation details § Focus on actor’s interactions with the Enterprise § No actor-to-actor interactions at this level: these are shown in the collaborations from the level above 23 © 2011 IBM Corporation

Software and Systems Engineering | Rational 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 Mc. Donald’s? – Is there a Hilton Hotel I can reach in about 5 hours? 24 – Let’s avoid freeways © 2011 IBM Corporation

Software and Systems Engineering | Rational Modeling realization connects behavior to architectural structure, integrating process with architecture. § Model enterprise as a set of operations that realize use case flows § Highest Level “specification” of the enterprise § Treat enterprise as black box § Provides basis for flow down § Identifies common logical capabilities needed across use cases § “Black box sequence diagram” of an Enterprise Use Case allows identification of candidate Enterprise Operations. § Name the messages as requests of the message destination NOT as the action taken by the initiator 25 © 2011 IBM Corporation

Software and Systems Engineering | Rational Data Flow and Activity Flow § Object flow in activity diagrams ties usage flow to data flow § Publish and subscribe patterns (e. g. DDS) are easily modeled as steps or flows within usage § Establishes responsibility for functionality and data together § Ties functional models to structural (schema) data models © 2011 IBM Corporation

Software and Systems Engineering | Rational Data Flow in Realization § Main focus is on system usage – That’s why systems are built 1: Complete Online Sale (Trans. ID, Cust. Num, Total. Purch) § Data modeling in MBSE ensures that only data needed for usage is built Retail System Trans. ID Cust. Num Total. Purch © 2011 IBM Corporation

Software and Systems Engineering | Rational Modeling joint realization allows us to show the relationship between physical/distribution architecture and logical architecture. § Allows reasoning about physical distribution of system elements and functionality § A locality is a place where some system functionality happens – E. g. software hosted on a particular server, or an alert indication on a dashboard § Locality diagram shows localities and their physical interconnections and characteristics. § Localities may apply at each level of abstraction § Locality is the context for dealing with adequacy of system to meet non-functional (quality) requirements (reliability, performance, capacity, cost, etc. ) © 2011 IBM Corporation

Software and Systems Engineering | Rational Joint realization shows how operations are realized both in logical and distribution architectures. § Select level of abstraction for locality model – Not usually done at Level 0 or 1 – Maybe done at multiple levels § Do sequence diagram of a use case – As before with logical elements – Now with distribution elements § Show distribution elements and actors § Show each operation as message into distribution element. 29 © 2011 IBM Corporation

Software and Systems Engineering | Rational Multiple viewpoints and levels of abstraction allow system engineers to focus on specific concerns while keeping the whole system in mind. Viewpoints Model Level Context Analysis Worker Logical UML Organization View System Context Diagram Generalized System Worker View Design Implementation Distribution Process Enterprise Data View Enterprise Locality View System Analysis Model (Subsystem Diagram) System Data View System Deployment Model (Locality View) System Process View • System Design Model (Subsystem/Cla ss Diagram) System Data Schema System Deployment Model (Descriptor View) Detailed Process View • Component views Worker Role Specification s and Instructions Information Deployment diagram at Implementation level for each configuration © 2011 IBM Corporation

Software and Systems Engineering | Rational Standard architectural views like Do. DAF/MODAF aid in communication to stakeholders, and should derive from the architectural models. Context § High-level stakeholders can learn to expect certain high level views Usage § Identify, classify and harvest Do. DAF content in the form of reusable assets Realization § Automated matrix creation to ensure consistency – AV-2, OV-3, SV-4, SV-5, SV-6 Joint Realization § Reporting of all Do. DAF views – Generated to a Microsoft® Word document § Import custom graphics (OV-1) § Do. DAF model framework for work products and views © 2011 IBM Corporation

Software and Systems Engineering | Rational Model Execution for early verification and validation through model execution its. User Uc 1_Control. Entry its. Access. Point its. Camera req. Read. Security. Card() req. Take. Snapshot() validate. Security. Card(Card. Status = Valid) display. Card. Status(Card. Status = Valid) req. Scan. Biometric. Data() scan. Biometric. Data() authenticate. Biometric. Data(Authentication. Status = Authenticated) display. Authentication. Status(Authentication. Status = Authenticated) req. Unlock. Access. Point() tm(1000) ev. Access. Point. Unlocked() Animated Statechart Diagram (Uc 1 Control. Entry) Animated Sequence Diagram (Uc 1 Sc 1) © 2011 IBM Corporation

Software and Systems Engineering | Rational Asset-Based Systems Engineering § Reuse: doing more with less What § Moving from documentation to recreation Requirements § Capture engineering and business value § Engineering asset – What, How and Why – Tailor and reuse – Contribute back to library Why Rationale How System Models § Precursor to full product line approach © 2011 IBM Corporation

Software and Systems Engineering | Rational Boeing Space Systems: Future Image System Ground Station Architecture Client situation Very large project § Approximately US$5 billion development project § Team made up of four companies with developers at five sites § Approximately five million lines of code, much of it new Status § One hundred forty-five system engineers building requirement specifications based on functional allocations § Poor communications with software developers; little progress § Engineering documents unusable by developers § Spending US$1 million a week Solution § Use the IBM Systems Engineering solution, modeling and requirements management for architecture framework § Organize a cross-functional team including system engineers and software architects § UML model created for all engineering efforts § Adopt iterative program management § Use-case-driven iteration and test planning Challenge § Introduce a process that scales to a large project that enables the different teams and stakeholders to collaborate Results “Project on track through five iterations, millions of dollars in savings. The solution enhanced our project success rate from 14 percent to over 90 percent. ” — Michael Mott, technical fellow Boeing S&IS © 2012 IBM Corporation 34

Software and Systems Engineering | Rational National Aeronautics & Space Administration: James Webb Space Telescope Solution Client situation James Webb Space Telescope (JWST) The next-generation telescope, which will succeed the Hubble space telescope, is expected to be launched by 2013. It will study galaxy, star and planet formation in the universe. To study the earliest star formation, NASA will observe infrared light using special instruments optimized to capture this part of the spectrum. Challenges § Develop and govern a large systems program § Reduce development time and cost § Provide consistency in designing large-scale systems across the program and various instruments being built (hardware and software co-development of systems) § Manage distributed systems development across systems integrators and NASA, which included the four instruments § Use standard processes for systems development across the organization, and comply with CMMI regulations § Reuse the software for the instruments across the program to improve productivity IBM Rational systems development solution—an integrated approach to architecting, building and governing complex systems of systems § IBM Rational Requirements Management —implemented requirements from business need to implementation in for traceability § IBM Rational Real. Time software— implemented full system model using UML to facilitate communication and reuse; increased predictability and reliability of the systems § IBM Rational Clear. Case and Rational Clear. Quest software—facilitated collaboration and asset reuse of artifacts across JWST Results “It was important that NASA be forward-looking with the James Webb Space Telescope by using a systems development platform that would be reliable and ahead of the marketplace throughout the extensive life of the mission. ” —Glen Camarata, ISIM flight software development lead, Satellite Software Corporation © 2012 IBM Corporation

Software and Systems Engineering | Rational One innovative organization made their models visible to everyone 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. © 2011 IBM Corporation

Software and Systems Engineering | Rational § § § § Learn more at: IBM Rational software IBM Rational Software Delivery Platform Process and portfolio management Change and release management Quality management Architecture management § § § Rational trial downloads Leading Innovation Web site developer. Works Rational IBM Rational TV IBM Business Partners 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 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. 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 on market 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 are trademarks 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. © 2011 IBM Corporation

Software and Systems Engineering | Rational 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, Clear. Case, Clear. Quest, IBM, the IBM logo, Purify. Plus, Rational Rose, Rational Test Real. Time, Rational Unified Process, RUP, So. DA, XDE and Web. Sphere 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. 38 © 2011 IBM Corporation