T-76.4115 Iteration Demo

1
T-76.4115 Iteration Demo

• Vitamin B
• I1 Iteration13.12.2006

2
Agenda

• Project status (15 min)
• Achieving the goals of the iteration
• Project metrics
• Used work practices (5 min)
• Work results (20 min)
• Presenting the iterations results
• Demo

3
Introduction to the project

• Assembly Party Management System (PMS)
• Assembly
• An annual computer party organized in Hartwall
  Arena, Helsinki
• Several thousand visitors in a four day event
• Main events in the party are competitions
  (compos)
• PMS
• Sever/client system for handling the Assembly
  party compos
• The new software will replace old system
• Old system has been used for years and is a
  bottle neck for the party organizing
• Requirements are pretty clear
• Will be open source software
• Other party organizations can take into use also

4
Results of the iteration

• The deliverables of the iteration
• Functional software
• Project plan
• Requirements document
• Architecture document
• Testing documents
• SEPA diaries

5
Status of the iterations goals (implementation)

• Original high level goals for the itereation
  were
• Implement a bunch of use cases (the list is on
  next slides)
• Implement centralized user rights management and
  authentication
• The goals were updated during the iteration
  (Scope was decreased)
• Centralized user rights management was moved to
  I2 iteration
• Some of the use cases were moved to I2 iteration

6
Status of the I1 iterations goals
(implementation)
Visitor use cases
Status
1. Implement the following use cases
VUC1 Register to PMS (no user account yet in PMS) OK
VUC2 Register to party OK
VUC3 Manage user account information Anyone can edit user account info.
VUC4 Submit entry Other info but the compo entry itself can be uploaded.
VUC5 Update entry Other info but the compo entry itself can be uploaded.
VUC6 Vote OK
7
Status of the I1 iterations goals
(implementation)
Organizing use cases
Status
OUC2 Manage compo entry OK
OUC3 Submit entry for a visitor Other info but the compo entry itself can be uploaded.
OUC12 See vote counting results OK
OUC18 Manage visitor user account information OK
OUC4 Retrieve entries Moved to I2
OUC6 Sort playlist Moved to I2
OUC8 Freeze playlist (reqs OUC6) Moved to I2
OUC9 Export compo slides Moved to I2
OUC13 Export prize giving ceremony slides Moved to I2
OUC15 Export diplomas Moved to I2
OUC16 Export results Moved to I2
2. Implement centralized user rights management and authentication Moved to I2
8
Status of the I1 iterations goals (documents)
Status
Project plan OK
Requirements document OK
Architecture document OK
Test cases OK
QA report OK
Test log OK
Progress report OK
SEPA diaries OK
9
Project people (1/2)

• Janne Holm Project Manager
• Henrik Hovi Software Architect
• Jukka Uskonen QA Manager
• Teijo Laine Developer
• Henri Tuomola Developer
• Jukka Tornberg Developer
• Pekka Helkiö Developer
• Mikko Sivulainen Customers technical advisor
• No effort calculated
• Ville Vatén The Customer
• No effort calculated

10
Resources (2/2)
Original plan (in the beginning of the iteration)

• The 20 hours extra for the people with 170 hours
  is for SEPA work

PM Ar QA D1 D2 D3 D4 SUM
PP 71 38,5 38,5 37 28 30 20 263
I1 29 81,5 61,5 63 62 65 70 432
I2 50 50 70 70 60 75 80 455
Total 150 170 170 170 150 170 170 1150
Realization and updated plan
PM Ar QA D1 D2 D3 D4 SUM
PP 71 38,5 38,5 37 28 30 20 263
I1 33 77 51 80 80 58,5 76,5 456
I2 46 54,5 80,5 53 42 81,5 73,5 431
Total 150 170 170 170 150 170 170 1150
(realized hours and updates)
11
Effort used (1/7)
12
Effort used (2/7)
13
Effort used (3/7)
14
Effort used (4/7)
15
Effort used (5/7)
16
Effort used (6/7)
17
Effort used (7/7)
18
Changes to the project

• During the I1 iteration no major changes were
  made to the project
• Scope was decreased somewhat when we noticed that
  we have no time to implement everything planned

19
Risks

• The updated identified risks to the project are
  listed below

ID Risk description Effect
1 A developer quits or a project member cannot do his job for a long time (getting sick or something else). Crucial knowledge is lost. Project scope must be decreased.
2 New technology causes problems Project slows down because fluid development is not possible due to problems with technology. Project scope must be decreased.
3 The customer has no time to participate the project The project cannot go on as the group does not know what to do and what the customer expects from the group.
4 Quality assurance action do not find real defects (wrong things tested) The software does not meet the requirements. Depending on how badly things go wrong, there are only minor annoyances in the software or it is totally useless.
20
Project plan (1/5)Stakeholders and staffing
21
Project plan (2/5)Project goals

• Replace the old system with a new one
• excellent framework to build on
• minimum amount of functionality to be able to
  replace
• Create high quality system with excellent
  maintainability and further development
  possibilities
• Create more advanced features to the system
• Some of the project members continue in the
  project after the course

22
Project plan (3/5)Project practices

• Iterative, incremental development (course
  dictates)
• Documents will be written in HTML
• Will be exported to PDF when needed
• Risks gone through and analyzed in each project
  meeting
• Time tracking weekly effort reports to PM
• Small groups (UI, architecture, requirements)
• Communication IRC, email, weekly meetings
• Defect tracking Trac

23
Project plan (4/5)Tools

• Programming languages C, PHP5
• MONO framework
• Visual Studio for code generation
• Subversion for version control
• PostgreSQL database
• Apache web server
• XHTML compliant UI

24
Project plan (5/5)Phasing

• The work will be conducted in three iterations
• Project planning
• Implementation 1
• Implementation 2

25
Used work practices (1/3)Mandatory work practices

• Iterative work
• Natural choice
• Time reporting
• Collecting by email is frustrating
• We would need a way of reporting hours directly
  to some system
• Version control (Subversion)
• Natural

26
Used work practices (2/3)Own work practices

• Weekly meetings
• First meetings were too long (2 hours or so)
• We have managed to shorten the meetings with
  SCRUM type meetings (now about 1 hour)
• We will continue the weekly meeting practice in
  I2 iteration
• Communication IRC, email
• IRC is our main communication tool
• However, not everyone is hanging on IRC all day
  long
• Email is used for important messages
• Web pages
• Trac (https//dev.assembly.org/trac/pms/)
• Our internal wiki
• pms.dy.fi
• Our public web pages

27
Used work practices (3/3)Work practices in the
future

• It seems that the work practices were using are
  working pretty well
• We moved the hour reporting to Trac
• Now everyone has a common place where to report
  hours
• Still all the tasks needs to be mapped to our
  higher level tasks by hand
• We need to have real reflection workshop to find
  out if project managers view is correct ?

28
Demo

• Visitor UI
• System administrator UI