T-76.4115 Iteration Demo Neula I1 Iteration 12.12.2008

T-76.4115 Iteration Demo

NeulaI1 Iteration

12.12.2008

Agenda

2

Introduction - Our key issues

Status of the iterations goals and deliverables

Technical Overview and Demo

Resources and progress

Quality status

Changes to the project

Risks

Other results of the project

Introduction to the project

3

Increased usability

Value for customers

Brand recognition

Enabling external development

… For which Suunto’s goals are…

… Which means that our key issues are…

Understanding the customers – Suunto and its users

Understanding possiblities for sports web 2.0

High level of collaboration – as external developers

We are creating gadgets…

4





Quality status


Risks


Status of the iteration’s goals and deliverables

5

3 gadgets with working functionality

5 Gadget prototypes

10 more prototype descriptions

Course documents

Implement the quality assurance measures

Implement the project management measures

Learning the platforms

Platform documents

Decisions with Suunto

2 new gadgets

Goals Difficulties and decisions Status

2 Gadgets that will be developed to commercial

Being reviewed by Suunto

Platform documents

2 new gadgets:

1 new platform, 1 new gadget

3 new prototype descriptions

Difficulty of gadgets

Done Progress report

6





Quality status


Risks



A1

Architecture

Demo

A2RelayChallenge Facebook

SimpleMeter iGoogle

1. Functional view

1. Parts and interconnections

2. Development view

1. Class diagram

Architecture

Demo

1. Functional view


2. Development view

1. Class diagram

JavaScript source code

External data interface

My Suunto

My Suunto

DB

API

iGoogle Canvas

Application A1:SimpleMeter

Application server

Google DB

User

Brow

ser

Browser

ImagesStyle Sheets

Hosting of

Functional view

LoggingView ViewCommonsSimple Meter View

SimpleMeter

Engine

LanguageUtils

Database Accessors

Google DB

Use

Google

Simplemeter Preferences

APIGoogle

DB

My Suunto

DB

API

My Suunto

Development view

Simple MeteriGoogle

Demo A1


A1

Architecture

Demo

A2RelayChallenge Facebook

SimpleMeter iGoogle

1. Functional view


2. Development view

1. Class diagram

Architecture

Demo

1. Functional view


2. Development view

1. Class diagram

User interface

External data interface

Facebook user data

My Suunto

My Suunto

DB

API

Application server

Application A2:Relay challenge

A PI

Facebook

Browser

DB

Shown in

User

Browse

r

Functional view

HTTP GET/POST

Mapper

Actions Pages

Permission/logic

Managers

Connectors

Suunto

DBNeula

DB

Facebook

DB

Databases

Connectors

Managers

Controllers

The Relay ChallengeFacebook

Demo A2

15





Quality status


Risks


Earned value of development work compared to the initial goals of the project

16

Total hours realized for the whole team (week 49): 825 out of 1494

Total development hours: 322,5 out of 624

Used hours

Team totals

Developers

Tasks

18

The planned total development hours was 567

We have a total of 624 development hours

We have been able to minimize

non-productive work.

Development workPlanned Realized

322,5 / 624 development hours used 2 gadgets of working functionality.

10% decrease in work load 4 working quality gadgets.

3 commercial quality and 1 working functionality?

20





Quality status


Risks


Development Process and Quality• Simultaneous development of autonomous tiny

applications• Three predefined qualitative levels of quality as a custom

framework

Prototype Description

(Level 0)

Prototype(Level 1)

WorkingQuality

(Level 2)

Commercial Quality(Level 3)

RequirementsCycle

Customer Feedback

Delivery

PlatformLearning

CodingTesting &

UI finalizingInnovating

Main Focus

Current Quality PaletteQuality Goal vs. Quality Practice(effect 1 - 3)

QG 1Compatibility

QG 2Layout

QG 3Usability

QG 4Localization

QG5Innovativeness

QG 6Exploration

QG 7Variety

Unit testing X 1Test cases X 1 X 1 X 1Explorative testing X 2 X 2 X 2 X 1

Coding standardsX 1

Side-by-side programming X 3 O 2 O 3 X 3

Code reviews X 2 O 2Heuristics X 2 X 1Documentation X 1 X 1 X 2General project management X 3 X 2 X 2

Dialogue with the customer X 3 X 3 X 3 X 2

Green = Used frequently Yellow = Used time to time Red = Rarely used

Defect Statistics

RelayChallenge (FB)

SimpleMeter

0.25 0.75 1.25 1.75 2.25 2.75 3.25 3.75 4.25RelayChallenge (FB) SimpleMeter

Major 2 0

Normal 4 3

Minor 1 0

Enhancement 2 2

Defect breakdown

14%

50%

7%

29%

Overall statistics

MajorNormalMinorEnhancement

• Defect reporting not considered very important at this phase Side-by-side programming and communication helps fixing

minor errors in practice

Code Statistics

• RelayChallenge 2795 lines• SimpleMeter 908 lines

Selected coding standards too narrow and time consuming vs. opportunity cost (in lost development time)

Value-added?

Quality Summary

• Practices have to be value-adding• Preliminary quality plans altered– Unit testing in minor role (web development

limitations)– Test cases will be executed mostly as acceptance

testing leaving integration and system levels debatable

– Defect reporting mostly academic exercise in I1• Coding standards need reviewing

26





Quality status


Risks



• Project planning iteration:

• Iteration 1:

27

Brainstorming

Creation of prototype descriptions in the team

Feedback and refining

[Meeting]

Discussion and ranking of prototypes

[Development]

New prototype descriptions

Sprint cycle

Iteration cycle

Requirements cycle

Goal discussion

Learning Insufficient

documentation Platforms

New platforms is a priority

Documenting platforms

Commercial quality is the priority

The priority is to complete the A1 and A2 gadgets to commercial quality and develop A3 and A4 to working functionality.

A3: new gadget for Vista

A4: Same gadget for OpenSocial

28





Quality status


Risks


Risks

29

Customer satisfaction of designs and working practices risks minimized

Sharing of tacit knowledge started and will be continued

More time has gone to learning the technology platforms

The interfaces from Suunto have not been opened yet.

The technology platforms are not documented as well as expected

According to the contingency plan:

1. Goals have been adjusted

2. Schedule has been adjusted to be more flexible

ID Risk Effect How to avoid Contingency plan Responsible Severity Probability at start of project

Probability

R1 The customer is not satisfied with the prototype descriptions

We run out of time because it is too difficult to innovate good enough gadgets

Concentrate on a pre-defined process and rules for the prototype descriptions and the creation of backlog

Set a deadline for new gadget descriptions, demand input from Suunto, begin to implement after the deadline

Paavo Häppölä 5 4 0

R2 Team cannot find common ground for communications and meeting practices

Time is wasted and we never get to the implementation phase

Start meetings early in the project and discuss the issues

Split team up into smaller parts that have their own meetings. Share responsibility

Riku Seppälä 5 4 0

R3 The documentation is not done properly, the customer is only given source code but no exchange of tacit knowledge is made

The project doesn't benefit Suunto as much as planned

Concentrate on the documentation and ask for feedback from Suunto

Create the documentation after the project is finished.


R4 Communication doesn't work, Suunto doesn't understand what we're doing and we don't know about their requirements

The targets are not met, we deliver an unusable product

Plan enough meetings and send clear descriptions of gadgets to be implemented, not just a description of functions. Engage Suunto in the innovation process

Add meetings to discuss communication issues

Paavo Häppölä 5 5 2

R5 The workload is distributed unevenly

Some members get frustrated and others not engaged. Quality suffers and no one enjoys the project

Have set times for working together and a weekly meeting where everyone has to be present or have a legitimate reason for not being present. Follow up on tasks accomplished and concentrate on scheduling

Remake the teams and delegate more responsibilites


R6 Most of the time is spent for optimizing for the course requirements and not for the actual project outcomes

Customer and project members are dissatisfied

Keep documentation light and let project manager handle the documentation for the course. Everyone doesn't have to be involved, keep everyone up-to-date at meetings instead

Concentrate more on the customer needs.


R7 The needed technologies can not be mastered in time. We are not able to make the prototype descriptons reality

The goals cannot be met Concentrate on what is most important, the important functionalities and leave the most difficult implementations to the end. Don't promise too big.

Go back to the designs and design simpler gadgets. Use more familiar technologies

Eero Palomäki 5 4 5

R8 Important persons from the customer side cannot be reached

Time runs out. The requirements elicitation takes up too much time.

Know when people are present. Use the telephone for communications. Have set practices and deadlines for gathering requirements

Take more control of requirements Riku Seppälä 3 4 1

R9 The technologies and support needed from the client cannot be delivered on time

Time runs out. The development becomes unneccesarily difficult, development effort goes to creating dummy interfaces etc.

Understand the requirements, keep in contact with the IT of Suunto

Lower the goals Eero Palomäki 3 4 5

R10 Used tools and technologies are poorly supported and development becomes difficult

Time runs out. Use well documented and/or familiar tools and technologies

Switch to other tools, lower the goals

Eero Palomäki 5 2 5

R10 Because of implementing the interfaces, we're not able to finish the gadgets

Time runs out. When we get the interfaces, start implementing them right away for the gadgets that have been developed already.

Chnage the goals Eero Palomäki 5 2 3

1 New risk has been identified: Time pressure from implementing the interfaces.

30





Quality status


Risks


Reflection workshop

• Is there anything that could be done better to help the development work?

• Are the communications working properly?

Key Issues

• A lot of time is spent figuring out how to fit the development to the quality practices

• A lot of time is spent mending the code to the coding standards – but it doesn’t improve readability

Complaints

• To save time for coding, we will not follow the coding standards too rigorously. It doesn’t improve readability of

the code.

• Communications are working very well, the Friday meetings are very good, information flows and everyone

knows what’s going on.

Improvements

Documents

T-76.4115 Iteration Demo Neula I1 Iteration 12.12.2008