T-76.4115 Iteration Demo

1. T-76.4115 Iteration Demo Team #13 : CloudSizzle I2 Iteration24.2.2010

2. Product presentation directed to the customer. (20 min) Introduction to the project Stakeholders and staffing Solution architecture System demo Project evaluation based on the final report. (20min) Achieving of project goals Resource usage Quality metrics Learning experiences Discussion Agenda

3. Introduction to the project • What ? • A social study planner for students of the Aalto University • Students can plan to take to courses and share the plan with their friends, • Students can recommend courses to their friends, • Students can see what courses their friends are planning to take. • Students can see what mutual courses he has with his friends. • Why? • to get an understanding of the Smart-M3 RDF store • to get an understanding of how it can be used to enable interoperability between OtaSizzle services and third party services. • To demonstrate how information can be extracted from Noppa and Oodi through loose coupling • Top 3 goals of the project • To achieve loose coupling between OtaSizzle services and third party services with the use of  the Smart-M3 RDF store. • To get an understanding of how Smart-M3 works in practise and what benefits and disadvantages it has. • To build a new useful service for the Aalto University students.

4. Stakeholders and staffingThe project’s environment HIIT – Helsinki Institute of Information Technology Department of Computer Science and Engineering Department of Communications and Networking External financers External stakeholders OtaSizzle Sizzle labs OtaSizzle platform CloudSizzle project OtaSizzle services Noppa administrators Kassi CloudSizzle development team Oodi administrators Ossi Peer group (#11) CityKani Students CloudSizzle Student counselors

8. Architecture discussion • The RDF store (SmartM3) • Strengths • Loose coupling, Interoperability • Enforces modularity • Weaknesses • Performance problems • No access control in smart M3 • Just open sourced, Quite buggy and immature at this time. • Not much documentation, we might be missing something very useful • Django MVT framework • Strengths : Easy to create server side web applications • Scrapy, WebCrawler framework • Makes gathering data from 3rd party systems easy. • Almost no real interfaces are needed • Detecting changes in the 3rd party systems remains an issue.

9. Achieving project goals

10. System demo

11. Resource usage Original and updated hour budget • JPä and JVa converted from 6 to 8 credit course in I1 • ShQ quit the course during I1 • KSn upgraded from 5 to 6 credit course in I2 Realized working hours up until 22.2.2010 I1 hour burndown I2 hour burndown (realized hours and updates)

12. Problems and challenges • materialized risks? • 1. A developer quits in the middlle of the project. – Software Architect. A new architect was assigned. Impact on slow start in development work. • 3. A developer may be lost in translation – Also affected development speed. Surprisingly big differences in developers’ capabilities. This has resulted in the team relying on one key developer for progress. • 7. Core components applied in the project are new and immature - Also affected development speed and workload. • Summary: • Our International multi culture team combined with the exotic immature technology requirement added to slope of the project compared with other teams.

13. Quality goals • Most important quality goals achieved • Interoperability • Smart-M3 used • Completeness • The most important requirements were implemented • Correctness • No critical bugs in the system • Documentation • Experience report of Smart-M3 • Deployment manual • Quality goal status

14. Quality assurance practices • Test case based testing • About 90 test cases • Exploratory testing • One session based test management • Informal exploratory testing used frequently in parallel with development • Most effective in finding defects • Code reviews • Two informal code reviews arranged in i2 • Collecting feedback from customer • Customer demo • Weekly newsletter • Demo site for testing • Programming sessions • At least one each week beginning from January • Evaluation of QA practices • Quality dashboard

15. Quality metrics • 59 closed defects, 9 open defects (1 major, 8 minor) • 2395 SLOC Python written (excluding tests) • Total 14634 lines in SVN including html, css, js etc • 151 files in repository. Average lines per file 96,9 • Average revisions per file 6,1 • Unit test coverage is 680 lines of 2395 lines (28%) • A total of 57 unit tests • Pylint rates the code at 7.72/10 (coding standard compliance) • Average cyclomatic complexity 1.6 -> good maintainability • More details in QA report

16. Used work practices Project • Time reporting and task management on trac tasks. Good experiences. • Work management by a relaxed scrum method. Weekly wrap-ups over Skype. • TKK Wiki and Google Docs used for document management • IRC is being used for communication. Good to a certain point. • Weekly newsletter in I2 Development • Version control. Subversion is being used. Works well • Continuous integration. Bitten is being used. Works well. • Automated unit tests are run with Pyunit. Coverage 28%. Quality assurance • Exploratory and test case based testing have been applied. • Static code analysis is being done during building. • Pair and co-operative coding sessions have been essential to get the development going for the whole team.

17. Discussion