Human Factors - On the Right TRAK?

1 Human Factors - Nic Plum Eclectica Systems Ltd. on the right TRAK? Chris Lowe Liv Systems Ltd. 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. Copyright © 2010 by Eclectica Systems Ltd. & Liv Systems Ltd. Published and used by INCOSE with permission Wednesday, 10 November 2010

The Main Theme / Objectives 2 • 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 (“deﬁnition”) + architecture description (“modelling”) Wednesday, 10 November 2010

3 Introduction /Overview Wednesday, 10 November 2010

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

Therefore, TRAK ... 5 • 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 Wednesday, 10 November 2010

6 Human Factors in the Design of TRAK Wednesday, 10 November 2010

Does a Framework Have a UI? 7 Tool Vendors • not on its own, but ... Modeling Tools • what is the system of interest - “The TRAK Enterprise” "The TRAK Enterprise" TRAK Framework Framework • there are many human roles involved, Definition Developers so Professional TRAK Body of Framework + yes it does! Bodies Knowledge Definition Store Training Providers + and we’d be silly not to consider the UI Wikitecture Wikitecture Glueware Model Repository • if you look after the people the rest will fall into place <<Node>> • but you then have to consider the Support Tracker interactions Architecture Browsers (TRAK) Architecture + framework definition cannot be done in Modellers isolation Wednesday, 10 November 2010

“TRAK Enterprise” Dynamics 8 • TRAK definition affects tools & No of [overlap/affordance] − Ease of View [com Viewpoints Selection pe nsati on] users [view − AF + cons − − isten cy] − Enforcement + complexity, selection [co p] ve l a Tool ra er ions ] + adequacy of rules ge v [o inat Enforcement ] mb e co [mo r + + Metamodel Size − Consistent • tools affect users [overlap] Representation [sem anti cs] + + + implementation e ] No. tur AD re-use uc + + Elements − Readability [fi le /str + Potential + rules / enforcement on a View + AD + Size + − AD • users affect tools & definition Exchange ] us] ity lex [complexity] Potential ct foc + need for rules mp − [co e [subj − Navigability No. Views Architect • users, tool, definition affect Tool Vendor + in AD Specifier Browser browsers (lay readers) Wednesday, 10 November 2010

Simplicity 9 • 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 speciﬁers - easily ﬁts 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) Wednesday, 10 November 2010

Consistency 10 • 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 speciﬁcation 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 Wednesday, 10 November 2010

Affordance & Visibility 11 • why? + potential source of confusion, inconsistency & therefore maintenance cost + eases cost of adoption <<Role>> <<Organisation>> <<Role>> plays SE Certiﬁcation extends to • TRAK response INCOSE System Engineer Authority + 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 Wednesday, 10 November 2010

Adequacy 12 • 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 Wednesday, 10 November 2010

The TRAK Metamodel 13 Uncontrolled copy - latest version at http://trakmetamodel.sourceforge.net • aimed @ user not tool is quantiﬁed by Requirement re aspires to tu Enterprise Goal ec Ar ail e R h K chit T has part Enterprise realises vendor or ew has m traces to fra part traces to requires TRAK Metamodel has Metric requires traces to part + v small compared with 20th October 2010 is quantfied by Project Activity delivers / removes GNU Free Document License terms Document apply Capability marked by DODAF 2 (c 250 undertakes Node Milestone elements), DNDAF (c supports has part Architecture owns necessary for = 170) depends Node on Description has for needs realises conducts realises Node introduction/ removal of requires Project has part marks Need Item Exchange is qualified by has part + no notation used has part realises View carries Resource • centred on ‘System’ System addresses triggers is configured governs is configured with Item Concept Activity with about is configured with has part is configured hosted on + that’s what we’re with Physical Software Concern has part Resource has realises part from/to Interaction has part physically Human Resource is member of interested in realises has depends performs on has part plays • but provides context wrt Function Role Job Organisation has part Contract requires governs projects, enterprise and to conduct Competence has part plays governs equivalent governs applies the concept triggers to has exposes * also used to represent sponsor of part extends to Architectural Task carries issued by Interaction Element exchanges Port Connection from/to Port implements Protocol has part Standard uses enacts depends super sedes on Wednesday, 10 November 2010

TRAK Architecture Viewpoints 14 NC Viewpo V-1 int Tit NC Ca V-2 pab • 22 viewpoints (view speciﬁcations) EVp-01 le Enterpr Questio ns / Co V-3 NC Ca pab ility V Goal ise What is Nncerns a C C ility ision EVp-02 the Ent V-4 ApabiesseTax ddr d o N erpr Ca + 47 - 53 in other frameworks Capabi lity goals d e pa w it oes it s CV-5ise andb hay Ph nom NC t out Caac ility t asin l y Hierarc What a to p hie re the e V-6 g hy the ente N nduriCg abilitve?Depe rpriseCV- n apa pabiyittio l es ndenc • each addresses set of related EVp-03 Capabi capabil NO requCes andlity 7 ir ca bi Org i s-1red? b hoto is anis es lity ity meaV apa wO How is N u concerns CVp-01 Phasing there an N Oi capabVl i2 Hig h -ty deliveLe ility to S per atio atio nal Concep y gaV s? Ope redel Are erv Op v? nal De t Have th N -3 rat Op ice Ac plo Need e conce Ope ion era sM tivi ym • organised by content not application CVp-02 Concep t identifie NO d? OV p -4 t nereds al No Org ation een de b tion al C app ing ties Ma ent pp Ma pp Has thN V-5 ani al I Co onc ing ing eO onceOp c sat nfo nne ept s identifie V-6 pt puapos iona rmat er r ctiv + e.g.separate structure from behaviour CVp-03 Concep used? V- NO ? How is tion e been e d aO a peirt seen l A lR lati ion Re ty De i t Item H NO 6b O atio ascbeing on nal tivi shi qui s rem cripti Exchan ave the-6 V per ty M pC ent on items e atio cO x Ac • complies with ISO 42010 ge NO concepV t -nodes a per changed tivity odel WhaPV 7 Info beetnoin e Stby Nt nal Mo har t s is1 equi rm i d l ntifiede T at CVp-04 conP ep Pro Nc -r red ao s a Ev ? ra del t a Concep V-2t needs? tion tisfy tent- he T nsitio + mandatory / optional content Activity t How/ar Pro NS V-1 e operrat gra mm Mod el rac eD n to g ai e Capabi sufficienSy NS mmal aPoirt on esc s d v e ct vifties t tote eli m I er cao a olio ript lity V- t pC + consistency rules CVp-05 Mappin g NS V-2 2S yst em nte rfac a ab bipty? li ion C o n ce p NS aS sC eD ility t Vh2- t yst o Ma Activity NS W ab does em P mmu escrip e • short, simple names keyed to CVp-06 Concep N n - ec So do?m Ve2 d Syste achoronce nic t ct pt node tion atio pp ing t SV H2d ar e - ow e m yst to S Spec nD principal stereotype PrVp-01 Sequen N ce SV Is Sy concept st r yst Co actiem iﬁc atio escr ipti Procure N -3 it impoeta ms t? nne vitiesoord n P on ment W Sys SV n ctiv rt Cered? Structu -4 hat ts m e Com e + all xx-01s are structural PrVp-02 re Sys i th t projec m ity C s o onn Procure is it gtov em rned Sy t stnuc tureuste ectivi e ur i c l Timelin ment W hat othe c Fun ? stem atio ? Hos rw ty e te r proijon s M n Qu alit ent on? asitiy thiatrix depend ct l s PrVp-03 s y Wednesday, 10 November 2010 P delive How d

Designing for Whole-Life 15 • 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 Wednesday, 10 November 2010

16 Using TRAK for Human Factors Application Wednesday, 10 November 2010

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

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 beneﬁts= + 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

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 simpliﬁcation? Wednesday, 10 November 2010

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-speciﬁc views + but always under review! Wednesday, 10 November 2010

What Happens when tried in rail Human Factors engineering? +Invensys Rail Automatic Train Regulation +A Train Trafﬁc 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

Where was TRAK used in the Invensys HF Task? Wednesday, 10 November 2010

How TRAK Was Used In Task Analysis Task Analysis Type Purpose trak Viewpoint Used CVp-05 Concept Activity Show relationships between Hierarchical Task Analysis SVp-04 Solution Function goals, tasks and plans (hierarchical format) Operational Sequence Identify how tasks are connected SVp-04 Solution Function (activity Diagram over time diagram format) Communications Link Show type and frequency of SVp-02 Solution Resource Interaction Analysis communication paths Show what tasks are performed SVp-02 Solution Resource Interaction Task-Operator Matrix by what people (Table Format) Wednesday, 10 November 2010

What was Learnt? • Highlighted interconnectedness of Automatic Train Regulation + Role of driver and platform staff + New human-automation communication paths • Beneﬁts found over traditional HF method: + Less time consuming HF workﬂow + 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

25 Concluding Remarks Wednesday, 10 November 2010

Where We Are 26 • early days + emphasis on architecture(!) of ‘the TRAK Enterprise’ - right building blocks, structure and control mechanisms not ﬁne 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 + deﬁnition 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

Lessons 27 • 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 ﬁnd 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 Wednesday, 10 November 2010

Human Factors - On the Right TRAK?

by Nic Plum on Nov 10, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Human Factors - On the Right TRAK? — Presentation Transcript