Development Process

Below are some notes about systems that can help the development process. Software developers are encouraged to explore these areas further.

Study Groups

John Reekie proposed that the Ptolemy group have weekly study groups, and many of the study groups were about software engineering issues.

The format of a study group is that at the beginning of the semester, individuals proposed topics and we decided as a group what topics we would cover, and who would facilitate the study group. The facilitator then chose the reading material and distributed it to individuals. Everyone was encouraged to read all the material, but each section of the material was assigned to an individual who would make an attempt to really understand the section.

This particpatory aspect of the study group is, in my mind, the single most important aspect of the study groups since it promoted involvement by each individual.

We covered a number of different software engineering issues, including UML, design reviews and CMM.

We strongly encourage individual research teams to set up study groups. We chose to do ours from 4-5:15 on Fridays, and then servered refreshments afterwards.

UML

UML diagrams are a good way to communicate and discuss the design of a system. UML diagrams give a development group a common language, where a picture is worth a thousand words.

When UML diagrams are combined with design patterns, then it becomes much easier to identify recurring themes, and for developers to quickly communicate ideas about class structure and how classes interact.

The "Software Practice in the Ptolemy Project," paper has more information about UML

Design and Code Reviews

The Ptolemy Project system of Design and Code Reviews is documented in "Software Practice in the Ptolemy Project,"

Each source file in the Ptolemy II System has a rating

Red: Unreviewed code, interface (method names etc.) subject to change
Yellow: Design reviewed code, interface is not likely to change
Green: Code reviewed code, interface is stable
Blue: Fully tested and documented stable code

A design or code review involves the following people:

The Moderator: who keeps things moving
The Author: who answers questions about the code
The Reviewers: who raise issues about the code
The Scribe: who takes notes about issues raised

The Ptolemy group usually scheduled two reviews a week at predetermined times.

To have a review, the author finds a moderator who in turn finds reviewers and a scribe. The moderator put up a web page with the review material, which usually included the javadoc output, and the source code. Design reviews usually had UML diagrams.

Design and code reviews take an hour to an hour and half.

The point of a design and code review is raise issues about the code, and not to provide solutions.

After the review, the scribe posts the notes on a web page, and the author goes through each issue and either fixes the problem, or explains that the issue is not really a problem.

The literature is full of statistics about the efficacy of detecting bugs by doing desk checks of the code. In the Ptolemy project, we found that many fundamental design flaws were detected early on by having a design review. This early detection helped us fix bugs earlier in the release cycle.

Capability Maturity Model (CMM-SW) for Software

The Capability Maturity Model (CMM-SW) for Software, developed by Carnegie Mellon's Software Engineering Institute, is described at http://www.sei.cmu.edu/cmm/cmm.html

The CMM-SW consists of 5 maturity levels:

Initial - chaotic and ad 'hack' methodology, success depend on heroics
Repeatable - project management skill are used to analyze and determine the schedule and cost. The success of previous projects can be repeated with newer, similar projects
Defined - the software process is documented, and all projects use an approved version of the process
Managed - results are carefully instrumented and controlled
Optimizing - feedback from analytical data is used to tune the software process .

Obviously, it is probably not appropriate in an academic environment to require CMM-SW level 5 for all software activities. However, being aware of the different levels can pay off in terms of higher quality product, and fewer last minute all nighters.

You are not logged in