340 likes | 517 Views
Roles in project teams. IMD07101: Introduction to Human Computer Interaction Brian Davison. Agenda. Working in teams Project management How to do meetings UML: Activity diagrams From specification to plan. Working in teams. Performing.
E N D
Roles in project teams IMD07101: Introduction to Human Computer Interaction Brian Davison
Agenda • Working in teams • Project management • How to do meetings • UML: Activity diagrams • From specification to plan
Working in teams Performing Shared vision; disagreements resolved positively; constructive problem-solving Roles are clarified; decisions made as a group; group norms established Norming Storming Decisions are difficult; team members compete for importance; rebellion against leader Forming High dependency on leader to clarify objectives and roles. Anxiety about processes
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
Project plan: Gantt chart List of tasks Task durations Timeline Task bar Milestone
Development Prototype 1 Prototype 2 Prototype 3 Final prototype Plan Test
Two kinds of prototype • Throwaway or low-fidelity • Paper • Powerpoint • Evolutionary or high-fidelity • Early prototypes develop into finished product
Controlling prototyping • Dynamic Systems Development Method (DSDM) • Prioritisation of requirements • Timeboxing Fixed duration Plan Review
Prioritisation Must have o Should have o Could have o Won’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:
Team routines • Regular times? • All together? • Prototyping cycle? • Meetings? • Pizza?
Meetings • Purpose • Process • Roles • Chair • Minute taker • Participants
Team meetings Agenda Minutes Agenda Minutes Agenda Minutes Meeting 1 Meeting 2 Meeting 3
Meeting agenda • Apologies • Confirmation of previous minutes • Matters arising • … • …
Minutes Meeting metadata: Title, date, attendees Notes divided by agenda item AB AB, CD Action column: Record of who is responsible AB CD
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 Actors Extend loan Library user Place hold Perform search Collect hold Issue book Library staff
Start Borrow book Find shelfmark on catalogue Activity (process) • Activity diagrams describe processes • Allow branching and parallel activities Branch Go to shelf Guard expression [book on shelf] [book not on shelf] Fork Self issue Place hold Wait for email Find alternative Join End
Swimlanes Library user Library staff Go to library desk Ask for held item Request student card Provide student card Find item Issue item Return card
OXO specification OXO Start game Actors Player Make move Check result System
Player System Start game [System starts] [Player starts] Make move Make move Check results Check results [Spaces] [Winner] [No winner] [Winner] [No winner] [Spaces] [No spaces] [No spaces] Offer new game
Use cases OXO Start game Actors Make move Player Check result System Offer new game
Start game Player Open home page Click start button [Player start] [System start] Click system start
Make move Player/system Choose square Place symbol
Check result System Check positions [System does not win] [System wins] Display "I win" [Player does not win] [Player wins] 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