T-76.115 Project Review

1. T-76.115 Project Review eGo PP Iteration29.10.2003

2. Project status (15min) achieving the goals of the iteration project metrics Used work practices (5 min) Completed work (20min) presenting the iteration’s results Plans for the next iteration (5 min) Agenda

3. Status of planned goals of the iteration • learning to know project team members, individual strengths and weaknesses, special interests etc. • OK • constructing the IPR agreement • OK, agreement done (IF the last persons have sign the agreement in the project review) • understanding the domain and the customer needs • OK, the project team feels it has a good overall understanding of the domain • planning the project, including: • project team members' responsibilities • OK • phasing of the project into four iterations • OK, phasing has been accepted by all stakeholders • creating preliminary tasks for the next iteration • OK, see below • selecting the most important tools and processes to be used in the project • Partially OK, questionnaire input tool selection postponed to I1 • defining project group's own goals in the project • OK

4. Status of planned goals of the iteration, cont. • requirements specification on general level, identifying the use cases and describing in greater detail the ones selected to be implemented in the first implementation iteration • OK • arranging communication channels: group web server, group e-mail address • OK, Hiekkalaatikko operational and yahoogroups address chosen • familiarizing in the technologies and development tools to be used in the project • JBoss & J2EE • Not OK, all project members don’t have sufficient skills • Eclipse + plug-ins • OK • using CVS • OK • installing the development environment to the development server and building the project skeleton to CVS so that starting the actual work is as fluent as possible • OK

5. Status of planned deliverables of the iteration • Project Plan • OK, all relevant chapters and phasing for I1 ready • Requirements document • OK, most important requirements in general, and project manager interface in detail (use cases 1 through 4) • Functional requirements only specified to the parts implemented in I1

6. Time scheduled well, total difference is minus 14,65 hours Problems with using Trapoli in the beginning Tasks not descriptive enough People kept forgetting to report their hours Hours vanished (technical problem in Trapoli) Lots of Trapoli features were misunderstood ”Plan work methods and tools” was superseded by ”write the project plan”, because it’s hard to tell planning from writing in this case Realization of the tasks

7. Working hours by person Realized hours in this iteration Plan in the beginning of this iteration • We managed to keep within the scheduled time • No modification were made to the future iterations plans at this stage, the 16 hours saved are left as a reserve for future allocation • Note that task and personal hours don’t match, someone reported hours while writing this... Latest plan (inc. realized hours and other updates)

8. Risks • The responsibility of risk management is handled by a group of three persons: Hannes Tolvanen, Lauri Helenius and Juha Koivula. These three are attending the SoberIT Risk Management Module (T-76.633) and hence have the best knowledge of this area

9. Work practices • work practices used in the PP iteration: • time reporting • Because it took time to understand how to use Trapoli effectively in our group, time reporting experiences were at first very negative • Now, with added knowledge and more specific tasks, we hope to improve time reporting • version control • CVS on the customer’s premises was harnessed into use from the beginning, in this phase mostly used for documents • Eclipse+CVS integration works very well, only few minor problems have been encountered • personal SE assignments have been selected and planned in the project plan, but none of the assignments have started yet so there’s nothing to report. • In the next phase • the personal assignment practices are started • all the other practices mentioned in the project plan are started

10. Results of the iteration • Nothing to demonstrate yet, we’ll focus on the documents produced • Deliverables for the iteration were (discussed in the following slides) • project plan • requirements • this project review • Other results • development environment ready for implementation start • group members have development tools installed (Eclipse, Lomboz, JBoss) • an initial project skeleton has been created in CVS and source generation and build automation work

11. Project plan • Stakeholders include four parties: Radar, project group, Karuko and mentor • Karuko acts as the technical advisor team • Each project team member has his own responsibility area • The top goals of the customer are: • Quality • Improving efficiency of the screening process • Improving efficiency of the segment size approximation of large crowds • Improving efficiency of small-scale ad hoc market data gathering • Having a central storage and improving communication in a marketing research project • Ease of administration • Also the project outcome will possibly be used as a base for future projects by Karuko, and therefore quality of documentation, adherence to domain best practices and reusability of components is important • The project team’s goals are strictly educational, building a quality product with interesting contemporary technologies and getting a good grade • Most of the recommended (by the course) work practices will be used • Personal assignments include • Heuristic evaluation • Design patterns • Pair Programming • Automated unit tests • Meeting practices • Communication practices • Documentation practises

12. Project plan, cont. • The project is divided into three implementation iterations • I1: project manager interface, marketing research project “definition phase” • I2: screening and interviewing, wap and web • I3: data export, triple-S to external systems, better info about ongoing projects • Risk management is done in the external course T-76.633 by three project member. Top-5 risks identified • project group members busy with work, studies or private life • customer finds a better solution • customer neglects server administration • group is not familiar with intended technologies • test plan is inadequate

13. User Requirements Document • The business domain is described in detail • terms and their relations • core competencies of the customer • System overview

14. User Requirements Document, cont. • Use cases and user groups shown in picture

15. User Requirements Document, cont. • Functional requirements • Functional requirements were identified and discussed grouped by the use cases • Also general functional requirements were identified • All functional requirements are named according to the MRRx.x –scheme for trackability • Usability requirements • Web GUI for project manager • Mobile phone used in screening • Web browser used in additional interviews • Quality and reliability requirements • Data integrity, stability, error tolerance • Also performance, scalability, documentation and further development requirements are discussed • Constraints and limitations • Student project limitations, • Free software used in development • Given user interface constraints

16. Plan for the next iteration • Goals • Have a fully working implementation of the ”definition part” of the marketing research project system • Testing done according to the testing plan • User interface evaluation and design for project manager interfaces • All technology evaluation and selection is finished • Specification of all protocols and external interfaces is done • Deliverables • Technical specification of the core architecture • Test case specifications • Test report • Software core • Use cases 1, 2, 3 and 4 implemented