Project Activities and Deliverables

---

Activity: Team Formation

Teams will be formed by yourselves, with some guidance from the instructor. However, within each team, there will be a designated team coordinator. Read the team roles descriptions and determine what team member will serve as the team coordinator. It is ok for the team coordinator to serve as the team leader, however it is not essential. It is encouraged for teams to consider changing team coordinators between each release.

In addition, exchange phone numbers as well as any other ways of communicating. Your team will also use Google Docs and Google Drive for storing documentation, and sharing it with your team as well as your instructor. Set up a Google Drive folder using your team name, and share the folder with team members (be sure to provide everyone with edit permissions!) Make sure everyone is comfortable using Google Docs as a collaborative tool.

Also be sure to share your Google Drive folder with me - mike.panitz at gmail etc etc

Deliverables:

1. Team Roles
   The team coordinator is to email the instructor the a list that identifies which person will be acting in which role(s).
   
2. Team Name
   The team coordinator is to include the name of the team in the email that lists the team roles.
   
3. Establish a Google Drive/Docs folder
   Based on team roles one person should establish a Google Drive/Docs folder for the team's shared documents.
   The folder must be shared with the other team members.
   This folder must also be shared with the instructor (it's fine to give the instructor read-only access to the folder, if you'd prefer)

---

Activity: Project Concept

Brainstorming  is  a team-based approach for creative problem-solving. The  concept behind this is to generate lots of ideas - including wild-and-crazy ideas as well - and then to subsequently choose one or more and synthesize the idea(s) into a coherent approach to the problem.

You will first be provided a statement of needs for a Math game to teach elementary school children math concepts. Each team member must read through the statement of need prior to the brainstorming activity.

Prior to the brainstorming session, each team member will then write down ideas for potential projects. The ideas will be brief descriptions (1-3 sentences) The brainstorming session will consist of:

1) Each team member will briefly describe their ideas to the team and all ideas will be written down on a board or piece of paper for all team members to see. During this initial phase, ideas are NOT evaluated: the contributor describes the idea and it gets put down, but no one else is allowed to comment on it.  (The idea of this is to create a non-threatening, non-evaluative environment, and to allow room for “crazy” ideas).

2) Once everyone’s ideas have been contributed,  the team then develops the project concept from this pool of ideas.  Note that ideas are not explicitly rejected, instead various good ideas are identified and synthesized into a solution.  An approach of discussing and developing a consensus is much preferable to voting.

At this stage, the focus is  primarily on whether the proposed project meets the customer needs, and whether it is feasible within the time and effort constraints.

Deliverable: Project Concept Document

This is a 2-3 page description of the concept for the project. This will include a description of how it is to be built and how it will work. This may include diagrams as well. This document does not need to be too detailed, rather, it is intended to convey the project concept to the customer and see if they like it and want to make any changes. It is ok if you want to take photos of hand-drawn illustrations, etc. The important thing is to effectively convey your initial ideas!

The content of this document is:

- Description of the idea

- Drawings and/or diagrams (if necessary)

- Profile of the users - who will use it and how?

- Usage model - how it will be used.

You may borrow from the statement of needs you are adopting.  This  will be written up as a Google Doc.  Ultimately, this document will serve as the starting point for a specific requirements document.
The due date for this deliverable is listed on the course schedule.

 IN ADDITION,  you must use Slack (to a substantive degree) to do this work.  You can use other things, too, but you need to show me that you can use Slack successfully, should you need to do so in the workforce. (This was added on 3/28/2018) 

---

Activity: Project Requirements

The requirements document is a detailed description of the proposed deliverable: what features it will support, what platform it will run on etc.  To create the requirements, work through the project idea to determine what specific features the product needs to have in order to make it useful and attractive, and in order to fulfill all the requirements mentioned in the project description.  Keep the time and effort constraints in mind and make sure the requirements are feasible.  The instructor is the customer, feel free to show them your preliminary requirements if you need some feedback before finalizing your requirements (your instructor will give you further feedback after you submit them).

In general, real-world software requirement specification (SRS) documents are much larger than what you will design as they may be 50 pages long with hundreds of user stories. We are attempting to build such a document on a smaller scale while retaining the core concepts.

Prepare user stories for the project. Using the stories, walk through the system. Identify a path through the system for each user/actor. 

-- Is the system complete? 

-- Is something missing? 

-- Are there features which seem incomplete? 

-- Is there too much?

Try to remedy any deficiencies so to make the user stories a reasonable example of the project.


It is important to note that developing the project concept, defining requirements, planning and creating a preliminary high-level design are not really totally sequential – they will all be affected by one another to some extent.  Do not expect to get everything “just right” after the first pass.

After you have identified your user stories, estimate  each user story using story points as the metric.

Lastly, prioritize them as 1,2,3 based upon the release. (i.e. a priority of 1 will go into release 1, a priority of 3 will go into release 3.)

Deliverable: Project Requirements Document

Using the following template, complete the requirements document and submit it to your shared Google Docs account.

You must also include a copy of the Common Core document(s) that you used to make sure that your software meets the Common Core requirements for 1st grade math instruction.

---

Activity: Dividing Up the Work

Once your group has determined the user stories that are to go into Release 1, you must further divide each user story into separate tasks. Whereas a user story describes a user-oriented level of functionality, the tasks are typically developer-oriented, and describe the technical activities that must be completed to fulfill the user story. Review the user stories that go into R1, and divide each user story into one or more tasks. Furthermore, provide an estimation in hours of how long completing the task is expected to require. This will include development, testing, and integration. This documentation will be considered as part of recording project requirements.

Each developer must then be assigned work. Details on how to approach this will be covered in class.


Deliverable: Project Status Document

This document will maintain the status of each task or user story as you proceed through the development process. An example describing how this document may appear can be found here. Keep in mind this is a living document - it is the responsibility of each developer to update this document when the status of a task or user story changes. Therefore, it is best that this document reside as a Google Doc.
There's also an example in the Agile.EDU slides

---

Activity: Acceptance Testing

Acceptance tests are used to test the validity of user stories. Acceptance tests are explained in this document (note: I'm linking to something from UC Santa Cruz.  Read the stuff that talks about acceptance tests in detail and ignore anything about how that other class is being run)

Deliverable: Acceptance Test Plan

Using the following template, fill in the acceptance tests for the user stories for Release 1.

---

---

Activity: Bug Tracking

Design a bug tracking system where you maintain a list of known bugs in your system, as well as the status of the bugs. A "bug" is a known failure, flaw, or defect in your system, and one that requires addressing by a developer. 

Deliverable

Please use the Issues feature of GitHub, to track bugs. 
For this deliverable each team must do the following:

1. EVERY member of the team must log at least one bug.
   Remember that the bug can be pretty trivial stuff, such as text overlapping an image (thus making the text hard to read).
2. At least 2 out of the 3 team members much log a bug, fix the bug, check the bugfix into GitHub (etc.) and then mark the bug resolved  (close the bug)
   1. For a team with an odd number of members you must round up.  For example, in a team of 3 members, 2 people must fix a bug

---

Activity: Release 2

Contents of Release 2:

- All code checked in to repository.

- Updated design documents consistent with project. [3 points]

- Updated requirements document with any changes to user stories, story points, and schedule. [2 points]

- Updated test report for acceptance tests. [3 points]

- Updated project status document. [3 points]

- Bug tracking software was used to track bugs. [3 points]

- Automated tests (either Selenium tests or unit tests built using a unit-testing framework (such as NUnit) ). [3 points]
Each team member must contribute (at least) one test case.  Overall, the test cases should thoroughly test one feature of your program (such as the login feature, or user account feature, etc)

- The code review. [3 points]


In your test report document, fill in the column for the current release.  Write "Passed" (in green) if the test passed, a red message "Failed"  if it failed (even if it failed only in some cases), and a yellow tag "Caution" if it passed but had some problems that needed fixing (e.g. “able to add user, but part of name gets chopped off”).  For tests that fail, add  a remarks section describing the circumstances in which it fails.  If a test failed, then you fixed the problem and it passed, leave both the red and the green mark in the test report.

For this release you must include EITHER unit test(s) or else Selenium test(s) for each acceptance test case.

Remember you must re-run all acceptance tests from R1 as part of R2!

Deliverable: Release 2 Presentation

You will give a 15 minute presentation demonstrating the features of Release 2. The format is:

- All team members must participate in the presentation, not one “speaker”. Each member must describe what portion of the project they worked on.

- A demo of the program so far.

- Any design decisions that have changed since R1.

- Any user stories that were pushed back to R3, or moved ahead to R2.

Here is the Presentation Rubric I will use to assess your R2 presentation, product delivery and reflection. [50 points]

---

Activity: Individual Report

All activities for your project have been team-based. However, this activity involves you submitting an individual, confidential report of how you felt your teammates contributed to the project.

Deliverable: Individual Report

Submit a report that highlights how each member of your team contributed to the project. In particular, focus on their level of contribution, responsiveness, responsibility, and accountability. This should not be a lengthy report (perhaps a page or two) I will treat your report with confidentiality.

---

Activity: User Documentation

You must provide user documentation for your project that at a minimum demonstrates the following functionality:

- How your application starts (this may be a URL, icon that is double-clicked, etc.)

- How the teacher and student gain access (i.e. log in.)

- How a student plays a game.

- How a student measures progress.

- How a teacher measures students progress.

You do not have to generate pages and pages of documentation, but rather enough to give a user of your software an idea how to access and run it. Screenshots provide an excellent visual depiction of your project, and I encourage you to use many of them.

Deliverable: User Documentation

Provide your documentation in either HTML or a PDF form. Your documentation may be provided online, or you may provide a version of it to me. Submit your documentation via Google Docs.

---