360 likes | 724 Views
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
E N D
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 • Examine current state of project • Cannibalize project for useful parts • Extract existing value from project
Problems Encountered • 3 scopes of problems: • Team Scope • Project Scope • Component Scope
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
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
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
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
Component Issues • Collaboration Diagram GUI Issues • Engine • Support classes & ContactMgr AccountMgr • ServiceMgr • Transport
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}
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}
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
Key Reason …. Continued • Other reasons • Took on too much for one semester • Underestimated the time • Docs • Coding • Personal problems interfering with work
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
What does work? • GUI is 80% done • Key Classes • Main GUI • Add Buddy GUI • Add Service GUI • Message GUI
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
Key features not working • Tree Listener • Scope issues with AddBuddy & AddService Mercury wouldn’t be useable without these features!
Support Classes (complete) • Exceptions • Contact • Account • Message • Status • Interfaces
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
AccountMgr - Difficulties • Design • Personal • Testing • Final Status
AccountMgr - Design • Unclear Design • Availability of group members • Data Members and Methods not included • No connection to ServiceMgr explicitly included in design
AccountMgr - Understanding • Lack familiarity with Middle End design • Change in responsibilities • More knowledgeable of Front End design throughout most of project
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
AccountMgr - Personal • Time Management • Heavy Courseload • Helping with Java Swing Code • Updating Web Page • Attempting to learn testing procedures
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
AccountMgr - Final Status • AccountMgr code complete according to design document • Not tested • Much of the unspecified but necessary interaction not implemented
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
ICQ Overview • Encoding was Important • UDP vs. TCP • Packet Acknowledgement • Time to Implement • Working Features
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
UDP vs. TCP • Messages to server use UDP • Login • Logout • Acknowledgements • Client Lists • Messages between clients use TCP • Messages • Chat • File
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
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
Working Features • UDP • Connect • Disconnect • Receiving packets from ICQ server • Sending Acknowledgements • Encoding
Recap • Importance of detailed design • Invisible & sunk costs should be estimated • Realistic goal setting & time lining is vital