T Iteration Demo PP Iteration

T Iteration demo 2 Agenda  Project status (20 min)  Achieving the goals of the iteration  Project metrics  Realization of tasks  Resource usage  Work results (15 min)  Project plan  Requirements  Draft of architectural design  Used work practices (10 min)

T Iteration demo 3 Introduction to the project  Business simulation games are used in educational purposes  Some evidence of the learning results is needed  Project topic: Learning Assessment Tool  For business simulations  Primary goals of the learning assessment tool project are the following:  To extract and store key performance data from the game system on an ongoing basis  To generate reports that compare the performance of a team or a group to the average performance or set performance targets in the game  To generate reports that compare the performance of a team or a group to their performance in the previous rounds of the game  To provide what-if analysis to the players, e.g. "What would have been the bottom line effect of raising the price of my product by 1€ on round 3?"

T Iteration demo 4 Status of the iteration’s goals  Goal 1: Project planning  OK in general. Technical design MOVED LATER, because meetings with the customer were so late.  Goal 2: Understanding the domain (and getting to know the game)  OK  Goal 3: Requirements specification on general level including most important functional requirements and use cases  Requirements elicitation: OK.  Requirements analysis, OK, except use-cases MOVED LATER.  Managing changes in requirements OK, changes will be documented in the requirements document and in agilefant backlog management tool.  Goal 4: Creating prototypes to understand technologies  MOVED LATER, because all the technologies used in development are not selected yet

T Iteration demo 5 Status of the iteration’s goals  Goal 5: Defining roles and responsibilities  OK  Goal 6: Selecting working methods and tools  OK. Some development tools may be selected later  Goal 7: Preparing for the development work (building infrastructure, studying)  NOT OK. Building infrastructure was delayed because the team server was not available. We also thought we had a wrong WikiSysop password and that’s why the wiki is not very well organized yet.  Goal 8: AgileFant installation and introduction  Installation OK. Introduction MOVED LATER, this week?  Goal 9: Risk analysis  OK

T Iteration demo 6 Status of the iteration’s deliverables  Project plan  OK, except chapters 6.3 and 6.4, because the later iterations are not planned yet  Requirements document  OK, Business goals, main domain concepts, user groups and all the important functional, non-functional requirements and contstraints have been collected and documented. Functional requirements are divided into three groups. Use-cases will be done later.  SEPA diaries  OK, except chapter 3, it will be added later when there are some experiences of SEPA methods

T Iteration demo 7 Realization of the tasks (1)  27 planned tasks  34 at the end of iteration  6 new tasks:  PM013: Meetings preparation  PM014: Reviewing project plan  PM015: Writing PP iteration plan  Separated from PM007: Writing project plan  RE004: Reviewing requirements document  ST007: SEPA: Heuristic evaluation  ST008: SEPA: Pair programming  Risk management split in two tasks:  PM011: Risk identification  PM016: Risk analysis * unplanned task (= a new task added during the iteration)

T Iteration demo 8 Realization of the tasks (2) (A sample table)

T Iteration demo 9 Realization of the tasks (3)

T Iteration demo 10 Realization of the tasks (4)  All hour reports not received yet  Differences = planned – realized (shoud be r – p, fixed later)  It seems like the corresponding tasks were not always found from the time tracking system  Group meetings include all kinds of meetings among the group members  Some other tasks were carried out in the meetings (for example risk identification), but the time is still reported as group meetings time

T Iteration demo 11 Realization of the tasks (5)  Interesting discrepancies:  PM002: Internal communication +16  Did not realize that reading would also take time!  PM004: Communicating with customer -4  Quite low?  PM006: Defining project goals –6,5  Reported somewhere else  PM012: Specifying tasks -8  No-one else than PM did?  Other major discrepancies are caused by unfinished tasks  Architecture is still to be planned and technical solutions designed  No time reports of requirements engineering  Infrastructure is not ready, because:  We don’t have the server yet  We thought we had a wrong WikiSysop password

T Iteration demo 12 Resource usage JL ML I MT SUM NK PL MB EK JR TK Total I1 PP Original plan (in the beginning of the iteration) Realization and updated plan ( – To be updated later!) (realized hours and updates) JL ML I Total I PP SUMMTJRTKEKMBPLNK

T Iteration demo 13 Resource usage explanations  The PP iteration plan was done quite in a hurry and so were the estimations  We forgot to estimate hours for I1 and I2!  Although the architect thought in the project planning phase that he was allocating hours for I1  No persons responsible declared for tasks!

T Iteration demo 14 Risks  Materialized risks  2. A member is unexpectedly unavailable (for example a member becomes ill)  3. Lack of skill, knowledge or expertice  9. SoberIT server is down  10. Unequally divided work  11. Inadequate commitment to the project due to other than project activities (full day jobs, other studying)

T Iteration demo 15 Results of the iteration  Major deliverables of the iteration:  Project plan  Requirements  And:  System architecture designed this far

T Iteration demo 16 Project plan - stakeholders  Stakeholders and staffing: The project group Iteration X NameRole Mari TyllinenDeveloper Jarkko RantamäkiDeveloper Markku LinnoskiviDeveloper Jussi LampiselkäDeveloper Teemu KiviniemiDeveloper Emmi KaivosojaDeveloper Michael BurmanArchitect Pekka LatvalaQA Manager Noora Korppi-TommolaProject Manager Other stakeholders NameRole Group 4: Team MaranelloAgilefant group Group 15: Bluebox InnovationsPeer group Group 6: braZilPeer group Kari SuhonenMentor Ilkka VesterinenCustomer Veijo KyöstiCustomer Santeri KorriCustomer

T Iteration demo 17 Project plan - stakeholders  Stakeholders and staffing: organizational chart

T Iteration demo 18 Project plan – project goals  Project goals (discuss most important goals and verification criteria)  1. Code quality and documentation  Code quality: 1) Unit test reviews and code reviews. 2) Test coverage.  Code documentation: Javadocs  Arhitectural documentation: Reviewed with the customer  2. Functionality  Functionality: Reviewed with the customer  Performance: Will be measured using J-Meter  Limitations: Functionality and performance tests  3. Production Use  Data Collection: Augmented after the first iteration  Analysis: Functionality and performance in production use is reviewed with the customer  4. User Documentation  Content: Reviewed with the customer  Integration: Incorporating user documentation to Cesim's standard documentation build process

T Iteration demo 19 Project plan – project practiced and tools  Some important practices and tools  Weekly meetings  Weekly reports  WR Time tracker for time tracking  Estimations on how much time is left for completing backlog items will be tracked with Agilefant

T Iteration demo 20 Project plan – phasing  PROJECT PLANNING ( )  IMPLEMENTATION 1 ( )  Sprint 1 ( )  Design core architecture  Basic implementation tasks  Sprint 2 ( )  After 2nd sprint the most important architectural solutions are implemented as well as the most common use cases.  Sprint 3 ( )  Refactoring the code, planning and performing tests. Enjoying the Christmas vacation.  IMPLEMENTATION 2 ( )  Sprint 4 ( )  Implementing additional functional requirements.  Sprint 5 ( )  Last changes are made and the software is ready Peer testing.  Sprint 6 ( )  Documenting and presenting the final product to the customer and mentor.

T Iteration demo 21 Requirements  System overview

T Iteration demo 22 Requirements  Functional goals  Implementing statistics, analysis and learning assessment of results, decisions and selected aggregates  Implementing what-if analysis  Implementing alternative sets of calculation features  Non-functional goals  System needs to be fast, it must support enough concurrent users and all features must be available with one login  Constraints  Http-protocol, only acceptable plugin is Macromedia Flash, Resin web-server, PostqreSQL 7 & 8 Support, CentOS linux support, Java 5, HTML 4.10 strict

T Iteration demo Architechture overview  Based on modules, to keep data management and userview separate  A WebService backend for loading procedure  Customer’s original project will be extended to support extracting data through WS.  MVC based frontend to show the results  All data handling will be done with persistence  All SQL/XML handling is done using POJOs  Results might change with time  Queries have to be configureable  New parameters can be indexed from original data  Original data is saved in the database as objects

T Iteration demo Architechture overview

T Iteration demo Coding conventions  Based on Java’s general conventions  Why recreate something that works?  Extended to suit our preferences  Extensions  Exception handling  Catch only what’s necessary, not more  Test driven development  JUnit is used with every module  Improves documentation  Commenting  Javadoc is used with every method  Comments inside the method, where necessary  Logging  Internals of the system are logged  Using different levels, debug, info and error  Good Object-Oriented coding  Small interference with insides of other objects  Functional cohesion and message coupling, if possible

T Iteration demo 26 Used work practices (updated on )  How have you been using the planned work practices, what are the experiences of  mandatory practices: time reporting, version control, …  any other practices  Are you going to  adopt some new practices  change the use of the current practices  stop using some adopted practices