Presentation given at the UK INCOSE Annual Systems Engineering Conference (ASEC) 2010 at Heythrop Park, Oxfordshire by Chris Lowe (Liv Systems Ltd.) and Nic Plum (Eclectica Systems Ltd.).
http://www.incoseonline.org.uk/Program_Files/Calendar/Show_Event_Details.aspx?CatID=Events&EventID=138
It describes the application of human factors/user-centred design in unusual places - in the design of an architecture framework (TRAK) and the use of TRAK for human factors tasks.
2. 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
Wednesday, 10 November 2010
4. 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
Wednesday, 10 November 2010
5. 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
Wednesday, 10 November 2010
6. Human Factors in the
Design of TRAK
6
Wednesday, 10 November 2010
7. 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 Vendors
Modeling Tools
"The TRAK Enterprise"
(TRAK)
Architecture
Modellers
Wednesday, 10 November 2010
8. “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] −
[overlap]
−[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
+
− [complexity] +
[subjectfocus]
−
+
−
−
[more combinations]
AD re-use
Potential
+
+
[semantics]
[file/structure]
Tool Vendor
Architect
BrowserSpecifier
−
[view consistency]
Wednesday, 10 November 2010
9. 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
Wednesday, 10 November 2010
10. 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
Wednesday, 10 November 2010
11. 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
Authority
extends toplays
Wednesday, 10 November 2010
12. 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
Wednesday, 10 November 2010
13. 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
has
part
enacts
marked by
Resource
Node
Need
Concept Activity
conducts
supports
requires
Enterprise
Capability
realises
Item
requires Project
owns
delivers/removes
is configured
with
realises
is configured
with
has
part
depends
on
Resource
Interaction
from/to
realises
Interaction
Element Port Connectionexchanges from/to
realises
Function
performs
Human Resource
SoftwarePhysical
triggers
Protocolimplements
uses
Standard
realises
JobRole
exposes
governs
is configured
with
is configured with
TRAK Metamodel
20th October 2010
TheR
ailArchitecture
fram
ew
orK
Requirement
traces to
Concern
View
addresses
about
has part
has part
hosted on
haspart
plays
has part
has part
has part
plays
governs
issued by
undertakes
necessaryfor
Competence
requires
to conduct
Document
traces to
has
triggers
Metric
is quantfied by
isqualifiedby
requires
has
part
Contract
applies
realises
has
part
has
part
marks
introduction/
removalof
Milestone
physically
depends
on
governs
governs
Organisation
System
Project Activity
Port
depends
on
super
sedes
equivalent
to
carries
has part
has part
Item Exchange
carries
aspires to
is quantified by
Enterprise Goal
has
traces to
extends to
Uncontrolled copy - latest version at http://trakmetamodel.sourceforge.net
GNU Free Document License terms
apply
haspart
Architecture
Description
has part
is member of
has part
* also used to represent sponsor of
Architectural Task
for
=
Node
needs
Node
Wednesday, 10 November 2010
14. 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 Title
Questions / Concerns Addressed
EVp-01 Enterprise
Goal What is the Enterprise and what
goals does it set out to achieve?
EVp-02 Capability
Hierarchy
What 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 ItemExchange
Have 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 ProcurementStructure
What is the project structure? How
is it governed?
PrVp-02 ProcurementTimeline
What other projects is this
dependent on? How ddelive
PrVp-03 PWednesday, 10 November 2010
15. 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
Wednesday, 10 November 2010
16. Using TRAK for Human
Factors Application
16
Wednesday, 10 November 2010
17. 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?
Wednesday, 10 November 2010
18. 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?
Wednesday, 10 November 2010
19. 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?
Wednesday, 10 November 2010
20. 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!
Wednesday, 10 November 2010
21. 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?
Wednesday, 10 November 2010
22. Where was TRAK used in the
Invensys HF Task?
Wednesday, 10 November 2010
23. 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 Activity
SVp-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 Matrix
Show what tasks are performed
by what people
SVp-02 Solution Resource Interaction
(Table Format)
Wednesday, 10 November 2010
24. 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
Wednesday, 10 November 2010
26. 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
Wednesday, 10 November 2010
27. 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
Wednesday, 10 November 2010