T-76.115 Project Review

1
T-76.115 Project Review

• Group pdm
• I2 Iteration10.2.2005

2
Agenda

• Project status (20 min)
• achieving the goals of the iteration
• project metrics
• Effort
• Quality
• Risks and changes to the project
• Work results (15 min)
• presenting the iterations 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
Introduction to the project

• Background and business problems
• Product development (PD) projects conducted in a
  company network
• Management of the lead-times of product programs
  becoming even more challenging!
• Establishing a network collaboration is
  laborious, slow and expensive
• How to manage processes through the network?
• E.g. How to manage engineering changes?
• Integration of IT systems takes time and is very
  expensive
• Takes typically moths, if done at all
• Every integration is very laborious, reuse seldom
  possible
• SMEs cannot be integrated to the network (no
  systems, costs)

Source SoberIt NetSetup
4
Introduction to the project

• NetSetup vision
• Product development network setup can be done in
  days in relation to
• PDM system integration allowing quick,
  affordable integration including SMEs
• Standard inter-company processes for Engineering
  Change (EC) and Product Data Management (PDM)

Source SoberIt NetSetup
5
Introduction to the project

• The goal of this project
• To provide IT tool for inter-company PDM
  integration
• A basic tool (Ruletti) exists, but this projects
  goal is to make a more sophisticated tool that
  distributes the right documents automatically to
  the right product development partners

6
Status of the iterations 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

7
Status of the iterations deliverables

• Updated project plan
• OK
• Updated requirements document
• OK
• Updated technical specification
• OK
• Updated test cases
• OK
• Test report and test log
• OK
• User's manual (draft)
• OK
• Progress report
• OK
• Updated SEPA diaries
• OK, can be found at TikiWiki

8
Realization of the tasks (1/2)
9
Realization of the tasks (2/2)
10
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

11
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 projects schedule
• Can AR catch up all the hours in the last
  iteration?

12
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 couldnt be reached

13
Time usage per worktype so far in the project

• The most time consuming worktype so far has been
  design
• Project planning and meetings have take about one
  third of the total time spent
• Only 11 of the time was spent programming

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

15
Quality assessment
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 1 K More testing will be needed as new functionality is added.
PDMConnector 2 J Implemented functionality works.
Client/ Client Listener 2 K 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 its
tested Quality J quality is good K not
sure L quality is bad
16
Software size in Lines of Code (LOC)
Modules PP I1 I2 FD
PDMConnector 0 932 (COM 323) 1326 (COM 486)
EventManager 0 102 (45) 370 (114)
LogConnector 0 176 (88) 514 (206)
BTConnector 0 36 (20) 611 (255)
RuleEngine 0 13 (8) 1221 (484)
RulexClient 0 0 576 (118)
Constants Util 0 117 (61) 262 (112)
RulexObjects RulexEvents 0 269 (86) 590 (299)
Total (NCLOC COM) 0 1645 6032
Comments (COM) 0 631 2330
17
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 GUIs 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

18
Risks (1/2)

• Realized risks and reactions
• As considering research project, the
  requirements arent clear enough
• Email 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 doesnt work well
• Defining the responsibilities according to
  modules
• Common programming sessions

19
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

20
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

21
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
• Partially completed
• Rule-engine methods OK, UI not implemented
• UC-04 Delete rule
• Partially completed
• Rule-engine methods OK, UI not implemented
• UC-16 Instruct RosettaNet adapter to send
  documents and/or acknowledgements
• Partially completed
• 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
• Partially completed
• UC-01 Login
• OK

22
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

23
Used work practices

• Mandatory practices
• Use-cases
• Making effort estimates for use-cases is tricky
• Use-case driven process did not work too well
  with us, in practice we had to focus on
  implementing system modules rather than use-cases
• Time reporting
• Use-case could have been divided into smaller
  tasks, such as designing, implementing
  functionality, and implementing GUI
• Version control
• CVS has worked well for the source code
• Risk management
• Risk may and will occur, as it was seen
• How to control risks outside our influence?
• SEPAs
• Meeting practices
• Have been in use during the whole project
• Design patterns
• Have been utilized though no explicit design
  patterns yet in use
• Static methods
• Good results from finding bugs and defects
• Usability testing

24
Thank you!

• Now it is time for your questions