1. T-76.4115 Iteration Demo Software Trickery PP Iteration 23.10.2007

2. 2 Agenda Project status (10 - 15 min) –achieving the goals of the iteration –project metrics Work results (10 - 20 min) –presenting the iteration’s results Used work practices (5-10 min)

3. 3 Introduction to the project Party management system v2.0 (PMS) –Modular web-based system Tournament management system module (TMS) –Replaces existing system (non PMS-module) –Extension module for PMS –A solution for managing game tournaments –Main user groups Administrators Tournament players Outside spectators

4. 4 Status of the iteration’s goals Goal 1: Creating contacts to all relevant stakeholders –OK Goal 2: Understanding the problem domain fully –OK Goal 3: Creating a solution for the given problem –DISCARDED (Practically same as GOAL 2 at this point) Goal 4: Creating the needed architecture for the project to succeed –MOVED to beginning of I1 –Studied existing PMS architecture Goal 5: Learning the basic usage of needed technologies for the solution –OK Goal 6: High level schedule for the project –OK Goal 7: Identification and preparation for possible risks in I1 –OK

5. 5 Status of the iteration’s deliverables Project plan –OK, Except chapter 5.2 (QA Plan) which is to be delivered later (2.11.) Requirements document –OK, all important requirements documented in general level Progress report –OK SEPA diaries –OK High level Architecture –Moved to Iteration 1

6. 6 Realization of the tasks Status RealizedPlanned Diff(Left) MeetingsOK 3149,5-18,50 Creating iteration planOK 12 00 Requirements engineeringOK 3148-170 Project PlanOK 3347-150 Studying existing system and technologiesStill Active 3681-4545 Overview of system architectureMoved 015-150 Rest of PP tasks 4130,5+10,5 Total 184283-9945 * unplanned task (= a new task added during the iteration)

7. 7 Resource usage Individual studying didn’t realize as planned Architectural design moved to beginning of I1 Estimating tasks without prior experience was hard PMQMSAMaGMiAToAJaLMaHErHSUM PP 5291452015 283 I1 454960855565 544 I2 535045855570 558 Total 150190150190125150 1405 Original plan (in the beginning of the iteration) Realization and updated plan (realized hours and updates) PMQMSAMaGMiAToAJaLMaHErHSUM PP 55701410456119184 I1 42607595607069 71611 I2 536061856175 70 590 Total 150190150190125150 1405

8. 8 Resource usage Wed and Sun are control points Estimates upward Tasks declared done correct the curve Some members lazy about reporting hours during iteration -> Curve corrects itself during the end

9. 9 Changes to the project Major changes since the Iteration plan –Iterations split into two sprints –Developers will be divided into smaller team

10. 10 Risks IDRiskP IEEffectsControlling actionsR 1Architecture delays whole project 7963No coding can be done since there is no architecture or the chosen architecture proves to be unusable for the project Using incremental architecture techniquesSA 2Key members of customer's side do not have enough time to do their part in project 7856The project team will develop software with inadequate information and the end result will differ from what the customer really wants Good planning beforehand meetings to utilize the time with the customer as efficiently as possible PM, QM 3Communication between project stakeholders fails 6954No one knows what is happening and stakeholders in the project become frustrated. Project suffers. Communication practices well planned and applied according to the plan PM 4Quality of the product is insufficient 5840The product is poor to use and is unstable See QA Plan for complete details.QM 5Requirements are misunderstood 5840The product becomes something other than what the customer wanted Quality manager presents requirements drafts to the customer frequently and makes sure everyone in project understands these requirements QM 6Project member quits in the middle of the project 4936Crucial information is lost and project scope must be decreased Increase the amount of beer. Promote good team spirit, and discuss about possible problems openly. Developers should be teamed up to minimize the effect of losing one developer. PM, SA 7New technologies cause problems 5735Coding is slower than thought and resource estimations fail Assigning coders to tasks that they have personal learning goals so that motivation of learning new is the highest possible PM, SA 8The project data is lost due to hard drive breakdown 110 All coding and documenting need to be done all over again All data is stored in external environment provided by the customer. This environment is secured for such events. Also, each developer has his local copy of the repository. PM 9Member of SE-Trio is hit by a car or some other object 110 Crucial information is lost and project scope must be decreased Decrease the amount of beer, SE-Experts must keep their replacements (assistants) in the loop to minimize the possible damage PM, QM, SA

11. 11 Results of the iteration Project plan –Project Plan document Requirements –Requirements document SEPA diaries –Pyry Lahti and Markus Granström –Topic: Continuous Integration and Automated Testing

12. 12 Project plan Stakeholders and staffing Project goals Project practices Tools

13. 13 Stakeholders and staffing

14. 14 Project Goals GoalVerification Criteria 1. All stakeholders are satisfied with the course outcome All group members receive grade 4-5 2. Customer is satisfied with the product Tournament management system can be used in both winter assembly and summer assembly 3. Project organization works smoothly Everyone is still on speaking terms after the project 4. Everyone reaches their personal learning goals on this course After the course each member has gained skill set which they defined 5. Winning the quality award with superior quality product Group receives quality award from Accenture 6. Creating interest in the assembly organization among the group One or more project team member becomes volunteer for ASSEMBLY Organizing

15. 15 Project Practices 1. Iterative development & Iteration planning –3 Iterations (PP, I1, I2) –2 Sprints in each implementation iteration

16. 16 Project Practices 2. Documenting –Documents created in the customer Wiki for easy availability –Weekly progress reports 3. Risk management –Identify, evaluate and prepare 4. Communication –E-mail & IRC –Mailing list –Meetings –Wiki for documents –Phone calls 5. Defect tracking and version control –Trac provided by the customer –Trac’s svn also used for time tracking (excel sheet)

17. 17 Project Practices 6. Coding conventions –C# –PHP 7. Development & Quality practices –Continuous integration –TDD –Incremental rearchitecture –Peer testing –Developer days (Side-by-side programming)

18. 18 Project tools ToolClassificationVersionAvailabilityComment MS Visual Studio.NET Development2005 ProMSDN AADe facto IDE for C# in Windows MonoDevelopDevelopment0.14http://www.monodevelop.comVisual Studio "replacement" for Linux Mono.netDevelopment1.2.5.1http://www.mono-project.com/.NET environment for non-Windows platforms NAntDevelopment0.85http://nant.sourceforge.net/A.NET build tool NUnitDevelopment2.2http://www.nunit.org/A.NET unit-testing framework AnkhSVNDevelopment1.0.2http://ankhsvn.tigris.org/Subversion-plugin for Visual Studio TortoiseSVNDevelopment1.4.5http://tortoisesvn.tigris.org/Handy Subversion-client for Windows SubversionDevelopment1.4.4http://subversion.tigris.org/The official command line SVN CruiseControl.NETDevelopment1.3http://pyppe.iki.fi:8880/ccnet/Continuous Integration tool TracDevelopment0.10.3.1https://kirves.assembly.org/trac/Project Management and bug tracking MS OfficeDocumentation2003Installed on HUT Windows desktopsOffice for documenting MS VisioDocumentation2007MSDN AATool for making charts, and graphs DoodleCommunication-http://doodle.chTool for communicating availability Google CalendarCommunication-Link from http://.trickery.biz/Calendar for project events IrssiCommunication-Installed on HUT computersTool for general communication TracWikiCommunication0.10.3.1https://kirves.assembly.org/trac/pms/wiki/Project wiki-page

19. 19 Requirements Engineering Conceptual model of TMS Use case diagram Overall status

20. 20 Requirements Engineering: Conceptual model of TMS (1/2)

21. 21 Requirements Engineering: Conceptual model of TMS (2/2)

22. 22 Requirements Engineering: Use case diagram

23. 23 Requirements Engineering: Overall status 8 use case descriptions 18 functional requirements 9 non-functional requirements Still needs to be officially approved All in all, requirements have been identified and represented quite well. –Good start for I1.

24. 24 Experiences on work practices Time reporting is still troublesome –Needs time specific DL (currently only Wed and Sun) Weekly meetings with customer –Seems to be a good way for sharing knowledge between stakeholders Individual studying –Needs benchmarking or tasks with deadlines

25. 25 Any Questions ? Thank you !