Sunday, August 15, 2010

Project Monitoring and Control for Task Coach

As announced in a previous posting, I am investigating which of the CMMI goals are achieved by the Task Coach project. The fourth process area I am looking at is Project Monitoring and Control (PMC). PMC is a project management process area at level two of the CMMI for Development. Because PMC is part of the core model foundation, it is also part of the other two CMMI constellations, CMMI for Services and CMMI for Acquisition. But here, I'll be looking at PMC from a development perspective.

According to the CMMI, "The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan." When we were investigating Project Planning (PP), we saw that the Task Coach project doesn't really do much project planning and that it doesn't have an established project plan. That probably means the PMC goals and practices won't be implemented either, but let's investigate that more closely before we draw conclusions.


The first specific goal (SG1) of PMC states "Actual performance and progress of the project are monitored against the project plan." To achieve this first goal, CMMI expects us to implement seven specific practices.

The first specific practice (SP1.1) of PMC reads "Monitor the actual values of the project planning parameters against the project plan." Since there is no project plan and there are no project planning parameters, this practice cannot be, and is not, implemented.

The second specific practice (SP1.2) of PMC expects us to "Monitor commitments against those identified in the project plan." Since we don't have a project plan, don't have documented commitments and we don't monitor (implicit) commitments, this practice is not implemented.

The third specific practice (SP1.3) of PMC says "Monitor risks against those identified in the project plan." Again, we don't have a project plan and we don't explicitly identify risks, so we cannot and do not monitor risks.

The fourth specific practice (SP1.4) of PMC wants us to "Monitor the management of project data against the project plan." Almost all project data is in some online repository (Subversion repository, bug tracker, feature request tracker, etc.) and these are monitored by means of automated emails when something gets changed. However, CMMI expects us to monitor the management of project data. I'm not sure monitoring the data itself is the same as monitoring the management of the data. Probably not, but then I don't know how to interpret this practice in the context of this project.

The fifth specific practice (SP1.5) of SG1 of PMC reads "Monitor stakeholder involvement against the project plan." As explained in the discussion of Project Planning, we do involve stakeholders (users mostly) but this is not monitored against a plan.

The sixth specific practice (SP1.6) of SG1 of PMC expects us to "Periodically review the project's progress, performance, and issues." This is something that is not done on a periodic basis, but could be a nice additional practice for the project.

The last specific practice (SP1.7) of SG1 of PMC is "Review the accomplishments and results of the project at selected project milestones." Like SP1.6, this not done, but would be good to do, probably in the form of post-release retrospectives.

Well, the conclusion is simple. The Task Coach project does not achieve the first specific goal of PMC.

The second specific goal (SG2) of PMC reads "Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan." Again, without a plan, this goal is hard to achieve. But let's look briefly at the practices anyway.

The first specific practice (SP2.1) of SG2 expects us to "Collect and analyze the issues and determine the corrective actions necessary to address the issues." We don't collect issues other than bugs. That doesn't mean there are no issues besides bugs of course, but these don't get collected and analyzed in a repeatable manner. It could be a good idea to keep track of other issues somewhere. Sourceforge allows for creating additional "trackers", so it wouldn't be hard to create a separate "issue tracker".

The second specific practice (SP2.2) of SG2 wants us to "Take corrective action on identified issues." Since we don't explicitly identify issues we also don't explicitly take corrective actions. At least not in a structured manner.

The third specific practice (SP2.3) of SG2 then expects us to "Manage corrective actions to closure." Again, we don't do this. Having an issue tracker would greatly help us do this.

Again, the conclusion is simple. This second goal of PMC hasn't been achieved either.

Friday, August 13, 2010

Tricks for debugging a wxPython GUI

The other day, it took me quite some time to debug an issue that would have taken much less time had I used these two tools sooner:
  • The wxPython Widget Inspection Tool that shows how GUI elements are related, and,
  • The traceback module that makes it easy to see who is calling a method by putting this line in a method: import traceback; traceback.print_stack().
Hopefully writing this down makes it easier to remember these tools for the next occasion.