Final Report for Dismal Prospects

CS 4500, Spring 2008

24 April 2008

1. Product-Related Information
   • Current Status of Product
     • Product is stable and ready for basic use: delay, bandwidth, link up/down.
     • Current agent supports RED/GRED queueing. Our agent does not yet, but was outside scope of project. Support can be easily added. Was not added due to time constraints.
     • Agent was never tested in a Linux delay node configuration. There are other parts of the Emulab architecture that would need to be changed to support a Linux delay node, and they were outside the scope of the project. No change to the new agent should be required to support this configuration.
   • Recommended Work
     • Adding support for packet loss rate and RED/GRED queues needs to be added before it can replace the current agent.
     • Modification of Emulab to support a Linux delay node.
     • Currently only FreeBSD 5.4 is supported (possibly later revisions as well). Supporting older revisons should be possible, but will require additional work.
     • Advice to Teams Continuing this Project

2. Project Team Information
   • Management Objectives and Priorities
     • Our management objectives and priorities have not changed from those expressed in the project plan. We used the Emulab wiki, cvs repository, and defect tracking tools to manage our project. We worked closely with the client to ensure that client needs were met. We also made sure that the final result is usable as a replacement for the existing Emulab delay agent.
   • Final Team Structure
     • Jon Duerig was responsible for the design and implementation of the front-end. Ryan Jackson was responsible for the back-end implementation.
     • Both of us reviewed each others' work to make sure there were no obvious design or implementation problems.
     • No changes to team structure would be necessary if starting the project over.
     • The team structure works as long as the interfaces between the modules has been clearly defined. If interface changes become necessary, they need to be noted and discussed.
     • Both of us fulfilled our roles and participated in the project. We each had other responsibilities (family, work, class, or personal) that sometimes made communication and collaboration difficult due to scheduling conflicts.
   • Schedule and Planning
     • We had no problem sticking to our weekly meeting with each other and the client.
     • Code reviews were not as formal or regular as specified in the project plan.
     • We used the Emulab wiki to help us track our progress and document project goals. Our weekly management reports were a very helpful tool for this purpose.
     • We could have been more formal with our scheduling. We tended to be pretty lax with internal (not class) deadlines due to outside scheduling constraints. Sticking to our schedule would have made things less stressful and helped us meet both internal and class deadlines.
   • Support Functions
     • Our Quality Assurance functions were handled by both of us, mainly through testing of each component as well as performing regular system tests at each milestone.
     • We used the Emulab wiki for defect tracking, although it was not extremely formalized. Due to the lack of formal defect tracking, most issues were not known to the other team members. Using the Emulab bug tracking system would have helped us keep track of each others' issues.
   • Working With the Client
     • We had a good relationship with the client. Discussing project progress during our weekly meetings always went well. The client was always consulted when making major design or implementation changes. The client also provided us wil all the information on the Emulab architecture that we needed during the course of the project.
     • We could have improved the relationship with the client if we had better scheduling practices. Sometimes meetings with the client had to be cut short for various reasons. Working more closely with the client's schedule would have helped.
   • Work With Project Mentors
     • Working with a mentor was good. It helped us to understand where our design or implementation may have problems or may not meet the client's needs.
     • Make sure to discuss major design and implementation ideas with your project mentor. It helps to eliminate bad or faulty ideas early on instead of later during implementation.
   • Other Issues
     • None

3. Feedback From the Mentors
   • We fulfilled the requirements for the project, but more features will need to be added before our implementation is ready to replace the existing implementation.
   • We spent too much time exploring the problem space and working out the abstract design before starting on the actual code.
   • We should have spent more time refining the requirements so that we didn't spend time designing for non-existant needs, such as having the front-end and back-end be separate processes.

   • Three General Pieces of Advice
     • If at all possible, try to have more than two people in your group. We were both busy with other things this semester, causing problems in scheduling and communication.
     • Make sure to have code and design reviews. This will help to reduce design flaws and bugs.
     • If you use test-driven development, make sure you have good tests and that you can easily automate them. Use the tests on each component and during development to help eliminate lurking bugs later on.