1. T Project Review
Group: pdm
I2 Iteration

2. Agenda Project status (20 min) Work results (15 min)
achieving the goals of the iteration
project metrics
Effort
Quality
Risks and changes to the project
Work results (15 min)
presenting the iteration’s results
demo
Discussion and questions (10 min)
Additional slides not shown in the presentation
Introduction to the project (slides 3-5)
Time usage per worktype (13)
Used work practices (slide 23)

3. Status of the iteration’s goals
The goals defined in the implementation 1 iteration plan:
Goal 1: Implement all the ”must” (defined in use cases) functions of Rulex
8 functions completed
13 functions partially completed
6 functions not completed
Goal 2: Implement the selected use cases
Partially completed
GUI and the functionalities (methods) have been implemented separately, they still need to be integrated
Goal 3: Create a draft version of the user's manual OK
Goal 4: use the personal software practices (SEPA) to facilitate the software development
Usability testing
OK, the GUI was successfully tested with an industry representative
Static methods
OK, code review session was successfully held
Design patterns
Explicit utilization not clear
Meeting practices
OK, have been in use throughout the project

4. Status of the iteration’s deliverables
Updated project plan OK
Updated requirements document
Updated technical specification
Updated test cases
Test report and test log
User's manual (draft)
Progress report
Updated SEPA diaries
OK, can be found at TikiWiki

5. Realization of the tasks (1/2)

6. Realization of the tasks (2/2)

7. Realized working hours by person
Realized hours in iteration I2
Räisänen and Toukoniitty had a lot of hours allocated to them but they could not reach their target
Näkki and Heimonen exceeded their effort estimates a little

8. Working hours by person
Plan in the beginning of this iteration
Latest plan
Five project members are performing according to the plan
When measuring the total effort spent, we are running behind of the project’s schedule
Can AR catch up all the hours in the last iteration?

9. Cumulative effort compared to the plan
Cumulative effort compared to the planned effort is shown in the figure above
The updated plan is colored green
 The gap in total effort couldn’t be reached

10. Quality metrics Bug metrics I1 I2 DE Total 9 + 50 7 + 3 69 3 + 50
Reported
9 + 50
7 + 3 69
Closed
3 + 50
0 + 2 55
Open
6 + 0
3(I1) 11
Module
Critical
Major
Minor
Trivial
Origin
Total
User Interface 1
Testing
Rule Engine 2
Inspection 3
BTConnector 4
PDMConnector
Client/
Client Listener 10

11. Quality assessment K J Code inspection of Rule Engine took 4 hours
Functional area
Coverage
Quality
Comments
User Interface 1 K
Only paper prototype has been tested. No major complaints found in usability testing.
Rule Engine 2 J
The logic of rule processing seems to be correct.
BTConnector
More testing will be needed as new functionality is added.
PDMConnector
Implemented functionality works.
Client/
Client Listener
No errors found. Ready for GUI integration.
Code inspection of Rule Engine took 4 hours
Legend
Coverage:
0 = nothing
1 = we looked at it
2 = we checked all functions
3 = it’s tested
Quality:
J = quality is good
K = not sure
L = quality is bad

12. Software size in Lines of Code (LOC)
Modules PP I1 I2 FD
PDMConnector
932 (COM 323)
1326 (COM 486)
EventManager
102 (45)
370 (114)
LogConnector
176 (88)
514 (206)
BTConnector
36 (20)
611 (255)
RuleEngine
13 (8)
1221 (484)
RulexClient
576 (118)
Constants & Util
117 (61)
262 (112)
RulexObjects & RulexEvents
269 (86)
590 (299)
Total (NCLOC + COM)
1645
6032
Comments (COM)
631
2330

13. Changes to the project
We decided to implement the rule-engine by ourselves and not use an existing engine
Good decision because implementing rule-engine by ourselves did not took too much time
Logic of rule-engine has to be well tested
Changes to the GUI’s logic
Role of manual sending changed to the basic drag-and-drop feature
Some focusing was made on the requirements
What PIP messages the system will support
We did not focus so much on the use-case driven process
Project members focused on implementing selected modules, functionalities and interfaces, rather than selected use-cases
Implementing one use-case requires in practice implementing parts of several modules. However, everybody cannot be experts on every modules
The following use-cases be easily implemented after all the modules have been made

14. Risks (1/2) Realized risks and reactions
”As considering research project, the requirements aren’t clear enough”
communication and meetings with the customer
Design sessions with the team
”The code is not ready, when testing starts”
Code review in first phase
Functional testing when also the UI is available
New risk identifications and reactions
UI testing too late to change the UI layout
The change requests were still possible to implement
UI design required more resources than planned
Use case driven implementation doesn’t work well
Defining the responsibilities according to modules
Common programming sessions

15. Risks (2/2) Status of risk control
Most of the 30 controlling actions are put into practice
Tools worked well
No overlapping work
All members work actively with the project
Customer is participating actively
UI was tested with paper prototype
More attention could have been paid for:
Keeping the coding deadlines
Pair programming

16. Results of the iteration
The most important substance of implementation 1 iteration
implemented use cases (slide 7)
updated specification document (document delivered)
updated test cases (document delivered)
updated user interface
draft on the user manual (document delivered)
Demo

17. Status of the use-cases
UC-02 Create a new rule
Partially completed
GUI for rule creation wizard implemented and rule-engine implemented, they still need to be connected
UC-03 Edit existing rule
Rule-engine methods OK, UI not implemented
UC-04 Delete rule
UC-16 Instruct RosettaNet adapter to send documents and/or acknowledgements
UC-17 Receive data from RosettaNet adapter
Ok, but interface to the RosettaNet is not tested
UC-18 Receive acknowledgements from RosettaNet adapter
Partially completed, connection to the log database not implemented
UC-15 Receive event from the PDM system
UC-01 Login OK
UC-05 List project rules
GUI for rule listing implemented and rule-engine implemented, they still need to be connected
UC-06 List rules for a document type
UC-07 List rules for a document
Not implemented
UC-14 Project log browsing
UI was created
UC-12: Retrieve information from the PDM system
UC-13: Save information to the PDM system

18. Demo Now it is time for a breath-taking demonstration!
Login to the system
Manual drag-and-drop sending
Create a rule using wizard
List rules
Document is updated  Rulex notifies this and sends the document
Log

19. Now it is time for your questions
Thank you!
Now it is time for your questions