DoDAF and Joint HSI WG (Human View) Dialog Kick-Off

Slides:



Advertisements
Similar presentations
Applying the Human Views for MODAF to the conception of energy-saving work solutions Dr Anne Bruseberg Systems Engineering & Assessment Ltd, UK on behalf.
Advertisements

Human Views for MODAF Dr Anne Bruseberg Systems Engineering & Assessment Ltd, UK on behalf of the Human Factors Integration Defence Technology Centre.
DoDAF V2.0 Community Update Overview
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
DoD Architecture Tools 5 January 2012 DoDAF Team.
A Combat Support Agency Defense Information Systems Agency Model Based Systems Engineering and Systems Modeling Language Chris Gedo Chief, Architecture.
Enterprise Architecture
Architectural Framework
12 August 2010 DoDAF Development Team
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
5 Systems Analysis and Design in a Changing World, Fourth Edition.
5 Chapter 5: Modeling Systems Requirements: Events and Things Systems Analysis and Design in a Changing World.
DoDAF V2.0 Community Update Overview
VERSION 15 Primitives – Lexicon IPR 6 August 2008
DoDAF Data Meta Model (DM2) Overview
Discussion Topics for Exploring OMG UPDM Way-ahead
DoD Architecture Framework Application
Agenda Federated Enterprise Architecture Vision
Overview 13 June 2011 DoDAF Team 1 1.
Unified Architecture Framework NATO Architecture CaT Introduction
Update on the Architecture CAT
Object Management Group Information Management Metamodel
Official Current Version of DoDAF
Chapter 11: Software Configuration Management
INCOSE Usability Working Group
DoD CIO Architecture and Interoperability Directorate December 2014
IC Conceptual Data Model (CDM)
DoDAF Version 2.03 Update 05 Jan 2012 DoDAF Team 1 1.
DoD Architecture Framework Version 2.0 Illustrative View Examples
Introduction to MODEM Building a Semantic Foundation for EA: Reengineering the MODAF™ Meta-Model Based on the IDEAS Foundation Model Lt Col Mikael Hagenbo,
DATA VERTICAL Technical Exchange
DoD Architecture Framework Application
VERSION 15 DoDAF Vendor’s Day Session 22 July 2008
US Kickoff brief to Frameworks Convergence Meeting
DoDAF Meta Model (DM2) Update -- Version 2.01
NDIA Architecture Analysis for System-of-System (SoS) Interoperability Assessment Karen L. Lauro, Ph.D Oct 21, 2003.
Brief to Extraordinary NATO A-CAT Mr. Walt Okon January 2013
Architecture Tool Vendor’s Day
Workshop for ACT – IAC, EA-SIG Mr. David McDaniel (ctr) 20 July 2012
Reification in DoDAF is formally superSubtype, wholePart, or ovelap
Agenda All-Monday 15 Sep 0800 Welcome - Opening remarks
Overview and Role in DoD Governance
Introduction DoDAF 2.0 Meta Model (DM2) TBS dd mon 2009 VERSION 15
Introduction DoDAF 2.0 Meta Model (DM2) TBS dd mon 2009 VERSION 15
Tutorial Mr. Walt Okon Mr. David McDaniel (ctr) February 2013
CV-1: Vision The overall vision for transformational endeavors, which provides a strategic context for the capabilities described and a high-level scope.
VERSION 15 9/12/ :44 International Defence Enterprise Architecture Specification (IDEAS) and DoDAF 2.0 Data Model OMG Systems Engineering Domain.
DoDAF Maintenance Update (v2.03)
DoDAF Maintenance Update (v2.03)
Version 3 April 21, 2006 Takahiro Yamada (JAXA/ISAS)
The Open Group Architecture Framework (TOGAF)
DoDAF Data Meta Model (DM2) Overview
DoD Architecture Framework Version 2.0 Illustrative View Examples
NATO Architecture Capability Team (A-CaT) Workshop
DoD CIO Architecture and Interoperability Directorate July 2013
DoDAF 2.x Meta Model (DM2) Conceptual Level
DoD CIO Architecture and Interoperability Directorate July 2013
DoDAF In-Depth DoD CIO Architecture and Interoperability Directorate
VERSION 15 UCORE Conference 23 Sep 2009
Conceptual Data Model (CDM) For: core process stakeholders
DM2 D O A F M E T L Conceptual Data Model (CDM)
Chapter 11: Software Configuration Management
IDEAS Core Model Concept
DM2 D O A F M E T L Conceptual Data Model (CDM)
Manager’s Overview DoDAF 2.0 Meta Model (DM2) TBS dd mon 2009
, editor October 8, 2011 DRAFT-D
Systems Architecture & Design Lecture 3 Architecture Frameworks
CORE Name: CORE® Description:
What is the DM2? DoDAF Vocabulary Discovery Categories D O A F M E T L
US Kickoff brief to Frameworks Convergence Meeting
Presentation transcript:

DoDAF and Joint HSI WG (Human View) Dialog Kick-Off 25 August 2010 DoDAF Development Team 1 1

Briefing Outline How human performance, metrics, and interactions are modeled in DoDAF Meta Model DoDAF views where this could show up Example from UPDM 1.0 Configuration Management of DoDAF for further refinement and evolution

Potentially Related Terms or Aliases A Human is a Performer DoDAF-DM2 Term Definition Potentially Related Terms or Aliases Performer Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability. Actor, Agent, Capability Configuration (MODAF) In architectures, we don’t ever model actual named persons, but, rather, their roles, e.g., President, not George Washington

Definitions of Other Terms in Diagrams DoDAF-DM2 Term Definition Potentially Related Terms or Aliases Activity Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state. Action, Process Operational Activity, Processes, Function, System Function, Operation, Task, Plan, Project activityPerformableUnderCondition Represents that an activity was / is / can-be/ must-be conducted under certain conditions with a spatiotemporal overlap of the activity with the condition.   activityPerformedByPerformer An overlap between a Performer and an Activity that is non-specific as to whether: 1. the Activity is solely performed by the Performer 2. the Activity is performed by several Performers 3. the Performer performs only this Activity 4. the Performer performs other Activities Agreement A consent among parties regarding the terms and conditions of activities that said parties participate in. Condition The state of an environment or situation in which a Performer performs or is disposed to perform. IndividualPerformer A specific thing that can perform an action IndividualPersonRole Person roles defined by the role or roles they share that are relevant to an architecture. Includes assigned materiel. LocationType The powertype of Location Materiel Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes.

Definitions of Other Terms in Diagrams DoDAF-DM2 Term Definition Potentially Related Terms or Aliases materielPartOfPerformer A whole-part association between a Performer (whole) and the Materiel parts of the Performer. (A Performer can have Personnel Type, System, Service, and Organizational components.)   Measure The magnitude of some attribute of an individual. MeasureableSkill A Skill that can be measured numerically measureableSkillOfPersonRoleType skillPartOfPersonRoleType is a member of Measure measureOfTypeActivity A measureOfType that relates an Activity to a Measure measureOfTypeCondition Condition is a member of Measure measureOfTypeResource ResourceType is a member of Measure Organization A specific real-world assemblage of people and other resources organized for an on-going purpose. Department, Agency, Enterprise OrganizationType A type of Organization Performer Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability. Actor, Agent, Capability Configuration (MODAF) PersonRoleType A category of person roles defined by the role or roles they share that are relevant to an architecture. Includes assigned materiel. Role personRoleTypePartOfPerformer A wholePart between a PersonRoleType and a Performer in which it performs

Definitions of Other Terms in Diagrams DoDAF-DM2 Term Definition Potentially Related Terms or Aliases Resource Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.   resourceInLocationType The relationship that describes the location of a performer or type of performer Rule A principle or condition that governs behavior; a prescribed guide for conduct or action ruleConstrainsActivity An overlap between a Rule and the Activities it allows Service A mechanism to enable access to a set of one or more capabilities , where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The "capabilities" accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents. Skill The ability, coming from one's knowledge, practice, aptitude, etc., to do something well. Training, Knowledge, Ability System A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.

Performers Perform Activities that Flow Resources

Metrics are Ubiquitous in DoDAF 2

The Ontologic Foundation is Key to DoDAF 2’s Modeling Four dimensionalist -- xyzt Extensional -- physical existence is the criterion for identity Signs and representations are separated from referents Mathematics: Type theory ~ Set theory Mereology (wholes and parts) 4D Mereotopology (spatio-temporal relations) http://www.ideasgroup.org Then domain concepts inherit several important properties. None of these foundation properties are unusual; they are all used in reasoning everyday: Individuals, things that exist in 3D space and time, i.e., have spatial-temporal extent. Types, sets of things. Tuples, ordered relations between things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework. Whole-part; e.g., components of a service or system, parts of the data, materiel parts, subdivisions of an activity, and elements of a measure. Temporal whole-part; e.g., the states or phases of a performer, the increments of a capability or projects, the sequence of a process (activity). Super-subtype; e.g., a type of system or service, capability, materiel, organization, or condition. Interface; e.g., an overlap between two things. [1] http://www.ideasgroup.org Three types of Things: Types (which are like sets), Tuples (ordered relationships), and Individuals (not persons, but Things that have spatial and temporal extent – spatio-temporal extent.) mereology is a collection of axiomatic first-order theories dealing with parts and their respective wholes. In contrast to set theory, which takes the set–member relationship as fundamental, the core notion of mereology is the part–whole relationship. Mereology is both an application of predicate logic and a branch of formal ontology.

Design Reification and Requirements Traceability describes describes describes Thing describes describes Pedigree (requirements) Pedigree (requirements) Pedigree (requirements) Pedigree (requirements) Architectural Description Pedigree (requirements) Architectural Description Architectural Description Architectural Description Architectural Description Rules A&D Successive refinement of the Architectural description. For any phase, it is traceable to the prior (pedigree). The prior phase becomes the rules that constrain the activities of the next performer – adherence to requirements baseline. They’re all aiming at the same future Thing, just describing it in more detail and in different ways as you go along. Rules Rules constrain Rules constrain Rules constrain constrain constrain Worker Technician Engineer Architect Executive Strategic Op Rqmt TLR SLR A-Spec B-Spec C-Specs time CBA ICD AoA Perf Spec CDD CPD IOC

Many Views Can Render this Data AV-1 Overview and Summary Information o AV-2 Integrated Dictionary OV-1: High Level Operational Concept Graphic   OV-2: Operational Connectivity Description OV-3: Operational Resource Flow Matrix OV-4: Organizational Relationships Chart OV-5a: Activity Decomposition Tree OV-5b: Activity Model OV-6a: Operational Rules Model OV-6b: State Transition Description OV-6c: Event-Trace Description SV-1 Systems Interface Description SV-2 Systems Communications Description SV-3 Systems-Systems Matrix SV-4 Systems Functionality Description SV-5a Operational Activity to Systems Function Traceability Matrix SV-5b Operational Activity to Systems Traceability Matrix SV-6 Systems Data Exchange Matrix SV-7 Systems Performance Parameters Matrix n SV-8 Systems Evolution Description SV-9 Systems Technology and Skills Forecast SV-10a Systems Rules Model SV-10b Systems State Transition Description SV-10c Systems Event-Trace Description SvcV-1 Services Interface Description SvcV-2 Services Communications Description SvcV-3a Systems-Services Matrix o SvcV-3b Services-Services Matrix SvcV-4 Services Functionality Description   SvcV-5 Operational Activity to Services Traceability Matrix SvcV-6 Services Data Exchange Matrix SvcV-7 Services Performance Parameters Matrix n SvcV-8 Services Evolution Description SvcV-9 Services Technology and Skills Forecast SvcV-10a Services Rules Model SvcV-10b Services State Transition Description SvcV-10c Services Event-Trace Description Standards View-1 Standards Profile Standards View-2 Standards Forecast PV-1: Project Portfolio Relationships PV-2: Project Timelines PV-3: Project to Capability Mapping CV-1: Vision CV-2: Capability Taxonomy CV-3: Capability Phasing CV-4: Capability Dependencies CV-5: Capability to Organizational Development Mapping CV-6: Capability to Operational Activities Mapping CV-7: Capability to Services Mapping DIV-1:Conceptual Data Model DIV-2: Logical Data Model DIV-3: Physical Data Model PersonRoleType A category of person roles defined by the role or roles they share that are relevant to an architecture. Includes assigned materiel. n=necessary o=optional

Version Control Initial baseline DoDAF 2.0 released May 2009 2.01 released Feb 2010 2.01 Version Description Document (VDD) describes changes made in response to Action Items 2.02 to be released 26 Aug 2010 2.02 VDD New baseline published on public and DKO DoDAF and DoD EA COI namespace in DoD Meta Data Registry 2.03 planned for Fed 2011 DoDAF-DM2 Action Item tracker identifies planned items New and other currently deferred AI’s will be prioritized by DoDAF-DM2 Working Group with Federated Architecture Council (FAC) oversight 2.0 2.01 2.02 2.03 May 2009 Feb 2010 Aug 2010 Feb 2011

Relevant Governance Process Documents Architecture Standards Review Group CONOPS Roles, Responsibilities, and Processes ASRG -- FOGO / SES level Federated Architecture Council – 06 level DoDAF and DM2 CM Plan Configuration Identification Organizational Roles, Responsibilities, and Interactions CM Processes and Procedures CM Business Rules DoDAF & DM2 WG EA COI COI POA&M COI Data Management Working Group Meets Quarterly, 1st meeting was 2 July 2010 COI Metrics

FAC is Small Formal Voting Body WG is Large Collaborative NSA AF DoN Army Marine Corps DISA DISA DISA * Some C/S/A have multiple members FAC – Voting – 23* votes DoD CIO DoDAF-DM2 Configuration Status Accounting Report (CSAR) DoDAF-DM2 Baseline Status DoDAF-DM2 WG Activity Summaries COI Metrics and Progress Report DoDAF-DM2 Change Requests • COI Guidance • DoDAF-DM2 Action Item Prioritization • DoDAF-DM2 Baseline Direction • JFCOM STRATCOM JCS J6 DCMO USD(I) P&R AT&L DNI CIO DoDAF-DM WG – Collaborative – Agreed-upon business rules enable analysis of different opinions Framework Groups OMG / INCOSE / NDIA MODAF / NAF / TOGAF FEA / FSAM Core Process Stakeholders CJCSI revs AT&L SoSE & Acq Reform Combatant Command architectures CPM Governance PA&E Framework & Ontology Groups OMG / INCOSE / NDIA IDEAS / NAF UCORE Enterprise Vocabularies 230+ members Meets weekly Vendors EA/ITA Tool M&S Data Analysis Repository Data Integration Data Exchange Pilots Early Adopters Federation COI Coordination Groups DoD MDR WG DoD COI Forum To join, go to www.silverbulletinc.com/DoDAF-DM2

2.00  2.01  2.02  2.03 Overview 2.00 2.01 2.02 2.03 (in-planning) 70 Action Items 2.02 29 Action Items 2.03 (in-planning) 25 AI’s currently queued 85 new AI’s to review DM2 CDM, LDM, PES 12 DM2 data groups 52 Models IDEAS v1.0 alignment Measures Representation, Names, Descriptions Structured Service Description Reification Structured Desired Effect Properties and Measures generalized and better aligned with IDEAS and JFCOM JMT needs Reification diagram to explain requirements, design levels, and traceability for SE community Consolidate Activity, Goal, diagrams Simplified complex tuples (triples, tuples as places) Redundant associations Re-organized type orders, e.g., for information and data Added more structure to Agreement Made higher-order typing consistent Some XSD cleanup from pilot feedback State machine diagram Temporal Flow diagram DoDAF Models revised to match DM2 terminology better Core process required datasets More structure to Rules and Agreement Services reification and joint action Ontologic structure for Command Relationships Basis for authority Vision vs. Desired Effect IDEAS Set Theory Unions (for mappings)

Questions?