1 / 14

T-76.115 Project Review

T-76.115 Project Review. eGo I3 Iteration 17.3.2004. Project status (20 min) achieving the goals of the iteration project metrics Used work practices (5 min) Completed work (15 min) demo Plans for the next iteration (5 min). Agenda. Status of planned goals of the iteration.

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 eGo I3 Iteration17.3.2004

  2. Project status (20min) achieving the goals of the iteration project metrics Used work practices (5 min) Completed work (15min) demo Plans for the next iteration (5 min) Agenda

  3. Status of planned goals of the iteration • Pilot case – Partially OK • The pilot case releaved new feature in quota control that was needed (multiquotas) • After this was solved pilot was started and a new blocker bug was founded(cookies in wap gateway in a long period of time) • The pilot was paused and the bug solved. • Pilot continued later • Working product – OK • Data export – OK

  4. Realization of the tasks • Planning was more accurate than in I2 partly because of shorter period of time • Some hours were left to the last iteration • Meetings took lot less time than expected

  5. About 90% of project is done Only 130 hours left Group had lot of other tasks collapsing with software project Work was done in few long sessions The ”Big Picture” shows that allthough some differencies between persons in iterations the sum of all work is still tolerable Working hours

  6. Quality metrics • BugZilla is part of our everyday life • Most of the open bugs are from peer testing Bug metrics

  7. Quality assessment • Feedback from the Quality Department • Peer testing • Pilot project • System testing at the end of iteration • Overall state of the system is good • Additional bug reporting tools used: TODO-lists, email, Messenger, ICQ... • Overall quality is good 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

  8. Test Documentation • Test planning • System test plan plus separate plan for peer group • Test cases • Used same verified practices as before • Test specification includes test log • Test report • concludes the results of testing • report from peer testing was also delivered • QA in the future • system testing in cooperation with customer • continue research on compatibility with different phone models

  9. Peer testing was executed by group Muuntaja user manuals (web, wap) questionnaire upload web UI functionalities wap interviewing Valuable feedback practical problems (login etc.) problems with WinWAP emulator 8 bugs reported in Bugzilla (severity unspecified) Usability was considered good Peer testing

  10. Software size (Java) • Configuration work, web resources, excel macros etc not included here • VM pages are also not included (both web and wap) • New ways of measuring the code. • The memory space of running project (perhaps some indications of size) Esurvey is 62 Megs at the time. • The number of methods 376 and the number of classes 61 • Hours spend on coding (this only works if same team in different projects) 481 hours

  11. Risks • Risk management is done by three the members of the group attending risk management module • Risk management plan is documented and updated as part of project plan • Current top-5 risks and their countermeasures: • Decrease of motivation caused by too much work in proportion to credits • workload balancing • Hacker attack on server • Distribute code base into group members’ homes • Binary upload of questionnaire • research • Customer requirements not fulfilled • meetings, pilot project... • Interviewing doesn’t work on some important phone model • Use friends’ phones for testing!

  12. Work practices • The group has used all the mandatory practices demanded by the course • Trapoli has not been working reliable. Crashes on every delivery • Bugzilla has been used extensively • The software has been builded in cycles • Personal practice reports are almost ready • Personal practice ”Communication practices” for a closer look • Communication method has to be decided according to target • Different methods with different stake holders • If method is used too much it looses its power

  13. Results of the iteration • DEMOTIME

  14. Plan for the next iteration • Goals • Finish the course with good grade • Leave customer satisfied • Deliverables • Code and deployable packets on a CD • Printed manuals • Final report • Final versions of all documents

More Related