T-76.4115 Final Demo

1. T-76.4115 Final Demo Tikkaajat I2 Iteration4.3.2008

2. Evaluation of the results (8min) Goals Quality Challenges Delivered documents Metrics (4min) Resources QA metrics Work practices and educational value (8min) Used practices Faced problems Important lessons Demo (20min) Agenda

3. Introduction to the project • jEhIntranet System • Informational logistic solution for Eduhouse Oy • coordinating system for customers, employees, and operations

4. Evaluation of the results

5. Development level goals The overall goal for the project was to reconstruct the current system into the Java based application using frameworks suggested by the customer. The following table describes major level goals in priority order.

6. Project level goals • Project level goals • Mostly focused to the resources, schedules, responsibilities, learning of the unknown technologies and communication. • Responsibilities were shared • Communication practices was used widely between IRC -discussion to the weekly face to face meetings

7. Quality goals The following table describes the status of project’s quality goals (in priority order) Quality: J = quality is good K= some issues still open L = quality is bad

8. Challenges • New technology • Team was required to work with various technologies • Training and prototyping was necessary • Finding the right persons for a task • Who can do and what? • Lack of documentation • There were many situations where • customer's experiences were needed • the project team misunderstood the current solution • International project team • Communication and documentation had to be in English • System’s user interface is Finnish • Hard for an exchange student to understand what the system does

9. Results of the project • Delivered documents • Project plan • Requirements documents • System architecture • QA report • Test case matrix and log • Code review logs • Test charters • Peer test session charters with exploration logs + summaries • User’s manual • Final report • Slides for the final demo • SEPA diaries • Demonstration • Demo scenario

10. Metrics

11. Realization of the tasks

12. Resource usage Original plan (in the beginning of the iteration) Realization and updated plan • More hours spent than estimated • The project team decided together at the beginning of the last iteration, • that all tasks will be finished, without thinking about overlapping of the personal hours.

13. Resource division

14. Defects and other quality metrics • No blocker or critical bugs open • Open bugs are mostly resulted from the personal details feature Ratio of passing test cases: 13/15 Ratio of closed and found defects: 50/61

15. Source code metrics LOC- P = Physical Executable Lines of Code (Empty lines not included, comments not included) CLOC = Comment lines of code Comment ratio = LOC-P / CLOC Total LOC = includes every line in the file

16. Work practices and educational value

17. Three most important work practices • Iterative development • Project was designed into the three iterations, which were divided into sprints • Development of every functional component was designed so, that the system was build against priority order • Waterfall -based process model couldn't be the selection in this kind of projects, where requirements are allowed to change • Iteration planning • Idea was to design the next iterations goals and estimate needed resources in advance • If problems occurs during the iteration, we could react rapidly. This means that the next sprint might be minored, because more important task is still in progress. • Allowed the management team to estimate the progress of the iteration quite soon • Requirements engineering • Helped us to understand the system to be built • Requirements document was useful in the first half of the project • Problems • Hard to get all requirements by just communicating with the customer • In implementation II, customer wrote specific requirements for certain features for developers to use.

18. Other work practices • Documenting • Risk management • Time tracking • Communication • Iteration demo • Defect tracking • Version control • Coding conventions • Process improvement • Change management • Design • Standards

19. Used QA practices • Test case based testing • Executed test cases: 15 • Passed test cases: 13 • All functional requirements that were reported as ready, were tested by test cases. • Exploratory testing • Testing was done by team members and by the peer group. Unfortunately, not all testing was documented. Most bugs that were reported were found during exploratory testing. • Code reviews • Source code review sessions were held in 5.12.2007 and 1.2.2008. During the code reviews, pairs reported their findings to the review log templates. Customer has access to these logs. • Unit testing • 20 unit tests were written in implementation II. 13 of them test the converter. • Pair programming • Conversion was 100% pair programmed • Personal details and search components were 50% pair programmed

20. Tools • Project management • MediaWiki • Bugzilla • Weekly Reporting Tool (by the manager) • MS Excel • MS Word • MS PowerPoint • LocMetrics • Development software • Apache Ant • Subversion • Eclipse • Environment • Java • Tomcat • MySQL • Hibernate • Velocity • ContextWaf • Joda Time

21. Educational value (1/2)Faced problems • Misunderstood requirements • Almost impossible task to specify the system in advance in a low level. • management team had to specify the requirements again, and developers had to re-implement, or at least fix the functional component. • The project team didn't understood correctly what the customer really expected – it was actually very qualitative code, not the amount correct functionality, which was the second priority. • Unrealistic schedule • team noticed a huge need for extra efforts to reach the iterations goals. • management team with the customer didn't understood the complexity of the database to be converted • Lack of testing • It may be that, the testing was seen as a boring task and what most, documentation of the testing was slapped away • New validation process was designed to prove that the quality is met in developed components.

22. Educational value (2/2)Important lessons • Agile software development methods in a real project • Many of the team members have studied methods of software engineering and agile development activities • Studies and the real-world was finally present at the same time. • Exploit experiences in the future • The project team had adopt new technology quickly and to learn how to use it • International project • Experiences will certain help the team members in the future. • Challenges in software development • There was a real problem domain in the project • Using the lessons learned from school courses • Team work is the key to advance • Communication language was English • good team spirit was present • Different people possess different skills.

23. Comparision • Similarities to the previous projects • Resource usage estimation is a hard task and goes usually wrong • Different stakeholders feel quality in a different way • Lacks in the low level testing (testing was felt boring) • Huge amount of documentation • Requirements changed • Differences to the previous projects • Very active customer involvement • Agile development process • Requirements were to be changed • Good communication between different stakeholders • Weekly meetings as a practice • New technology (developers are usually familiar with the technology) • Large and international project team • The current system was to be re-implemented

24. Demo

25. Demo • Database conversion • Shown features • Login • Viewing calendar • Search • Viewing trainer and customer information • Modifying trainer information • Logout

26. Thank You!