Operating Systems Project Postmortem

I finished an operating systems course a couple weeks ago. The main component of the course was the group project. The course project was to implement the following (which I copied from the syllabus):

The system is designed to remotely monitor and control the servers deployed in the ECS (our school’s computer science network) local area network. It
is expected to have the following features:

• A Web interface to enable the IT administrator to remotely manage the Linux and the Windows servers in real time;

• The management interface enables both performance monitoring and system control.

• The Performance monitoring component collects, manipulates, and displays statistics of a server and its applications such as CPU, memory, disk, and network utilization.

• The system control component enables the IT administrator to remotely execute commands against the managed servers, e.g. login, shutdown, restart, basic file management, etc.

The below diagram shows the system outline:

The class was organized into three teams (1) Windows agent, (2) Linux agent and the managing server, (3) Web server.

I was the team lead for team (2). The timeline of the project was the beginning of September through the first week of December. Which gave us a little more than 3 months. Our professor Dr. Ouyang had us give a sequence of demos during the three months and then submit a working system at the end.

What We Did Right
As the team lead for my team I instituted use of github.com for revision control. Github.com was a great choice, it’s an amazing site. The source code is available at https://github.com/bjwbell/CSC239-Linux-Team.

The web team used Dropbox for source code collaboration. Dropbox was a reasonable choice but they had to track revisions of the software manually so they ended up with directory names like “Website V017”. The Windows team was a mess they didn’t have any centralized collaboration system until the end where google code was used, https://code.google.com/p/239windowsteam/.

Another thing we did right was that my teammate Vinit Azad did a great job of specifying the interface between the agents and the managing server. This made it much easier to split the work up and have individuals program to the interface.

What We Did Wrong

  • We didn’t impose hard deadlines. This caused portions of the project to be pushed later and later. At the end this caused integration issues where we were working on the managing server and the webserver while we were trying to integrate them.
  • I didn’t fully specify the interface between the managing server and the web server. This caused problems when we integrated the two. It would have been much easier for the website team if I had specified a complete interface to the managing server that they could have programed against. This would have made integration significantly easier.

I would recommend setting a weekly schedule upfront with very specific milestones for each week with each milestone a portion of the project grade. The milestones should not be verbal confirmation that the milestone goals have been finished. Instead each team would email the professor their code with instructions on how to run it. With the code the professor can independently decide what part of the milestone goals have been finished. It is important that the team leads are not the ones to determine if the milestone goals have been completed because they are not independent evaluators.

The results of our class project were mixed. I could have done a much better job with specifying the interface between the managing server and web server. I didn’t realize until the end the importance of first specifying the interface and then coding to the interface. Given the constraints that it was a class project –so most of the team members had only had about one day per week to work on it– I believe a well defined schedule is very important to determine if the teams are falling behind and if so in exactly what areas.