The Human View Handbook for MODAF: Part V – Appendices

The Human View Handbook
Part 5: Appendices
View
SV-
6
SV-
7
SV-
8
SV-
9
SV-
10a
SV-
10b
SV-
10c
SV-
11
DoDAF Title
Systems Data
Exchange Matrix
Systems
Performance
Parameters
Matrix
Systems
Evolution
Description
Systems
Technology
Forecast
System Rules
Model
Systems State
Transition
Description
Systems Event-
Trace
Description
Physical
Schema
MODAF Title
Systems Data
Exchange Matrix
Resource
Performance
Parameters
Matrix
Capability
Configuration
Management
Technology &
Skills Forecast
Resource
Constraints
Specification
Resource State
Transition
Description
Resource Event-
Trace
Description
Comments on perceived function
• Physical detailing and specification of data exchanges: “For example, the Levels of Information Systems Interoperability
(LISI) level required for the operational information exchange is replaced by the LISI level achieved through the system
data exchange(s)”.
• Specific step after a series of system specification steps based on SV-1, SV-2 and OV-3:
• “On SV-6, each operational Needline is decomposed into the interfaces that are the systems equivalents of the
Needline”.
• “The system data exchanges documented in SV-6 … constitute the automated portion(s) of the OV-3 information
elements”.
• Specifies achievement criteria of system elements, system functions, and interfaces.
• Focus is on identifying parameters that are measurable.
• Relates current performance parameters to future ones for different timescales.
• Basis for acquisition decisions and product assessments.
• May include performance range – thresholds, objectives, measures (e.g. time/speed).
• May include parameters for ISO software quality criteria (maintainability, effectiveness).
• Defines project milestones for system development over large timescales of operation.
• Distinguishes evolution and migration:
• Planning aid for system’s time scopes in operation from a technical constraint perspective;
• Expressed as timeline annotated with milestone descriptions and system version numbers;
• Recognises that system design is not final after initial implementation and further adaptations are required.
• Tracks new technologies that will become available: “Emerging technologies and software/hardware products that are
expected to be available in a given set of time frames and that will affect future development of the architecture”.
• Within the bounds of architecture purposes being described.
• MODAF now includes notions for availability of skills through actual human resources.
• Applies to system rules only: “The Systems Rules Model (SV-10a) has the same format as the Operational Rules Model
(OV-6a); however, the scope and applicability of the rules here are for individual systems, where OV-6a applies the
architecture as a whole”.
• Few examples are given and the expression is fairly open: “UML constraints are a direct analogue and have been
stereotyped to “SystemConstraint””.
• Rule types are given: “Systems rules can be expressed in natural language, as with OV-6a:
a. Imperative – a statement of what shall be under all conditions – e.g. “B shall be less than 6.0”
b. Conditional Imperative – a statement of what shall be, in the event of another condition being met – “If B is equal to 4
then A shall be true”.
• DoDAF users specified are Designer/ Builder/ Contractor only.
• Dynamic description of actions by specifying sequences related to conditional events triggering actions and state
changes; Focus is on graphical representation.
• Closely related to other SV-10 products: “Both SV-10b and SV-10c describe systems responses to sequences of
events. Events may also be referred to as inputs, transactions, or triggers.”
• Can be presented at different levels of abstraction.
• Closely relates to scenarios and focuses on critical sequences of events only: “allows the tracing of actions in a scenario
or critical sequence of events”.
• Adds an explicit time dimension.
• Includes interactions with human roles, thus specifying activities at human-computer interfaces.
• Deals with assessments of information availability and communication activities.
• At a low level of detail.
Physical Schema • Solution design, not requirements anymore: “closest to actual system design in the Framework”.
• Format may vary.
• Specifies options.
• Besides specifying solutions to OV-7, it relates to other SV products: “Object classes defined here should trace to (a)
system data flows in SV-4, (b) system data elements specified in SV-6, (c) transition triggers in SV-10b, and/or (d)
events in SV-10c”.
page 12