T-76.115 Project Review

1. T-76.115 Project Review RoadMappers Final demo 6.4.2004

2. Project background (5 min) Demo (15 min) Delivery phase (3 min) Achieving the goals of the iteration Realization of tasks Project in general (15min) Project progress (PP-I3) Aftermath Results Used work practices and tools Comments and questions (5 min) Agenda

3. Background • Main task • “Create a graphical user interface for a modelling tool for configuration tasks” • Other groups (Confuse and Comet) in previous courses have produced the underlying system • The Sarcous research project is studying the possibility to model software product families and their components • Aim to bring more automation in the configuration process • The tool will be used in the research of software product families • Testing different modelling methods for the variability in software product families • Tool provides a interface for drawing UML-like diagrams of product families and assigning dependencies like requires and conflicts to the components in diagram

4. Demo • Some of the key functionality will be presented during demo

5. DE: Goals • Fix remaining defects and finalize system • Some minor bugs remain • They are documented • Finalize project documentation - OK • Delivery of system – Customer has received system • Evaluate own work – Final report • Hold final meeting - OK

6. Bug fixing took more time than first estimated Some new bugs found Estimate was updated during phase More time in testing and defect reporting also Acceptance testing did not require effort DE: Realization of the tasks Realized tasks Not started Unplanned

7. Project progress – Project planning • First meetings • Requirements definition • Done by requirements team • Elicitation, analysis, documentation and validation phases • Project planning • Goals were set • Learning goals for team • Top-10 goals of customer • Work practices -> Quality Handbook • Project infrastructure was created • Server, CVS etc.

8. Project progress – Implementation 1 • Work practices were clarified • Design of UI in general and some use cases • UI prototype was created • Heuristic evaluation • Usability tests • Design of core architecture • Start of implementation was delayed • Not enough time to implement GUI-module • Design decisions were demonstrated with the prototype • Prototype was later used as base for GUI-module • Module integration took more time than expected • Not enough time to test • Testing was done in the beginning of the next iteration

9. Project progress – Implementation 2 • Testing of the previous iterations implementation • Design of remaining use cases • Planned usability tests were moved to I3 • Heuristic evaluation was done • Architecture was refined • Remaining use cases were implemented • GUI-module was started • Functionality existed in the underlying code, but GUI did not offer support for everything • Some of the system test could not be run • The phase was divided by the exam season and Christmas holidays • Had some trouble in getting back to work, but managed to catch up the planned schedule

10. Project progress – Implementation 3 • Last bits of design • Pop-ups, icons etc. • Usability tests • Heuristic evaluation • Remaining parts of GUI-module were implemented • Rest of the iteration consisted of testing and debugging • Unit testing was given less attention due time constraints • Peer testing • Peer group tested our system • System was not mature enough at this phase • Only six new bugs found • We tested peer groups system

11. Project progress - Delivery • Mainly testing and debugging • Acceptance testing done by customer • Final meeting was held • Final version with some bug fixes delivered to customer after acceptance testing • Document delivery • Final report • Final versions of other documents

12. Working hours by person in DE Realized hours in this iteration • The implementers (Enbuska, Siltanen, Latto) still had quite a lot of work with the bugs in the last iteration • Others could not participate in this • Also more work for test manager

13. Working hours by person in the whole project • As whole the project stayed on budget • Deviation was 1,5 % (22 hours) • Individual deviations were between -9% (18,8 hours) and +8% (16 hours) • The roles were clearly divided and in the end it was very difficult to try to participate in other persons work load • BUT not all the effort was marked to Trapoli • For example writing an e-mail takes about 5 minutes -> no need to report this • What if you wrote 100 e-mails during this project? • Over 8 hours of work that was never reported • We tried to correct this by creating a task for internal communication • Other similar activities (hidden work) still exist

14. Quality metrics 1/2 • Two usability tests (I1 and I3) • First with two users • Second with four • Heuristic evaluation • Three analyses, five evaluators • Majority of problems found were minor problems • Proposals for improvement and reporting the problems were most time-consuming • Valuable results with relatively small effort Usability problems

15. Quality metrics 2/2 • Unfixed bugs 13 • 1 critical • 5 serious • 7 minor • Unit tests: • No new tests made • Old ones slightly updated • Two test cases removed • All 53 test cases pass

16. Quality assessment • Final product satisfies item pass/fail criteria for unit level and acceptance level • It fails on system level, because there are critical and serious issues that are not resolved • Test case TC-3-13 could not be executed, because it requires that the endpoints of the relationships can be dragged with mouse • This also makes test cases TC-3-11 and TC-3-12 fail. Legend Coverage: 0 = zero coverage 1 = poor coverage 2 = adequate coverage 3 = good coverage 4 = excellent coverage 5 = full coverage Quality: J = quality is good K = not sure L = quality is bad

17. Software size in Lines of Code (LOC) • GUI contains generated code • Total LOC/COM without GUI 9465/6144 • For comparison Comet data • LOC 8987 parts used by us 5858 • COM 3466 parts used by us 2626 • LOC+COM 12 553 parts used by us 8484 • Our underlying code is bigger than the whole Comet code

18. Project goals • Receive a graphical configuration modeling tool • Customer has received the tool • Be able to edit a configuration model (change type-hierarchy and part-hierarchy, edit types etc.) • Be able to view only part of the model • Create constraints between different types • Create ports and connect ports to each other • Connecting ports does not work, but is not necessary either • Good communication with project • Customer is satisfied • Stable program, no unexpected crashes • Traceability of code to specification and to requirements • Customer did not have time to verify this • Group has no experience in this either • Architecturally good product, i.e. module divisions, clean interfaces • Customer is satisfied • For the project team to learn why 6,7,8 and 9 are important

19. Risks • Risk management utilized Riskit method (J. Kontio) • Produced risk analysis efficiently • Required active monitoring and controlling actions • 24 risk were identified and analyzed during the project • Most of these during the PP iteration • 11 risk materialized • Risk rankings: 1-5, 8, 9, 12, 13, 15, 19 • 2 risks materialized 3 times • 5 risks materialized 2 times • Rankings of the materialized risks are high • This indicates that risk analysis was successful • Utility losses of the materialized risks decreased a little during the project • Risk monitoring and controlling were quite effective

20. Work practices 1/2 • Personal assignments • Project progress tracking and control -Eila • Configuration management - Tuomo • Refactoring- Samuel • Heuristic evaluation - Sanna • Usability testing - Marko • Design patterns - Jan • Automated unit testing - Mikko • Hour reporting • Some problems in the beginning • Trapoli was unstable • Communication practices • Internal meetings improved during projects • E-mail was major communication tool • Talk was used in urgent situations • Risk management • Requirements management • Definition done in PP phase • Some obsolete requirements, but no new

21. Work practices 2/2 • Architectural design • Done by a team • Design patterns used • Coding conventions • Made code readable • Some deviations occasionally • Document reviews • First with the whole team - Inefficient • Later only few members participated in reviews when needed • Testing • Unit and system testing • Test manager in charge of things • Bug reporting • Done with Bugzilla – usability problems • Time consuming • Peer testing • Very little use • But nice experience

22. Questions?