T-76.4115 Iteration Demo Vitamin B I1 Iteration 13.12.2006

T-76.4115 Iteration Demo

Vitamin BI1 Iteration

13.12.2006

2

T-76.4115 T-76.4115 IterationIteration demo demo

Agenda Project status (15 min)

Achieving the goals of the iteration Project metrics

Used work practices (5 min) Work results (20 min)

Presenting the iteration’s 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 iteration’s goals (implementation)

Original high level goals for the itereation were:1. Implement a bunch of use cases (the list is on next slides)2. 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 iteration’s goals (implementation)

Status1. Implement the following use casesVUC1: Register to PMS (no user account yet in PMS) OKVUC2: Register to party OKVUC3: 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

Visitor use cases

7


Status of the I1 iteration’s goals (implementation)

StatusOUC2: Manage compo entry OKOUC3: Submit entry for a visitor Other info but the compo entry

itself can be uploaded.

OUC12: See vote counting results OKOUC18: Manage visitor user account information OKOUC4: 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

Organizing use cases

8


Status of the I1 iteration’s goals (documents)

StatusProject plan OKRequirements document OKArchitecture document OKTest cases OKQA report OKTest log OKProgress report OKSEPA 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 Customer’s technical advisor No effort calculated

Ville Vatén The Customer No effort calculated

10


Resources (2/2)

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

PM Ar QA D1 D2 D3 D4 SUMPP 71 38,5 38,5 37 28 30 20 263I1 29 81,5 61,5 63 62 65 70 432I2 50 50 70 70 60 75 80 455Total

150 170 170 170 150 170 170 1150

Original plan (in the beginning of the iteration)

Realization and updated plan

(realized hours and updates)

PM Ar QA D1 D2 D3 D4 SUMPP 71 38,5 38,5 37 28 30 20 263I1 33 77 51 80 80 58,5 76,5 456I2 46 54,5 80,5 53 42 81,5 73,5 431Total 150 170 170 170 150 170 170 1150

11


Effort used (1/7)

Estimated vs. Actual effort per iteration

0,0

50,0

100,0

150,0

200,0

250,0

300,0

350,0

400,0

450,0

500,0

PP I1 I2

EstimatedActual

12


Effort used (2/7)

Used hours per task type (High level)Iteration I1

0,0 50,0 100,0 150,0 200,0 250,0 300,0

Other

Communication

Quality Assurance

Architecture

Management

Design & implementation

Estimated

Actual

13


Effort used (3/7)

Used hours per task type (High level)Whole project

0,0 50,0 100,0 150,0 200,0 250,0 300,0 350,0

Other

Communication

Quality Assurance

Architecture

Management

Design & implementation

I1

Whole project

14


Effort used (4/7)

Used hours per task type (low level) Iteration I1

0,0 20,0 40,0 60,0 80,0 100,0 120,0 140,0

Usability test planning & execution (SEPA)

Documentation (updating w iki)

Other w ork

Requirements development

Review s

Project planning (iteration planning)

Test automation (SEPA)

Test case design

QA planning

Unit and integration testing

Course lectures or meetings

Communication (IRC, email, etc.)

QA documentation (test logs, QA report)

Learning the tools (C#, subv., Visual Studio)

Design and implementation (DB)

Architecture development

Design and implementation (UI)

Project management (project meetings)

Design and implementation (core)ta

sk

hours

15


Effort used (5/7)

Used hours per task type (low level) Whole project vs. I1

0,0 20,0 40,0 60,0 80,0 100,0 120,0 140,0 160,0 180,0

Usability test planning & execution (SEPA)

Other w ork

Test automation (SEPA)

Test case design

QA planning

Unit and integration testing

Documentation (updating w iki)

Review s

QA documentation (test logs, QA report)

Course lectures or meetings

Requirements development

Design and implementation (DB)

Communication (IRC, email, etc.)

Project planning (iteration planning)

Learning the tools (C#, subv., Visual Studio)

Architecture development

Design and implementation (UI)

Design and implementation (core)

Project management (project meetings)

task

hours

Iteration I1

Whole project

16


Effort used (6/7)

Iteration 1 hours estimated vs actual

-100,0

0,0

100,0

200,0

300,0

400,0

500,0

43 44 45 46 47 48 49

Week

Hou

rs Hours left

Estimated hours left

17


Effort used (7/7)

PP (weeks 39-42) and I1 (weeks 43-50) hours estimated vs. actual

-40,0-20,0

0,020,040,060,080,0

100,0120,0140,0160,0180,0

39-40 41 42 43 44 45 46 47 48 49 50

Week

Hou

rs

Actual hours

Original estimated hours

Unused hours

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 Effect1 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

1. Replace the old system with a new one excellent framework to build on minimum amount of functionality to be able to replace

2. Create high quality system with excellent maintainability and further development possibilities

3. Create more advanced features to the system4. 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

https://dev.assembly.org/trac/pms/

27


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

It seems that the work practices we’re 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

manager’s view is correct

28


Demo Visitor UI System administrator UI