T 76 115 project review
This presentation is the property of its rightful owner.
Sponsored Links
1 / 23

T-76.115 Project Review PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on
  • Presentation posted in: General

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)

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


T 76 115 project review

T-76.115 Project Review

RoadMappers

Implementation 13.12.2003


Agenda

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


Status of planned goals of the iteration

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


Status of planned deliverables of the iteration

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


Realization of the tasks

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


Working hours by person

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


New plan

…New plan

  • Total amount was updated to 1400 hours

  • Trying to even up the efforts by distributing hours


Quality metrics 1 2

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


Quality metrics 2 2

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


Quality assessment

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


Software size in lines of code loc

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


Changes to the project

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


Risks

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


Work practices

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


Usability tests

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


Results of the iteration

Results of the iteration

  • Technical Specification and Architectural Design (Samuel)

  • Test plan (Mikko)

  • User Interface Design Process (Sanna)


Technical specification and architectural design

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


Example test plan 1 2

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


Example test plan 2 2

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


User interface design process

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)


Gui demo

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


Plan for the next iteration

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


  • Login