Agenda

1. A Model Centric Approach to CMMI - “HARMONY®”Delivering“First Time, All Time, Best Quality” Systems (Authors of “HARMONY®” – Dr Peter Hoffman and Dr. Bruce Douglass)

2. Agenda • Introduction • CMMI • Process Overview • Model Driven Development • Benefits of a Model Centric Approach CMMI® Performance Results are often measured in terms of Cost Schedule, Productivity, Quality, Customer Satisfaction. Return on Investment. Ideally, performance results are as important as attaining a high CMMI assessment level (unfortunately, actual results indicate that this is not always the case!!!).

3. Overview - Who We Are… • Established in 1987 with products focused on systems design and validation - Statemate ® • 1998 – New generation Unified Modeling Language (UML) compliant application development platform for -time embedded systems - Rhapsody® • 2004 – Seamless Systems and Software Engineering Systems and Software Engineering Solution based on UML and SysML.

4. Overview - Technological Competencies • Systems and Software Engineering using Executable Models • Behavioral modeling and validation • Formal verification • UML • SysML • Production quality code generation (Certifiable)

5. CMMI • The purpose of CMMI is to provide guidance for improving processes? • CMMI provides a structure to appraise its process area capability, establish priorities for improvement, and implement these improvements? • Achieving a CMMI level provides no guarantees of program success. • If individual processes and practices are inadequate for supporting the program's specific development or evolutionary needs, the program success is severely compromised!!!

6. CMMI - Impact on Program Performance Organizations whose focus on achieving a CMMI level replaces the focus on continuous improvement have lost sight of the goal of continuous improvement. Programs need even more focus on improvement to help to identify systemic issues that plague poor program execution performance, despite high maturity level. Mark Schaeffer Director of Systems Engineering Office of the Under Secretary of Defense Acquisition Technology and Logistics Annual CMMI Technology Conference, November 2004

7. Model-Based Concurrent Engineering Processes System Engineers Software Engineers Electrical Engineers Mechanical Engineers Test Engineers Systems Analysis & Design System Integration & Test Module Integration & Test Requirements- Analysis HW/SW Implementation System Acceptance HW/SW Design Increase design stability by requirements validation and systems analysis prior to implementation Cost of Design Change Time

8. Process? • A project template that guides workers from a concept to a delivered and sustainable system. • Active risk reduction to keep the project on track • A means for effective communication among workers • A collaborative environment allowing multiple workers to achieve common work goals • A consistent level of reliability, predictability and safety. • Repeatable high quality systems development • Reduced time-to-market for a given quality and feature set • A basis for scheduling and estimation

9. Process? • An audit trail • A means to measure progress and success • A means to identify and incorporate process improvements • A means of Managing Requirements • Forward Traceability allows you to track from a requirement to the model elements, design, code and test cases that are relevant to each specific requirement. • Backward Traceability allows you to track from the code, test cases design and model elements back to the requirements it meets. • Use configuration management • Be able to back changes out • Control revisions that go into builds • Control quality of artifacts that contribute to builds

10. Process? • Address risks early • Identify risks in Risk Management Plan • Use prototypes to schedule and manage risk reduction • Apply an Architecture Design Process that will: • Test the seams of your system early and often • Eliminate the most expensive defects - between architectural units • Apply strong architectural modeling techniques • Architectural design patterns to reuse best-practice architectures • Strong architectures result in adaptable, robust systems

11. Process? • Apply a means of deriving design selection. • Apply use case-driven development • Ensure the system completeness and correctness Throughout the engineering lifecycle. • You can only test what you can execute, therefore execute and test early and often. • Separate logical and physical models - Reuse comes largely from redeploying common logical models

12. Process? • Apply Good Tools – • Automation as a process improvement strategy is quantitatively and economically superior to all of the others. (Davenport, Davidson, Reid, Downes and Mui). • Tools that will automate tasks required for effective Requirements Management, Traceability, Validation, Verification, Implementation and Test. Good tools help support an iterative or spiral process as well as the ability to sustain of a system throughout it’s life. • Good Tools are cheap when compared to the alternative! • For an independent UML 2.0 tool evaluation? Go to: http://www.embeddedforecast.com/REDUML_0304.pdf • For more information on Process Improvement Strategies go to http://www.dacs.dtic.mil/techs

13. Process? • In short, a good process should enable teams of people to work together to construct complex systems with fewer defects in less time with greater reliability and predictability and to identify and reduce risks as early as possible.

14. HARMONY®Systems & Software Engineering Process • An integrated engineering process. • Model-driven support for Traditional systems engineering techniques • Seamless transition from systems engineering to software engineering by using the UML™ (rel. 2.0) / SysML™ as paradigm independent modeling language (“same language, different dialects”) • Tool support: • Any tool that provides strong support for UML 2.0 and SysML may be used to produce most of the specified artifacts. • Most of these tools support XMI which is the OMG standard interchange format. • Provide a common database for systems software engineering. • Not all tools may provide the same level of support for the standards or levels of automation.

15. HARMONY®Integrated Systems / Software Development Process System Acceptance RequirementsAnalysis System Analysis & Design (Sub-)System Integration & Test System Architecture Baseline SW Analysis & Design SW Implementation & Unit Test System Changes Systems Engineering HARMONY-SE Test Scenarios Model / Requirements Module Integration & Test Software Engineering HARMONY-SWE

16. HARMONY®Systems Engineering Objectives • Identification / derivation of required system functionality • Identification of associated system states / modes • Allocation of system functionality / modes to a physical architecture With regard to modeling, these key objectives imply a high level of abstraction. Emphasis is on the identification and allocation of a needed functionality.

17. HARMONY®Systems Engineering Workflow Requirements Diagram Requirements Capture Definition of System Use Cases System Use Cases Black Box Use Case Scenarios System Level OpCons Black Box Analysis White Box Analysis White Box Use Case Scenarios Use Case Consistency Analysis HW/SW Trade Off Physical Subsystem Use Case Scenarios Definition of Phys.SS Use Cases HW/SW Specs ICD Requirements Analysis System Use Cases System Functional Analysis Use Case 1 Black Box Use Case Model, System Level Operational Contracts Use Case Analysis Requirements Repository White Box Use Case Model Logical Subsystem Operational Contracts Abstracted Use Case Models Updated Logical Subsystem OpCons Test Database Logical Subsystem OpCons System Architectural Design Deployment Model, HW/SW allocated Operational Contracts Physical Subsystem Use Cases Links providing traceability to original requirements HW/SW Design

18. HARMONY®Essential Systems Engineering Model Artifacts

19. HARMONY®Development Spiral Unit Integration Testing Testing Detailed Increment Review Validation Validation Design (Party) Testing Iterative Prototypes Mechanistic Design Architectural Design Object Analysis Implementation Testing Translation Design PrototypeDefinition Analysis

20. HARMONY®Benefits of a Model Centric Approach • SysML and UML is standard language that allows the specification of all the requirements of a system. • Behavior • Timing • Interfaces • Constraints • Parametric data • The benefits of using a Standard language include: • The flexibility of not being locked into a proprietary solution (If the XMI Standard is supported). • Common method of communication

21. HARMONY®Benefits of a Model Centric Approach • Improved Project Management. Capture all the elements related to cost, schedule and performance risk. This includes: • Requirements definition • Design maturation • Subcontractor management • Test and evaluation • Verification and validation • Implementation • Sustainable System

22. HARMONY®Benefits of a Model Centric Approach • Complete traceability between all the artifacts and elements of system throughout its life. • Requirements • Architectures • Detailed designs • Validation • Verification • Trade analysis • Documentation • Reuse • Implementation • Test Throughout the Life of the System

23. HARMONY®Benefits of a Model Centric Approach • Elimination of potential errors throughout the engineering lifecycle. • Improved Communication by using one language • Detection of Defects through Executable Models • Within host environment, • Within simulation environment • Within target environment

24. HARMONY®Benefits of a Model Centric Approach • Elimination of potential errors throughout the engineering lifecycle. • *The automatic generation of test vectors: • Expedite validation and testing of your systems and your code (systems design, detailed design, unit test, integration test, etc).  • Enables both systems and software engineers to efficiently identify and eliminate up to 100 percent of the functional defects throughout the engineering process. • *Automatic Translation between Design and Implementation

25. HARMONY®Benefits of a Model Centric Approach • UML 2.0 supports scalable specification of systems with complex behavior. • Ports • Sequence Diagrams • UML Statecharts.

26. HARMONY®Benefits of a Model Centric Approach • Ports UML 2.0 • Allows better encapsulation of architectural pieces as well as enforcing rigid interface design

27. HARMONY®Benefits of a Model Centric Approach • Sequence Diagrams UML 2.0 • Reference Interaction Occurrence – Allows reuse of common scenarios, as well as more complex interaction descriptions

28. HARMONY®Benefits of a Model Centric Approach • Sequence Diagrams UML 2.0 • Lifeline Decomposition – Allows easy system decomposition within dynamic system views

29. HARMONY®Benefits of a Model Centric Approach • UML 2.0 Inherited State Behavior • Allows you to easily reuse existing behavior in order to capture more complex behaviors Derived statechart with Extended ‘On’ state Base statechart

30. HARMONY®Benefits of a Model Centric Approach Example UML 2.0 Statechart - A straightforward cyclomatic complexity for the example And State yields a complexity of 1 (7-8+2).

31. HARMONY®Benefits of a Model Centric Approach Flat Statechart from UML 1.4 - The same computation on the semantically identical statechart yields 25 (35 -12+2).

32. Benefits of a Model Centric Approach using “Harmony” • Elimination potential errors throughout the engineering lifecycle. • Improved Communication by using one language • Execution of complex models running within host, simulation or target environments • The automatic generation of test vectors provides up to 100% coverage. • Automatic translation of design into code