Development ProcessBelow are some notes about systems that can help the development process. Software developers are encouraged to explore these areas further.
Study GroupsJohn 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.
UMLUML 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 ReviewsThe 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
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 SoftwareThe Capability Maturity Model (CMM-SW) for Software, developed by Carnegie Mellon's Software Engineering Institute, is described at
The CMM-SW consists of 5 maturity levels: