The
goal of this project is to go through all aspects of the software
development life cycle in a small team. This will give you real
experience in each stage from problem formation, requirements gathering
and analysis, design, implementation (somewhat) and testing. You will
use UML diagrams, text descriptions, and scheduling tools to create
your deliverables.
In
this project you will create a small educational game. The game can
teach anything you want, but it must teach something. You are the
software team creating the game. You should
assume other teams exist in your company (marketing sales, tech
support, etc...). These other teams will be stakeholders
(people
who have an interest in what
you're doing). NOTE: These are virtual people, you have to think for
them in this project, or you can ask the professor or TA to answer
questions to these people.
Your project should have the following characteristics:
- It must teach something
-
Multiple screens (about 3-7 screens) - A screen can be a setup screen,
high score list, game levels, etc... It may be logical to have some
screens displayed together (status and game play)
-
Data storage and retrieval
Be creative, but keep it
manageable
You are encouraged to come up with your own game, however if you cannot
think of anything some sample ideas are:
- Math attack - equations are falling and you must type in
the answer to "shoot" the equation before it hits the base
- Memory - Shows multiple boxes that users click on to reveal
pictures. Revealing the same picture scores a point.
- Spelling
- A games where you must drag letters together to spell the name of a
"picture" shown on the screen ("dog", "elephant", etc...)
- Physics - setup multiple types of blocks (rubber, curved)
to get a ball from one place on the screen to the next
- Software Engineering - show a class diagram and click on
the methods needed to perform a user story :-)
- Many many more are possible... watch Sesame Street for more
ideas
Goal:
During this stage you will form into groups of 4-5 students. You may
choose your own teams, however they may be adjusted if necessary to
have equal numbers of students in all teams. If you cannot find a team,
please see me and you will be assigned to a team.
One
challenge of software engineering (and life in general) is making
decisions based on limited information. You need to choose a team, but
you do not have enough information about the other students in the
class to do this well, but you need to do it. To maximize your
decision-making ability you will fill out the following form, and then
have 20 mins in class to discuss the form and anything else with fellow
students to come up with the best team you can.
Team Interview Sheet
Deliverable:
A short written document including:
- Your
team (company) name
- Your team member's
names
- A project
idea for the software you would like to design. Including:
- What is it teaching?
- What age group will use it?
- A short (1-2 sentence) description of the screens (as
much as you know now)
- Any simplifying assumptions (You can make
more later during the design phase if required.)
- The
team interview sheets from each team member
- 3-Week Plan
This
should be in a notebook or folder you will use for the entire semester.
It should be at least 1.5" with a divider of some sort for each
deliverable below (Team Formation, Design, Test cases, etc...). You
will turn this in with new pages added for every deliverable during the
project.
For this
deliverable you will create user stories. If we have a customer, you
should try to do this with them. If we have no customers, your team
will need to take the role of customer. NOTE: User stories are supposed
to be written by the customers, but this isn't always practical in
class. Your user stories should each describe something functional in
your system of
value to your stakeholders (customers, testers, marketing team, etc...).
The customers should also add a
priority
to the story, "high", "medium", "low". Something that must be in the
project would be "high", something that is nice to have, but the
project will work without it is "low". Something that is in between is
"medium".
The development team must then add a
time estimate to the
story in "ideal development time". If your story time is greater than 2
weeks, you must break it down into multiple stories.
Lastly, your user story should have a
source with a role.
My source:
Source: John Smith, Customer
Source: John Smith, Marketing
Source: John Smith, End-user
Source: John Smith, Subject matter expert,
etc...
For this deliverable you will create a project risk list. This list
should be in a table format (possibly a spreadsheet?) and have
the following columns:
Ranking this
week: 1, 2, 3... etc... based on exposure. Essentially you should rank
your risks from the onces that most concern you #1 to the ones that are
less of a concern. To do this, sort by exposure. The rankings will
change over time as you add more risks, probabilities go down, etc...
Description:
Short description identifying what the risk is e.g. "Implementation may
be to advanced for someone on the project". We don't know JGame, and
thus cannot do implementation"
Probability
of occurrence: 30%
Impact if
occurs: High=10, Medium=5, Low=1
Exposure:
Probability*Impact
Risk management:
-
Mitigation
Plan: How
can I lessen the probability of occurrence?
- Risk
Action Plan: What
action will I take if the risk occurs?
Note about the description: If the risk description is true, then you
don't have a risk anymore, it has occurred and you need to deal with it.
"No one knows JGame" is not a risk, it is true or not. If it's true,
you must deal with it. A risk is something unknown, when the risk
occurs it is a situation you must deal with.
You will update this throughout the semester. If a risk occurs, mark
it's probability as 100% but keep it at the end of the list. You can
remove its ranking because it's no longer a risk. Similarly,
if a risk can no longer occur, mark it's probability as 0% and move it
to the end of the list and remove it's ranking.
Example
| Rank | Description | Probability | Impact | Exposure | Mitigation | Action Plan |
| 1 | Implementation may be to advanced for John who has never programmed in Java. | 80% | 5 | 4 | Have Mary work with John before coding to teach him what he needs to know. | Assign John's coding tasks to Mary and assign Mary's writing to John. |
Notice:
The mitigation is what to do before the risk occurs to hopefully reduce
the chance that the risk will occur. The action is what to do AFTER you
have determined the risk occurred.
Grading Rubric
Goal:
To create a schedule for the next deliverable. In the schedule you
should have which user stories are going to be completed and who will
be doing them.
See description of the
software schedule.
This will be a high level object design of your project.
You will turn in:
- CRC cards for your project
- A UML class diagram at the analysis
level
- A state diagram documenting the
different game states you will have
Grading Rubric
In this deliverable you will produce a UI mockup of your game. This can
be in any form that works for you (actual software prototype,
PowerPoint, hand drawn screens, etc...). The goal of the UI prototype
is to communicate the basic functionality of the system at this stage.
In future projects you may have a basic UI prototype to show the basic
functionality and rough screen layouts and later a detailed
prototype to show the actual look and feel of the project. For this
class you need to create at least the basic prototype.
For
the prototype make sure to cover the whole system. If you have multiple
user interfaces (Administrator and normal user) for example, show both.
Also, if there are different screens a user will use, show all of them.
Grading Rubric
Goal:
To produce and run a set of test cases for your project. These test
cases will
be for a subset of your project, not the whole thing.
You
will need to turn in:
- Unit test
descriptions for 2 classes (these should be 2 of your main
classes that do significant work, not your simplest
classes!)
- System test descriptions for 5 user stories
- Alternative
to unit test descriptions: If you have working code, you may turn in
JUnit tests instead of the Unit test descriptions above. However you
still must do the system tests!
Unit Tests
- Describe
the inputs and outputs
- Ensure you cover both valid
and invalid inputs in a variety of forms
- See the detailed
description
of the Unit Test including the format.
- Unit tests must cover all methods in the class
System Tests
- Describe
which user story is being validated.
- The test case should follow the Sample
System Test
Case.
Note: Because we are using more agile techniques and do not have
traditional detailed requirements, use User Stories in place of
requirements for the test case. Generally this means one test
case
will cover one or part of one user story.
Helpful
Hints:
- If a test step says "the user
presses button x or button y" -- make two test cases, one for button x
and one for button y.
- If
a test result says "if the password was valid, the user goes forward,
otherwise they get sent to the login screen" -- make two tests, one for
a valid login and one for an invalid login
- Test
cases should be repeatable and clearly test one scenario
Grading Rubric
Goal:
To describe your experience working in a team environment. Including
lessons learned, how you would work differently in the future and your
description of each team member's contribution. For more information,
see this
more detailed
version of the project team review assignment.
NOTE: Each student must
submit
this individually!
Each
group will present their project for 10-20 minutes. The
presentation
should include:
- Project overview - what
software you're developing and how it is used
- Explain
your user stories
- Explain
your software designs
- Describe your risks and what happened as the class
progressed
- Describe your team's lessons learned and
how you would pursue a team software development task in the future
- Demo your software at whatever stage it is in
Take as much as you can from your previous deliverables to make these
slides. The
presentation slides for 2-4 can be taken directly form your previous
deliverables. 1 and 5 are just bullet point summaries of other
deliverables.
I will use
this
form to
grade the presentations. It provides more information about the
required presentation content.
Each
group will submit their final version of their software on the last day
of class with the final version of all their documents. The software
should conform as much as possible to the design. Included in the final
submission should be an overall status of the software. How far did you
get (which user stories are completed and which are not)? I don't
expect a finished product. The goal of this project is to understand
the process and "live it". your software should work and run, but does
not need to be feature-complete.
The
project is a significant portion of your overall grade in the class.
Each student is expected to participate equally in the project. Your
grade for each deliverable will be partly a team grade and partly a
grade on your individual contribution. If you are having
problems
with
people not participating equally on the team see me EARLY. Do not wait
till the end of the semester, at that point there is little I can do.
You
will have the opportunity during the class to revise and resubmit most
deliverables to achieve a better score if desired.
The total project grade will be the average of all pieces of the
project.