Transcript UML for System Engineers Chapter 3

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)
May not be reproduced owithout permission.
www.ilogix.com
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!!!).
May not be reproduced owithout permission.
www.ilogix.com
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.
May not be reproduced owithout permission.
www.ilogix.com
4
Overview - Technological Competencies

Systems and Software Engineering using Executable
Models

Behavioral modeling and validation

Formal verification

UML

SysML

Production quality code generation (Certifiable)
May not be reproduced owithout permission.
www.ilogix.com
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!!!
May not be reproduced owithout permission.
www.ilogix.com
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
May not be reproduced owithout permission.
www.ilogix.com
7
Model-Based Concurrent Engineering Processes
System Engineers
Software Engineers
Electrical Engineers
Mechanical Engineers
Test Engineers
RequirementsAnalysis
Systems
Analysis &
Design
Cost of
Design
Change
HW/SW
Design
HW/SW
Implementation
Module
Integration &
Test
System
Integration &
Test
System
Acceptance
Increase design stability
by requirements validation
and systems analysis prior
to implementation
Time
May not be reproduced owithout permission.
www.ilogix.com
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
May not be reproduced owithout permission.
www.ilogix.com
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
May not be reproduced owithout permission.
www.ilogix.com
10
Process?

Address risks early



Apply an Architecture Design Process that will:



Identify risks in Risk Management Plan
Use prototypes to schedule and manage risk reduction
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
May not be reproduced owithout permission.
www.ilogix.com
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
May not be reproduced owithout permission.
www.ilogix.com
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
May not be reproduced owithout permission.
www.ilogix.com
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.
May not be reproduced owithout permission.
www.ilogix.com
HARMONY®
Systems & Software Engineering Process




14
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.
May not be reproduced owithout permission.
www.ilogix.com
15
HARMONY®
Integrated Systems / Software Development Process
System Changes
Systems
Engineering
HARMONY-SE
Requirements
Analysis
Test Scenarios
System
Acceptance
System
Analysis & Design
(Sub-)System
Integration & Test
System Architecture
Baseline
SW
Analysis & Design
Module
Integration & Test
Software
Engineering
HARMONY-SWE
SW Implementation
& Unit Test
May not be reproduced owithout permission.
www.ilogix.com



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.
May not be reproduced owithout permission.
www.ilogix.com
HARMONY®
Systems Engineering Workflow
17
Requirements Analysis
Requirements Diagram
System Use Cases
Requirements Capture
Definition of System Use Cases
System Use Cases
White Box Use Case Model
Logical Subsystem Operational Contracts
Use Case Analysis
Black Box Use Case Model,
System Level Operational Contracts
Use Case 1
Black Box Use Case Scenarios
Black Box Analysis
System Level
OpCons
White Box Use Case Scenarios
White Box Analysis
Test Database
Requirements Repository
System Functional Analysis
Abstracted
Use Case Models
Updated Logical Subsystem OpCons
Use Case Consistency Analysis
Logical Subsystem OpCons
Deployment Model,
HW/SW allocated Operational Contracts
System Architectural Design
HW/SW Trade Off
Physical Subsystem
Use Case Scenarios
Physical Subsystem Use Cases
Definition of Phys.SS Use Cases
Links providing traceability
to original requirements
HW/SW Design
ICD
HW/SW Specs
May not be reproduced owithout permission.
www.ilogix.com
HARMONY®
Essential Systems Engineering Model Artifacts
May not be reproduced owithout permission.
www.ilogix.com
18
HARMONY®
Development Spiral
Translation
Unit
Testing
Integration
Testing
Detailed
Design
19
Validation
Testing
Increment Review
(Party)
Mechanistic
Design
Prototype
Definition
Iterative
Architectural
Design
Prototypes
Object
Analysis
May not be reproduced owithout permission.
www.ilogix.com


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
May not be reproduced owithout permission.
www.ilogix.com

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
May not be reproduced owithout permission.
www.ilogix.com

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
May not be reproduced owithout permission.
www.ilogix.com

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
May not be reproduced owithout permission.
www.ilogix.com
23

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
May not be reproduced owithout permission.
www.ilogix.com
24

HARMONY®
Benefits of a Model Centric Approach
UML 2.0 supports scalable specification
systems with complex behavior.
 Ports
 Sequence Diagrams
 UML Statecharts.
May not be reproduced owithout permission.
www.ilogix.com
25
of
HARMONY®
Benefits of a Model Centric Approach
Ports UML 2.0
Allows better encapsulation of architectural pieces as
well as enforcing rigid interface design
May not be reproduced owithout permission.
www.ilogix.com
26
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
May not be reproduced owithout permission.
www.ilogix.com
27
HARMONY®
Benefits of a Model Centric Approach
Sequence Diagrams UML 2.0
Lifeline Decomposition – Allows easy system
decomposition within dynamic system views
May not be reproduced owithout permission.
www.ilogix.com
28

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
May not be reproduced owithout permission.
www.ilogix.com
29
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).
May not be reproduced owithout permission.
www.ilogix.com
30
HARMONY®
Benefits of a Model Centric Approach
31
Flat Statechart from UML 1.4 - The same computation on the
semantically identical statechart yields 25 (35 -12+2).
May not be reproduced owithout permission.
www.ilogix.com

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
May not be reproduced owithout permission.
www.ilogix.com
32