Project Activities and
Deliverables
Activity: Team
FormationTeams 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:
- Team Roles
The team coordinator is to email
the instructor the a list that identifies which person will be acting
in which role(s).
- Team Name
The team coordinator is to include
the name of the team in the email that lists the team roles.
- 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: Release 1
A release is a stable version of all
the code, together with a set of documents (requirements, design) that
are consistent with the code. Once a release is ready, don’t continue
making changes to it – last-minute “improvements” are a major cause of
demo failures.
Contents
of
Release
1:
-
All
code
checked
in and merged with the master branch.
-
Updated
design
documents
consistent with the code.
-
Test
report
(using
the same
template as from the Acceptance
Tests.)
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.
Deliverable:
Release
1
Presentation
You
will
give
a
15-20 minute presentation demonstrating the features of
Release 1. This can be a product demonstration, or screen shots.
-
All
team
members
must participate in the presentation, not one
“speaker”. Each member must describe what portion of the project they
worked on.
-
Recap
the
product
concept briefly.
-
The
major
focus
is on the design and product concept. Show the
conceptual design, and describe briefly how you tested it (acceptance
tests.)
-
Give
a
short
demo of the product. (If possible)- This will be evaluated using
this rubric
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:
-
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).
- 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)
- 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.