T Iteration Demo Vitamin B I1 Iteration

T Iteration demo 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 iteration’s results  Demo

T Iteration 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

T Iteration demo 4 Results of the iteration  The deliverables of the iteration  Functional software  Project plan  Requirements document  Architecture document  Testing documents  SEPA diaries

T Iteration demo 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

T Iteration demo 6 Status of the I1 iteration’s goals (implementation) 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 Visitor use cases

T Iteration demo 7 Status of the I1 iteration’s goals (implementation) 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 entriesMoved to I2 OUC6: Sort playlistMoved to I2 OUC8: Freeze playlist (reqs OUC6)Moved to I2 OUC9: Export compo slidesMoved to I2 OUC13: Export prize giving ceremony slidesMoved to I2 OUC15: Export diplomasMoved to I2 OUC16: Export resultsMoved to I2 2. Implement centralized user rights management and authenticationMoved to I2 Organizing use cases

T Iteration demo 8 Status of the I1 iteration’s goals (documents) Status Project planOK Requirements documentOK Architecture documentOK Test casesOK QA reportOK Test logOK Progress reportOK SEPA diariesOK

T Iteration demo 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 SivulainenCustomer’s technical advisor  No effort calculated  Ville VaténThe Customer  No effort calculated

T Iteration demo 10 Resources (2/2)  The 20 hours extra for the people with 170 hours is for SEPA work PMArQAD1D2D3D4SUM PP 7138, I1 2981,561, I Total Original plan (in the beginning of the iteration) Realization and updated plan (realized hours and updates) PMArQAD1D2D3D4SUM PP 7138, I ,576,5456 I2 4654,580, ,573,5431 Total

T Iteration demo 11 Effort used (1/7)

T Iteration demo 12 Effort used (2/7)

T Iteration demo 13 Effort used (3/7)

T Iteration demo 14 Effort used (4/7)

T Iteration demo 15 Effort used (5/7)

T Iteration demo 16 Effort used (6/7)

T Iteration demo 17 Effort used (7/7)

T Iteration demo 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

T Iteration demo 19 Risks The updated identified risks to the project are listed below IDRisk descriptionEffect 1A 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. 2New technology causes problemsProject slows down because fluid development is not possible due to problems with technology. Project scope must be decreased. 3The 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. 4Quality 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.

T Iteration demo 20 Project plan (1/5) Stakeholders and staffing

T Iteration demo 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 system 4. Some of the project members continue in the project after the course

T Iteration demo 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, , weekly meetings  Defect tracking: Trac

T Iteration demo 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

T Iteration demo 24 Project plan (5/5) Phasing  The work will be conducted in three iterations  Project planning  Implementation 1  Implementation 2

T Iteration demo 25 Used work practices (1/3) Mandatory work practices  Iterative work  Natural choice  Time reporting  Collecting by is frustrating  We would need a way of reporting hours directly to some system  Version control (Subversion)  Natural

T Iteration demo 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,  IRC is our main communication tool  However, not everyone is “hanging” on IRC all day long  is used for important messages  Web pages  Trac (  Our internal wiki  pms.dy.fi  Our public web pages

T Iteration demo 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

T Iteration demo 28 Demo  Visitor UI  System administrator UI