T-76.4115 Iteration Demo

T-76.4115 Iteration Demo Tikkaajat [I1] Iteration9.12.2007

Project status (25 min) achieving the goals of the iteration project metrics Work results (20 min) presenting the iteration’s results demo Used work practices (5 min) Agenda

Introduction to the project • jEhIntranet System • Informational logistic solution for Eduhouse Oy • coordinating system for customers, employees, and operations

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

Status of the iteration’s goals • Goal 1: Designing of quality assurance • OK • Goal 2: Designing of test cases • OK • Goal 3: Architecture is finalized • OK • Goal 4: Database is ready to use • OK • Goal 5: Conversion System for database designed, implemented, tested • 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

Status of the iteration’s deliverables Documentation: • Quality Assurance Plan • OK • Updated Project Plan • OK, updated chapters 4.1 and 6. • Updated Requirements document • OK, updated chapters 3, 6 • Technical Specification • OK • Test cases • OK, derived from the use cases: UCP001, UCP002, UCP006, UCP009 • Use cases UCP001, UCP002 implemented and tested • UCP009 is under development. Will be tested as soon as reported as ready. • QA report and test log • OK • Progress report • OK

Status of the iteration’s deliverables Software: • Build environment • OK • 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 • 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

Realization of the tasks

Resource usage Original plan (in the beginning of the iteration) Realization and updated plan (realized hours and updates)

Defects and other quality metrics One critical bug open When running the conversion system there are SQL Exceptions about inability to convert 0000-00-00 00:00:00 to TIMESTAMP (when converting cv_users) and to Date(when converting Cources). 10

Source code metrics 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 11

Quality dashboard 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

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

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

Risks Materialized risks ID #5: Iteration/sprint schedule unrealistic. Some requirements need more resources than anticipated. Scope must be reduced in implementation II. 15

Changes to the project • Scope of the database minored • Work applications, Event log and Collections are dropped away

Results of the iteration • Documentation and design • QA plan • System architecture • Implemented use cases • Demonstration • Demo-scenario • Login, calendar and logout

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

System architecture • Architecture design was started in the project planning iteration, and was finalized during this iteration • The work was clearly divided in two • Database design • Software architecture • Results • 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

System architecture: Overview

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

This slide has been removed • 2/2 slide is removed from this public document

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

This slide has been removed • 2/2 slide is removed from this public document

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

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

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

Used work practices • Code Review’s and unit testing • 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 • Pair programming is a good way to solve problems • 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 •  Many reports in late • Task effort estimation in EXP-group • 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 • 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”

T-76.4115 Iteration Demo