Party Management System Vitamin B. Agenda Party Management System (PMS) The Project.

Post on 02-Jan-2016

218 views 0 download

Transcript of Party Management System Vitamin B. Agenda Party Management System (PMS) The Project.

Party Management System

Vitamin B

Agenda

Party Management System (PMS) The Project

Party Management System (PMS)

A web based system for organizing eventsCreated for Assembly 07Modular

Main module is Compo Management System New modules easy to attach

Open source (MIT licence) Apache, PostgreSQL, PHP MONO, .NET, C#

PMS Main features

Web based visitor pages View the schedule View the compo information Participate to compos Vote Edit own user info

PMS Main features

Web based administrator pages Same as the visitors, but in addition: Can create, edit and delete events (compos) Can modify user data (reactivate passwords

etc.) View the voting results during voting

Architecture overview

Live demo

The Project

Project personnel

Customer, Assembly Organizing Ville Vatén (The customer) Mikko Sivulainen (Technical advisor)

Mentor Kauko Huuskonen

Project personnel

The project team Janne Holm (Project manager) Henrik Hovi (Architect) Jukka Uskonen (QA manager) Jukka Tornberg (DB developer) Teijo Laine (UI developer) Henri Tuomola (Core developer) Pekka Helkiö (Core developer)

Goals of the project

1. Replace the old closed source system with an open source software

2. Create high quality system with good maintainability and extendability

3. Create more advanced features to the system

4. Some of the project members continue with the project after the course

Goals of the project

Replace the old closed source system with an open source software

Almost, but not quite A few features missing Stability needs improvement

Goals of the project

Create high quality system with good maintainability and extendability

Extendability: Yes Maintainability: Somewhat High quality: Somewhat

Goals of the project

Create more advanced features to the system

Not achieved, ”quality before new features” Minimum amount of features was

implemented in order to achieve the first goal The minimum functionality began to be stable

towards the end of the project

Goals of the project

Some of the project members continue with the project after the course

Maybe?

Main problems encountered (1/2)

Complex architecture Architecture was complex due to scalability

requirements Architecture was not communicated well to

other project members Added extra effort to the developers figure out how

things work

Problems encountered (2/2)

Loose project management Project management didn’t give clear enough

tasks to project members As the architecture was not communicated well,

actions should have been taken to fix this

Lessons learned

Architecture has to be clear and communicated to others This is the base onto which all the implemented

components rely

Project management has to be clear on the tasks Different people need different amout of

guidance

Metrics, cost of the product

Metrics, used effort per iteration

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 I2A I2B

Estimated

Actual

Metrics, used hours weekly (est vs. act)

Weekly hours estimated vs. actual

0

20

40

60

80

100

120

140

160

180

39-40

41 42 43 44 45 46 47 48 49 50 51 52 1-2 3 4 5 6 7 8

Week

Use

d h

ou

rs

Estimated

Actual

Metrics, used effort per task type

Hours used per task type

0,0

50,0

100,0

150,0

200,0

250,0

300,0

350,0

400,0

Oth

er

Comm

unicat

ion

Qua

lity A

ssur

ance

Archit

ectu

re

Man

agem

ent

Design

& im

plem

enta

tion

Metrics, used hours per project member

Hours used per person

0,0

20,0

40,0

60,0

80,0

100,0

120,0

140,0

160,0

180,0

jamu ferrix(sepa)

juskonen(sepa)

aroppuu(sepa)

mnd jst (sepa) _pekka(sepa)

That’s all

http://www.assembly.org