Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
M4 Domain Design and CRC Summer 2007
Techzilla Specifications:
User Types
- admin (Has the ability to add/delete users, set user types (admin, manager, etc) and add/delete projects. Additionally, an admin can do everything a manager can do)
- manager (For each project, there is a manager who can reject bug reports, delete bug reports, add a new dev, and remove a dev from their project. In addition, Managers can do everything a dev can do).
- dev (For a project, a dev can submit bug reports, search bug reports, be assigned a bug report for fixing, and/or mark a bug report as fixed. Additionally, they can do anything a customer can do.)
- cust (Customers can submit bug reports and receive the following reports: outstanding bugs, rejected bugs.)
The system should ensure that users who login to the system only have the appropriate rights. The system does not have to encrypt passwords. They may be stored in plain text. For basic credit, each user has a single type. For extra credit, you can model the fact that someone may be a manager for Project 1, a developer on Project 2 and just a customer for all other projects.
Bug Reports
When a user wants to submit a Bug Report, they first must login and then select the Project from a list of available projects in the system (the projects which the admin has set up). The user must then provide the following information:
- severity The severity should be either: enhancement, critical, major, normal, minor or trivial.
- description A short one sentence description of the bug.
- details A longer text description of what is wrong with the application. (for extra credit allow users to attach an image/screen shot or log file to the details).
The system then creates a new bug, adds it to the project and timestamps it. The bug is given a status of new and the bug is assigned a unique ID number.
Managers can request the system display a list of new bugs. For each bug, they can change to status to rejected (the bug does not exist), open (the bug does exist but is not assigned to anyone), closed (the bug has been corrected), or assigned (the bug does exist and has a developer working on it). If the Manager sets the status to assigned, the system should prompt for a developer to assign the bug to. The manager should be able to select the developer from a system-supplied list of developers (dev user type) assigned to the project and should also enter an approximate estimate of the effort in hours.
Developers can search for all bug reports based upon any of the following criteria:
- Bugs assigned to me personally
- Status (all open bugs, all closed bugs, etc)
- Date (all bugs after a date or between two dates)
- Extra Credit (all bugs containing a particular word or phrase in the description)
Developers can mark bugs assigned to them as fixed. This results in a status change. When marking a bug as fixed, the system should prompt for a resolution (text), which is recorded in the bug report. Developers should also be allowed to record the number of hours actually required to fix the bug.
Customers can request a display of all outstanding bug reports (all those with a status that is not closed or rejected) or of all rejected bug reports.
Reports
The system should provide the following formatted reports:
- Effort The effort report looks at all the bug reports for a project and totals up the estimated and actual hours of work performed. This is presented as a simple textual display.
- Status The status report looks at all the bug reports and totals up for a project the number of bugs in each status category. This data is then displayed in a pie chart where each slice of the pie is proportional to the number of reports in that category.
- Severity The severity report looks at all the bug reports and totals up for a project the number of bugs at each severity level. The data is then displayed in a bar chart where the length of each bar is proportional to the number of bugs at a given severity level.
- Benchmark This report is available only to managers and allows a manager to compare their bug numbers to other projects in the system. When requested, an xy line chart is generated that plots two lines, your project in blue, and another project in red. The system then plots total defects on y axis against severity categories on the x axis. This allows a manager to see how they are faring compared to other projects.
- Assignment This report is available to developers and should list the projects that the developer is on, and for each project the bugs that have been assigned to that developer.
- Bugs This report is available to anyone and prints a complete listing of all bugs for a selected project.
Other than the required information, your team is free to design the reports and layout in the manner you think is most appropriate.
Persistence
You must be able to save the application data to an external file, shut down the application, restart it and load the data back from the external file.
Extra Credit
Besides the extra credit already listed, your team can propose other extra credit opportunities for design and implementation. As students propose extra credit ideas, I will post them here. Extra credit is applied to the programming portions of the assignment (10% of your grade) so that 10 points extra credit would add 1 point onto your class average.
1. Hook up a database to the system for the backend.
2. Extensive UI enhancements (really nice charting and graphing, autoscaling on window resize, etc)
3. Additional project management or bug track features (look at some of the commercial products for ideas)
M4 Requirements
- Make a team page and indicate your team members and which option you are pursuing.
- A brainstormed list of Domain classes
- A list of candidate classes after filtering
- A set of CRC cards for the candidate classes. Cards should be filled out on both sides (role stereotypes and responsibilties/purpose).
- A set of scenarios that cover typical uses of system and exercise the CRC Cards.
- Meet with assigned TA after submission to discuss your design
Grading Criteria
Brainstormed Classes.......................... 10
CRC Cards..................................... 30
Scenarios..................................... 20
Role Stereotypes, Purpose and Responsibilities 10
Team page setup............................... 10
TA Meeting.................................... 20
Link to this Page