1 / 23

T-76.115 Project Review

T-76.115 Project Review. RoadMappers Implementation 1 3.12.2003. Project status (15 min) achieving the goals of the iteration project metrics Used work practices (5 min) Completed work (15 min) presenting the iteration’s results demo Plans for the next iteration (5 min)

rory
Download Presentation

T-76.115 Project Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. T-76.115 Project Review RoadMappers Implementation 13.12.2003

  2. Project status (15 min) achieving the goals of the iteration project metrics Used work practices (5 min) Completed work (15 min) presenting the iteration’s results demo Plans for the next iteration (5 min) Comments and questions (5 min) Agenda

  3. Status of planned goals of the iteration • Goal 1: Design core architecture • OK • Goal 2: Design user interface on general level • OK • Goal 3: Implement some basic use cases • Mostly OK, GUI-module not implemented yet so visual demos are not possible

  4. Status of planned deliverables of the iteration • Base architecture of the GUI • OK • Use cases: UC-01, UC-05, UC-06, UC-07, UC-08, UC-09, UC-10, UC-11, UC-12, UC-25 • Use cases 1, 4-13, 15-16, 18-19, 21-22, 24-28, 30-31 have their underlying code implemented • GUI-module is not yet implemented • Optional use cases: UC-02, UC-03, UC-04 • UC-4 was implemented

  5. Still had some estimation problems especially recarding implementation The estimation was changed module based durin I1 Tasks like Personal Assignment vere hard to estimate as all seven members participate with their individual input Addign up mistake in Weekly meetings plus one extra meeting Architectural design was at first underestimated and never was updated Several persons participating in the task GUI module not yet started Testing was not yet started SOME HOURS MAY STILL BE MISSING DUE THE LATE RECOVERY OF TRAPOLI! Realised tasks Realization of the tasks Not started tasks

  6. Working hours by person Realized hours in this iteration Plan in the beginning of I1 iteration • Latto spent more time on the infastructure and as also a key player in the implementation • Design and usability demanded little more than expected from Karkkunen • Testing also demanded more than espected from Sarmanne • Project manager’s needed effort was less than expected

  7. …New plan • Total amount was updated to 1400 hours • Trying to even up the efforts by distributing hours

  8. Quality metrics 1/2 • Major problems in usability tests • The functionality of the list of objects in the view is not clear to the user • Hiding a set of objects is too difficult • Major problems in heuristic analysis • The meaning of the filtering buttons is not clear • The relationship between filtering buttons and the list of objects is not clear • The meaning of the little triangles in the model is not clear • Separating the columns 'other end' and 'role' is confusing Usability problems

  9. Quality metrics 2/2 • Testing has not yet fully started (will continue in the beginning of next iteration) • 3 tests made • 0 bugs found • Tests only for Controller module • All sources compile ok Bug metrics

  10. Quality assessment • Not much to tell • Unit test phase continues • Implementation started late • Tried to wait for the interface -> Lack of interface hindered design • Coders were slow starters • However • Features to test tend to be either simple (maybe even too simple to test) • or complex enough to require some amount of time to design and implement • Most of the underlying code is now written 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

  11. Software size in Lines of Code (LOC) • Prototype was generated not coded, part of this code can be used later • Implementation started towards the end of iteration

  12. Changes to the project • Technical advisor left the project -> Customer acts in a double role • GUI-module not implemented in this phase due time constraints • Gave us more time to implement the base code • GUI-prototype will offer some reusable code later • Customer agreed with this decision

  13. Risks • Risk management uses Riskit type approach • The risk management group (Siltanen, Saarmanne, Enbuska) • 22 risks were identified during the PP iteration • 5 risks have materialized (ID, weight 1-100, rank) • Interface (R10, weight 30, #1) => New architecture • Work sharing (R5, weight 28, #2) => Balanced in the next iterations • Disagreements (R3, weight 25, #3) => Following the Quality Handbook and Coding Conventions • Server problems (R18, weight 24, #4) => Backups, internal deadlines, planning the move beforehand • Trapoli (R21, weight 24, #5) => The bug fixed • All of these have been reacted or the risks have been solved otherwise • No new risks found

  14. Work practices • The planned practises were mostly used • Some exceptions like refactoring will start in next iteration • Some missing practices were updated to he quality handbook • No new plans at his moment • Example: Usability testing

  15. Usability tests • Two usability tests were done during the iteration • Two users with slightly different kind of skills • At usability laboratory (computer science buildind) • Two members of our group • Marko Saastamoinen (experimenter) • Sanna Karkkunen (making notes) • Methods used • Test tasks and scenarios • Thinking aloud • Recording the tests • Interview and discussion • Preparation, testing and analyzing took about 16 hours • Results • 10 usability problems were found • two of the problems were major, no catastrophic problems at all • improvements made and tested again in the next iteration • Positive experiences • problems were quite different from the problems found with heuristic analysis • valuable feedback from the users • Negative experiences • a larger pool of users would have been useful to gather more problems • In the next iteration special emphasis will be put on testing the new functionalities, improvements made and users understanding of the model itself

  16. Results of the iteration • Technical Specification and Architectural Design (Samuel) • Test plan (Mikko) • User Interface Design Process (Sanna)

  17. Technical Specification and Architectural Design • Architectural design process • Design meetings • Individual design and documentation (=> technical specification) • Tasks were shared per module basis • Integration of the modules • The basic architecture • Four modules • GUI – communicates with users • Controller – takes commands from the GUI and delegates them forward • Model – keeps the internal model up to date • Views – controls the individual views • The existing configurator and modelling tool • Interface by COMET wrapped mostly into the Model module • Design priciples • Design Patterns • Flexibility against the GUI

  18. Example: Test Plan 1/2 • What is tested • Implementation of the system • All funtional requirements • Most of the non-functional requirements • What is not tested • Some non-fuonctional requirements (1, 3, 11) • Performance, resource usage, HW compatibility • Testing on three levels • Unit testing • System testing • Acceptance testing • Phasing/Schedule • I1, I2: unit and system • I3: unit, peer and system • DE: acceptance

  19. Example: Test Plan 2/2 • Metrics • Time used for testing • Time used for fixing defects • Total number of defects found • Number of defects in each category • Number of defects in each module • Number of fixed defects • Number of verified fixes • Total number of test cases • Number of test cases run • Number of test cases passed • Other topics • Item pass/fail criteria • Suspension and resumption criteria • Test deliverables • Testing tasks • Staffing, Responsibilities • Environment, Risks

  20. User Interface Design Process • Designing the navigation model (I1) • Designing the screens • Overall design (I1) • Use cases of each iteration (I1-I3) • Designing the menus • Menu bar (I1) • Pop up menus (I3) • Designing the representation of the configuration model (I2) • Designing the toolbars (I3)

  21. GUI Demo • Adding a component type • Viewing the component type properties • Filtering the configuration model • Creating a new view • Opening a PCML file as a graphical representation

  22. Plan for the next iteration • Goals • refine architecture • design user interface in more detail • implement remaining use cases • implement GUI-module • test system • Deliverables • GUI-module • Use cases: 2, 3, 14, 17, 20, 23, 29, 30, 31, 32 and 33 • Test report and test log • User's manual • Plus some updates

More Related