T-76.115 Project Review

1
T-76.115 Project Review

• Group pdm
• I1 Iteration2.12.2004

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)
• Status of use-cases (slide 7)
• Time usage per worktype (13)
• Effort estimates planning accuracy (slide 14)
• QA methods (slide 25)
• Used work practices (slide 29)
• UI-views (slide 27)

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 build the basic architecture
• OK, the basic architecture has been designed,
  documented and mostly implemented
• Goal 2 implement the selected use-cases
• UC-12 Retrieve information from the PDM system
• OK
• UC-13 Save information to the PDM system
• Partly completed
• UC-17 Receive data from RosettaNet adapter
• Not completed
• UC-14 Project log browsing
• OK
• Goal 3 use the personal software practices
  (SEPA) to facilitate the software development
• Usability testing
• Not utilized, UI-responsible has been sick during
  the whole iteration
• Static methods
• OK, code review session was succesfully held
• Design patterns

7
Status of the use-cases

• UC-12 Retrieve information from the PDM system
• Current implementation
• PDMConnector-module can currently retrieve all
  document parts (document, document version,
  subdocument, subdocument version and
  representation the actual binary file) from
  EDMS.
• Future developing
• Query functions are not yet implemented. Thus its
  yet impossible to retrieve special document parts
  especially when exact document name is not
  known.
• UC-13 Save information to the PDM system
• Current implementation
• PDMConnector-module is able to store whole
  document metadata to EDMS. Only exception is that
  creating Representation does not currently work.
  Storing currently contains automatic update
  thus if document already exists this PDMConnector
  only stores new document components.
• Future developing
• Creating representation is obvious and top
  priority function. Additional functionality to
  deal with document states may also be necessary.
• UC-17 Receive data from RosettaNet adapter
• Current implementation
• Not currently implemented.
• Future developing
• Fully implemented in next iteration.
• UC-14 Project log browsing
• Current implementation
• LogConnector has connection to SQL database and
  is able to read and write log events. With all
  the functionality of SQL the log can be searched
  for any event or rule and even retrieve full
  event and rule histories.
• Future developing

8
Status of the iterations deliverables

• Updated project plan
• Quality Assurance Plan was delivered as a
  separate document
• No changes were made to the actual project plan
• Updated requirements document
• OK, minor changes were made
• Technical specification
• OK
• Plan for the user interface is a separate
  document (UI-plan)
• Test cases
• OK
• Test report and test log
• OK
• Progress report
• OK
• Updated SEPA diaries
• OK

9
Realization of the tasks

• Implementing UC-17 was not started
• Implementation of UC-14 was more straightforward
  than estimated
• Integration testing couldnt be done as
  comprehensively as planned
• The programming languages were familiar to the
  coders, no need to study java/XML

• Implementing UC-12 and 13 needed much input also
  from the customer
• We introduced our own CVS since the courses CVS
  wasnt operating when it was needed
• Studying project domains took more time than
  estimated

10
Working hours by person
Realized hours in this iteration

• The biggest discrepancy - AR couldnt do anything
  for the project since he has been very sick!
• PT has done only about half the effort needed
• Others are running a little below the plan

11
Working hours by person
Plan in the beginning of this iteration
Latest plan (updates coloured green)

• When measuring the effort spent, we are running
  behind of the projects schedule
• More effort must be made in the next iteration
• This means working during the projects Christmas
  holiday

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

13
Time usage per worktype

• The most time consuming task in the
  implementation 1 iteration was design (25 )
• Only 16 of the time was spent programming

14
Effort estimates planning accuracy

• Histogram shows realized hours / planned
  hours for tasks
• Average effort estimate accuracy was 79
• Three peaks can be observed
• 0 - tasks that were not done at all
• gt 200 - tasks that took over two time the time
  planned
• 80 - tasks that took almost the time planned

15
Quality metrics
Bug metrics
I1 I2 DE Total
Reported 9 50 59
Closed 3 50 53
Open 6 0 6
Defects found in code inspection
Module Critical Major Minor Trivial Origin Total
PDMConnector 1 8 5 Inspection 14
0 4 4 1 Testing 9
EventManager 0 8 1 Inspection 9
0 0 0 0 Testing 0
LogConnector 1 8 4 Inspection 13
0 0 0 0 Testing 0
Other 0 10 4 Inspection 14
59

• No critical bugs found!

16
Quality assessment
Functional area Coverage Quality Comments
PDMConnector 1 K Some functionality missing. Needs more development and testing in the next iteration.
EventManager 2 K Tested version had very limited amount of functionality. More testing will be needed as new functionality is added.
LogConnector 2 J Implemented functionality seems to work OK.
BTConnector 0 K Not started
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

• Code inspection took 16 hours
• Test execution took 5,5 hours (26 test cases)
• Implementation of BTConnector-module was delayed
  and it wasnt tested at all

17
Software size in Lines of Code (LOC)
Modules PP I1 I2 FD
PDMConnector 0 932 (COM 323)
EventManager 0 102 (45)
LogConnector 0 176 (88)
BTConnector 0 36 (20)
RuleEngine 0 13 (8)
RulexClient 0 0
Constants Util 0 117 (61)
RulexObjects RulexEvents 0 269 (86)
Total (NCLOC COM) 0 1645
Comments (COM) 0 631
18
Changes to the project

• The project is running now with only 6 persons
• It remains unseen when AR can return to the
  project
• No changes to the requirements
• More effort must be spend in the next iteration
  to make sure the project will complete on time

19
Risks (1/2)

• Realized risks and reactions
• Too abstract requirements ? programmers apply
  them by themselves
• Email communication with the customer
• TikiWiki and face-to-face discussion with the
  team
• Long sickness of a team member ? UI design
  delayed
• UI design started by other team members
• Actual implementation in I2
• The code is not ready, when testing starts
• Code reviews in first phase
• Functional testing in second phase
• Everyone doesnt know, what to really do ? one
  week missed
• Defining the responsibilities
• Effective use of Action Point list

20
Risks (2/2)

• New risk identifications and reactions
• TikiWiki discussion about design issues isnt
  effective enough
• Appointed times for programming together
• Tools provided by the course late
• Own CVS
• Problems in the computer classroom (no connection
  to SoberIt)
• Communication with administrator and course
  assistant
• Programming at home or at Maari
• Status of risk control
• 30 controlling actions addressed to certain
  persons
• 14 are in action or planned, 16 not yet
  implemented
• In later iterations risk controlling should be
  more actively

21
Results of the iteration

• The most important substance of implementation 1
  iteration
• system architecture (slides 22 and 23)
• implemented use cases (slide 7)
• specification document (document delivered)
• test cases (document delivered)
• QA approach (slides 24 and 25 document
  delivered)
• User Interface plan
• Demo
• Retrieving information from EDMS
• Saving information to EDMS
• Log browsing

22
Results system architecture

• Module architecture design as shown
• See technical specification document for more
  details

23
Results system architecture (2)

• Complete
• EventManager
• LogConnector
• Partially complete
• PDMConnector
• Incomplete
• BTConnector

24
Results QA Approach
Goals Metrics Iteration
Correctness of architecture Review I1
Compatibility with existing interfaces Review, Integration testing I1, I2, FD
Testability Code inspection I1, I2
Readability of code Code inspection, standard checks I1, I2
Correctness of modules Unit tests (by programmers), Regression testing I1, I2, FD
Functional correctness System testing I2, FD
Usability Usability testing I2
Software portability Istallation and Acceptance testing I2, FD
25
Results QA Methods

• Testing
• Unit testing informally by the programmers
• Integration testing by testers
• System testing with UI by testers
• Usability testing by usability testers
• Test reporting
• Test logs by testers
• All found defects reported using Bugzilla
• Test report by Test manager
• Static methods
• Document reviews
• all deliverables read by 1-2 people
• design documents together with the whole group
  (and customer)
• Code inspections
• most essential classes in sessions of 3 people
• Coding standard checks
• By reading the code

26
User interface plan

• Planning of the user interface has started
• Next step is to test the plans before
  implementing them
• The picture above shows a draft of the systems
  project view

27
Planned UI views

• Planned UI-views are shown in the picture above
  (texts are in Finnish)

28
Demo

• Now it is time for a breath-taking demostration!
• Retrieving information from EDMS (UC-12)
• Saving information to EDMS (UC-13)
• Log browsing (UC-14)

29
Used work practices

• Mandatory practices
• Effort estimates
• Making effort estimates for use-cases is tricky
  before designing the system architecture
• Time reporting
• This time we tried to split the tasks to smaller
  units
• Version control
• Problems faced with the TikiWiki (multiple users
  changing a document at the same time)
• CVS has worked well for the source code
• Risk management
• Risk may and will occur, as it was seen
• Controlling risks requires effort and
• SEPAs
• Meeting practices
• Are in use, good experiments, time usage has been
  efficient
• Design patterns
• Have been utilized though no explicit design
  patterns yet in use
• Static methods
• Good results from finding bugs and defects
• Usability testing

30
Thank you!

• Now it is time for your questions