dodaf maintenance update (v2.03) 5 jan 2012 dodaf team
TRANSCRIPT
DoDAF Maintenance Update (v2.03)
5 Jan 2012
DoDAF Team
22
Outline
• Recap of the DoDAF Configuration Management Process
• CM Plan (CMP)• ASRG, FAC, and DoDAF-DM2 WG• CM Processes Overview• CM “Business” Rules• Changes for 2.03• Formal coordination review plan
3
DoD Architecture Framework Evolution and CM
• C4ISR F/W’s– Joint Interoperability
• DoDAF 1.0– JCIDS, applicability beyond C4ISR
• DoDAF 1.5– Net-centricity and SoA
• DoDAF 2.0– Fit-for-Purpose, data-centric
architecture, improved models of systems, services, capabilities, rules, measures
• CM phase:– High-priority improvements, error
correction, emerging requirements– Stability for governance developers,
users, vendors
4
DoDAF is Under Formal CM
• Configuration Identification• Organizational roles,
responsibilities, and interactions• DoDAF-DM2 CM Processes
and Procedures • DoDAF-DM2 CM Business
Rules• Configuration Status Accounting
5
Configuration Identification
1. DoDAF Viewpoint Definitions. Conventions for the construction, interpretation and use of architecture views and associated architecture models.
2. DoDAF Model Specifications. Specifications from which architecture views representing an architecture are composed.
3. Glossary. Defines all non-demotic terms used in DoDAF and the DoDAF Meta Model.
4. DM2. Consists of a Conceptual Data Model (CDM) diagram and narrative description, a Logical Data Model (LDM) in an UML file adapted to IDEAS and a narrative description, and Physical Exchange Specification (PES) XML Schema Descriptions.
• NOTE that introductory, tutorial, document outlining, and web navigation documentation is considered under control of the DoDAF Journal editorial team and not subject to formal CM in scope of this plan.
66
CM Organizational Roles
CONFIGURATION STATUS
ACCOUNTING• CR Tracker (CRT)• CSAR• VDD
ASRG
ASRG Secretariat
FAC ITSC GIG CMB
DoDAF-DM2 WG
DARS WG
Ad Hoc WGs
ITSC Secretariat
ITSC WGs
IT Standards Principals
GIG Secretariat
EWSE IPTs
GTG Dev Groups
1. FAC Redirects on Specific CR2. DRAFT Baseline Comments3. DoDAF-DM2 Baseline Release
Approval
FAC
DoDAF-DM2 WG
FCM monthly report to FAC:1. WG Activity summary info brief2. Other info briefs of significant
recommendations being considered3. Configuration Status Accounting
Report (CSAR) document
77
CMP Processes
• CR Processing and Configuration Status Reporting
• Baseline Process
Change Request submitted via WG
web
Change Request communicated to WG CR Tracker
Enter into system as
“unassigned”
Record: “defer” and planned
version (if known)Reject
CoA and actionee(s)
Update status (defer, reject, in-progress) and, if necessary,
CoA and actionee(s)
Record as “done in v2.xx”
Prepare readahead:§ Next batch of
“unassigned”§ Topics selected at
last meeting§ Material submitted
by Actionee(s)§ FAC redirects
Conduct Meeting
Call for “unassigned” originators to brief
their CRs and facilitate discussions
Discuss problem and CoA: defer, reject, or select
CoA and actionee(s)
Present and prepared to
discuss
Yes
Move to bottom of queue
No
Facilitate CoA updates by actionee(s)Facilitate
topic discussions
Provide research findings, possible
solutions, etc.
More work
Minority member non-
concurr?
WG Business RulesData Dictionary
Current and working baselinesCR databaseDM2 models
Core process requriements
Report non-currence to
FAC
No
YesYes
Call for topics for
next meeting
Report to FAC:WG activity summary
CSARFAC redirect
impacts
Facilitate FAC redirect
CoA revisions
FAC vote to redirect?
Impact:Biz rulesProgramsVendors
Discuss new CoA and
actionee(s)
Yes
FA
CC
I &
CR
C
ust
odi
an
CR
Ori
gin
ator
s an
d
Act
ione
e(s
)F
CM
Yes
Bi-weekly
Monthly
See “Detailed CR Processing” for
amplification
CR WG review
C R r e q u e sts n e w vie w
C R r e q u e sts d e le te e xistin g vie w
N e w r e la tio n sh ip
Y e s
Y e s
Y e s
Y e s
Y e s
Y e s
Y e s
Y e s
C o n str u ct IA W vie w d e scr ip tio n style g u id e :
N a m e“ O n e -lin e r ”D e scr ip tio nC P U sa g e
D M 2 m a p p in g
S T A R T
E N D
C R r e q u e sts ch a n g e to e xistin g
vie wN o
N e w o r ch a n g e d te r m s
N o
A r tifa cts r e q u ir e d b y co r e p r o ce ss
g o ve r n a n ce
A r tifa cts in clu d e d in e xistin g vie w
S u b se t r e q u ir e d b y C P g o ve r n a n ce
R e q u e st d e le te a r tifa cts fr o m vie w
Y e s
Y e s
Y e s
P r o p o se C R a s R e je cte d
D e le te vie wN o tify C P
g o ve r n a n ce o f ch a n g e to o th e r
vie w
N o
D e le te a r tifa cts
fr o m vie wN o
A r tifa cts r e q u ir e db y co r e p r o ce ss
g o ve r n a n ce
A r tifa cts in clu d e din e xistin g vie w
S u b se t r e q u ir e d b y C P g o ve r n a n ce
N oN e w o r ch a n g e d
a r tifa cts
D D P r o ce ss
R e la tio n sh ip P r o ce ss
Y e s
N o
N o
C o n siste n cy , a lia s , o th e r Q A o r
vie w d e scr ip tio n style g u id e issu e s
P r o p o se C R a s D o n e
C R W G r e vie w
A ll a r tifa cts d e le te d ?
D e le te vie w
Y e s
P r o p o se C R a s R e je cte d
N o
N o
Y e s
N o
N o
N o
N o
N o
CR requests new term or definition change
CR requests DM2 relationship change
New relationship
Evaluate restitch impact : what
definitions and other rqmts effected
Can a supertype be determined
Determ ine supertype using BORO analysis
Should it be an alias ?
Collect source definitions and
enter in DD
Review and pick or formulate
definition
New or alias?
Enter mapped terms
Determ ine relationships in
DM2
Determ ine supertype using BORO analysis
Negative impact
Yes
NewAlias
No
No
Yes
AlternativesYes
No
Prpose CR as Rejected
Make change to DM2
Yes
NoAdd as alias to DD
Make change to DM2, add to DD,
and define
No
Yes
Yes
No
ST ART
END
END
DD Process
Relationship Process
CR WG review
Record:Date of WG
approval
Update status (defer, reject, in-progress) and, if necessary,
CoA and actionee(s) Restatus as “in progress”
for next version
Prepare for technical cutoff:
§ CR’s actionee(s) consider complete & ready for WG review
§ CR’s in progress§ FAC redirects
Conduct Technical Cutoff Meeting
Call for “done” actionee(s) to brief their CRs
Present solution and discuss
Majority present agree?
Yes
No
Call for “in progress”
actionee(s)
Provide status of solution(s)
Can make cutoff and / or priority for
version
Minority member non-
concurr?
Report non-currence to
FAC
NoYes
Yes
Report to FAC:§ CR’s “done”
for version§ CR’s
planned for version
§ Version release timeline & any issues
FAC vote to redirect?F
AC
CI &
CR
C
usto
dian
CR
Ori
gin
ator
s an
d
Act
ione
e(s
)F
CM
Yes Update date of status update
FAC vote to re-prioritize?
Yes
Technical cutoff & no FAC re-
prioritizations or redirects
No
Monthly
Bi-weekly
FAC vote to redirect?F
AC
CI &
CR
Cus
todi
an
CR
Origi
nat
ors
and
Act
ione
e(s
)FC
M
Conduct production of
draft for Component
review: document,
IDEAS model, XSD, VDD
Conduct QA: tech edit,
IDEAS tools , XML tools
Request entry of draft version into
SACP & tasker to
Components to review
Issue tasker for Component review
Collect Component comments
Re-status affected CR
Facilitate normal CR
processing of re-statused
CR’s
Report to FAC
Yes
All comments resolved & no FAC redirects
No
Conduct production of
final: document,
IDEAS model, XSD,
VDD
Conduct QA: tech
edit, IDEAS tools,
XML tools
Post to DoDAF
website & MDR;
deprecate prior version
Archive “dones”
Request promulgation
notice
Notify Components
of new version
Technical cutoff & no FAC re-
prioritizations or redirects
Yes
Yes
Monthly
88
CMP Business Rules
1. Terms and Definitions2. Aliases3. Core Process Requirement4. Aggregation Rule5. Subtype Rule6. Typed Relationships7. Attributes and Properties8. DoDAF Model Specification9. Information Pedigree10.Security Classification Marking
99
DoDAF-DM2 WG Status:Change Request Status
DM2 DoDAF Journal High Med LowOBE 2 2 0 0 0 0 2
Defer to 2.04 52 46 6 0 11 30 11In Progress for 2.03 40 22 17 1 0 21 19
Unassigned 99 57 37 5 4 55 40Consult IDEAS Group 20 18 2 0 7 8 5
Defer 92 87 5 0 41 23 28In Ver 2.03 43 39 3 1 0 3 40
Rejected 4 2 2 0 1 3 0In Progress for Journal 5 0 0 5 0 4 1
No Action Required 0 0 0 0 0 0 0
CI LOE
1010
Packaging for Formal CM
• Vol. I– DM2 Conceptual Model– DoDAF Viewpoints & Models
• Vol. II– DM2 Logical DM– DoDAF Model Specs– DoDAF Glossary– SparxEA .EAP DM2
• Vol. III– DM2 Physical DM: PES– SparxEA .EAP IDEAS Foundation
11
• TECHEDITS• Normative parts separated from informative parts
– Normative parts subject to formal coordination with DoD Components– Informative parts moved to DoDAF Journal
• Document + Webpages • Major DM2 CR’s:
– Rules and Desired Effects:1. Their Descriptions are produced by rule and goal-setting authorities2. They are consumed by Activities (ala Controls in IDEF0)3. Conforming Activities are subtypes
– Information resource flow was simplified into flatter type structure so it would be logically correct and consistent with other Resource Flows, e.g.,
• Aircraft 123 on my scope {all reports on A/C 123} {TADIL-J 3.2 msg}
– Capability made a subtype of Property so that it is the set of Tasks performed under Conditions that meet certain performance standards (Measures)
• Makes Capability comparison and dependencies more direct (simple set operations)– Distinguished that Guidance influences Activity from Rules that control Activity– Added SoA Joint Action concept– Continued work on distinguishing Roles (within scope of EA) from types of Persons
(outside scope of EA)
11
Changes for v2.03
exists spatio-temporally a set usable in, e.g., SV-6
1212
Marine Corps - Led TECHEDIT Team
• Marine Corps commented on many incorrect, ambiguous, and inconsistent statements– After working on this for several meetings, the WG
requested a rewrite rather than line-by-line fixes
• SPAWAR noted many undefined and inconsistent terms in the DoDAF model
• A long-standing CR asked for a DM2 diagram for each DoDAF model as in DoDAF 1.x documents
1313
TECHEDIT Team Rules
• Must follow DoDAF-DM2 WG rules (per CM Plan)
• Structure of each model specification:– Name. The twenty-four revised names agreed to by the WG
under CR #579 shall be used.
– One Sentence Description. The twenty-four revised “one-liners” agreed to by the WG under CR #579 shall be used.
– Narrative Description (one page maximum). DoDAF Glossary terms (in DM2 or aliases) shall be used per DoDAF-DM2 CM Business Rule #8.
– Meta-model diagram (one-half to one page).
– Other Names for this artifact (one-quarter page).
14
OV-2 As-Is
Text is lengthy…but doesn’t actually ever get around to unambiguously specifying content for an OV-2 model…
1515
TECHEDIT Example (pg 1 of 2)
SHALLS & MAYS
3.5.3 Organizations and Resources (OV-2)
a. Description. This model identifies and describes resources consumed and produced by activities performed by organizational-performers.
b. Narrative. This model emphasizes the exchange of resources among organizational performers, that is, performers capable of responsibility. These resources include information, materiel, and performers. The dependency between a resource to be consumed by one activity and a resource produced by another activity may be described as the flow of resources from producer to consumer. Activities are modeled in OV-2 models only in detail sufficient to show the relationships between resources produced by the activities of one organizational performer and the resources consumed by the activities of other organizational performers.
c. Activities are seen in OV-2 models much as they are in other DoDAF models. An activity consumes resources to produce resources. Performers in OV-2 models are resources who are capable of responsibility rather than resources that are materiel, systems, or services. Such performers—organizations and persons in roles—follow guidance, rules, and standards to carry out their activities. Performers carry out their activities under conditions that affect their performance.
d. Performers and other resources are related to their locations to ensure that resources to be consumed are available to activities when and where those resources are needed and that performers are there to carry out those activities when those resources are available.
e. Activities and resources may be measured. Guidance of various sorts may refer to types of applicable measures, and specific measures for specific activities may be drawn from such guidance.
f. Activities and resources shall be modeled. In particular, resources that are information shall be modeled. Types of organizations shall be modeled; specific organizations may be modeled. Persons in roles may be modeled. Types of locations of resources may be modeled, and specific locations may also be modeled. Rules and conditions may be modeled. Measures related to activities, resources, performers, locations, rules, and conditions may be modeled.
1616
TECHEDIT Example (pg 2 of 2)
g. Meta-model. Figure 3.5.3-1 shows the DoDAF meta-model for OV-2 models.
Figure 3.5.3-1: DoDAF meta-model diagram for OV-2 models
h. Alternate names: Operational Resource Flow Description; Organizational Resource Flows Identification.
i. Notes. (a) The architectural data of an OV-2 model may be grouped and ordered by organizational-performers who perform activities that produce resources. (b) The architectural data presented by an OV-2 artifact is typically a subset of the architectural data presented by an OV-3 artifact. Activities and measures may be de-emphasized by an OV-2 presentation.
class OV-2
Activity
Resource
Performer
activityConsumesResource
activityPerformedByPerformer
activityProd ucesResource
PersonRole
Individua lResource
Organiza tionType Organization
IndividualPerformer
PerformerCapableOfResponsibility
Information
resourceInL ocationTypeLocationType
ruleConstrainsActivityRule
ConditionactivityPerformab leUnderCondition
Measure
+ numericValue: stringmeasure OfType
Can apply to any of the core elements
Location
17
• Name: Systems Interface Description• One liner: The identification of systems, system items, and their interconnections.• Description:
– composition and interaction of Systems– links together the operational and systems architecture models -- a SV-1 may represent the realization of a requirement
specified in an OV-2 – there may be many alternative SV models that could realize the operational requirement. – in an “As-Is” architecture, the OV-2 may simply be a simplified, logical representation of the SV-1 to allow communication of
key Resource Flows to non-technical stakeholders. – A System Resource Flow is a simplified representation of a pathway or network pattern, – Note that Resource Flows between Systems may be further specified in detail in SV-2 Systems Resource Flow Description
and SV-6 Systems Resource Flow Matrix.– Sub-System assemblies– SV-1 may also identify the Physical Assets (e.g., Platforms) at which Resources are deployed– optionally overlay Operational Activities and Locations – In many cases, an operational activity and locations depicted in an OV-2 may well be the logical representation of the
resource that is shown in SV-1.– The SV-1 is used in two complementary ways:
• Describe the Resource Flows exchanged between resources in the architecture. • Describe a solution, or solution option, in terms of the components of capability and their physical integration on
platforms and other facilities. • Detailed Description:
– Systems and sub-systems – The real benefit of a SV-1 is its ability to show the human aspects of an architecture, and how these interact with Systems. – Capability and Performers which is used to gather together systems, assets and people into a configuration, which can meet a
specific capability. – A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary sub-systems,
performer and activities (functions) and their interactions. – SV-1 contributes to user understanding of the structural characteristics of the capability.– The physical resources contributing to a capability are either an organizational resource or a physical asset, i.e., a system
cannot contribute alone (it must be hosted on a physical asset used by an organizational resource of both). – Organizational aspects can now be shown on SV-1 (e.g., who uses System). – Resource structures may be identified in SV-1 – DoDAF does not specifically use terms such as, sub-System and component as these terms often denote a position relative to
a structural hierarchy. – Any System may combine hardware and software or these can be treated as separate (sub) Systems. DoDAF V2.0 includes
human factors (as Personnel Types and a type of Performer). Should an architect wish to describe a System which has human elements, then Systems, Personnel Types and Performers should be used to wrap the human and system elements together.
– optionally be annotated with Operational Activities, Capabilities, and/or Locations originally specified in OV-2
SV-1 Issues Identified by DoDAF WG
• Every phrase analyzed contains problematic terms or expressions that are:– not defined
– used mysteriously
– inconsistent within this description or across the document
– ambiguous
– vague
– suggest content exists elsewhere that does not exist
– logically, operationally, or technically wrong
Spotlight on synopsis prepared by DoDAF WG. Highlighted words were found to be problematic.
18
SV-1 Content Guidance for Template and Descriptions
• Several distinct pieces are currently described. They should be refactored:1. SV-1a Interface Description. The SV-1a shows interfaces (Resource Flows)
between Systems, Services, and/or Person Types.
2. SV-1b Perfomer Configuration Diagram. Interface Description plus composition (whole-parts) of Resources involved. If Locations are involved in the configuration, relationships to Resources.
3. SV-1c Functional Allocation. Activities (System Functions) performed by Systems, Services, and Person Types.
4. SV-1d Organizational Resources. Shows Resources that are part of (whole-part) Organizations.
5. SV-1e Organizational Dependencies. Shows Organizations whose Activities are reified by System Functions (Activities) performed by Performer Configurations.
6. All views should show traceability to higher-order reifications, other views that constitute requirements, and/or other non-view requirements. This should be restated for just about every model.
7. Systems relationship to Capabilities – already in SV-5.
19
To-Be SV-1a
•Refocused to be a model of system interfaces
(SV-1a)
2020
DoDAF v2.03 Release Plan
Task Name
Start New Baseline
Process CR's for new baseline
Begin Technical Cutoff
Technical Cutoff Process
Technical Cutoff
DRAFT Baseline Production
DoD CIO Internal Review
DCIO Comments Adjudication
DRAFT Revision
DRAFT Baseline Entry in SACCP and Formal Review Taskerto Components
Component Review
Component Comments Adjudication
Revision and Production
ASRG Approve 2.03 Baseline
Publish and Promulgate New Baseline
Begin Processing CR's for Next Update (2.04)
9/1
10/20
11/17
9/24
9/24
Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep OctQtr 3, 2010 Qtr 4, 2010 Qtr 1, 2011 Qtr 2, 2011 Qtr 3, 2011 Qtr 4, 2011 Qtr 1, 2012 Qtr 2, 2012 Qtr 3, 2012 Qtr 4, 2012
21
Next: Systems Engineering and Architecture Harmonization and
Efficiency
SystemO & M
System Validation
System Verification
Subsystem Verification
Component Verification
Component Design
SystemDesign
Prototyping
MSA
CBAValidation &
Verification
Build
Acquisition Model Decisions & Milestones
CMMIProcess Areas
Requirements Development (RD)Requirements Management (REQMTechnical Solution (TS)Product Integration (PI)Verification (VER)Validation (VAL)
TEMPcapabilities
TEMPoperational
TEMPsystemStdV
AV
CV
DIV1OV
DIV2
DIV3
StdVDIV2
Unit Test
SwDD; IDD; DBDD
SvcVSV
SvcVSV
SwRS; IRS
SDD
RD
REQM
TS
VER
VAL
PI
MS-A
SRR
SFR
MS-B
CDR
TRR
SVR
MS-C
Typical Systems Engineering Work Products
• System Requirements Document (SRD) / Technical Requirements Document (TRD) / System Segment Specification (SSS)
• System Design Document (SDD) / System Segment Design Document (SSDD)
• Software Requirements Specification (SwRS)
• Software Design Document (SwDD)• Interface Requirements Specification
(IRS)• Interface Control Document (ICD) /
Interface Design Document (IDD)• Data Base Design Document (DBDD)• Test and Evaluation Master Plan (TEMP)
PDR
Technology Development (TD)
Engineering &Manufacturing Development (E&MD)
Capabilities Based Assessment (CBA)Material Solutions Analysis (MSA)
System Engineering Technical Reviews
System Requirements Reviews (SRR)System Functional Reviews (SFR)Preliminary Design Reviews (PDR)Critical Design Reviews (CDR)Test Readiness Review (TRR)System Verification Review (SVR)
DoDAF ViewpointsAll (AV)Capabilities (CV)Operational (OV)Data / Information (DIV)Systems (SV)Services (SvcV)Standards (StdV)
JCIDS DocumentsInitial Capabilities Doc (ICD)Capabilities Design Doc (CDD)Capabilities Production Doc (CPD)Information Support Plan (ISP)
SRD
CDDfinal; ISPfinal
CDDprelim; ISPprelim
CPD
ICD
Notional Systems Development “V”
2222
Questions?