1 May not be reproduced owithout permission. www.ilogix.com A Model Centric Approach to CMMI - “ HARMONY ® ” Delivering “First Time, All Time, Best Quality”

Slides:



Advertisements
Similar presentations
Model-Based Testing with Smartesting Jean-Pierre Schoch Sogetis Second Testing Academy 29 April 2009.
Advertisements

ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
HP Quality Center Overview.
 2004 by SEC Chapter 2 Software Development Process Models.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Alternate Software Development Methodologies
Chapter 2 Process Models
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
1/31 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2005] January 22, 2009.
® IBM Software Group © 2007 IBM Corporation Achieving Harmony IBM's Platform and Methodology for Systems Engineering and Embedded Software Development.
Copyright  Larry Dribin, Ph.D. SE470_EngFlows_v1.ppt SE470 EngFlows - 1 Excellence in Software Engineering Repeatable Level Defined Level Manage.
1 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2002] January 26, 2006.
Effective Methods for Software and Systems Integration
Principles of Object Technology Module 1: Principles of Modeling.
What is UML? What is UP? [Arlow and Neustadt, 2005] January 23, 2014
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
CLEANROOM SOFTWARE ENGINEERING.
Rational Unified Process Fundamentals Module 4: Disciplines II.
What is a life cycle model? Framework under which a software product is going to be developed. – Defines the phases that the product under development.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Chapter 2 Process: A Generic View
Identify steps for understanding and solving the
Service Transition & Planning Service Validation & Testing
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
Testing Workflow In the Unified Process and Agile/Scrum processes.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
1 Introduction to Software Engineering Lecture 1.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
Chapter 4 프로세스 모델 Process Models
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
UML - Development Process 1 Software Development Process Using UML.
Software Engineering (CSI 321) Software Process: A Generic View 1.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
© 2009 Artisan Software Tools. All rights reserved. Testing Solutions with UML/SysML Andrew Stuart, Matthew Hause.
Advanced Software Engineering Dr. Cheng
Software Project Configuration Management
An Overview of Requirements Engineering Tools and Methodologies*
What is UML? What is UP? [Arlow and Neustadt, 2005] October 5, 2017
Software Requirements
Rational Worldwide Software Symposium
Introduction to Software Testing
Introduction to UML.
Chapter 2 Process Models
Chapter 2 Process Models
Chapter 2 Process Models.
Chapter 2 Process Models
Software Development Process Using UML Recap
Presentation transcript:

1 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. Overview - Technological Competencies Systems and Software Engineering using Executable Models Behavioral modeling and validation Formal verification UML SysML Production quality code generation (Certifiable)

5 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. Model-Based Concurrent Engineering Processes Time Cost of Design Change Increase design stability by requirements validation and systems analysis prior to implementation System Engineers Test Engineers Electrical Engineers Software Engineers Mechanical Engineers System Integration & Test System Acceptance HW/SW Design HW/SW Implementation Module Integration & Test Systems Analysis & Design Requirements- Analysis

8 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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: For more information on Process Improvement Strategies go to

13 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. HARMONY ® Integrated Systems / Software Development Process Test Scenarios (Sub-)System Integration & Test System Acceptance Module Integration & Test System Analysis & Design SW Analysis & Design SW Implementation & Unit Test Software Engineering HARMONY-SWE System Changes Systems Engineering HARMONY-SE Requirements Analysis Model / Requirements System Architecture Baseline

16 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. HARMONY ® Systems Engineering Workflow Black Box Use Case Scenarios Requirements Diagram Black Box Use Case Model, System Level Operational Contracts White Box Use Case Model Logical Subsystem Operational Contracts Deployment Model, HW/SW allocated Operational Contracts Requirements Repository Test Database White Box Use Case Scenarios System Use Cases Links providing traceability to original requirements Physical Subsystem Use Case Scenarios ICD HW/SW Design System Architectural Design Use Case Analysis Abstracted Use Case Models System Functional Analysis Requirements Analysis Definition of System Use Cases Updated Logical Subsystem OpCons Requirements Capture Definition of Phys.SS Use Cases HW/SW Trade Off Physical Subsystem Use Cases System Use Cases Logical Subsystem OpCons Use Case Consistency Analysis White Box Analysis System Level OpCons Black Box Analysis Use Case 1 HW/SW Specs

18 May not be reproduced owithout permission. HARMONY ® Essential Systems Engineering Model Artifacts

19 May not be reproduced owithout permission. HARMONY ® Development Spiral Mechanistic Design Detailed Design Translation Unit Testing Integration Testing Iterative Prototypes Architectural Design Object Analysis Prototype Definition Validation Testing Validation (Party) Increment Review

20 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. HARMONY ® Benefits of a Model Centric Approach  UML 2.0 supports scalable specification of systems with complex behavior.  Ports  Sequence Diagrams  UML Statecharts.

26 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. HARMONY ® Benefits of a Model Centric Approach  Sequence Diagrams UML 2.0  Lifeline Decomposition – Allows easy system decomposition within dynamic system views

29 May not be reproduced owithout permission. 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 Base statechart Derived statechart with Extended ‘On’ state

30 May not be reproduced owithout permission. 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 May not be reproduced owithout permission. HARMONY ® Benefits of a Model Centric Approach Flat Statechart from UML The same computation on the semantically identical statechart yields 25 ( ).

32 May not be reproduced owithout permission. 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