Human View Development and DoDAF 2.0 Integration

1. Human View DevelopmentandDoDAF 2.0Integration Robert J. Smillie, PhD, CPE SPAWAR 5.1 robert.smillie@navy.mil

2. Outline • Describe how Human View evolved. • Define and summarize Human View products. • Describe a case study using data from system development effort to build Human Views. • Provide a short plan for including Human View as part of the Department of Defense Architecture Framework (DoDAF) ================================================================================================================= • Backup Material • SAR Example with some Human View inserts • Definition and Information Requirements for each Human View • Human View and DoDAF Mapping • Human View Example – HV-E - - Human Networks

3. Background • Architecture frameworks: • Common approach for development, presentation, and integration of architecture descriptions • Mechanism for understanding and managing complexity • Systems Engineering tool • Current frameworks fail to capture the human-centered design aspects needed to ensure the effectiveness of human operated systems. Technical Systems Human Operational • With advent of DoD Architecture Framework 2.0 opportunity exists to fully integrate human centric viewpoint.

4. Emergence of the Human View • Early efforts focused on human role and activities analysis (Hildebrand and Adams, 2002) • Canada and United Kingdom added human related actions to architecture frameworks (Baker et al, 2006; Bruseberg, 2008). • NATO Research and Technology Organization (RTO) Human Factors and Medicine (HFM) Panel 155 developed human view structure – Handbook and Quick Start Guide

5. Human View (HV) • Combination framework and process to assist acquisition Program Managers and system engineers to map out range of human performance within a system, and then simulate impact of human and system changes over time. • Serves as effective methodology for Human Systems Integration (HSI) practitioners coordinating and collaborating with systems engineers.

6. Why the Human View? • The Human View is an architecture viewpoint that focuses on the human as part of a system. • What does it do? • Organizes information into a framework about how the human functions in the system in order to model the impacts of human performance from tasks, personnel, and system resources. • What does it provide? • A set of products which captures information on Human Capabilities, Constraints, Tasks, Roles, Networks, Training, and Metrics, which are integrated with a dynamic model used to determine human risk. • What is the value added? • Provides more complete representation of mission effectiveness by including human capabilities and limitations as an integral part of the system design.

7. Human View Products

8. Human View Case Study • NATO Human View Quick Start Guide was used to represent tradeoffs within the Army’s Infantry Brigade Combat Team (IBCT) system (Formerly FCS). • Selected Improved Performance Research Integration Tool (IMPRINT) to simulate human dynamics • Stochastic task-network modelling tool to help assess interaction of people and system performance from concept and design through field-testing and system upgrades. (Mitchell et al, 2008) • Enables evaluation of mental workload while testing alternate system-operator function allocations. (Wickens, 1991). • Human View data products used to populate IMPRINT.

9. IMPRINT Model and Human View Products

10. IMPRINT/HV-H Results • Baseline simulation successfully provided initial levels of mission performance time and accuracy. • Subsequent model runs showed a distribution of performance and workload measures, based on personnel, CONOPS, technology factors. • Some tasks in alternative model configurations did not meet the IBCT accuracy standards. • High workload and cognitive resource conflicts triggered drill-down to explain task accuracy shortfalls.

11. Take-Away from Case Study • Human View methodology provides a fully integrated set of products that ensure an effective and efficient design, development, and production process. • Case study demonstrated that Human View data for a complex system, such as IBCT, can be used to assess design impacts when combined with a simulation tool, such as, IMPRINT.

12. Net Effect of a Human View • Human View products facilitate a more structured language for communicating with other disciplines, particularly, systems engineers, during system development. • HSI practitioners can use Human View methodology to provide a fully integrated set of products that ensure an effective and efficient design, development, and production process. • Human Views can be used for communicating enterprise behavior. It is important for capturing the “as-is” and assessing design decisions implications of the “to-be”.

13. Further Information • RTO TECHNICAL REPORT TR-HFM-155, Human Systems Integration for Network Centric Warfare (Intégration des systèmes humains dans les opérations réseaux centrées), AC/323(HFM-155)TP/287, February 2010. • NATO Human View Handbook: A compendium of the development of the NATO Human View. • NATO Human View Quick Start Guide: Descriptions, examples and templates for practitioners. • Systems Engineering Journal: • Architecture Framework Human View: The NATO Approach Handley, H.A.H., & Smillie, R.J. (2008). Architecture framework human view: The NATO Approach. Systems Engineering, 11(2), 156-164. • Human View Dynamics – The NATO Approach Handley, H.A.H., & Smillie, R.J. (2009). Human View Dynamics - The NATO approach. Systems Engineering, 13(1).

14. Way Ahead: Tasks HV-G HV-C • Integrate the Human View with DoDAF. • Participate DM2 WG • Conduct workshops to identify gaps • Complete the data model for the HV. • Identify Data Elements and Product Renderings and map context of HV • Apply to an acquisition program and execute simulation models. • Demonstrate how HV augments SE process • Define ROI Human View Integration with DoDAF 2.0 Concepts HV-G (2) Data Concepts Data Concepts Activity, Domain Information, Resource Activity, Performer, Resource Operational Activity Model OV-5b (Taxonomy) Op Activity toSys FunctionTraceability Matrix SV-5a (Mapping) Model Performer, Resource Decomposition Organizational Relationships Chart OV-4 (Structural) Activities Activity ResourceAllocation Tasks HV-C A part of HV-C/D (20) ArchitectureRepresentation None Listed Role Locations High Level Operational Concept Graphic OV-1 (Pictorial) Specialization Concept HV-A Responsibilities Roles Representation Human Roles HV-D HV-G (22) Relationships Teams, Interactions Activity, Performer, Resource Performers Organizational Structure IT Structure Operational Resource Flow Description OV-2 (Structural) Requirements, Limitations Organization Human Networks HV-E Information IMPRINT HV-F HV-D HV-E (22) HV-E (34) Task Network HV-D (32) HV-A HV-E

15. Backup

16. DoDAF 2.0In ActionSearch and Rescue (SAR) Example with some Human View inserts

17. Step 1 - Determine Intended Use of Architecture • Find ways we can reduce cost to meet new budget restrictions using enterprise architecture data • Use analysis methods for time and cost and human role • Examine data and dependencies of “search” • What is highest value that could be gained for this effort? • Build “search” architecture outwards • Establish foundation for future optimization Our primary intent is to understand costs associated with “search” and look for any anomalies that may reveal a way to cut costs without reducing efficiency…

18. Step 2 - Determine Scope of Architecture • Limit to Coast Guard specific SAR • Focus on “search” aspect of SAR through capability and functional analysis • Define AS-IS (current only) capabilities • Identify and focus on elements that have a high cost (time and money and people) • Phase 1 of EA development will provide enough “depth” to discover possible vulnerabilities that require future optimization

19. High Level Operational Concept Graphic (OV-1/ HV-A) • Definition: Scenario from a conceptual level. • Main operational concepts • System and operational (human) interaction • Pictorial depictions of the system and its human component. • High level indicators of where human system interactions may occur. • Textual descriptions of the overall human component of the system. • Use cases which describe the human process. • Data Sources: Mission Statement, Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document • Purpose: Provide high-level description of what the architecture is supposed to do and how it is supposed to do it. Provide a conceptual, high-level representation of the human component of the enterprise architecture framework. Its purpose is to visualize and facilitate understanding of the human dimension in relation to operational demands and system components. • Analysis: Find costly and burdensome capabilities that others are dependent upon for speed and reliability. Identify human interfaces that may be bottlenecks. • Consumers: • Executive Level Stakeholder • Enterprise Architect • Program Manager • General Stakeholder

20. SAR High Level Operational Concept Graphic (OV-1) Potential Human Interfaces

21. High Level Operational Concept Graphic (OV-1) • Disaster occurs (person is in distress) • Emergency beacon is activated • Signal is picked up by other ships and satellites • Signal received by Mission Control Center • Operators perceive signal • Decision maker decides to act on signal • Search team analyzes signal for location • Alerts RCC • Initiates search pattern • Rescue Coordination Center dispatches search and rescue team • SAR team tracks signal • Debrief and “lessons learned”

22. Step 3 - Determine Data Required to Support Architecture Development Human abilities and limitations

23. Step 3 - Determine Artifacts Required to Support Architecture Development • Operational (Human) Process (OV-6) • Human Processes, Rules and Data • Human Elements (HV-C, D, E, H) • Tasks, Roles, Networks involving humans • System Process (SV-10) • System Processes, Rules and Data • Overview and Summary Information (AV-1) • Scope, Goals and Purpose • Capability Vision (CV-1) • Goals, Purpose, and Capability dependencies • Capability Taxonomy (CV-2) • Capability Dependencies • Capability to Activity Map (CV-6) • Capability and Functions of Scope A number of other supportive views were created to understand and define the entire SAR program – only ones relevant to the demonstration thread are listed

24. Step 4 - Collect, Organize, Correlate, and Store Architectural Data • Data was collected using tools that can capture all data to support DoDAF 2.0 views • Worked with operational and system team (including HSI practitioners) to gather information to create views • Data was stored in a repository that supports robust storage and analytical capabilities • Data was collected through screen entry and import

25. Operational (Human) Process Model (OV-6) • Definition: Models the timing and sequencing of events that capture operational behavior of an process or function. • Purpose:Traces actions in a scenario or sequence of events • Data Sources: Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document • Analysis: • Cost and timing of process • Process dependency on logical data and state changes • Consumers: • Enterprise Architect • Program Manager • General Stakeholder Include Human Views

26. SAR Operational Process Model – Perform SARSAT Search (OV-6) This may not be the best way to represent humans in all situations. Time and cost data is for illustrative purpose only and does not reflect real values. • Considered? • Human SA that disaster occurred • Human decision-making process Supportive Data Most expensive process Human(s) represented as Pool Is there amplifying information available to narrow this? Gateway Process Using supportive data (as mandated in DoDAF 2.0) we can see this process seems to be taking too long and thus costing too much money.

27. Tasks(HV-C) • Definition: Describes the human-specific activities, i.e., the tasks that have been assigned to the humans in a system over its entire life cycle. • Purpose:Traces actions and identifies responsibilities in a scenario or sequence of events. It considers how the functions are decomposed into tasks and the dependencies between tasks. • Data Sources: Task Analysis, Subject Matter Expert (SME) Interviews, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document • Analysis: • Cost and timing of process • Process dependency on logical data and state changes • Human-related functions in a system • Allocation of functions between humans and machines • Decomposition of functions into tasks • Task descriptions in terms of various criteria and the KSA requirements • Depiction of the inter-dependencies between different tasks • Consumers: • Enterprise Architect • Program Manager • General Stakeholder

28. SAR Tasks – Mission and Search (HV-C) KSA Matrix Task Dependencies 1 + Ship-A/C? Roles Matrix Crew Workload? Task Criteria

29. Step 5 – Conduct Analysis in Support of Architecture Objective • Multiple types of analyses are available to an architectural effort with two primary categories: • Static analysis leverages model structure and attributes to derive qualitative, quantitative and functional analyses • Dynamic analysis (executable models) examine temporal, spatial, or other performance aspects of a solution through dynamic simulations • Static analyses were performed using analysis tools through database queries for function and quantity • Static HVs • Provide a model of the impacts of human performance from tasks, personnel, and system resources. • Captures information on Human Capabilities, Constraints, Tasks, Roles, Networks, Training, and Metrics. • Need HV-H Dynamic View • Design decisions recorded in the static HV-A to G should be assessed through a dynamic evaluation of human system performance. • Trade off analyses should be conducted to determine the impact of system parameters on human performance metrics. • Data are entered into models through user interfaces and underlying human performance algorithms are employed to perform simulations. • Model outputs can be used to predict the impact of design decisions on the performance of the operators of a system.

30. DefinitionandInformation Requirements for eachHuman View

31. HV-A • Concept View (HV-A) Concept is a conceptual, high-level representation of the human component of the enterprise architecture framework. Its purpose is to visualize and facilitate understanding of the human dimension in relation to operational demands and system components. Information Requirements • Pictorial depictions of the system and its human component. • High level indicators of where human system interactions may occur. • Textual descriptions of the overall human component of the system. • Use cases which describe the human process.

32. HV-B • Constraints View (HV-B) HV-B1: Manpower Projection HV-B2: Career Progression HV-B3: Establishment Inventory HV-B4: Personnel Policy HV-B5: Health Hazards HV-B6: Human Characteristics

33. HV-B1/B2/B3 • Constraints View (HV-B) HV-B1: Manpower Projection illustrates predicted manpower requirements for supporting present and future projects that contribute to larger capabilities. Information Requirements • Manpower forecasting to allow initial adjustments in training, recruiting, professional development, assignment and personnel management. • Impacts (and timeframe) related to numbers of personnel, personnel mix, Military Occupational Structure Identification (MOSIDs), Rank/level distribution, and, postings/relocations of personnel. • Number of personnel with necessary Knowledge, Skills, and Abilities (KSAs) ‘ready and able’ to support fielding of future program. HV-B2: Career Progression illustrates career progression as well as the essential tasks, skills, and knowledge (and proficiency level) required for a given job. Information Requirements • Impacts of alternative system and capability designs on career progression. • Jobs available given an individual’s current job and occupation. • Competencies required for each individual job. • Identify availability of individuals with necessary competencies. HV-B3: Establishment Inventory defines current number of personnel by rank and job within each establishment. Information Requirements • Forecasts of trained effective strength. • Number of people that must be trained, recruited, etc. to fill gaps required for ‘out years’.

34. HV-B4/B5/B6 • Constraints View (HV-B) HV-B4: Personnel Policy ensures that personnel are fairly considered, properly treated, well looked after and supported in a legal, moral and ethical manner.. Information Requirements • Department policies dealing with (governing) HR issues. • HR documents, such as policies, doctrine, laws, benefits, pay, Standard Operating procedures (SOPs), etc. HV-B5: Health Hazards (HV-B5) Considers the design features and operating characteristics of a system that can create significant risks of illness, injury or death. Information Requirements • Hazards may include system, environmental or task hazard assessment;air quality control assessment; noise/vibration pollution evaluation; impact force, shock protection;Workplace Hazardous Materials Information System (WHIMS) evaluation of tasks; radiation/LASER protection; Chemical and Biological (CB) protection; extremes of temperature, etc. • It may include aspects of survivability, i.e. limiting the probability of personal injury, disability or death of personnel in their interactions with the system. This can include providing protection from attack, and reducing detectability, fratricide, system damage, personnel injury and cognitive and physical fatigue. HV-B6: Human Characteristics (HV-B6) considers the physical characteristics of an operator and movement capabilities and limitations of that operator under various operating conditions. Information Requirements • It may include aspects such as anthropometrical/medical data; reach data; range of motion data; physical strength data; visual and auditory assessment; speed or duration of activity data; cognitive workload; working memory capacity; ability to be security cleared; personality, motivation, etc.

35. HV-C/HV-D Tasks View (HV-C) Tasks describe the human-specific activities, i.e., the tasks that have been assigned to the humans in a system over its entire life cycle. It also considers how the functions are decomposed into tasks and the dependencies between tasks. Information Requirements • Human-related functions in a system • Allocation of functions between humans and machines • Decomposition of functions into tasks • Task descriptions in terms of various criteria and the KSA requirements • Depiction of the inter-dependencies between different tasks • The tools required to accomplish a task • Interface design guideline on the basis of task requirements Roles View (HV-D) The Roles describe what have been defined for the humans interacting with the system. A role represents a job function defining specific behavior within the context of an organization, with some associated semantics regarding the authority and responsibility conferred to the person in the role, and competencies required to do the job. Information Requirements • Responsibility -accountability and commitment • Authority -the access ability of an individual to perform a specific task • Competencies -the quality of being able to perform; a combination of knowledge, skills and attributes • Multiplicity -a role may be performed by a human or by multiple humans at the same time.

36. HV-E/HV-F Human Network View (HV-E) The Human Network captures the human to human communication patterns that occur as a result of ad hoc or deliberate team formation, especially teams distributed across space and time. Information Requirements • Role groupings or teams formed, including the physical proximity of the roles and virtual roles included for specific team tasks. • Type of interaction –i.e., collaborate, coordinate, supervise, etc. • Team cohesiveness indicators -i.e., trust, sharing, etc. • Team performance impacts -i.e., synchronization (battle rhythm), level of engagement (command directed) • Team dependencies -i.e., frequency/degree of interaction between roles Training View (HV-F) Training is a detailed accounting of how training requirements, strategy, and implementation will impact the human. It illustrates the instruction or education and on-the-job or unit training required to provide personnel their essential tasks, skills, and knowledge to meet the job requirements. Information Requirements • ‘As-is’ training resources, availability, and suitability • Risk imposed by ‘to-be’ operational and system demands • Cost and maturity of training options for tradeoff analysis • Determine training required to obtain necessary knowledge, skills, and ability to support career progression • Differentiation of basic, intermediate, or advance job training; operational vs. system specific training; and individual vs. team training

37. HV-G Metrics View (HV-G) Metrics provides a repository for human-related values, priorities and performance criteria, and maps human factors metrics to any other Human View elements. It may map high-level (qualitative) values to quantifiable performance metrics and assessment targets or it may map measurable metrics to human functions, i.e., human performance specifications. Information Requirements • Human Factors Value definitions level 1…n • Human Performance Metrics (what is to be measured) • Target Values (what quantifiable value is acceptable) • Human Task to Metrics mapping • Value definition links • Value to design element mapping • Methods of compliance

38. HV-H Human Dynamics View (HV-H) Human Dynamics capture dynamic aspects of human system components defined in other views. It pulls together definitions from across the Human View to be able to communicate enterprise behavior. It provides inputs to human behavior and executable models that may be supported by simulation tools. Information Requirements • Organizational/team structure • Task/Role assignments to people • Team interaction modes • Demands on collaboration load (e.g. need to spend effort in building shared awareness, consensus-finding, communicating) • Task switches/interruptions • Critical / frequent / representative / typical scenarios • Operational constraints (e.g. extensive heat stress) • Time conditions: sequence, duration, concurrency • Workload • Decision speed • Team interaction/collaboration style • Trust in commanders intent

39. Human ViewandDoDAF Mapping

40. Human View Overlay on DM2 CDM METRICS TASK PROCESS PERSONNEL HUMAN FACTORS TRAINING ROLE CONCEPT TEAM

41. Human View Integration with DoDAF Products System Performance Parameters Matrix SV-7 (Tabular) Systems Functionality Description SV-4 (Behavioral) Operational Activity Model OV-5 (Taxonomy) High Level Operational Concept Graphic OV-1 (Pictorial) Performance Parameters Metrics HV-H HV-B (HFE) Activities Technology Measures Architecture Representation Health Hazards HV-B5 Concept HV-A Tasks HV-C Restrictions Human Characteristics HV-B6 Organizational Relationships Chart OV-4 (Structural) Human Concept Responsibilities Roles Human Roles HV-D Competencies Training HV-F Systems Technology And Skills Forecast SV-9 (Tabular) Technology Changes Teams Limitations Operational Node Connectivity Description OV-2 (Structural) Human Networks HV-E Structure HV-B (Personnel) Manpower Projections HV-B1 Career Progression HV-B2 Information Flow Information Requirements Operational Information Exchange OV-3 (Tabular) SystemsInterfaceDescription SV-1 (Structural) Personnel Policy HV-B4 Establishment Inventory HV-B3

42. Human ViewExampleHV-E - - Human Networks

43. Example: HV-E Human Networks • The HV-E captures the human to human communication patterns that occur as a result of ad hoc or deliberate team formation, especially teams distributed across space and time. This diagram indicates the interactions across teams involved in the Commander’s Update Brief process. It also specifies the communication types and team locations. Role groupings or teams formed, including the physical proximity of the roles and virtual roles (HV-D) included for specific team tasks (HV-C). Type of interaction – i.e., collaborate, coordinate, supervise, etc. Team cohesiveness indicators – i.e., trust, sharing, etc. Team performance impacts – i.e., synchronization (battle rhythm), level of engagement (command directed). Team dependencies – i.e., frequency/degree of interaction between roles.