1 / 36

Mercury Post-mortem

Mercury Post-mortem. CS 490D April 24, 2001. Overview. Goals of post-mortem procedures Summary of problems Possible solutions & lessons learned Design review w.r.t. implemented functionality. Why do a Post-mortem?. Learn from mistakes & document for future reference

tertius-aric
Télécharger la présentation

Mercury Post-mortem

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. Mercury Post-mortem CS 490D April 24, 2001

  2. Overview • Goals of post-mortem procedures • Summary of problems • Possible solutions & lessons learned • Design review w.r.t. implemented functionality

  3. Why do a Post-mortem? • Learn from mistakes & document for future reference • Examine current state of project • Cannibalize project for useful parts • Extract existing value from project

  4. Problems Encountered • 3 scopes of problems: • Team Scope • Project Scope • Component Scope

  5. Team Scope Problems • Busy schedules • Difficult to meet & coordinate • Large group • Miscommunication & confusion • Strong-willed personalities • Too many chefs • Interruptions, too much debate… • Lack of Accountability • Why should members be responsible? • Personal Issues • Interference from the outside world • Timelining problems • Decreases in available time, over-optimism

  6. Possible Solutions • Set weekly time block for entire group to meet • Meet as sub-groups as necessary • More strict & organized environment for meetings & development • Peer evaluations of performance • Rewards system for progress

  7. Project Scope Problems • Lack of existing infrastructure • No testing procedures • No code repository • No coding standards • Not enough low-level detail in design • Classes not well-defined • Cross-tier interfaces not in design • GUI & Transport never broken-down • UML & Java learning curves

  8. Possible Solutions • Define & implement infrastructure early using existing & familiar tools • Build testing into design early • Design all the way down to method names & parameters • Design entire project in-depth to near psuedocode level

  9. Component Issues • Collaboration Diagram GUI Issues • Engine • Support classes & ContactMgr AccountMgr • ServiceMgr • Transport

  10. Key Reason I Couldn’t get GUI to Work • Design • Didn’t spec out the actual functions and member variables • Didn’t fully understand the communication between layers {i.e. interfaces} • Didn’t have any specs for the GUI. {Not sure what to put in the menu and what to make buttons for}

  11. Key Reason …. Continued • Coding • Didn’t start earlier • Learning curve took longer than expected • Borders between layers were fuzzy due to the lack of defined functions in system design. • Java doesn’t work on every OS the same { menu bar}

  12. Key Reason …. Continued • Research • Swing • Was difficult to find GOOD examples • Wasn’t like a regular CS class where you can just ask a TA your questions! • Forte • Little too late

  13. Key Reason …. Continued • Other reasons • Took on too much for one semester • Underestimated the time • Docs • Coding • Personal problems interfering with work

  14. What would I do differently • Have class functions and member variables clearly defined in design doc. • Have GUI layout before I start coding {i.e what buttons/menu options where} • Read a book on interfaces • Less lenient on others when deadlines are missed

  15. What does work? • GUI is 80% done • Key Classes • Main GUI • Add Buddy GUI • Add Service GUI • Message GUI

  16. What doesn’t work • No connection to middle end via interface • Never fully grasped the communication between layers • AccountMgr wasn’t completed early enough • ServiceMgr wasn’t complete enough to send/receive messages • Interfaces weren’t completely understood

  17. Key features not working • Tree Listener • Scope issues with AddBuddy & AddService Mercury wouldn’t be useable without these features!

  18. Support Classes (complete) • Exceptions • Contact • Account • Message • Status • Interfaces

  19. ContactMgr • Can store contacts • Retrieves contacts • Creates new contacts • Send & Receive messages implemented w/o backing from other components • No support for the ignore list feature yet

  20. AccountMgr - Difficulties • Design • Personal • Testing • Final Status

  21. AccountMgr - Design • Unclear Design • Availability of group members • Data Members and Methods not included • No connection to ServiceMgr explicitly included in design

  22. AccountMgr – Design and Interactions

  23. AccountMgr - Understanding • Lack familiarity with Middle End design • Change in responsibilities • More knowledgeable of Front End design throughout most of project

  24. Timeline 1/10 – Assigned Web Master position 3/23 – Assigned to testing Start of Sem. End of Sem. 2/21 – Part of the GUI team 4/10 – Assigned to develop AccountMgr

  25. AccountMgr - Personal • Time Management • Heavy Courseload • Helping with Java Swing Code • Updating Web Page • Attempting to learn testing procedures

  26. AccountMgr - Testing • Stubs not written to test interaction with other layers • Circular Dependency • GUI waiting for AccountMgr to be developed • AccountMgr waiting for GUI to be developed

  27. AccountMgr - Final Status • AccountMgr code complete according to design document • Not tested • Much of the unspecified but necessary interaction not implemented

  28. Difficulties with ServiceMgr • Unfamiliar with Java Threading Model • Difficulty integrating with Services • Figuring out how to communicate • Dealing with ICQ’s unpredictability • Vague Design • Passing of Account Information • Return Values • How ServiceMgr is used by other classes

  29. ICQ Overview • Encoding was Important • UDP vs. TCP • Packet Acknowledgement • Time to Implement • Working Features

  30. Encoding • Many bit-wise operations • Running packet through a hex table and checksum key • Scrambling key • Without encoding packet, it wouldn’t be recognized • It’s encoding or scrambling but not encrypting

  31. UDP vs. TCP • Messages to server use UDP • Login • Logout • Acknowledgements • Client Lists • Messages between clients use TCP • Messages • Chat • File

  32. Packet Acknowledgement • Use UDP, but need acknowledgement • Session fails without acknowledgement packets • Identification numbers need to be correct or session will fail • Would sometimes send wrong identification numbers

  33. Implementation Time • Challenging work but not impossible • Not a speedy process • Took weeks to get base operations down • Debugging and necessary error-checking were continual • Didn’t get to TCP process. Would take at least 20-40 man-hours to get working

  34. Working Features • UDP • Connect • Disconnect • Receiving packets from ICQ server • Sending Acknowledgements • Encoding

  35. Recap • Importance of detailed design • Invisible & sunk costs should be estimated • Realistic goal setting & time lining is vital

More Related