The Human View Handbook for MODAF: Part V â Appendices

More documents

Recommendations

Info

The Human View Handbook Part 5: Appendices View OV- 4 OV- 5 OV- 6a OV- 6b OV- 6c OV- 7 DoDAF Title Organisational Relationships Chart Operational Activity Model Operational Rules Model Operational State Transition Description Operational Event Trace Description Logical Data Model MODAF Title Organisational Relationships Chart Operational Activity Model Operational Rules Model Operational State Transition Description Operational EventTrace Description Information Model Comments on perceived function • Mainly specifies formal human organisational structure, based on existing ones to a large extent. • Primarily defines organisational units and their command relationships in a hierarchical way • May extend to role level definitions (at later stages of framework). • Besides command relationships, it may include different types of relationships: • Organizations with a primary role and those with a supporting role (DoDAF); • Coordination or other specified relationship (MODAF). • Includes both hierarchical breakdown presentations and flow presentations. • For requirements engineering, MODAF suggests that operational views are intended to be independent of (technical) solutions. The focus should be on requirements rather than constraints. Solutions are, in the operational perspective, to be seen as constraints. • Is encouraged to draw on high-level mission-specific paradigms such as Detect/Control/Engage. • May be detailed using standard operational activities (e.g. from (US) Universal Joint Task List (UJTL) or Servicesderived task lists). • Captures activity constraints from an operational perspective, through the identification of rules that deal with constraints. • Is not intended to be at the level of detailed human activity. • There is a notion of dynamic behaviour in the identification of IF/THEN rules. • Further specifies information from OV-1, and closely relates to and extends OV-5. • There is no UML representation; Textual rules may be attached to OV-5 diagrams; Operational rules can be expressed in a number of different formats: e.g. structured English; decision tree. • Models behaviours through describing transitions. • Represents a dynamic analysis, simulation tools are recommended in DoDAF (e.g. Colored PetriNets). • Captures action sequences in relation to conditional and state changes that underlie rule definitions. • Captures alternative event/action flows for different conditions. • Captures elements of larger flow, defined through beginning and end point. • State is understood as an action lasting until a certain output/trigger has been reached that triggers the next action. • Cognitive tasks (e.g. planning strike) may be included with an outcome (planned strike), without going to detail of modelling underlying cognition. • They may be related to nodes, but appear to be understood as human activities (person or organisation). • DoDAF suggests use for workload assessments. • Time information is added for more detailed descriptions of operations. • Does not describe tasks as a whole but specific scenarios. • Deals mainly with timely availability of information for (human) nodes and tasks. • Describes ‘operational threads’ that further define capabilities. • Describes events (i.e. information communication events) and times at which ‘nodes become aware of the events’. • Includes sequencing/precedence, actual time descriptions, logical conditions, and timing constraints. • Depicts directions for the flow of control from one node to another. • May include ‘junctions’ that describe decision logic that may lead to several subsequent path options. • Specifies system information needs, as a basis for system specification. • Defines operational rules that govern system data (types, characteristics, relationships). • Classification of the information types being used as part of the system – i.e. business information requirements specification. • Supports interoperability through common standardised definitions of data types to be produced, exchanged, and used. • Defines new data: “may be necessary for interoperability when shared system data syntax and semantics form the basis for greater degrees of information systems interoperability, or when a shared database is the basis for integration and interoperability among business processes and, at a lower level, among systems.” page 10
The Human View Handbook Part 5: Appendices View SV- 1 SV- 2 SV- 3 SV- 4 SV- 5 DoDAF Title Systems Interface Description System Port Specification Systems- Systems Matrix Systems Functionality Description Operational Activity to Systems Function Traceability Matrix MODAF Title Resource Interaction Specification 2a System Port Specification 2b System Port Connectivity Description 2c System Connectivity Clusters Resource Interaction Matrix Functionality Description Function to Operational Activity Traceability Matrix Comments on perceived function • Defines the system elements to be used to fulfil the information needlines between operational nodes defined in OV2 (i.e. technical instantiation of nodes and needlines). • Specifies system nodes that correspond to operational nodes (and may be identical); MODAF defines the concept of ‘Physical Asset’ that are instantiations of Nodes; DoDAF defines ‘System Node’: “The term System Node describes a logical or physical deployment for Operational Nodes – e.g. locations, Platforms, units, facilities, etc”. • Identifies system boundaries, and breaks down systems into system elements. • Identifies hardware and software needs, and their relationships based on communication links between resource elements (i.e. system interfaces). • Systems are understood as interconnected technology: ”The term system … is used to denote a family of systems (FoS), system of systems (SoS), nomenclatured system, or a subsystem. An item denotes a hardware or software item”. • DoDAF does not distinguish a,b,c; is most like the MODAF SV-2c. • SV-2 defines specific communication links or communication networks between systems, thus adding more detail to SV- 1 (“comprehensive specification of how systems are connected,”); seen as key for NEC strategy: “quickly plan and visualise how communications between systems are to be implemented”; details abstract specifications. • SV-2a defines the hardware/software that communicates between technical system components. • SV-2b specifies how the protocols connect the ports, and shows which systems they connect; May be all in one diagram or a set of diagrams: “The architect may choose to create a diagram for each connection in the Architecture (recommended) or to show all the connections on one diagram (may be harder for readers to follow)”. • SV-2c provides a grouping of system-to-system connectivity into node-links (i.e. clusters) – thus abstracting back to a functional perspective; e.g. node-link may be ‘situational awareness’ ‘operational feedback, ‘e-mail’; No detail is given as to how the groupings should be derived; Helps to assess specified communication networks regarding redundancy and performance by considering constraints: “… to identify redundancy in the system of systems, and to reduce the number of point-to-point connections that need to be maintained (thereby reducing maintenance and support costs). This View can be used to assess network performance needs, and again shows external system constraints”. • Provides an overview of the interfaces identified in SV-1, and draws attention to important ones (‘key’). • Specifies different types of relationships depending on purpose of representation: “examples: a. Status, (e.g., existing, planned, potential, deactivated), b. Purpose, c. Classification level, d. Means, e. Standard, f. Key Interface”. • Alternatives are encouraged: “These are constraints based on existing systems, and alternatives should be considered when deciding on the solution: this View should not in itself provide the solution design”. • Combines a functional breakdown into subcomponent functions with functional flow describing system behaviour. • Describes functional level only – not embodiment: “is used to show what functions the system must be able to perform, not how it is to perform them, as that will be up to the system designers to determine.” • “Actors in systems use case diagrams may represent a mix of both the humans supported by the system functions …and other systems external to the system being described but not necessarily external to the architecture.” • “System functions are not limited to internal system functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions.” • “Class diagrams are used to show static relationships between system functions. These diagrams collectively describe the systems support to the operational activities and operational use cases modeled in OV-5”. • Provides a matrix that traces the reasoning behind the definition of system functions to the operational needs (i.e. the activities/operational functions that are needed by the joint system). • Operational activities should not be understood here as human tasks (whilst they need to be supported by human functions). • May be used as mapping between URD and SRD items. • Provides a link between OV-5, 6b, 6c and SV-4: “Although there is a correlation between ... (OV-5) or business-process hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for... (SV-5), which provides that mapping”. page 11
Page 1 and 2: The Human View Handbook for MODAF:
Page 3 and 4: The Human View Handbook Part 5: App
Page 11: The Human View Handbook Part 5: App
Page 55: HFIDTCPIII_T02_02e Version 2/ 11 Au

The Human View Handbook for MODAF: Part V â Appendices

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?

The Human View Handbook for MODAF: Part V â Appendices