Download - Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
1
Lifecycle Modeling on the Cloud:An Approach to Simplified, Rapid Development, Operations, and Support
Steven H. Dam, Ph.D., ESEPPresident, SPEC [email protected]
May 14, 2012
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Overview
What is Cloud Computing? Cloud Computing Implications for Systems Engineering Lifecycle Modeling Language Overview Suggested LML Processes LML Tool Needs Use of LML for Architecture Use of LML for Systems Design Use of LML for Software Development Use of LML in Test and Evaluation Use of LML in Operations and Support Summary
2
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
3
What is Cloud Computing?Hint: It’s not just a website
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
4
What is cloud computing?
• Definition from NIST: – Cloud computing is a model for enabling
convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models
From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
5
Five Essential Characteristics• On-demand self-service. A consumer can unilaterally provision computing capabilities,
such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.
• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).
• Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.
• Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
• Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.
From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
6
Three Service Models
• Software as a Service (SaaS): The end user system
• Platform as a Service (PaaS): Tools and services to create a SaaS Application
• Infrastructure as a Service (IaaS): Full control of the software stack and services
SaaS (Saleforce.com, Google Docs, Microsoft Office
365)
PaaS (Google App Engine, Microsoft Azure, Oracle Public
Cloud, Red Hat OpenShift)
IaaS (Amazon EC2, Red Hat CloudForms, Terremark)
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
7
Four Deployment Models
• Private cloud– Operated solely for an
organization – May be managed by the
organization or a third party
• Community cloud – Shared by several
organizations – Managed by the
organizations or a third party
• Public cloud– Available to the general
public or a large industry group
– Owned by an organization selling cloud services
• Hybrid cloud– composition of two or more
clouds that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
8
Hardware
App AppAppApp
Normal Server Deployment
1) Two applications running under normal conditions
2) One application’s demand increased3) Server crashed, both applications down
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
9
Hardware HardwareHardware
Hardware VirtualizationHardware Virtualization
App AppAppApp
Virtualized Server Deployment
1) Two applications running under normal conditions
2) One application’s demand increased4) Application’s demand increased5) Application’s demand decreased6) Hardware server crashes,virtualization continues
3) Added third server, extended virtual server
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
10
Hardware Hardware Hardware
Hardware Virtualization Layer
Box
0(C
ontr
olle
r)
App App App App
Net
Disk
Cloud Virtualized Servers
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
11
“Cloud-First” Policy“The Federal Government’s current Information Technology (IT) environment is characterized by low asset utilization, a fragmented demand for resources, duplicative systems, environments which are difficult to manage, and long procurement lead times. These inefficiencies negatively impact the Federal Government’s ability to serve the American public.”
“Cloud computing has the potential to play a major part in addressing these inefficiencies and improving government service delivery. The cloud computing model can significantly help agencies grappling with the need to provide highly reliable, innovative services quickly despite resource constraints.”
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
12
From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012
13
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
13 14
Security must be addressed at each layer
From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
14 15
From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
15
USG Approach to Cloud Authorization – Risk Based
See http://www.gsa.gov/portal/category/102371
FedRAMP provides a means to ensure government use of the cloud is secure and minimizes costs to cloud providers
IOC – June 2012
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
16
How Secure is the Cloud?
• We are using Google App Engine for SaaS application development: – Proven Reliability: Google App Engine is one
of the most secure enterprise services in the world
– Multiple layers of physical and virtual security
– Safer than most internal networks: With multiple layers of firewalls, sandboxed code, and software protection Google App Engine is more secure than most company networks
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
17
Advantages
• Reduce the total number of independent servers
• Individual applications are secured from one another (“Sandboxed”)
• Servers stored at secure locations• Only accessible on the secure network• Inexpensive• Scalable
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
18
Disadvantages• Scalability means “no-SQL” out of the box
– SQL Databases are designed for single servers or small clusters
– Caching data in memory becomes more important as it is inefficient (and expensive) for applications to read the database for common queries
– Requires understanding use cases ahead of time
• Software development cost is typically higher– Bleeding edge technology (changing everyday)– Requires significant new code – cannot just port
old code
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
19
Cloud Computing Bottom-Line• Enhances scalability• Enhances capability for large
collaborations on design and development throughout the lifecycle
• Upside: We can design more complex systems
• Downside: We will have to manage more complex systems development
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Cloud Computing Implications for Systems Engineering
20
Complexity of the problem can not be masked by the complexity of the systems engineering
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
21
Cloud Computing Implications for Systems Engineering
• Larger, more complex systems development implies:– A need for larger, distributed teams– A need for a clear concise way to
express the system design (clear, logically consistent semantics)
– New tools to enable collaboration across the entire lifecycle
Complexity has been identified by many as a critical problem facing system engineers
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
22
Complexity • With the growth of the Internet and daily changes in IT, systems have become more complex and change more rapid than ever before
• Cloud computing gives us new tools to deal with these larger systems
• Systems engineering methods have not kept up with these changes
• SE has been relegated to the beginning of the lifecycle
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
23
How Does SE Typically Respond to Complexity?
• Focus on “architecture”• More complex languages• More complex procedures• More layers of abstraction
– “Systems of Systems”– “Family of Systems”– “Portfolio Management”
• Need more time and money!
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
24
More Money Is a Problem
• Calls for doing more with less continue
• Need for lower labor and tool costs essential for acceptance of SE across the lifecycle
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
How can we simplify things enable “quicker/ cheaper”? Let’s start with the language we use
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
25
State of Current “Languages”• In the past decade, the Unified Modeling
Language (UML) and now the profile Systems Modeling Language (SySML) have dominated the discussion
• Why?– Perception that software is “the problem”– Hence need for an “object” approach
• SysML was designed to relate systems thinking to software development, thus improving communication between systems engineers (SE) and software developers
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
26
Why Objects Are Not the Answer• Although SysML may improve the communication
of design between SEs and the software developers it does not communicate well to anyone else– No other discipline in the lifecycle uses object oriented
design and analysis extensively– Users in particular have little interest/acceptance of
this technique– Software developers who have adopted Agile
programming techniques want functional requirements (and resent SEs trying to write software)
– Many software languages are hybrid object and functional
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Popular Software LanguagesPosition
Mar 2012Position
Mar 2011Programming
LanguageRatings
Mar 2012Delta
Mar 2011Functional/
Object/Hybrid
1 1 Java 17.110% -2.60% Object
2 2 C 17.087% +1.82% Functional
3 4 C# 8.244% +1.03% Hybrid
4 3 C++ 8.047% -0.71% Hybrid
5 8 Objective-C 7.737% +4.22% Object
6 5 PHP 5.555% -1.01% Hybrid
7 7 (Visual) Basic 4.369% -0.34% Hybrid
8 10 JavaScript 3.386% +1.52% Functional
9 6 Python 3.291% -2.45% Hybrid
10 9 Perl 2.703% +0.73% Hybrid
27
Trend to hybrid functional and object
From http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html accessed 4/6/2012
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
28
So What Do We Do?
• Recognize that our primary job as SEs is to communicate between all stakeholders in the lifecycle
• Be prepared to translate between all the disciplines
• Reduce complexity in our language to facilitate communication
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
29
What We Did
• In preparing for the cloud computing world of SE we:– Researched the variety of languages (ontologies)
in common use (DM2, SysML, BPMN, IDEF, SREM, etc.)
– Researched the variety of representations (FFBDs, N2, Behavior Diagrams, Class Diagrams, Electrical Engineering Diagrams, etc.)
– Took the best of each of these languages and representations and distilled them down to the essential elements, relationships, attributes, and diagramsThe result: Lifecycle Modeling Language
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
LIFECYCLE MODELING LANGUAGE (LML) OVERVIEW
30
A language to simplify system design description for the cloud
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
31
The Lifecycle
Architecture Development
System Design
Hardware/Software Acquisition
Integration and Test
Operational T&E and Transition
Future Operations and Maintenance
Demolition and Disposal
Program Management
Current Operations and Maintenance
Desig
n &
Analysis
Inte
gra
tion
& V
eri
fica
tion
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
32
Lifecycle Modeling Language (LML)
• LML combines the logical constructs with an ontology to capture information– SysML – mainly constructs – limited ontology– DoDAF Metamodel 2.0 (DM2) ontology only
• LML simplifies both the “constructs” and ontology to make them more complete, yet easier to use
• Goal: A language that works across the full lifecycle
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
33
LML Ontology* Overview
• Taxonomy**: – 12 primary element classes– Many types of each element class
• Action (types = Function, Activity, Task, etc.)
• Relationships: almost all classes related to each other and themselves with consistent words– Asset performs Action/Action performed by
Asset– Hierarchies: decomposed by/decomposes– Peer-to-Peer: related to/relates
*Ontology = Taxonomy + relationships among terms and concepts** Taxonomy = Collection of standardized, defined terms or concepts
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
34
LML Taxonomy Simplifies and Enhances the Semantic Schema Elements• Technical
– Action– Artifact– Asset
• Resource
– Characteristic• Measure
– Input/Output– Link– Statement
• Requirement
• Programmatic/Technical– Cost– Decision– Location
• Physical, Orbital, Virtual
– Risk– Time
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
LML Sequencing
Action A Action BAction A
Action B
Action C
Condition 1
Condition 2
Action A
Action B
LOOP
Action A
Action C
Range
Range (e.g.) 1 to n (iterate)
Until r < z (loop)
PARALLEL
SEQUENTIAL
SELECTION
SY
NC
OR
Action C (Exit Criteria)L
OO
P
35
No constructs – only special types of Actions – ones that enable the modeling of command and control/ information assurance to capture the critical decisions in your model
Coordinated by Asset C
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
36
OR
LML Action Diagram Captures Behavior
Which path?
Action in ParallelAction
Start End
Trigger
SY
NCInput/Output 2
Synchronize Information
1.2
1.3
1.7
Action1.1 Optional Action 2 in
Loop
1.6
External Input
External Output
Input/Output 3L
OO
P
Exit Criteria
1.5
Optional Action 11.4
Input/Output 1
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
37
LML Physical Block Diagram*
Sensor Systems Operator
P.5.2.1
Asset (Human)
I.1.3 Operator-Sensor Platform InterfaceSensor Platform
P.5.2.2
Asset (System)
connected with/connects
Sensor System Memory
R.5.2.2.1
Asset (Resource)
used by/uses• capacity (10 Mbits/sec)• Latency (100 millisec)
• maximum quantity (6 Gbytes)• minimum quantity (10 Kbytes)
*Note: Work in progress
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
LML Combined Physical Behavior Diagram* Enables Instances and Clones
38
Sensor Systems Operator
P.5.2.1
Asset (Human)
I.1.3 Operator-Sensor Platform Interface
connected with/connects
Sensor Platform A(2)
P.5.2.2
Asset (System)
Asset (Resource)
Sensor Platform A(3)
P.5.2.2
Asset (System)
Asset (Resource)
Sensor Platform A(1)
P.5.2.2
Asset (System)
Asset (Resource) Clon
es p
rovi
de m
ultip
le in
stan
ces
of
an A
sset
for u
se in
sim
ulati
on
A.3.1
Action (System Function)
A.3.2
Sense Targets
A.3.1
Action (System Function)
A.3.1
Deploy Sensor
input to/input from
input to/input from
Deploy Command
*Note: Work in progress
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
39
LML Translation• Two types of mapping for tailoring:
– Map names of classes to enable other “schema” models to be used
– Map symbols used (e.g., change from LML Logic to Electrical Engineering symbols)
– Enable diagram translations (e.g., Action Diagram to IDEF 0)
LML Symbol
Electrical Engineering
BPMN …
AN
D
LML Class DM2 SysML …
Action Activity Activity
Asset Performer Actor
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
40
Other Diagrams
• Physical Block Diagrams– With option for icon
substitution
• Interface Diagrams– N2 (Assets or Actions)
• Hierarchy Diagrams– Automatically color coded
by class
• Time Diagrams– Gantt Charts– Timeline Diagram
• Location Diagrams– Maps for Earth– Orbital charts
• Risk Chart– Standard
risk/opportunity chart
• Organization Charts– Showing lines of
communication, as well as lines of authority
• Pie/Bar/Line Charts– For cost and
performance
• Combined Physical and Functional Diagram (?)
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
41 CHARACTERISTIC TIMELOCATION
LOCATION TIMECHARACTER ISTIC STATEMENT
LINK RISK STATEMENT
LINK RISK
causesmitigates
referenced byresolves
based ontakes
occurs
located atdefines protocol
forreferenced by
causesmitigatesresolves
based on occurs
causesincurred bymitigatesresolves
based onincurred by
occurs
causesmitigatesresolves
ACTION ARTIFACT ASSET COST INPUT/OUTPUT DECISION
ACTION ARTIFACT ASSET COST INPUT/OUTPUT DECISION
referenced by
decomposed by decomposes
related torelates
referenced by
captured byconsumed by
performsproduced by
references
decomposed bydecomposesorbited by
orbitsrelated to
relates
causesreferenced by
resolvesreferenced by
incursreferenced by
referenced byspecified by
specifiesreferencesspecifies
ACTION
ARTIFACT
ASSET
CHARACTER-ISTIC
COST
INPUT/ OUTPUT
DECISION
LINK
LOCATION
ISSUE
LINK
LOCATION
RISK
ARTIFACT
ASSET
CHARACTERISTIC
COST
INPUT/ OUTPUT
RISK
STATEMENT
TIME
decomposed by decomposes
related torelates
references
capturesconsumes
performed byproduces
specified by
located at
STATEMENT
TIME
ACTIONincursgeneratesreceives
causesresolves
-
specified by incurs -causes
resolvesresponds to
connected by
occursbased on
referenced bysource of
located atcauses
mitigatesresolves
transferred by located at
specifies
decomposed bydecomposes
related torelates
incursspecifies
causesmitigatesresolvesspecifies
based onspecifies
specifies occurs
specifiescauses
resolvesspecifies
specifieslocated atspecifies
incurred bycauses
incurred byresolves
incurred by located atincurred byincurred byreferences
incurred byincurred byspecified by
decomposed by decomposes
related torelates
caused byresolved by
responded by
caused byresolved byspecified by
caused byincurs
resolved by
transferscauses
resolves
generated byreceived by
references - specified by incurs
decomposed by decomposes
related torelates
causesresolves
locates locates locateslocates
specified bylocates
based on occurs
caused bycauses
mitigatesresolved by
resolves
caused byresolved by
occurs
-defined protocol by
referencesconnected to specified by incurs
caused byresolved by
caused bycauses
decomposed by decomposes
related torelates
resolved by
caused byresolved by
located at
causesmitigatesresolves
based ondelayed by
occurs
caused byresolved by
caused byreferences
resolved by
occurs
caused bymitigated by
referencesresolved by
caused bymitigated byresolved by
caused bymitigated byresolved byspecified by
caused byincurs
mitigated byresolved by
caused bycauses
decomposed bydecomposes
related torelates
resolved by
caused bymitigated byresolved by
relates
locates locates locates
decomposed bydecomposes
related torelates
basis ofincurs
caused bymitigated byresolved by
caused bycauses
mitigated byresolved by
resolves
caused bymitigated byresolved by
located atmitigated by
decomposed bydecomposes
related torelates
located at
locatesmitigates
based onlocates
causesmitigatesresolves
decomposed bydecomposes
related torelates
relates
caused bymitigated byresolved by
taken by occurred by
occurred by occurred byspecified by occurred by
occurred by
basis ofcauses
resolvesbasis of
basis oflocated at
occurred by occurred bydelays
occurred byoccurred by related to related to
decomposed bydecomposes
related torelates
basis ofbasis of
referencessourced by
basis ofbasis of
specified by
LML Relationships Provide Linkage Needed Between the Classes
• decomposed by/decomposes
• orbited by/orbits• related to/relates
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
42
Reducing Complexity by Association
ResourcesPictureOtherProgrammaticAction
Name
Number
Description
Select Icon
Icon
Type
Key Relationships
Inputs (receives/triggers)
Outputs (generates)
Statement (based on)
Children (decomposed by)
Asset (performed by)
Parents (decomposes)
trigger?YesNo
Duration (takes)
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
43
ResourcesPictureOtherAction Programmatic
Name
NumberRelations for Risk Analysis
List of Issues or Risks or None
causes: Issue or Risk
List of Issues or Risks or None
resolves: Issue or Risk
List of Risks or None
mitigates: Risk
List of Costs or None
incurs: Cost
List of Locations or None
located at: Location
List of Times or None
occurs: Time (TimeFrame or PointInTime)
Map It
Reducing Complexity by Association
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
44
ResourcesPictureProgrammaticAction Other
Name
Number List of Artifacts or None
references: Artifact
Peer-to-Peer Relationships
List of Actions or None
related to: Action
List of Actions or None
relates: Action
Context
Context
List of Characteristics or None
specified by: Characteristic
Reducing Complexity by Association
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
45
ResourcesPictureOtherAction Programmatic
Name
Number
List of Resources or None
captures: Resource (Asset subclass)
List of Resources or None
consumed by: Resource (Asset subclass)
List of Resources or None
produces: Resource (Asset subclass)
Relations for Resource Modeling
Amount
Reducing Complexity by Association
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
46
LML Summary• LML provides the fundamental foundation for a
tool to support SE in the cloud• LML contains the basic technical and
programmatic classes needed for the lifecycle• LML defines the Action Diagram to enable better
definition of logic as functional requirements• LML uses Physical Diagram to provide for
abstraction, instances, and clones, thus simplifying physical models
• LML provides the “80% solution”– It can be extended to meet specific needs (e.g.
adding Question and Answer classes for a survey tool that feeds information into the modeling)
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
47
Break
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
48
SUGGESTED LML PROCESSESThe cloud will require us to be more disciplined
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
49
Processes are key to success on the cloud
• Cloud computing enables participation in design across the planet
• Hence, common processes are needed to enable different practitioners to contribute to the design in a coherent manner
• The following processes are offered as a starting point for such development
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
50
Requirements Analysis
Functional Analysis and Allocation
Synthesis
System Analysis and Control
Middle OutBest Use: Architecture Development (To-Be)
Systems Engineering During Design Phase
Bottom Up
Top DownBest Use: “Classical SE”
Best Use: Reverse Engineering (As-Is)
Adapted from EIA-632
Note: On the cloud the customer participate in the requirements development process and as such may want to focus on a scenario-based approach
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Requirements Analysis
51
Source Documents
External Interface Database
User Needs
Decompose Statements
Critical Issue?
Statement Verifiable?
Determine Options and Perform Trade Studies
See System Analysis and Control for details
Resolve Issues with Customer
YES
NO
Coordinate Changes to Make Statement Verifiable
NO
Review Statements and Risks with Customer
Update Knowledgebase
YES
Identify Risks and Plan Mitigation
Updated Requirements
Traceability Matrix
Preliminary Test Requirements
Standards Selected
Change Requests
Architecture Knowledgebase
Note: On the cloud the customer can have direct access to the design and provide comments directly
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
52
Key LML Elements for Requirements Analysis Process
• Artifact– Types: Briefing, Change Notice, Change Request,
Concept of Operations, Directive, Doctrine, Document, Guidance, Instruction, Interface Control Document, Policy, Procedure, Requirements Document, Trade Study, …
• Statement– Types: Acronym, Composite, Constraint, Definition,
Directive, Doctrine, Functional, Goal, Objective, Performance, Plan, Policy, Question, Requirement, Rule, Scope, Standard, Statement, Vision
• Risk• Issue
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Functional Analysis and Allocation
53
Architecture Knowledgebase
Develop/Revise Context Diagram
Determine Options and Perform Trade Studies
See System Analysis and Control for details
Review Model and Risks with Customer
Identify Risks and Plan Mitigation
Updated Architecture
Knowledgebase
Develop Series of Scenarios for Analysis
Create/Update System Behavior Model
Analyze Behavior Model Performance
Behavior Model•Control Flow•Data Flow (Activity Model)•Performance Criteria
Allocate Actions to Assets and Input/Outputs to Links
Updated Architecture
Knowledgebase
Detailed Operational
Concept
Operational Requirements
Document (ORD)
Note: On the cloud risks can be identified and mitigated quickly due to enhance visibility
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
54
Key LML Elements for Functional Analysis Process
• Action– Types: Activity, Capability, Function,
Mission, Operational Activity, Program, Service Orchestration, Simulation Workflow, Subprocess, System Function, Task, Training, Work Process, Workflow
• Input/Output– Types: Analog, Digital, Event, Mixed,
Physical, Product, Verbal
• Time: Duration
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Synthesis
55
Architecture Knowledgebase
Identify Component Assets
Optional Assets?
Determine Options and Perform Trade Studies
See System Analysis and Control for details
Select New Assets in Coordination with Customer
YES
NO
Review Design and Risks with Customer
Identify Risks and Plan Mitigation
Technology Insertion
Recommend-ations
Allocate Assets
Updated Architecture
Knowledgebase
Functional Requirements
Document (FRD)Design Diagrams
See Functional Analysis and Control for details
Transition Plan
Link to programsProgrammatic
Roadmap
Note: On the cloud the customer and SEs can interact directly with hardware & software providers to synthesis solutions more rapidly
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
56
Key LML Elements for Synthesis Process • Asset
– Types: Architecture, Assembly, Component, Context, CSC, CSCI, CSU, Element, Environment, External System, Facility, Hardware, Human, HW Element, HWCI, Infrastructure, LRU, Materiel, Operational Element, Organization, Part, Performer, Personnel, Segment, Service, Software, Subassembly, Subsystem, System, System Instantiation, Test Equipment, Test Software, Unit
• Link– Types: Cable, Downlink, Human-in-the-Loop, Human
Machine Interface, Interface, Landline, Link, Needline, Network, Pipe, Relationship, RF - Satcom, RF - Terrestrial, Roadway, Service Interface, Uplink, Wireless
• Location• Cost• Characteristic
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Systems Analysis and Control
57
Identify Technologies, Methods and Needs for Study
Recommend Changes and Prepare Reports
Analyze Performance and Cost Effectiveness (Dynamic)
Assess Risk Probability and Consequence
Analyze Effectiveness, Use, O&M, Security, and Training Impacts
Updated Architecture Knowledgebase
Develop Metrics for Trades
Develop Risk Mitigation Approach
Trade Study Reports
Architecture Knowledgebase
Technology Insertion
Recommend-ations)
Note: On the cloud we will be able to accommodate large-scale simulations to perform the trade studies and verify performance
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
58
Key LML Elements for Systems Analysis and Control Process
• Characteristic– Types: Condition, Data Element,
Environmental, Functional, Performance, Physical, Scenario, Security, Verification Category
• Time: subclass Timeframe• Risk
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
59
LML TOOL NEEDSThe cloud will require new tools to make use of its potential for enhanced scalability and collaboration
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
60
LML Specification
• A complete specification and book are in development
• Considering standards bodies for promulgation (INCOSE?)
• May just make it an open “standard” allowing others to adapt and refine it
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
61
Tool for Vision for MBSE• Tool must be designed as a
MBSE tool using Lifecycle Modeling Language (LML)– All artifacts must be
produced from the tool using standard reports
• Tool must enable both seamless data flow and distributive, collaborative teams working on the same model
• Implies need for ability to scale “infinitely” on demand
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
62
Tool for Complexity• Tool must be designed for
use throughout the lifecycle, thus enabling end-to-end systems engineering– Legacy systems are a key
part of any modeling environment – LML has specific information classes for capturing designs at different times in one knowledgebase
• Tool must embed simulation, which enables real time simulations as well as the ability to scale “infinitely” to hundreds of server instances
• Tool must also reduce complexity by use of special input screens, which enhance configuration management as well
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
63
Tool for Multi-Decadal/Generation
• Tool must enable tracking of performance over time as Characteristics of the Assets
• Environments and conditions can also be captured as evolved over time and location (including orbital locations)
• Tool must evolve of the lifecycle of systems, but the data must be captured and reused throughout the lifecycle
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
64
Tool for Uses and Challenges • Tool needs to create a
CONOPS report based on scenario modeling
• Capture Issues and Decisions, as well as Cost for cost, schedule and performance tradeoffs
• TRL levels must be easily captured in the tool
• Software as a service provides inexpensive tool, while scalability enables fidelity level required; LML method enables rapid SE design and analysis
• Tool should automate what can be automated to reduce “wetware” requirements and enhance teaming
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
65
Tool for Uses and Challenges (continued)
• Tool should enable design down to detailed level (if desired), as well as V&V support
• Manufacturing enhanced by linking design to CAD/CAM systems (export design information as required)
• Use of XML files to import/export data from other design tools
• Design rationale, assumption and other programmatic information captured as part of Issues, Risk and other program-related elements of LML
• Standards should be captured and developed using the tool; enforcement by tailoring “personal trainer” version
• Operations data and obsolescence part of LML elements (Assets, Characteristics and Time)
• Use of a scenario-based approach enables better information capture from operators
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
66
Tool for Managing Complexity
• Tool in conjunction with a process should capture a reasonable number of scenarios for modeling and simulation, using a test matrix approach (move away from “peeling the onion”)
• Use “test matrix” approach to provide breadth of problem space, including failure modes, to capture the full functionality required
• Test must become even more dependent on simulation
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
67
Tool for Managing Complexity
• Tool should enable sharing of models, thus creating a “library” of component models
• Contributions should be made from academia (tool should be free access to academia) to this library
• Government sponsored research can also be made available to the NASA family via website
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
68
Key Tool Features Needed• Scalable Modeling• Scalable Discrete Event Simulation• Functional Behavior Diagrams• Physical Block Diagrams w/ Icons• Element Extractor/Automated Parsing• Splitting and Merging Requirements• Merge databases from other tools• Access to the web• Automated report writing• Enterprise data search• Customization• Collaboration• Configuration Management
No current tool meets all of these needs
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
69
Project Innovation
• SPEC is developing prototype software to test LML capabilities
• Working on using modern User Interface design to reduce remaining complexity (e.g. relationships)
• See SPEC Innovations booth for a demonstration
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Why a new tool?Response to NASA’s Vision for MBSE
• SPEC’s prototype software is designed as a MBSE tool using Lifecycle Modeling Language (LML)– All artifacts can be produced
from the tool using standard reports (Java for speed) and JavaScript for specialty reports
• Cloud based (using Google App Engine PaaS) that enables both seamless data flow and distributive, collaborative teams working on the same model
• Ability to scale “infinitely” on demand70
From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011
* MBSE=Model-Based Systems Engineering
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
What is SPEC’s Prototype Software?• A tool to capture design, operations and
support information using systems engineering principles
• Applies cloud computing technology to model-based systems engineering techniques and discrete event simulation
• Implements the lifecycle modeling language (LML) and enables translation to UML, SysML, DoDAF (DM2), and other languages
71
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
What are the system requirements?
• Operating system– Any (Windows XP/7, MAC OS X, Linux)
• Devices– Any (PC, Mac, iPad, Android Tablet)
• Software– Any modern web browser (Google
Chrome, IE 9+, Firefox 5+, Safari)
72
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
What Will SPEC’s Prototype Software Produce?• Specifications for detailed design (in the languages
of the design engineers)• Concepts of Operations (and Support)• Processes and Procedures for Operations and
Training• Test and Evaluation Master Plans• Early Simulation/Design Validation• End-to-End Design Management and Collaboration• Repository of Analyses from Any Tool• Traceability from Requirements to Functions to
Components to Test to Operations to Support to Disposal
73
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Requirements
74
Requirements quality checks with definitions
Trace to assets
Trace to higher level requirements
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Visual Representations
• Hierarchy charts• Traceability charts• Action Diagram (Functional)• Asset Diagram (Physical/Interface)• Geo-Location view (maps)• Gantt chart (via simulator)
75
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Entity editor
76
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Database view
77
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Chat
78
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Simulation result
79
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Geo-Location
80
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Hierarchy Chart
81
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Action Diagram
82
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
SPEC’s Prototype Software Features and BenefitsFeatures Benefits
Chat/Real-time Notification Enables collaboration worldwide
Lifecycle Modeling Language (LML) schema and Web User Interface
Provides simplicity and ease of use with little or no training
Open feature requests with voting on priority by users
Supports transparency between users and developers
Google App Engine’s cloud computing capability
Can scale design to deal with very large projects that include millions of objects
Nimbus security layer with Google App Engine security layer and SSL
Provides secure
Automatic upgrades; no installation; runs on any computer or device (e.g., iPad)
Reduces IT support costs and trouble significantly
Monthly payment plan Buy what you need, when you need it
83
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Next Steps
• We look forward to your thoughts and ideas on how to improve the tool– Online feedback available when
released
• As a Software as a Service (SaaS) tool, we will deliver the capability on a monthly basis, if desired, at a low cost
84
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
85
Break
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
USE OF LML FOR ARCHITECTURE DEVELOPMENT
86
Architecture development on the cloud may focus on a middle-out/scenario-based approach to speed up the system specification process
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
14. Provide Options
Architecture Development Process and Products
87
5. Develop the Operational Context Diagram
15. Conduct Trade-off Analyses
6. Develop Operational Scenarios
1. Capture and Analyze Related Artifacts
4. Capture Constraints
3. Identify Existing/Planned Systems
2. Identify Assumptions
7. Derive Functional Behavior
8. Derive Assets
10. Prepare Interface Diagrams
12. Perform Dynamic Analysis
11. Define Resources, Error Detection & Recovery
13. Develop Operational Demonstration Master Plan
16. Generate Operational and System Architecture Graphics, Briefings and Reports
Requirements Analysis
Functional Analysis
Synthesis
System Analysis and Control
This implementation of the middle-out approach has been proven on a variety of architecture projects
AV-1
AV-2
OV-1OV-2
OV-3
OV-4
OV-5
OV-6
9. Allocate Actions to AssetsSV-1
SV-2SV-3
SV-4
SV-5SV-6
SV-7
SV-8 SV-9
SV-10
StdV-1 StdV-2
AV-1Draft DIV-2
DIV-3
DIV-1 CV-1CV-2
CV-3
CV-4
CV-5CV-6
CV-7
PV-2PV-3
PV-1
CONOPS
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
88
Key Architecture Products
• DoDAF Diagrams• Concept of Operations (CONOPS)• Functional Specifications of Hardware and
Software• Early Design Validation Through Modeling
and Simulation• Test and Evaluation Plans (for T&E)• Processes and Procedures (for Operations
and Support, as well as inputs to training plans)
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
89
Key LML Elements and Use - ArchitectureElements Use
Action Scenario analysis
Asset High level for gap analysis
Cost High level cost estimates - lifecycle
Characteristic Key metrics for performance/acceptance
Input/Output Key data elements
Link Critical interfaces (between systems of systems)
Risk Key schedule, cost, performance risks
Time - Timeframe Broad roadmap
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
90
• Add in slides on CONOPS report, ICD and other Nimbus SE report outputs
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
91
USE OF LML FOR SYSTEM DESIGN
The cloud will enable detailed designs together with the architecture analysis
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
92
Requirements Analysis
Functional Analysis and Allocation
Synthesis
System Analysis and Control
Middle OutBest Use: Architecture Development (To-Be)
System Design Process
Bottom Up
Top DownBest Use: “Classical SE”
Best Use: Reverse Engineering (As-Is)
Adapted from EIA-632
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
93
Key Systems Design Products• System/Segment Specifications• Interface Control Documents• Detailed Integration and Test Plans
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
94
Key LML Elements and Use – System DesignElements Use
Action Functional analysis
Asset Design packaging
Cost Detailed cost estimates - lifecycle
Characteristic Specific metrics for performance/acceptance
Input/Output Data elements
Link Interfaces (between components)
Location Identifies differences due to location
Risk Schedule, cost, performance risks
Statement Key requirements
Time - Duration Key time dependences
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
95
USE OF LML FOR SOFTWARE DEVELOPMENT
Our cloud capability must include software developers as well
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
96
Support Object Analysis (if desired)
• Assets = Objects• Links = Relationships/Interfaces• Characteristics = Attributes• Actions = Methods
– Can include key logic algorithms
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
97
Otherwise – Support Functional Requirements Specification
• Actions• Input/Output• Packaging using Assets and Links
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
98
Key LML Elements and Use – Software DevelopmentElements Use
Action Functional requirements for methods
Asset Classes and/or packages
Characteristic Specific metrics for performance/acceptance
Input/Output Data elements
Link Interfaces (Inheritance between Classes)
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
99
Break
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
USE OF LML IN TEST AND EVALUATION
100
T&E on the cloud may occur early and often by starting with low fidelity simulations evolving to high fidelity simulations that may reduce the need for expensive testing
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
101
Coming Up the Vee
I&V Planning
Integration
Verification
Des
ign
Mon
itorin
g
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
Measure of Performance (MOP) View
102
Measure of Performance (MOP)
Type = MOPMOP 1.1
SystemType = System
System
MOP Test ResultType = MOP Occurrence
MOP 1.1 [System (SW1/HW1)]
MOP Test ResultType = MOP Occurrence
MOP 1.1 [System (SW2/HW2)]
MOP Test ResultType = MOP Occurrence
MOP 1.1 [System (SW3/HW3)]
System InstantiationType = System Instantiation
System (SW1/HW1)
System InstantiationType = System Instantiation
System (SW2/HW2)
System InstantiationType = System Instantiation
System (SW3/HW3)
instantiates /instantiated by
instantiates /instantiated by
specifies /specified by
Characteristics
Assets
1:M
1:M
1:M
specifies /specified by
specifies /specified by
1:1 1:1 1:1
Measure of Effectiveness (MOE)
Type = MOEMOE 1
decomposed by /decomposes
instantiates /instantiated by
instantiates /instantiated by
1:1 1:1 1:1
System FunctionType = System Function
Function
tests /tested by
allocated to /performs
Actions
1:1
1:M
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
103
Key LML Elements and Use – Test and EvaluationElements Use
Action Test processes and procedures/ functional requirements for testing
Asset Test configurations
Cost Test costs
Characteristic (Technical Measurement subclass)
Specific metrics for performance/acceptance (MOEs, MOPs)
Input/Output Data elements for measurement
Link Interfaces (between components)
Statement Key requirements for testing
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
USE OF LML IN OPERATIONS AND SUPPORT
104
The cloud may enable our integration into the operational world more rapidly and transparently
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
105
LML Support Operations and Support Analyses
• Process Modeling• Simulation of Operations• Training Processes and Procedures• Operations Manuals• Logistics Analysis
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
106
Key LML Elements and Use – Operations and SupportElements Use
Action O&S processes and procedures
Asset Configurations
Cost O&S costs
Characteristic (Technical Measurement subclass)
Specific metrics for performance/acceptance (MOEs, MOPs)
Input/Output Data elements for decision making
Location Differences due to location
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
SUMMARY
107
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
108
People Considerations for SE on the Cloud
• Large teams make organization and focus on a vision very difficult– Need better ways to collaborate– Need process discipline, perhaps enforced by a tool
• You need people with a wide variety of skills and personalities– Someone with vision– Someone who can perform the detailed system
engineering– Someone who understands the domain– Someone familiar with the technique and tools– Someone who understands the process
• They need to be trained as a team – including the government personnel
© 2012 Systems and Proposal Engineering Company. All Rights Reserved
109
SE on the Cloud Bottom-Line• The cloud provides a new capability to
deal with complex problems, but:– It requires new ways to communicate,
including a simplified language accessible to all stakeholders
– It requires discipline to ensure all designers have common standards enabled by processes
– It requires new tools that can take advantage of this new capability
• The cloud is in our near-term future … are you ready?