T-76.115 Project Review

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

2. Project status (15 min) Achieving the goals of the iteration Status of the deliverables Resource usage Risk review Used work practices (5 min) Completed work (15 min) Presenting the iteration’s results and deliverables more precisely Project plan Requirement specification Technical specification Plans for the next iteration (5 min) Agenda

3. Status of planned goals of the iteration • Goal 1: Specify the goals of the project from all perspectives • OK • Goal 2: Select and adapt work practices to be used in the project • OK • Goal 3: Define requirements for system to be delivered • OK • Goal 4: Define language to be used in describing models • OK • Goal 5: Define system-level architecture • OK • Goal 6: Schedule remaining iterations of project • OK, although we decided only to evaluate next iteration more carefully

4. Status of planned deliverables of the iteration • Project Plan • OK, except • Chapter 1.3 (Rights to project outcome), because we decided to postpone the discussion regarding the commercial rights. • Chapters 6.4-6.6 (Project phases I2-DD), because we decided to postpone task-level planning until the end of the previous iteration. • Requirements specification • OK • Technical specification • OK • Language specification • OK

5. Working hours by person Realized hours in this iteration Latest plan for remaining iterations • No exact plans for PP iteration had been made

6. Realization of the tasks • No data available for several reasons • Trapoli is not working properly. We spent numerous hours inputting the data again and again, but still the program was losing the information. • No precise planning of resource usage was performed for this iteration. • Most planned tasks were finished in time, but resource usage was heavy due to nature of project

7. Risks • Three members of the group are participating also in the courseT-76.633 Special Course in Software Engineering: Risk Management. • Risks were identified in a brainstorming session and they were analysed in a group. • All of the risks that were identified are in control • back-up plans have been made • considered relatively harmless • not dependent of the group • Risk management practises will be specified during the next iteration. • Since the risk identification session, one additional risk has been identified and it has also materialized. • A risk is involved in the obligatory tools, e.g. Trapoli. • Trapoli is not working properly and this is causing delays and unplanned work for the project. • Risk has been managed since all the group members have gathered the required information also to another location besides Trapoli.

8. Work practices • So far time management and version control tools have been used • Time management system Trapoli has been problematic, there seem to be bugs in the system • Documentation practices have been used to some extend in finalising deliverables • OpenOffice.org seems a suitable solution, but Dia has some problems regarding different versions of the software. • Process needs to be worked on, but basics are ok. • During phase I1 a more systematic approach will be started regarding several work practices • Meeting practices • Coding standard • Pair-programming • Testing practice

9. Results of the iteration • The most important result for the Project planning iteration was a thorough understanding of the project ahead. • This target was met quite well. Every person within the project group has some kind of understanding of the system under work, at least to the extend required for them to perform their tasks. • The project group also spent time in meetings to gain understanding in each others’ way of thinking, which is important for a successful completion of the project. • Other results were the deliverables • Project plan • Requirements specification • Language specification • Technical specification

10. Project plan • Background of the project • Customer is SoberIT / WeCoTin • Idea is to develop a system for solving boundaries for linear limitation problems • Project organization • Project manager Hannu Kauppinen • Documentation Jouni Karppinen • Language Joonas Kekoni • Usability Mitro Kuha • Architecture Tuomas Luttinen • Requirements Vesa Salento • Testing Kalle Valo • Customer Juha Tiihonen • Technical advisor Juha Nurmilaakso • Mentor Pietu Pohjalainen

11. Project plan (2) • Project goals • Develop Lmodels as defined in the requirements specification • During the development the objectives of the project group and customer will be obeyed • Project resources • Main resources are the human resources from the project group and customer • Estimated market value for human resources is 115 000 € • Some other resources are required, but the value of these is insignificant • Project practices and tools • Currently some practises have been defined • Testing practises • Programming practises • Documentation practises • Meeting practises • Several tools have been selected for the project • Java, GNU Make, CVS, Cup, JLex, GPLK, Bugzilla, Trapoli, OpenOffice.org, Dia, CCCC

12. Project plan (3) • Iterations • Project divided into 5 iterations • Project planning (PP) 4 weeks • Implementation I (I1) 5 weeks • Implementation II (I2) 10 weeks (incl. Christmas holiday) • Implementation III (I3) 5 weeks • Delivery (DE) 3 weeks • Risk management plan • Risk identification has been performed through brainstorming • Risks have been categorized and preliminary management plans have been made • Risk management will be defined more precisely during the next iteration

13. Requirements specification • Example of a problem setting: # muuttujat määritellään ennen rajoitetta boolean kaksitaajuus, lahialue, ilta_tai_viikonloppu; # kokonais- ja liukulukulukumuuttujat, joilla on sama domain,# voidaan määrittää samalla kertaa integer C, CD, PC [0,1]; float kuukausimaksu [5.5,200]; # rajoite (kaksitaajuus implies (C = 0)) and (not(kaksitaajuus or kaksitaajuus or kaksitaajuus ) implies (CD = 0)) and (lahialue implies (C = 0)) and (not(lahialue) implies (PC = 0)) and (ilta_tai_viikonloppu implies (CD = 0)) and (not(ilta_tai_viikonloppu) implies (PC = 0)) and (C + CD + PC = 1)and (3.33 * C + 3.5 * CD + 3.67 * PC <= kuukausimaksu)

14. Requirements specification (2) • All requirements were classified and prioritised • Classifications • language requirements • user requirements • functional requirements • miscellaneous requirements • Prioritizations • 1 – Critical • 2 – Important • 3 – Additional • The requirements specification forms the basis for the following iterations since it defines the desired end results of the project • Important when designing the test cases

15. Language specification • Defined in close co-operation with customer • Presented as an appendix of requirements specification due to its nature

16. Technical specification

17. Plan for the next iteration • Goals • Goal 1: Designing client-server model • Goal 2: Implementation of linearization • Goal 3: Finalization of technical specification • Goal 4: Translating model from language • Goal 5: Designing linearisator and defining its interfaces • Goal 6: Designing interface for the solver • Goal 7: Building the basis of the client

18. Plan for the next iteration (2) • Deliverables • Project plan (updated) • Requirements specification (updated) • Technical specification (updated) • Testing plan • Implemented software • Priorities between goals • The internal parts of the system (linearisator, language translation) are the most important goals • Work on the client will be started, but with a low priority • Risks / uncertainties • Exact affect of Mitro’s vacation is still a question • Potential problems with mathematical content will rise during the next iteration • Schedule • Task prioritisation will be done in the beginning of the iteration • Internal deadlines will be set on task-level, currently no need for setting deadlines for different tasks