Party Management System

1
Party Management System

• Vitamin B

2
Agenda

• Party Management System (PMS)
• The Project

3
Party Management System (PMS)

• A web based system for organizing events
• Created for Assembly 07
• Modular
• Main module is Compo Management System
• New modules easy to attach
• Open source (MIT licence)
• Apache, PostgreSQL, PHP
• MONO, .NET, C

4
PMS Main features

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

5
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

6
Architecture overview
7
Live demo
8
The Project
9
Project personnel

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

10
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)

11
Goals of the project

• Replace the old closed source system with an open
  source software
• Create high quality system with good
  maintainability and extendability
• Create more advanced features to the system
• Some of the project members continue with the
  project after the course

12
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

13
Goals of the project

• Create high quality system with good
  maintainability and extendability
• Extendability Yes
• Maintainability Somewhat
• High quality Somewhat

14
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

15
Goals of the project

• Some of the project members continue with the
  project after the course
• Maybe?

16
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

17
Problems encountered (2/2)

• Loose project management
• Project management didnt give clear enough tasks
  to project members
• As the architecture was not communicated well,
  actions should have been taken to fix this

18
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

19
Metrics, cost of the product
20
Metrics, used effort per iteration
21
Metrics, used hours weekly (est vs. act)
22
Metrics, used effort per task type
23
Metrics, used hours per project member
24
Thats all

• http//www.assembly.org