Roles in project teams IMD07101: Introduction to Human Computer Interaction Brian Davison

Roles in project teams

IMD07101: Introduction to Human Computer InteractionBrian Davison

Agenda• Working in teams• Project management• How to do meetings• UML: Activity diagrams• From specification to plan

Working in teams

Forming

Storming

Norming

Performing

High dependency on leader to clarify objectives and roles. Anxiety about processes

Decisions are difficult; team members compete for importance; rebellion against leader

Roles are clarified; decisions made as a group; group norms established

Shared vision; disagreements resolved positively; constructive problem-solving

Roles not people

• Technical (Microsoft)– Architect– Developer– Designer– Author– Tester– Administrator

• Belbin– Innovator (Plant)– Investigator– Co-ordinator– Shaper– Evaluator– Teamworker– Implementer– Finisher– Specialist

Specification of requirements• Functional

– WHAT the system must do

• Non-functional– HOW the functions are presented

Specification

Implement prototype

Evaluate prototypePlan

Design

Project plan: Gantt chart

List of tasks

Task durations

Timeline Task bar Milestone

Development

Plan Test

Prototype 1 Prototype 2 Prototype 3 Final prototype

One way to organise your week...

Two kinds of prototype• Throwaway or low-fidelity

– Paper– Powerpoint

• Evolutionary or high-fidelity– Early prototypes develop into finished product

Fixed duration

Controlling prototyping• Dynamic Systems Development Method (DSDM)• Prioritisation of requirements• Timeboxing

Plan Review

Prioritisation

M ust have

o

S hould have

o

C ould have

o

W on’t have

Aim to complete M and S within

timebox

Project Management• Maintain the plan• Ensure timescale is observed• Ensure testing is being done• Ensure documentation is being produced• Review the issue log• Take action to resolve issues

Time management• Whole team agrees a plan• Project Manager ensures everyone performs

• All team members have to take responsibility • The PM helps ensure things happen at the agreed time

• PM adjusts the plan as the project goes along

Communications• Contact details

– Email– Phone

• Shared location– Google Docs– Windows Live– Dropbox– Facebook

The issue log• Running list• Any team member may add to the list• Reviewed regularly by the Project Manager• Status updated as appropriate• Issue details:

Issue Number

Type (RFC, Off-Spec or General)

Author

Date Identified

Date of Last Update

Description

Status

Team routines• Regular times?• All together?• Prototyping cycle?• Meetings?• Pizza?

Meetings• Purpose

• Process

• Roles– Chair– Minute taker– Participants

Team meetings

Meeting 1

Meeting 2

Meeting 3

MinutesAgenda MinutesAgenda MinutesAgenda

Meeting agenda

1. Apologies

2. Confirmation of previous minutes

3. Matters arising

4. …

5. …

Minutes

AB

AB,CD

AB

CD

Meeting metadata:Title, date, attendees

Action column: Record of who is responsible

Notes divided by agenda item

Short break

Translating ideas into specifications• Use cases

– Identify actors– For each actor, identify interactions

• Activity diagrams– Like flowcharts (but better)– Develop each use case as an activity diagram

Example Library

Borrow book

Extend loan

Place hold

Perform search

Library user

Library staff

Issue book

Actors

Collect hold

Borrow book• Activity diagrams describe

processes

• Allow branching and parallel activities

Find shelfmark on

catalogue

Go to shelf

Self issue Place hold

Wait for emailFind

alternative

[book not on shelf][book on shelf]

Start

Activity (process)

BranchGuard

expression

Fork

JoinEnd

Swimlanes

Request student card

Find item

Issue item

Library staff

Go to library desk

Ask for held item

Provide student card

Library user

Return card

OXO specificationOXO

Start game

Make move

Player

System

Actors

Check result

System

Start game

Make move

Player

Check results

[Player starts] [System starts]

Make move

Check results

[Winner] [No winner]

Offer new game

[No winner]

[Winner]

[Spaces]

[No spaces]

[Spaces]

[No spaces]

Use casesOXO

Start game

Make move

Player

System

Actors

Check result

Offer new game

Start game

Click system start

Open home page

Click start button

Player

[System start][Player start]

Make move

Choose square

Place symbol

Player/system

Check result

Check positions

System

[System wins][System does not win]

Display "I win"[Player wins][Player does not win]

Display "You win"

UML to pseudo-code• Display start page with start options• If system starts

– System moves• While spaces

– Player moves– Check for winner– System moves– Check for winner

• Offer new game

Non-functional requirements• P

– What kind of people will use the system?– How can you reflect their needs in the design?

• A– What kind of activities are involved – work/leisure, urgent/relaxed, etc?– What implications are there for the interface?

• C– In what context will the system be used – work, home, public place, mobile, etc?– Implications?

• T– What technologies are available?– Which technology choice would be appropriate?

Design Principles (Benyon p.90)

• Access, Learn and Remember– Visibility– Consistency– Familiarity– “Affordance”

• A Sense of Control– Navigation– Control – Feedback

• Safety and Security– Recovery– Constraints

• Suitable– Flexibility – Style – Conviviality