T-76.4115 Iteration T-76.4115 Iteration DemoDemoSoftware TrickeryI2 Iteration

5.3.2008

2

Agenda for presentationAgenda for presentation

• Project status (5 min)– Achieving the goals of the project– Project metrics

• Work results (25 min)– Brief overview of the system– Demo of TMS

• Quality Assurance (10 min)– Continuous integration– Automated unit and acceptance tests– Agile methods, and used practices

3

Introduction to the project:Introduction to the project:Tournament Management SystemTournament Management System

• Module for Party management system v2.0 (PMS)– Modular web-based system for managing party events– E.g. used in Assembly events

• Tournament management system module (TMS)– Replaces existing system (non PMS-module)– A solution for managing game tournaments– Main user groups

• Administrators• Tournament players• Outside spectators

– Will be first used at Winter Assembly 2008 gaming festival• Estimated 1500 users at this event

4

Status of the project’s goalsStatus of the project’s goals

• Goal 1: All stakeholders satisfied with course outcome– OK, the final points will tell

• Goal 2: Customer is satisfied with the product – OK, TMS to be used in Winter Assembly 2008

• Goal 3: Project organization works smoothly – OK, Everyone still happy

• Goal 4: Everyone reaches their personal learning goals on this course– OK

• Goal 5: Winning the quality award with superior quality product– OK, looks pretty good

• Goal 6: Creating interest in the assembly organization among the group– OK, at least 1 developer going to WA 2008 as an organizer

5

Status of the iteration’s Status of the iteration’s deliverablesdeliverables

• Project plan, QA-plan, Requirements document & Technical specification– OK, updated

• Test cases, QA report and test logs – OK

• Software and online user manual– OK – Known defects listed in customer’s Trac

• Final report – OK

• T-76.5158: SEPA diaries– OK

6

Resource usageResource usage

• DevDays helped to utilize

• Ok, 5% error goal set for the iteration reached

PM QM SA MaG

MiA ToA JaL MaH

ErH SUM

PP 55 70 14 10 4 5 6 11 9 184I1 43 67 78 76 33 60 24 52 50 483I2 52 53 58 104 88 85 110 87 91 728Total

150 190 150 190 125 150 150 150 150 1405

Original plan (in the beginning of the iteration)

Realization and updated plan (realized hours)

PM

QM SA MaG

MiA

ToA

JaL MaH

ErH

SUM

PP 55 70 14 10 4 5 6 11 9 184

I1 43 67 78 76 33 60 24 52 50 483

I2 51 62 57 107 80 83 107

88 90 728

Total

149

199 149

193 117

148 147 151 149

1402

7

Results of the iteration I2Results of the iteration I2

• New major features developed during I2– Phase types

• Double-elimination, Round-robin, Single-result

– Clan management– Seeding

• By rank

– Online admin user’s manual – New user interface

• Tested by peer group

8

System overviewSystem overview

9

PMS permissionsPMS permissions

Users User groups Permissions

Administer module X

Administer tournaments

Site admins

Tournament administrators

Organizer

10

TMS access controlTMS access control

TMS

Administer tournaments

TMS Administration

Organizer

PMS Administration

”Authenticated user”

PMS

Organizer

Create tournaments Edit Tournaments

Organizer

Administer clans / games / platforms

Framework

Modules

Actions

11

Sample tournamentSample tournament

Group B

1.2.3.

Group A

1.2.3.

Finals

A1 vs B2B1 vs A2

1. and 2.

1. and 2.

12

DemoDemo

• The actual software developed• You may use the demo script to follow the presentation

13

Quality Assurance (1/3):Quality Assurance (1/3):Quality dashboardQuality dashboard

Part of the systemQualit

yConfiden

ce Comments

Administrative functionality

3 • Thoroughly tested by acceptance-level test suites and exploratory testing.

• Some minor usability issues are still at large, but the overall status is very good.

Participant functionality

3 • Thoroughly tested by acceptance-level test suites and exploratory testing.

Tournament phases and progression

2 • The tournament progression and phases contain a huge amount of special cases. These could have been tested a bit more thoroughly.

Spectator functionality

3 • Thoroughly tested by acceptance-level test suites and exploratory testing.

14

Quality Assurance (2/3):Quality Assurance (2/3):Quality goalsQuality goals

Goal Status Reasoning

QG01: Functionality • Almost everything is implemented that were planned for I2.

• Although, some of the less important nice-to-have features had to be dropped out.

QG02: Usability • The test results provided by the customer and our peer group indicate that the system is easy to use.

• However, there are some issues due to the fact the amount of functionalities, especially in the admin part of the software, is very high. Nonetheless, the overall status of usability is good.

QG03: Code correctness

• We have extensive suites of automated unit and acceptance tests for all the important features.

QG04: Security • We have automated unit-tests and acceptance-level tests for all the most important features.

• PMS-platform acts as a safety-net.

QG05: Maintainability • Code is not as clear and commented as well as it could have been.

15

Quality Assurance (3/3):Quality Assurance (3/3):CruiseControl & automated testingCruiseControl & automated testing• Automated unit-tests (NUnit)

– 45 test cases concentrating on the most important modules

• Automated acceptance-tests (Selenium)

– Thorough suite of 111 test cases

• Automated performance-tests (JMeter)

• Code metrics and analysis• Linking between failed

acceptance-tests and defect reports

• See http://pyppe.iki.fi:8880/ccnet/

Number of builds:

428

Number of failed builds:

37 (of which 84% was caused by failing unit tests)

Build success rate:

91%

Avg. build fix time:

80 minutes

Median of build fix time:

62 minutes

Maximum build fix time:

5 hours 24 minutes

Minimum build fix time:

4 minutes

16

Changes to the projectChanges to the project

• Moved to regular development days in I2– Project not so distributed anymore

• Requirement for new UI in sprint S2.2– More important to customer than functionalities

17

Agile methodsAgile methods- used work practices- used work practices

• Regular development days– Held 2 or 3 times a week

• Weekly status meetings– Held every Tuesday– Customer present

• Version control and documentation on customer server– Helps customer to find software and documentation

• Demo environment for external stakeholders– Running 24/7 after I1

• Automated testing– Unit and acceptance-level

• The Carrots of Agility

18

Any Questions ?Any Questions ?

• Software Trickery would like to thank everyone!