Final Project Description

Projects are usually somewhat open-ended. If we do not specify how you have to do something, then you are free to use your own imagination. You may use any of the code from M1 and M2 (that you or your teammates wrote),or you may decide to throw it all out and start over.

A few extra credit opportunities are suggested. You may propose other ideas by sending them to me via email. This milestone is in two parts. You will develop your deliverables as detailed below. Then you will set up a time to meet with your TA. Your TA will look over your design and make recommendations. You will then turn in the corrected information. Because of the summer semester, you will have only 1 weekstotal to work on this milestone, so plan ahead to meet with the TA in time to incorporate their suggestions.

Your project team should have 4 people. While 4 is an upper limit, I have had teams of 3 (and a couple of 2). The requirements are still the same, so most people opt for the full 4 people. Please post your project team pages by Friday, 6 June, so I can pair up students not on a team.

VisualScrum

As you may have surmised from M1 and M2, this semester's project is designing and implementing a team project management support tool. This tool supports an Agile Development methodology called SCRUM. This is the current project management technique used in the Senior Design class (CS4911).

The Application

VisualScrum is an application to help teams plan and track their software projects. Team members login to the application and can view tasks assigned to them, report on completion status, hold a distributed meeting and generate reports. There is not a requirement for concurrent access (except for extra credit).

VisualScrum may host one or more projects being completed by one or more teams. Team members may be a part of multiple projects, but should only be able to view the project that they are currently logged in to.

VisualScrum maintains security logs. These logs record all login attempts (successful and failed). Additionally, it logs the userid of anyone when they create, edit or delete a project, task or feature. The log format can be up to you, as long as it records the userid of the person attempting the action, the time the action occured, and what the action was.

VisualScrum data should be persistent between application invocations. Thus if I enter users, then they should be "remembered" the next time the server starts up. You may use flat files or you may hook up to a database (extra credit).

Projects

VisualScrum hosts one or more projects. A project represents a single software application or component being built by a single team. A project has the following data:

• Project Name: A short descriptive name of the project
• Project Description: A detailed text description of the project
• Team Members: A set of team members. Each team member has a name, email, userid and password.
• Project Manager: One of the team members is designated the project manager.
• Start Date: The date the project started or is planned to start
• End Date: The date the project is scheduled to be completed or the date it was completed
• Status: In-Progress, Completed, Not Started, Cancelled or Transferred.
• Total Hours Projected: derived by adding up all work remaining estimates for all features in the project
• Burndown. For each week the project is active, the work remaining is "remembered". This is the project work history.

Features

The fundamental way that VisualScrum helps manage projects is through the concept of a feature. A project is composed of a set of features that will be implemented in the project. Features represent the functionality of the software system we are building. Features have the following data:

• Feature Name: A short descriptive name of the feature.
• Priority Category: This is one of 5 values: Very High, High, Medium, Low, Very Low. It represents a high-level ordering of the features based upon customer desires.
• Priority: A number from 1 - n that represents the current priority of the feature. 1 = highest priority task to complete,
• Description: A longer text description of the feature.
• Estimate: A number in hours of how long the team thinks it will take to complete this feature
• Work Remaining: A number of hours that expresses how much work is left to do. If it equals the estimate, then no progress is being made, if it is 0 the feature is completed. This value is derived by summing all the work remaining data of the supporting tasks.

Tasks

Tasks A task is a piece of work on the project that can be assigned to a single team member. A feature may have one or more tasks that need to be completed to implement it. Tasks have the following data components:

• Display name: This is a short string or title that can represent the task.
• Description: A longer text description of the task.
• Priority Category: This is one of 5 values: Very High, High, Medium, Low, Very Low. It represents a high-level ordering of the tasks based upon customer desires.
• Priority: A number from 1 - n that represents the current priority of a task. 1 = highest priority task to complete,
• Original Estimate: An estimate in hours of how long that task will take
• Assigned To: The project team member responsible for this task.
• Work Remaining: The number of hours left to complete this task.
• Status: One of 5 values: Not Started, In-Progress, Completed, Cancelled, Transferred.

The total of all the task original estimates for a feature should equal the total estimate for the feature that this task supports. The total of all work remaining on a task should equal the work remaining on the feature that it implements. For example I have the feature: Print Services. Our team estimated that it would take 30 hours to implement. We broke the feature down into 4 tasks: Create Print Dialog Box - 5 hours, Create Print Job Buffer - 10 hours, Write Print Driver - 10 hours, Integrate into GUI - 5 hours. Bob works 3 hours and the dialog box and estimates there is 4 hours to go. Sally works 4 hours on the print buffer and estimates she has 1 hour remaining. Pete works on the print driver for 8 hours and estimates there are 3 hours to go. Fred has not begun integration, so there is 5 hours still left to do. Our Feature Work Remaining should show: 13 hours.

Project Execution

Projects are executed in iterative increments called Sprints. A sprint normally consists of 4 weeks, but the sprint length should be configurable by the Project Manager. The Project Manager should be able to specify an estimated number of sprints for the project.

Project managers control the overall project through a display known as the Product Backlog. This is a list of the Features ordered by Priority from highest to lowest. The format is shown below:

The first 2 columns come directly from your Feature data (name and estimate). The work remaining shows how many hours of work there are left in the project (on the bottom total row) and how much for each feature is left (each row entry). In the example above, when we start Sprint 1, we have 120 hours of work on the project. The project selection feature we see has 3 hours of work left at the start of Sprint 1. Since there is zero hours in sprint 2, we must have completed it. Looking at the Trend Report feature, we see that for Sprint 1, 2, 3 the work remaining is constant at 5 hours. This tells us one of two things, we either did not work on this Feature till Sprint 3, where we finished it, or we worked on it in earlier sprints, but it took longer than planned, so we did not make any progress on it.

Each Sprint is controlled through the Sprint Backlog. This is a list of all Tasks for the Features in that Sprint. The Sprint backlog looks like:

Here we see the sprint layed out from start to finish. For each high-priority feature placed in the sprint, all its associated tasks are placed in the current sprint backlog. People can update the status, and work remaining on a task. Once the work remaining is 0, that task is completed. At a glance, the team can see what they are supposed to be working on, how much time is left and what the status of the different tasks is.

Reports

Management Information Systems like VisualScrum are not much good if they don't present information in a useful format. The following reports should be generated from VisualScrum:

• Adminstrator summary report. If someone logs onto VisualScrum as an administrator, they should be able to view this report. It basically gives a list of all Projects on the server grouped by: Projects completed, Projects in progress, Projects not yet started. For each project, in a group, list the project name, project manager, total hours originally projected and total hours remaining.

• Product Backlog. Anyone logged into the project should be able to view the current product backlog. Should be displayed in a spreadsheet-like format

• Sprint Backlog. Anyone logged into the project should be able to view the current sprint backlog. Should be displayed in a spreadsheet-like format.

• Work Plan. If someone is logged into a project and is a team member, they should be able to view all the tasks assigned to them. For each task assigned to that person, the task name, status, estimate, priority, and work remaining should be shown.

• Project Burndown graph. For a project, display a graph by sprint that shows the hours remaining on the project.

• Sprint Burndown graph. For a sprint, display a graph by day, that shows the hours remaining in that sprint.

Roles

• Administrator. This is the person(s) who can create new projects and delete old projects from VisualScrum. They can also add, create, update and delete users (project managers and team members). The administrator can reset a user's password or inactivate a user (disable their login with deleting them). Additionally, they are allowed to request the administrator summary report.

• Project Managers. This is the person responsible for managing a particular project. Project managers are also team members as they may be performing tasks in addition to their project management responsibilities. Project managers can add new people (from a list that the administrator has already entered) to the project as team members. The Project manager can also control whether team members can create and delete features and tasks, or just read and edit them. Project managers can always create and delete tasks and features. Project managers set the sprint length.

• Team Members. These are the people working on the project. Team members can read or edit features and tasks. If the project manager allows, they can also create and delete features and tasks (extra credit).

Extra Credit:

• Database back end
• Multiple Concurrent Users (client-server or P2P)
• More extensive security rights (such as the ability to override default rights)

M3 Requirements

• Create team page and indicate your team members. (PLEASE DO THIS AS SOON AS POSSIBLE)
• 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 responsibilities/purpose). These should real index cards, not a word document.
• A set of scenarios that cover typical uses of system and exercise the CRC Cards. The number of scenarios is left to you, but they should cover the major uses of the system.
• Meet with assigned TA to discuss your design and get corrections.

Grading Criteria

• Brainstormed Classes................................. 10
• CRC Cards............................................... 30
• Scenarios................................................ 20
• Role Stereotypes, Purpose and Responsibilities 10
• Team page setup...................................... 10
• TA Meeting.............................................. 20