T Iteration Demo Team #13 : CloudSizzle I2 Iteration

T 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

T 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.

T 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

T Iteration demo 5

6

7

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.

T 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.

T Iteration demo System demo 10

T 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 (realized hours and updates) MLiJPäShQUHaVKoBoPKSnJVaYXiSum PP4858,873, I I Orig Curr MLiJPäShQUHaVKoBoPKSnJVaYXiSum PP I I Total Budget vs. actual I1 hour burndown I2 hour burndown

T 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.

T 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

T 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

T Iteration demo 15 Quality metrics  59 closed defects, 9 open defects (1 major, 8 minor)  2395 SLOC Python written (excluding tests)  Total 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

T 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.

T Iteration demo 17 Discussion