DeMon (which stands for Dependency Monitor) was my group project for CS685 (Software Engineering), taught by Kevin Sullivan during the Fall 1998 semester. The other group members were: Rob Bartholet, Steve Geist, Jim Gunderson, and Miro Kresonja.
This page includes links to all of the documentation, source code, and data files associated with the project. These documents (specificly those which list "Travis" or "txe" as the author) provide a fairly representative example of my current design, coding, and documentation habits.
The project was implemented in Java. It ran successfully in our classroom demonstration and earned me (and likely the other group members as well) an "A". The IPC or file IO libraries provided with our version of the JAVAC compiler were not (at the time) fully compatible with the departmental web server; this prevents the applets from running over the WWW, although they run fine when using the local java viewer.
Note: If you are currently taking CS685, and know or suspect that you may be assigned a similar project, please DO NOT read these web pages; in doing so, you may be violating the honor code.
Each of us wore two hats: that of a Manager and that of a Programmer. As Managers, we each oversaw some part of the software development process, and had "final say" in that area when it came to making decisions (we were free to ask each other for suggestions, however). As Programmers, each of us was responsible for implementing one or more modules within the system.
Note: The following pages don't link back here; you might want to open them in a separate window.
| Title | Member | Responsibilities |
|---|---|---|
| Project Manager | Rob Bartholet | Rob was responsible for ensuring that the overall project development remained focused and on schedule. He saw to it that each of our responsibilities as Managers and Programmers were being met (i.e., he was the "Boss-Boss"). He also wrote the User's Manual. |
| Requirements Manager | Jim Gunderson | Jim was responsible for documenting all of the required functionality of the DeMon. All of the major design decisions regarding program operation went into the Requirements Document. This served as the basis for the Specifications and Testing (see below). |
| Software Development Manager | Travis Emmitt | Trav's main role was to specify how we planned to implement the system, based on the Operational Requirements that Jim had laid out. He wrote the Software Development Plan, the Style Guide, and the Specifications, which define all of the interfaces between modules in the system. |
| Configuration Manager | Steve Geist | Steve organized our Configuration Management procedures, documenting them in the CM Document. He also housed the "public" version of our web pages. (I have copied the final versions to my directory). |
| Quality Assurance Manager | Miro Kresonja | Miro was responsible for ensuring that the system's implementation met the Requirements and Specifications. He did this by developing a Quality Assurance Plan, Checklist, and Testing Plan. |
Note: The following pages don't link back here; you might want to open them in a separate window.
| Document | Authors | Description |
|---|---|---|
| Operational Requirements | Jim, Miro | Provides an overview of the project design, from an operational standpoint. Includes preliminary design sketches. |
| Tracking and Oversight Plan | Rob | Lists the Project Manager's strategies for keeping development on track, and outlines the weekly meeting schedules and project milestones (deadlines). |
| Software Development Plan | Travis | Somewhat superseding the Tracking and Oversight plan, this specifies our meeting schedule, the modular coding responsibilities of each of the Programmers, and the greatest perceived risks to project development. |
| Style Guide | Travis | These coding guidelines are meant to ensure that we can read and modify each other's source code without a steep stylistic learning curve. |
| Software Specifications | Travis | Provides an implementation-based overview of system architecture, operation, and a complete definition of all modules' required operations and interfaces. No coding of any module was allowed until it had been fully specified in this document. Also contains links to Makefile and data files. |
| Configuration Management Plan | Steve | General CM policy, instructions on how to use RCS, and the current contents of the RCS repository. Trav's Makefile ended up automating the RCS procedures. |
| Quality Assurance Plan | Miro | Specifies measures for ensuring that the program implementation meets the Requirements and Specification. Includes a checklist, testing plan, and sample QA report. |
| User's Manual | Rob | High level description of program operation. Includes screen grabs of the program in execution. |
| Parnas Example | Jim | Example modularization, based on configurations meantioned in 1972 Parnas paper. |
Note: The following pages don't link back here; you might want to open them in a separate window.
The following applets don't operate over the WWW. Check out the screen grabs in the User's Manual to get a view of the program in action.