T-76.4115 Final Demo Tikkaajat I2 Iteration 4.3.2008.

T-76.4115 Final Demo

TikkaajatI2 Iteration

4.3.2008

T-76.4115 T-76.4115 IterationIteration demo demo

2

Agenda

Evaluation of the results (8min) Goals Quality Challenges Delivered documents

Metrics (4min) Resources QA metrics

Work practices and educational value (8min) Used practices Faced problems Important lessons

Demo (20min)


3

Introduction to the project

jEhIntranet System

Informational logistic solution for Eduhouse Oy

coordinating system for customers, employees, and operations


Evaluation of the results

4


5

Development level goals

Goal Status

Database of the current system needs to be improved and implemented entirely

OK

Software engine has to be maintainable and expandable and some functionality from the current system has to be implemented

OK

Improved graphical user interface has to be implemented for the implemented engine parts

OK

The overall goal for the project was to reconstruct the current system into the Java based application

using frameworks suggested by the customer. The following table describes major level goals in priority order.


Project level goals

Project level goals Mostly focused to the resources, schedules, responsibilities, learning of the

unknown technologies and communication. Responsibilities were shared Communication practices was used widely between IRC -discussion to the

weekly face to face meetings

6


Quality goals

The following table describes the status of project’s quality goals (in priority order)

7

Goal Quality Analysis

Safety

According to QA plan, all test cases should be passed in order to achieve this quality goal. However, there are some test cases which failed. These have not been fixed in implementation II. These bugs mostly resulted from bad form handling.

Security Login and logout tests passed. No security issues have been found in any testing method.

Usability Some usability issues are still open.

Code and document quality

Code has been reviewed and customer has validated classes. Documents are up-to-date. Customer is satisfied of document quality (feedback has been positive).

Quality:

= quality is good

= some issues still open

= quality is bad


Challenges

New technology Team was required to work with various technologies

Training and prototyping was necessary Finding the right persons for a task

Who can do and what? Lack of documentation

There were many situations where customer's experiences were needed the project team misunderstood the current solution

International project team Communication and documentation had to be in English System’s user interface is Finnish

Hard for an exchange student to understand what the system does

9


10

Results of the project

Delivered documents Project plan Requirements documents System architecture QA report Test case matrix and log Code review logs Test charters Peer test session charters with exploration logs + summaries User’s manual Final report Slides for the final demo SEPA diaries

Demonstration Demo scenario


Metrics

11


12

Realization of the tasksTask Planned Realized Difference

Planning 187 194 - 7

1. Iteration planning 32 28 + 4

2. QA and Testing 17 22,5 - 5,5

3. Architecture design 65 87 - 22

4. Others (PP, Training, guidelines, etc) 73 56,5 + 16,5

Development 510,5 640 - 129,5

5. Database 173 264 - 91

6. Functionality 295,5 321 - 25,5

7. Others (GUI improvement, Bugs) 42 55 - 13

QA and RE -activities 125,5 113,5 + 12

8. Requirement engineering 48,5 44,5 + 4

9. Risk Management 18 4,5 + 13,5

10. Quality Assurance 15 20,5 - 5,5

11. Test Cases 32 9 + 23

12. Others (Peer Testing, Code Reviews, etc) 12 35 - 23

Management 70 121,5 - 51,5

13. Project Tracking 19 21,5 - 2,5

14. Arrangements 18 63 - 45

15. Others (Reporting, etc) 33 37 - 4

Unclassified tasks 657 572,5 + 84,5

16. Meetings 216 235,5 - 19,5

17. Communication 40 25,5 + 14,5

18. Prototyping 129 135 - 6

19. SEPA: Pair Programming 80 52 + 28

20. SEPA: Automated Unit Testing 120 88,5 + 31,5

21. Others (Adopting, install, etc) 72 36 + 36

Total: 1550 1641,5 - 91,5


13

Resource usage

Original plan (in the beginning of the iteration)

Realization and updated plan

Iteration TL TH SM VS ST VH TM TI YZ SUM

PP 71 73,5 56,5 49 19 67 36 42 33 525

I1 76 75,5 47,5 75 61 75 82 64 47 603

I2 43 41 46 66 70 48 72 44 70 603

Total 190 190 150 190 150 190 190 150 150 1550

Iteration TL TH SM VS ST VH TM TI YZ SUM

PP 71 73,5 56,5 49 19 67 36 42 33 447

I1 81 92,5 47,5 94 40,5 91,5 100 74,5 50,5 672

I2 63 44 37 71,5 104 57 60,5 25,5 60 522,5

Total 215 210 141 214,5 163,5 215,5 196,5 142 143,5 1641,5

More hours spent than estimated

•The project team decided together at the beginning of the last iteration,

that all tasks will be finished, without thinking about overlapping of the personal hours.


Resource division

Per Cent

Planning12 %

Development39 %

QA and RE7 %

Management7 %

Meetings14 %

Prototyping8 %

Others13 %


15

Defects and other quality metrics

No blocker or critical bugs open Open bugs are mostly resulted from the personal details feature

Ratio of passing test cases: 13/15Ratio of closed and found defects: 50/61

Blocker Critical Major Normal Minor Trivial Enhancement TOTAL

Found in implementation I

2 2 4 8 2 5 7 30

Found in implementation II

0 1 3 17 3 5 2 30

Found total 2 3 7 25 5 10 9 61

Open 0 0 1 7 1 1 0 10


Source code metrics

16

Component (.java)

LOC-P CLOC Comment ratio Total LOC

Database 1673 493 3.4 2949Controller 597 504 1.2 1292Converter 1288 286 4.5 1890

System 120 164 0.7 342Util 492 391 1.3 1048

View 679 494 1.4 1395Unit tests 1616 607 2.7 2769Training 439 121 3.6 699

Total 6 904 3 060 2.4 12 384

Other Total LOCHTML templates 1353JavaScript 336Setup and configuration files 827Database mappings (XML) 1284Database testing 805Total 4 605

LOC- P = Physical Executable Lines of Code (Empty lines not included, comments not included)CLOC = Comment lines of codeComment ratio = LOC-P / CLOCTotal LOC = includes every line in the file


Work practices and educational value

17


18

Three most important work practices

Iterative development Project was designed into the three iterations, which were divided into sprints Development of every functional component was designed so, that the system was build against priority order Waterfall -based process model couldn't be the selection in this kind of projects, where requirements are

allowed to change

Iteration planning Idea was to design the next iterations goals and estimate needed resources in advance If problems occurs during the iteration, we could react rapidly. This means that the next sprint might be

minored, because more important task is still in progress. Allowed the management team to estimate the progress of the iteration quite soon

Requirements engineering Helped us to understand the system to be built Requirements document was useful in the first half of the project Problems

Hard to get all requirements by just communicating with the customer In implementation II, customer wrote specific requirements for certain features for developers to use.


19

Other work practices

Documenting Risk management Time tracking Communication Iteration demo Defect tracking Version control Coding conventions Process improvement Change management Design Standards


20

Used QA practices

Test case based testing Executed test cases: 15 Passed test cases: 13 All functional requirements that were reported as ready, were tested by test cases.

Exploratory testing Testing was done by team members and by the peer group. Unfortunately, not all testing was documented.

Most bugs that were reported were found during exploratory testing.

Code reviews Source code review sessions were held in 5.12.2007 and 1.2.2008. During the code reviews, pairs reported their

findings to the review log templates. Customer has access to these logs.

Unit testing 20 unit tests were written in implementation II. 13 of them test the converter.

Pair programming Conversion was 100% pair programmed Personal details and search components were 50% pair programmed


Tools

Project management MediaWiki Bugzilla Weekly Reporting Tool (by the manager) MS Excel MS Word MS PowerPoint LocMetrics

Development software Apache Ant Subversion Eclipse

Environment Java Tomcat MySQL Hibernate Velocity ContextWaf Joda Time

21


Educational value (1/2)Faced problems

Misunderstood requirements Almost impossible task to specify the system in advance in a low level.

management team had to specify the requirements again, and developers had to re-implement, or at least fix the functional component.

The project team didn't understood correctly what the customer really expected – it was actually very qualitative code, not the amount correct functionality, which was the second priority.

Unrealistic schedule team noticed a huge need for extra efforts to reach the iterations goals. management team with the customer didn't understood the complexity of the database to

be converted

Lack of testing It may be that, the testing was seen as a boring task and what most,

documentation of the testing was slapped away New validation process was designed to prove that the quality is met in

developed components.

22


Educational value (2/2)Important lessons

Agile software development methods in a real project Many of the team members have studied methods of software engineering and agile

development activities Studies and the real-world was finally present at the same time.

Exploit experiences in the future The project team had adopt new technology quickly and to learn how to use it International project Experiences will certain help the team members in the future.

Challenges in software development There was a real problem domain in the project Using the lessons learned from school courses

Team work is the key to advance Communication language was English good team spirit was present Different people possess different skills.

23


Comparision

Similarities to the previous projects Resource usage estimation is a hard task and goes usually wrong Different stakeholders feel quality in a different way Lacks in the low level testing (testing was felt boring) Huge amount of documentation Requirements changed

Differences to the previous projects Very active customer involvement Agile development process

Requirements were to be changed Good communication between different stakeholders Weekly meetings as a practice New technology (developers are usually familiar with the technology) Large and international project team The current system was to be re-implemented

24


Demo

25


26

Demo

Database conversion Shown features

Login Viewing calendar Search Viewing trainer and customer information Modifying trainer information Logout


Thank You!

27

Date post:	01-Jan-2016
Category:	Documents
Upload:	kristopher-shepherd
View:	215 times
Download:	0 times