T-76.4115 Iteration Demo

T-76.4115 Iteration Demo

Team #13 : CloudSizzleI2 Iteration

24.2.2010

T-76.4115 T-76.4115 IterationIteration demo 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

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

Stakeholders and staffingThe project’s environment

Noppa administrators

Department of Computer Science and

Engineering

Department of Communications and

Networking

External financers

External stakeholders OtaSizzle

CloudSizzle project OtaSizzle 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


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.


Achieving project goals

9

Test Smart-M3 The 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.


System demo

10


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)

MLi JPä ShQ UHa VKo BoP KSn JVa YXi SumPP 48 58,8 73,5 73,5 40 29 48 29 24 425I1 40 51 49 65 90 64 42 64 51 516I2 40 51 39 66 89 64 42 64 51 506

Orig. 120 147 147 147 201 147 120 147 120 1296Curr. 120 201 0 147 201 147 147 201 120 1284

MLi JPä ShQ UHa VKo BoP KSn JVa YXi SumPP 38 46 56 16 26 19 36 33 18 288I1 43 67 0 83 69 53 76 95 53 540I2 30 120 0 40 108 73 35 105 49 560

Total 111 233 0 139 203 145 146 234 120 1331Budget vs.

actual 9 -32 0 8 -2 2 1 -33 0 -47

I1 hour burndown

I2 hour burndown


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.


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

13


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

14


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

T-76.4115 Iteration Demo

Documents

smartm3 rdf store

cloudsizzlei2 iteration

iteration demoteam

aalto students

test smartm3

party services

aalto university students

production level rdf