SoftProjJonathan Drake, Neil Howerton, Katie Kester, Doug Siemon

SoftProj is a system that allows student teams in software project classes to submit their software development artifacts for review by other teams.

A team must be registered before submitting an artifact.

The lecturer assigns an RPM (Review Project Manager) to a team the first time the team submits an artifact. The RPM is responsible for handling the review of all artifacts submitted by that team.

After an artifact is submitted, the assigned RPM finds and assigns at least two reviewers from candidate reviewers to review the artifact.

Project Overview

A reviewer uses a template provided by the system to review and rate the artifact.

Once all reviews are entered, the RPM rates the artifact based on the reviews. The RPM can decide the reviews present conflicting views and have reviewers read each other’s review, discuss their viewpoints, and modify reviews.

Once the RPM rates an artifact, the lecturer looks over reviews and rates the artifact, RPM, and reviewers.

The system informs the submitter of review results. A submitter may submit a group of related artifacts. In this

case, the RPM assigns a reviewer to each artifact. A review that cuts across artifacts is also needed. All artifacts in the group are available to all reviewers.

Project Overview cont.

Use Case Diagram

Domain Model

Increment 1: ◦ Created UML use-case diagram, and wrote down assumptions and clarifications

about system. Increment 2:

◦ Wrote core use cases in fully dressed form: Submit an Artifact Review Artifact View Artifact View Review Create Team

◦ Created domain model Increment 3:

◦ Created SSD’s for core scenarios with corresponding operation contracts.

Revisions and Increments

Increment 4:◦ Created UML package diagram, Static architectural model, and design class

diagram.◦ Created SD for three core SSDs (ViewArtifact, ViewReview, submitArtifact)

Increment 5:◦ Created Unit Test Plan, System development plan, and the initial GUI design.◦ More SD’s created. ◦ 10% of Java code is written

Increment 6: ◦ 40% of Java code is written◦ Function Test plan is written

Increment 7:◦ Glossary is written, pattern use described, installation guide and user manual

written◦ Function Test plan extended

Revisions and Increments

The pattern most often used it the observer pattern. Each of the action listeners listening for any actions such as mouse clicks and keystrokes uses the observer pattern.

The Singleton pattern is used in each of our sets (ex. UserSet, ArtifactSet, etc..). We use Singleton because it allows us to only have one copy of each set, and therefore we will not end up with multiple copies of the information used in the system.

The controller follows the facade pattern. The controller gives the GUI a way to interact with the underlying system without having direct knowledge of the system. This hides the inner workings of the system from the user and keeps information private. It reduces the coupling between the GUI and the system. We can change the underlying system and the user and GUI are none the wiser of the changes. 

Patterns

Process of iterative development helped us to revise documents and design strategies as needed

Good communication among group, and between group and customer is vital.

Patterns help when making requirements and class diagrams (overall design of the system).

Lessons Learned