human factors - on the right trak?

Human Factors - on the right TRAK?An every day tale of applying human factors to unusual things and using an architectural framework for human factors work in a challenging SE environment.

1

Nic Plum

Eclectica Systems Ltd.

Chris Lowe

Liv Systems Ltd.

Copyright © 2010 by Eclectica Systems Ltd. & Liv Systems Ltd. Published and used by INCOSE with permission

Wednesday, 10 November 2010

The Main Theme / Objectives• Human Factors/ user-centred design in unusual situations

+ design of an enterprise architecture framework (TRAK)

+ using the framework for HF applications

• i.e. applying system-thinking & recognising how people are affected by, interact with and can be represented using

+ architecture framework (“definition”)

+ architecture description (“modelling”)

2


Introduction /Overview

3


Background & Challenges 4

• UK rail

+ complex industry organisation

+ regulation - large suite of standards

• SE in rail:

+ strong functional disciplines (cross-discipline links hard to maintain) ... silos

+ emphasis on interface management and system integration (important, but only part of SE)

+ systematic focus rather than systemic

+ custom and practice

+ DfT become de facto System/Integration Authority

• architecture framework/modelling therefore ...

+ scary, new, seen as complicated, not well understood or accepted


Therefore, TRAK ...• Therefore TRAK

+ needs to bring disciplines together

+ must be simple, understandable

+ must be usable and relevant to typical problems faced by SE practicioners/stakeholders

+ must provide a means to illustrate, describe and facilitate discussion

+ must augment or complement existing methods, tools, techniques

• all of these are very human-centric qualities

5


Human Factors in the Design of TRAK

6


Does a Framework Have a UI? 7

• not on its own, but ...

• what is the system of interest - “The TRAK Enterprise”

• there are many human roles involved, so

+ yes it does!

+ and we’d be silly not to consider the UI

• if you look after the people the rest will fall into place

• but you then have to consider the interactions

+ framework definition cannot be done in isolation

TRAK Framework Definition

Framework Developers

Framework Definition Store

TRAK Body of Knowledge

Wikitecture Glueware

Wikitecture Model Repository

<<Node>>Support Tracker

Professional Bodies

Architecture Browsers

Training Providers

Tool VendorsModeling Tools

"The TRAK Enterprise"

(TRAK) Architecture

Modellers


“TRAK Enterprise” Dynamics

• TRAK definition affects tools & users

+ complexity, selection

+ adequacy of rules

• tools affect users

+ implementation

+ rules / enforcement

• users affect tools & definition

+ need for rules

• users, tool, definition affect browsers (lay readers)

8

Metamodel Size

Ease of View Selection

No of Viewpoints

+ [coverage]

−

[overl

ap]

−[overlap/affordance]

Consistent Representation

−[overlap]

AD Exchange Potential

+AD

Size

+ +

Tool Enforcement

+

AF Enforcement

+

−

[compensation]

Navigability

−[complexity]

Readability

+No. Elements on a View

No. Views in AD

+−

[comple

xity]

+[s

ubje

ct fo

cus]

−

+

−

−

[more combinations]

AD re-use Potential

+

+

[semantics]

[file/structure]

Tool VendorArchitect

BrowserSpecifier

−[view consistency]


Simplicity• why?

+ ADs/modelling about communicating

+ aid understanding - diverse technical/non-technical readership

+ cost of preparing and maintaining models

• TRAK response

+ small, simple metamodel aimed at users not specifiers - easily fits on a page

+ 22 viewpoints (and view types)

+ short names - easy to scan / understand

+ relate to SE practice

+ views can be read as sets of sentences by anyone (metamodel provides allowed nouns & verbs)

9


Consistency• why?

+ supports simplicity (less confusion), affordance (easier to pick right element, view), understanding

+ ‘standardisation’ aids exchange/portability

+ frameworks often use different names to differentiate themselves e.g. NAF vs MODAF vs DNDAF vs DODAF

+ consistency needed to maximise re-use, exchange of models / collaboration potential

• TRAK response

+ ISO 42010 terms used - e.g. view, viewpoint (a specification not collection)...

+ mapping views map upwards (as you’d expect), xx-01 views are all structural, ...

+ small, non-overlapping metamodel - removes user’s subjective choice

+ mandatory tuples designed to cover whole metamodel without gaps

+ rules for content of each view, consistency rules between views, TRAK Bye Laws and minimum allowed view sets for model consistency

10


Affordance & Visibility• why?

+ potential source of confusion, inconsistency & therefore maintenance cost

+ eases cost of adoption

• TRAK response

+ colours for stereotypes mandated & keyed to TRAK Perspective

+ use relationships to denote structure, role etc not colour / tools provide graphics as well

+ relationships always have text description and direction - not everyone is technical / UML-aware

+ viewpoint names keyed to stereotype + have Perspective name e.g. Solution ...

+ Bye Laws

+ mandate that all elements / relationships must be visible

+ Metamodel-on-a-page concept - keep it all in view

11

<<Role>>System Engineer

<<Organisation>>INCOSE

<<Role>>SE Certification

Authorityextends toplays


Adequacy• why?

+ time = money

+ need to minimise size, complexity, maintenance maximise re-use, collaboration

+ fit with existing SE practices & tools

+ frameworks often defined by procurers not SE practitioners and hence tuned/ refined in up-front aspects

+ architectural description not always best or most appropriate to task

• TRAK response

+ minimise metamodel and viewpoint set sizes and therefore potential model size - just fit for purpose

+ minimal process based on ISO 42010 i.e. identify taskholder concerns, choose viewpoint(s) addressing concerns... model away!

+ self-documenting - MV-02 Architecture Description Design Record documents concerns, findings and model

+ reflect working practice needs - make it easy for users to interact / get involved with TRAK definition

12


The TRAK Metamodel• aimed @ user not tool

vendor

+ v small compared with DODAF 2 (c 250 elements), DNDAF (c 170)

+ no notation used

• centred on ‘System’

+ that’s what we’re interested in

• but provides context wrt projects, enterprise and the concept

13

haspart

enacts

marked by

Resource

Node

Need

Concept Activity

conductssu

ppor

ts

requires

Enterprise

Capability

real

ises

Item

requires Project

owns

deliv

ers

/ rem

oves

is configured with

realises

is configured with

has part

depends on

Resource Interaction

from

/to

real

ises

Interaction Element Port Connectionexchanges from/to

realises

Functionperforms

Human Resource

SoftwarePhysical

triggers

Protocolimplements

uses

Standard

realises

JobRole

exposes

gove

rnsis configured

withis configured with

TRAK Metamodel20th October 2010

TheRail

Archite

cture

framew

orK

Requirement

traces to

Concern

View

addresses

about

has part

has parthosted on

has part

plays

has part

has part

has partplays

governs

issued by

unde

rtake

s

nece

ssar

y fo

r

Competencerequires

to conduct

Document

traces to

has

triggers

Metricis quantfied by

is q

ualif

ied

by

requires

has part

Contract

applies

realises

has part

has part

mar

ks

intro

duct

ion/

rem

oval

of

Milestone

physically depends

on

governs

governs

Organisation

System

Project Activity

Port

depends on

supersedes

equivalent to

carries

has part

has part

Item Exchange

carries

aspires tois quantified byEnterprise Goal

has

traces to

extends to

Uncontrolled copy - latest version at http://trakmetamodel.sourceforge.net

GNU Free Document License terms apply

has

part

ArchitectureDescription

has part

is member of

has part

* also used to represent sponsor of Architectural Task

for

= Node needsNode


NCV-1 Capability Vision

NCV-2 Capability Taxonomy

NCV-3 Capability Phasing

NCV-4 Capability Dependencies

NCV-5 Capability to Organisational Deployment Mappings

NCV-6 Capability to Operational Activities Mapping

NCV-7 Capability to Services Mapping

NOV-1 High Level Operational Concept

NOV-2 Operational Node Connectivity Description

NOV-3 Operational Information Requirements

NOV-4 Organisational Relationship Chart

NOV-5 Operational Activity Model

NOV-6a Operational Activity Model

NOV-6b Operational State Transition

NOV-6c Operational Event-Trace Description

NOV-7 Information Model

NPV-1 Programme Portfolio

NPV-2 Programme to Capability Mapping

NSV-1 System Interface Description

NSV- 2 Systems Communication Description

NSV-2a System Port Specification

NSV-2b System to System Port Connectivity

NSV-2c System Connectivity Clusters

NSV-2d Systems Communication Quality

NSV-3 Systems to Systems Matrix

NSV-4 System Functionality

TRAK Architecture Viewpoints• 22 viewpoints (view specifications)

+ 47 - 53 in other frameworks

• each addresses set of related concerns

• organised by content not application

+ e.g.separate structure from behaviour

• complies with ISO 42010

+ mandatory / optional content

+ consistency rules

• short, simple names keyed to principal stereotype

+ all xx-01s are structural

14

Viewpoint TitleQuestions / Concerns Addressed

EVp-01 Enterprise Goal What is the Enterprise and what goals does it set out to achieve?

EVp-02 Capability HierarchyWhat are the enduring capabilities the enterprise requires and how is capability measured?

EVp-03 Capability Phasing How is capability delivered? Are there any gaps?

CVp-01 Concept Need Have the concept needs been identified?

CVp-02 Concept Has the concept purpose been identified? How is it seen as being used?

CVp-03 Concept Item ExchangeHave the items exchanged by concept nodes been identified? What is required to satisfy the concept needs?

CVp-04 Concept Activity to Capability Mapping

How/are operational activities sufficient to deliver capability?CVp-05 Concept Activity What does each concept node

need to do?CVp-06 Concept Sequence

How are concept activities ordered? Is it important?

PrVp-01 Procurement StructureWhat is the project structure? How is it governed?

PrVp-02 Procurement TimelineWhat other projects is this dependent on? How does their delivery time affect us?

PrVp-03 Procurement Wednesday, 10 November 2010

Designing for Whole-Life• how do we maximise maintainability, improve ‘mid-life’ update capability and responsiveness of

framework to users’ needs?

+ flexibility

+ metamodel, viewpoints - logical definitions not tied to implementation in any tool or notation & not hard-wired to any other framework such as DODAF

+ TRAK is open source under GNU Public License and GNU Free Documentation License

+ Sourceforge used as host

+ metamodel (trakmetamodel.sourceforge.net) separated from viewpoints (trakviewpoints.sourceforge.net) - future re-use?

+ configuration management, collaboration and communication tools provided by SF for free

+ anyone can raise bugs, support and feature requests - traceable, systematic work flow to sentence

+ minimal fixed admin based on Internet Engineering Task Force (IETF)

+ anyone can identify a problem, form a working group and work together to identify solutions

+ separate community site, wiki and forums at trak-community.org

15


http://trakmetamodel.sourceforge.net


http://trakviewpoints.sourceforge.net


http://trak-community.org

http://trak-community.org

Using TRAK for Human Factors Application

16


Overview

+Human Factors = Human Factors Engineering

+Why bring Human Factors Engineering and Architecture Frameworks closer together?

+How does TRAK do it?

+What happens when tried in rail Human Factors engineering?


Systems Engineering and Human Factors Engineering – Why Bother?

+Renewed HF interest in whole-system approach

+ From SE, recognition that Human Factors Engineering is necessary

+ Potential benefits=

+Common reference point across design disciplines

+ Products get designed as a system, considering all system parts appropriately

+ So use Architecture Descriptions?


Human View Approach

+‘Human View’ approach for MODAF/NAF

+Set of viewpoints to capture human-related concerns

+Related to existing views, but not expressed via MODAF metamodel

+Ties in with good practice in HF Engineering

+Provides a focus for HF

+Opportunities for simplification?


TRAK & Human Factors Concerns

+No dedicated Human Views in TRAK yet

+Why?

+Metamodel built from whole-system philosophy

+ All resources, whether systems, physical, software, or humans, are of equal status

+Objective to not have discipline-specific views

+ but always under review!


What Happens when tried in rail Human Factors engineering?

+Invensys Rail Automatic Train Regulation

+A Train Traffic Controller tool to ‘smooth’ service delivery

+How to design the ATR technology so that it supports the people within the railway system?


Where was TRAK used in the Invensys HF Task?


How TRAK Was Used In Task Analysis

Task Analysis Type Purpose trak Viewpoint Used

Hierarchical Task Analysis

Operational Sequence Diagram

Communications Link Analysis

Show relationships between goals, tasks and plans

CVp-05 Concept ActivitySVp-04 Solution Function

(hierarchical format)

Identify how tasks are connected over time

SVp-04 Solution Function (activity diagram format)

Show type and frequency of communication paths

SVp-02 Solution Resource Interaction

Task-Operator MatrixShow what tasks are performed

by what peopleSVp-02 Solution Resource Interaction

(Table Format)


What was Learnt?• Highlighted interconnectedness of Automatic Train Regulation

+Role of driver and platform staff

+New human-automation communication paths

• Benefits found over traditional HF method:

+ Less time consuming HF workflow

+ Easier to model human-automation interaction sequences

+Overlapping viewpoints supported different aspects of task analysis

+Good tool for talking with SEs about whole system behaviour, not just HMI

• Valuable in conjunction with paper prototyping (adds ‘rich picture’)

• Encouraging response from other HF specialists


Concluding Remarks

25


Where We Are 26

• early days

+ emphasis on architecture(!) of ‘the TRAK Enterprise’ - right building blocks, structure and control mechanisms not fine detail

+ identifying how and what views might be useful for (applications) will take a lot longer

• trying to engage within the domain and different disciplines

+ not traditional

+ AD is an integration mechanism - no respecter of traditional sensitivities / organisational boundaries

• encouraging folks to get involved by using the open source mechanisms provided

+ definition http://trakviewpoints.sourceforge.net and http://trakmetamodel.sourceforge.net

+ registry for identifying TRAK, etc ADs for sharing http://trak-community.org/index.php/modelRegistry






http://trak-community.org/index.php/modelRegistry




Lessons• SE doesn’t just apply to products but to the ‘business’ developing the products

+ helps structure, identify interfaces, allocate function and stops it becoming a muddle

+ people are involved with both - ignore the HFI at your peril!

• anticipating how users behave is essential but hard - often empirical

• keeping an AF small and consistent is essential but hard

• everyone thinks their domain/specialism is uniquely tricky and needs it’s own terminology or views and are often unhappy to find it isn’t/doesn’t

• an AF / whole-system approach can bring different disciplines / players together

+ architecture description isn’t the sole prerogative of a small specialist priesthood

• good ideas still need a sponsor to be taken seriously - SE advocates like DfT and LUL essential

27


human factors - on the right trak?

Technology

design of trak

trak perspective

right trak

models trak response

trak bye laws

tools denition

tools users

rules users