Transcript Progress report - I1

T-76.4115 Iteration Demo
Tikkaajat
[I1] Iteration
9.12.2007
T-76.4115 Iteration demo
Agenda

Project status (25 min)



Work results (20 min)



achieving the goals of the iteration
project metrics
presenting the iteration’s results
demo
Used work practices (5 min)
2
T-76.4115 Iteration demo
Introduction to the project

jEhIntranet System

Informational logistic solution for Eduhouse Oy

coordinating system for customers, employees, and operations
3
T-76.4115 Iteration demo
Introduction to the project

jEhIntranet System

Current system allready exist



Extended over time
 Overlapping
 Cluttered code
 Low speed functionality
Lack of documentation
The basic idea is to re-develop the current system as ready as possible


Using Java language and different techniques
 Hibernate, Velocity, Ajax
Documentation for furher development
4
T-76.4115 Iteration demo
Status of the iteration’s goals

Goal 1: Designing of quality assurance


Goal 2: Designing of test cases


OK
Goal 5: Conversion System for database designed, implemented, tested



OK
Goal 4: Database is ready to use


OK
Goal 3: Architecture is finalized


OK
MOVED LATER, because the task was underestimated - more resources is
needed
Partial conversion OK, decided together with the customer
Goal 6: Login and logout implemented and tested

OK
5
T-76.4115 Iteration demo
Status of the iteration’s deliverables
Documentation:

Quality Assurance Plan


Updated Project Plan


UCP009 is under development. Will be tested as soon as reported as ready.
QA report and test log


OK, derived from the use cases: UCP001, UCP002, UCP006, UCP009
Use cases UCP001, UCP002 implemented and tested


OK
Test cases


OK, updated chapters 3, 6
Technical Specification


OK, updated chapters 4.1 and 6.
Updated Requirements document


OK
OK
Progress report

OK
6
T-76.4115 Iteration demo
Status of the iteration’s deliverables
Software:

Build environment


Database classes and related Hibernate mappings




OK, designed, implemented and tested against requirements
Customer validation
Some changes need to be done
Conversion System for database




OK
Partial conversion OK
Need much more resources than estimated
Database conversion moved later
Working skeleton of the system




Personnel Login, OK
Personnel Logout, OK
Main Page for Personnel, OK (surpass the goals)
Personnel Calendar, Functionality OK (surpass the goals), but the code doesn’t
respect guidelines as it should
7
Realization of the tasks
T-76.4115 Iteration demo
Status
Realized
Planned
Diff
(Left)
Task 1. Iteration plan
Ok
8
12
Task 2. Quality assurance plan
Ok
19,5
11
+ 8,5
Task 3. Technical design and documentation
Ok
73
49
+ 24
Ok
94,5
39
+ 55,5
Unfinished
68
39
+ 29
Task 6. Engine Design and Implementation
Ok
86
63
+ 23
Task 7. GUI Design and Implementation
Ok
84
73
+ 11
Task 8. Unit level testing and code reviews
Ok
43
45,5
- 2,5
2,5
Task 9. Test cases
Ok
5
17
--
12
Task 10. Requirements engineering
Ok
8
6,5
Task 11. Risk Management
Ok
1
10
Task 12. Quality Assurance
Ok
9,5
11
Task 11. Project tracking
Ok
10
10
Task 12. Progress report
Ok
12
17
Task 13. Meetings
Ok
83,5
72
+ 11,5
Task 14. Arrangements
Ok
40,5
9
+ 31,5
Task 15. Communication
Ok
13,5
19
- 5,5
5,5
Task 16. SEPA – Pair Programming
Unfinished
9
20
--
11
11
Task 17. SEPA – Automated Unit Testing
Unfinished
0
20
--
20
20
672
603
PLANNING AND ARCHITECTURE
--
4
4
DEVELOPMENT
Task 4. Database design and implementation
Task 5. Data conversion system
QA AND RE ACTIVITIES
12
+ 1,5
MANAGEMENT
0
--
5
UNCLASSIFIED TASKS
Total:
+ 69
8
T-76.4115 Iteration demo
Resource usage
Original plan (in the beginning of the iteration)
TL
TH SM VS
PP
71 73,5 56,5 49
I1
76 75,5 47,5 75
I2
43
41
46
66
Total 190 190 150 190
ST
19
61
70
150
VH
67
75
48
190
TM
36
82
72
190
TI
42
64
44
150
YZ
33
47
70
150
SUM
525
603
500
1550
TL
TH SM VS
ST VH
PP
71 73,5 56,5 49
19
67
I1
81 92,5 47,5 94 40,5 91,5
I2
38
24
46
47 90,5 31,5
Total 190 190 150 190 150 190
TM
36
100
54
190
TI
42
74,5
33,5
150
YZ SUM
33
447
50,5 672
66,5 431
150 1550
Realization and updated plan
(realized hours and updates)
9
T-76.4115 Iteration demo
Defects and other quality metrics
Blockers
Critical
Major
Normal
Minor
Trivial
Enhancement
Total
Reported in
Implementation I
2
2
4
8
2
5
7
30
Reported total
2
2
4
8
2
5
7
30
Open
0
1
3
5
1
2
0
12

One critical bug open

When running the conversion system there are SQL Exceptions about inability to convert 0000-0000 00:00:00 to TIMESTAMP (when converting cv_users) and to Date (when converting Cources).
10
T-76.4115 Iteration demo
Source code metrics
Component (.java)
LOC-P
CLOC
Comment ratio
Database
1405
413
3.4
Controller
238
195
1.2
Converter
577
177
3.3
System
101
188
0.5
Util
363
345
1.1
View
441
437
1.0
Training
439
121
3.6
Total
3564
1876
1.9
Other
LOC- P = Physical Executable Lines of Code (Empty lines not included, comments not included)
CLOC = Comment lines of code
Comment ratio = LOC-P / CLOC
Total LOC = includes every line in the file
Setup and
configuration
files
Database
mappings (XML)
Database testing
Total
Total LOC
2497
497
915
333
835
1025
699
6801
Total LOC
770
1275
805
2850
11
T-76.4115 Iteration demo
Quality dashboard
Part of the system
Quality
Confidence
Comments
Database
Implemented
database
K
3
Much effort put to the new database. Almost all
hibernate mapping files are validated by customer.
Open bugs need to be fixed early in the next
iteration.
Conversion
K
2
Conversion works partly. Major bugs still open. A bit
behind schedule.
Engine
K
3
Future test cases under construction. No major
defects. Code concerning calendar requires more
work.
3
GUI & engine team are working closely together.
Information is passed around so we can integrate
GUI and engine components early for the testing.
GUI

Legend
Confidence:
3: Strong belief that quality goals are reached
2: A bit unsure whether it’s possible to achieve all requirements
1: We’re probably not getting the job done.
Quality:
 = quality is good
K = not sure
= quality is bad
12
T-76.4115 Iteration demo
Used quality practices & status

Quality practices




Pair programming
 50% (~100h) of all development work was done by pair programming
Code & document reviews
 Source code was reviewed 5.12.2007 by two pairs (~10h)
 All deliverables reviewed by expert trio
Test cases
 Design and testing took 5 hours
 Design just in time against use case to be implemented
Quality status



Database is the most error prone area.
Few bugs found in engine after development work concerning login
 We were able to fix them before delivery
GUI’s bugs are usually fixed at the same time as developing. Usually quick to
fix.
13
T-76.4115 Iteration demo
Quality goals




Safety

Verification criteria: All test cases passed
 Currently, there are no features that we could test for safety. (E.g. user must confirm
change when modifying database).
 Use cases are written so that it explains safety criteria.
Security

Verification criteria: Login/logout and session validation function tests passed.
 Few login session bugs fixed
 Test cases passed
Usability

Verification criteria: Usability is satisfactory according to the customer.
 Skeleton menu working
 Usability testing will be done in implementation II, when more features are possible to
test
Code and document quality

Verification criteria: Customer approves all documents. Documents and code follow
guidelines and coding conventions
 Most of the code follows coding conventions. Some parts still need more reviewing
 Documents are up-to-date
14
T-76.4115 Iteration demo
Risks

Materialized risks

ID #5: Iteration/sprint
schedule unrealistic.
 Some requirements
need more resources
than anticipated.
 Scope must be
reduced in
implementation II.
15
T-76.4115 Iteration demo
Changes to the project

Scope of the database minored

Work applications, Event log and Collections are dropped away
16
T-76.4115 Iteration demo
Results of the iteration

Documentation and design




QA plan
System architecture
Implemented use cases
Demonstration

Demo-scenario
 Login, calendar and logout
17
T-76.4115 Iteration demo
Quality assurance plan

QA plan contains






Quality goals
Quality practices and scheduling
 Automated unit testing
 Test case based testing
 Exploratory testing
 Coding standards
 Code and document reviews
 Usability programming
 Pair programming
Quality palette
Defect tracking guide
References to QA documents and used software
Used metrics
18
T-76.4115 Iteration demo
System architecture


Architecture design was started in the project planning iteration, and was
finalized during this iteration
The work was clearly divided in two



Results




Database design
Software architecture
System overview (already in PP -iteration)
 Different components and main ideas of frameworks
Database design
 Objects, relations, approaches
 Attributes and chosen solutions
Engine/GUI architecture
 Controllers, views
 Practices
The process and end results (including validation) have been
documented in architecture specification document
19
T-76.4115 Iteration demo
System architecture: Overview
20
T-76.4115 Iteration demo
System architecture: Database 1/2



Using Hibernate (requirement)
Conversion from the old DB must
be possible, but total rewrite and
different approaches
Phases of design:




Analysis and draft
Iterations in close co-operation
with the customer
Final entity relation diagram
Low level design and
implementation by writing objects
and mappings
21
T-76.4115 Iteration demo
This slide has been removed

2/2 slide is removed from this public document
22
T-76.4115 Iteration demo
System architecture: Engine&GUI 1/2


Using ContextWaf framework
Design phases:



Controller/view division based on the existing system
Execution flow analysis and design
Implementation
23
T-76.4115 Iteration demo
This slide has been removed

2/2 slide is removed from this public document
24
T-76.4115 Iteration demo
System architecture: Development

The system is basically a servlet, so we are using Sun Java standards
and well known practices and tools:




Eclipse
Apache Ant
Tomcat manager and related build targets for easy testing
Other defined practices:


Repository layout (Sun Java and Ant recommendations)
Coding conventions
25
T-76.4115 Iteration demo
Implemented use cases

UCP001: Login



Procedure
 1. The user fills his username and password.
 2. The user clicks log in button.
Expected results
 The user is logged in the personnel’s system.
Exceptions



a) The password or the username is invalid.
 1. System informs the user that the username/password is invalid
 2. User is not logged in.
b) If login fails, a 5 second delay before next login try.
UCP002: Logout


Procedure
 1. The user clicks log out button.
Expected results
 1. The user is logged out.
 2. The user is directed to the login page.
26
T-76.4115 Iteration demo
Demonstraatio

Olga Odusoga, joka työskentelee firmassa Oo Oy, tilaa Eduhouselta kurssin
“Leading Your Organization”. Kurssin opettajana tulee toimimaan Jari Sarasvuo.
Kurssin vastuuhenkilönä toimii Eduhousen puolesta Marko Lavikainen.
HUOM! Erillinen demoskenaariodokumentti: Iteraatiodemo_I1_demoskenaario.doc
27
T-76.4115 Iteration demo
Used work practices

Code Review’s and unit testing


Pair programming is a good way to solve problems







Three persons might not be enough to estimate
More accurate estimations if every group member estimates all tasks
This could be arranged in the weekly meeting before I2
Skype as a meeting platform



 Many reports in late
Task effort estimation in EXP-group


Decicion making is easier in pairs
Navigator knows what should do next and driver knows how to do it
 Implementation is faster
Good for a team spirit
Good way to share experiences if pair’s are mixed reqularly
Weekly reporting is still hard to understand as an important task


Process for testing activities is important to define
 The code doesn’t respect all guidelines at the moment
 Validation of the unit after the tests need to be in practice
Very positive experiences!
All EXP meetings arranged in Skype during the iteration
Testing process will be improved

Architect will validate every object before it is ”ready”
28