Milestone: M0 Initial Planning and Design

Milestone M0 Checklist

☐ Set of user stories

☐ Definitions document

☐ Sitemap for your web app

☐ User interface wireframes

☐ Class diagram of your model

☐ Customer sign-off

☐ GitHub release (URL submitted to eCourseware dropbox)

☐ Teammate evaluations

The main deliverables to come out of this iteration are a collection of artifacts regarding project requirements, planning, and design.

1. Requirements and Design Artifacts

For this milestone, you must submit the requirements and design artifacts specified in the following subsections.

All your artifacts must be of high quality with respect to the various criteria discussed in class. All your designs should follow principles of good design, such as the SRP (Single Responsibility Principle) and DRY (Don’t Repeat Yourself) principles.

You must use consistent names for things across artifacts. That way, for example, we can tell where each UI sketch fits into the sitemap. Make sure that all artifacts have unique IDs, so that they may be easily cross-referenced in your task reports. For example, you should employ IDs like US1, US2, US3, etc. for your user stories and WF1, WF2, WF3, etc. for your wireframes.

Diagrams need not be anal-retentively typeset; however, they must be readable.

Keep all artifacts with your web app code. Specifically, there will be a folder docs in the top level of your project in which the requirements, design, and planning artifacts will go.

Keep in mind that these artifacts will evolve as the project rolls along. Plan for such evolution.

1.1. User Stories

You must submit a set of user stories that covers all the main feature of the system. Each team should have only one user stories document that is shared by all team members. Your USs must follow the templates/guidelines/principles described in lecture. Additionally, your US document must follow the following template.

# User Stories

Project: (Nickname of project goes here)

## (Second-level headings optionally may be used to group/categorize USs by type of functionality)

| ID          | (ID of user story goes here) |
| ----------- | ----- |
| Title       | (Title of user story goes here) |
| Description | (Description of user store goes here) |
| Estimate    | (Number of days of work required to implement the US) |
| Priority    | (US priority number goes here) |
| Status      | (US status) |

In filling out the above template, you must follow the following constraints:

• The ID must be of the form US1, US2, US3, etc., and each user story must have a unique ID. Don’t change a US’s ID once a valid ID has been assigned, and don’t worry about sorting user stories by ID.
• The title must follow the verb/noun template discussed in class.
• Description must follow the who/what/why template discussed in class.
• Estimate must be one of the following values in days of work:
  • 0.5 days (3–4 hours of work)
  • 1 day (6–8 hours)
  • 1.5 days (around 12 hours)
  • 2 days (around 16 hours)
  • 3 days (around 24 hours)
  • 5 days (around 40 hours)
• Priority must be a number from 10 to 100.
• Status must be one of the following:
  • Not started
  • In progress
  • Completed-intermediate
  • Completed-final

1.2. Definitions

You must submit a definitions document that covers all the key terms, concepts, and business rules referred to in your user stories and other design artifacts. Each team should have only one definitions document that is shared by all team members. The definitions themselves must be clear (however you go about expressing them). Additionally, your definitions document must following template.

# Definitions

Project: (Nickname of project goes here)

## (Second-level headings optionally may be used to organize definitions)

(Definitions of terms and concepts go here)

1.3. Sitemap

You must submit a sitemap that covers all the main pages of your team’s app. I don’t care about the exact notation you use for this diagram. However, it should be easy to figure out what pages your site will have and how those pages will be interconnected. Furthermore, be sure to cross-reference your UI wireframes (explained next).

1.4. UI Wireframes

You must submit user interface wireframes that cover all of the main user interfaces of your team’s web app. Your UI wireframes should show the basic page elements (fields, buttons, etc.). They may or may not be styled (e.g., with colors/graphics). You must give each wireframe a unique ID of the form WF1, WF2, WF3, etc. to facilitate cross-referencing in other documents. Don’t change a wireframe’s ID once a valid ID has been assigned, and don’t worry about sorting wireframes by ID.

1.5. Model Design Diagram

You must submit a UML class diagram of your model. Use proper class diagram notation (as given in lecture). Label all associations, and include all multiplicities. Include attribute types (e.g., “name : string”).

2. Submitting the Milestone

2.1. Customer Sign-Off

Before your milestone submission will be considered complete, your customer have signed off on it, as per the form below. (Note that I will contact the customer directly to collect their sign-off, so you need only to get their verbal approval.)

2.2. GitHub Release

Once all team members tasks have been completed and their pull requests have been merged into the master branch, your team must create a release for the milestone:

• Set the Tag version to m0v1. If changes (e.g., bug fixes) are made to the release after it is created, you can create a new release that includes the changes—just be sure to increment the version (e.g., m0v2).
• Set Release title to Milestone M0, Version 1 (replacing Version 1 with the appropriate version of the release).

As the last step, your team must submit the URL of the release page to the appropriate eCourseware dropbox. Only one team member needs to perform this step. If you need to correct a release, don’t forget to resubmit the URL as well to reflect the correct version.

3. Teammate Evaluations

At the end of each iteration, each team member must provide an evaluation of each other team member. Instructions and forms for performing these teammate evaluations will be communicated by email near the end of the iteration.

Milestone M0 Customer Sign-Off Form

Customers: Please indicate your approval of the following items—but ONLY if you agree 100% with the statement for the item.

If you have ANY disagreement, do not give your approval. Instead, provide the team with feedback, and have them resolve whatever issue is preventing your approval.

☐ I have reviewed the user stories, and they are consistent with my wishes.

☐ I have reviewed the user-interface designs, and I approve of them.

Grading Rubric

Below are each of the grading items for this Milestone, along with their point values and weights. If an item is not submitted at all, 0 points will be awarded for that item. The top-level bullets specify grading criteria. The sub-bullets indicate standard deductions for errors in a submitted item. The deduction list below may not be complete because there may be mistakes that we did not expect. The deduction for an unexpected mistake will be assessed at the time it’s discovered and will reflect how severe the instructor thinks the mistake is. If the deductions for a grading item total more than the total points for that item, 0 points will be awarded for the item.

User Stories

20 points with weight of 30%

• Followed title and description templates
  • -1 for each violation up to a max of -5
• Not too big
  • -1 for each violation up to a max of -5
• Complete set
  • -1 to -10, depending on how incomplete
• Functional user requirements only
  • -1 for each violation up to -3
• Customer-oriented
  • -1 for each violation up to -5
• No design, just requirements
  • -1 for each violation up to -3
• Has status tracking
  • -1 per missing/incorrect status up to -4

Definitions Document

20 points with weight of 10%

• All key terms/concepts defined
  • -1 to -20 per undefined term/concept (that arguably should have been defined) depending on relative size of the concept

Sitemap

20 points with weight of 10%

• Shows pages and how they’re interconnected
  • -15 if the figure doesn’t convey this
  • -1 for each missing page up to -15
  • -1 for each missing connection up to -5
• Clear and understandable
  • -1 to -20 depending how unclear or difficult to understand

User Interface Wireframes

20 points with weight of 20%

• Clear and well detailed
  • -1 to -15 depending on how unclear or how many details are missing
• Shows the basic page elements
  • -1 to -15 depending on how many page elements are not accounted for
• Complete set
  • -1 to -15 depending on how many interfaces are not accounted for

Class Diagram of Model

20 points with weight of 25%

• Clear and detailed
  • -1 to -15 depending on how unclear or how many missing details
• Complete
  • -1 to -15 depending on how incomplete
• Uses proper class diagram notation
  • -1 for each departure from class diagram notation up to -5
• All associations and multiplicities labeled
  • -1 for each missing association or multiplicity label up to -4
• Follows good design principles
  • -1 to -5 depending on the number and severity of design issues

Release in GitHub

20 points with weight of 5%

• Followed prescribed naming convention
  • -3 to -6 depending on how much the release departed from the convention
• Repo well organized
  • -1 to -15 depending on how disorganized the repo is