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

2. T-76.4115 Iteration demo 2 Agenda  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

3. T-76.4115 Iteration demo 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 1.To achieve loose coupling between OtaSizzle services and third party services with the use of the Smart-M3 RDF store. 2.To get an understanding of how Smart-M3 works in practise and what benefits and disadvantages it has. 3.To build a new useful service for the Aalto University students.

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

5. T-76.4115 Iteration demo 5

6. 6

7. 7

8. 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. T-76.4115 Iteration demo Achieving project goals 9 Test Smart-M3The project successfully piloted the Smart-M3 RDF store through the developed social study planner. The requirement of loose coupling was achieved and piloted in I1. The project revealed some serious defects in that system that prohibit it as working as a production level RDF store. Also the project was able to test the feasibility of applying an RDF store for this kind of a system. Build a useful service for Aalto Students The project succeeded in developing a useful service for Aalto students. Given the defects in the platform and the prototype characteristics of the system, it cannot however as such be put into production use. The peer group thought that the system looked very nice and was easy to use for the target group. Create a social study planner The project succeeded in defining, designing, developing and testing a social study planner. Attract more users to OtaSizzle SizzleLabs can use the developed system as a basis for a future service to attract more users to OtaSizzle. The end result of this project cannot however be used as such for that purpose, so we can't really argue that this project attracted more OtaSizzle users. The produced system is easily maintainable The developed system is easily maintainable because the RDF store (Smart-M3) forces low coupling between components and Django provides a pre-defined well structured backbone to the user interface. Convince other systems (Oodi) to offer APIs This goal will be left for the customer orgainsation to work upon. To get research data for social services This project provides a tool where social services can be piloted in the future.

10. T-76.4115 Iteration demo System demo 10

11. T-76.4115 Iteration demo 11 Resource usage  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 Original and updated hour budget Realized working hours up until 22.2.2010 (realized hours and updates) MLiJPäShQUHaVKoBoPKSnJVaYXiSum PP4858,873,5 4029482924425 I1405149659064426451516 I2405139668964426451506 Orig.120147 2011471201471201296 Curr.1202010147201147 2011201284 MLiJPäShQUHaVKoBoPKSnJVaYXiSum PP384656162619363318288 I143670836953769553540 I230120040108733510549560 Total11123301392031451462341201331 Budget vs. actual9-3208-221-330-47 I1 hour burndown I2 hour burndown

12. T-76.4115 Iteration demo 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. T-76.4115 Iteration demo 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 Quality goal status 13

14. T-76.4115 Iteration demo 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 Evaluation of QA practices  Quality dashboard Quality dashboard 14

15. T-76.4115 Iteration demo 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 reportQA report

16. T-76.4115 Iteration demo 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. T-76.4115 Iteration demo 17 Discussion