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 technology-based solution to help one of
the
United
Nation's Millenium Development Goals. The solution does not
need to completely solve the problem. Pick one of the eight areas and
come up with a software solution that can help take a step towards the
goal.
This project could lead to a development project next semester for the
Microsoft ImagineCup 2010.
If you're interested in this we'll have to find a way to make it happen
as a project/independant study course next semester. See me as early as
possible if you are interested in this.
Your project must have the following characteristics:
- It must take a step towards solving one of the Millenium Development
Goals
-
The user interface must have multiple screens (about 3-7 screens)
- It may be logical to have some
screens displayed together (status, frames of a website, etc...
-
Data storage and retrieval of some type. There should be some
persistent storage of information.
- It can use hardware, but you are designing SOFTWARE. You can assume
hardware exists and is compatible with your software.
Be creative, but keep it
manageable
You are encouraged to come up with your own ideas, here are some
thoughts in case you need help getting started:
- Combat HIV/AIDS - Provide a collaboration tool where
medical personel can freely share information about ongoing research
ideas
- End Hunger - Create a software interface to a hardware
device that checks soil composition and makes simple recommendations to
help impoverished farmers yield more crops. iPhone?
- Maternal Health - Provide a service where current mother's
and doctors can answer health qwuestions from developing countries
- Child health - Develop a predictor for disease outbreaks in
developing countries. Note: You can predict health alerts by assuming
you have data such as levels of drugs being purchased. Charting a rise
in these can be an indicator of health epidemics beginning
- Universal Education - Provide online courses on XYZ which
pair US students with underprivleged students to provide "peer teaching"
NOTE: There are many "Websites to provide information" types of things
that would help, but you should think of a more innovative idea than
simply providing a mostly static website.
These are just some ideas... have fun with it. If you need to assume a
certain technology or skill is present -- you can do that. We aren't
implementing the software in this class, so as long as you can design
it, that's okay.
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 in a notebook including:
- Your
team (company) name
- Your team member's
names
- A description of your project idea for the
software you would like to design. Including:
- Background on the Millenium Development Goal you're
support
- How will it help the goal
- Some approximation of how much you think it will help the
goal
- A measurement that would indicate success or failure of your
system. (What can you measure before your system is in place, and then
after that will help you determine success?)
- 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
- Management
Information Sheet
You must turn in this
(and all future project deliverables) in a notebook as described in
Description of the notebook
The software requirements specification will add more formality to
your team formation. It should give people a detailed idea of the
software you're creating, however it does not need to include
implementation details/choices at this stage. For example, a
requirement can be "We shall store all user information". It does NOT
need to specify where (e.g. in a database, in files, etc...). Those are
implementation details.
The requirements spec should include:
- Use cases
- Include the main use cases for your software (follow the
use case format discussed in class)
- Functional Requirements
- Be sure to state your requirements clearly
- Be sure to include numbering scheme to allow traceability
- Non-Functional Requirements
- Be sure to include numbering scheme to allow traceability
A
sample SRS template.
For the first part of the SRS due 9/21/2009 you should complete SRS
sections: 1, 2, 4
For the second part of the SRS due 10/5/2009 you should complete
sections: 5,6,7, Appendix B (if anything there)
Notes on Use Cases
- Lessons learned from previous classes
Notes on
Requirements - Lessons learned from previous classes
Grading Rubric
Also:
Management
Information Sheet
NOTES:
- Revision history should have names and what they did, not just the
Team Name
- Table of Contents should be correct
Goal:
To create a schedule, cost estimation and critical path for remainder
of the project.
See description of the
software schedule.
Also:
Management
Information Sheet
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 - Ensure you inclue cardinalities, attributes, operations, name, generalization/specialization (where needed)
- Diagrams documenting the software. You shall include at least
three
diagrams containing at least two different types. Sequence diagrams,
state diagram, activity diagram, DFD -- whatever you feel makes sense
for your software. Put a title on your diagram so I know what it
represents "Sequence Diagram for Use Case 9: Update Vaccine Information"
- Note for DFD: If you do a DFD you must do level 0 and level 1 (that counts as one diagram... still need two more).
- Typically a State Diagram will model the whole system
- Typically an activity or swimlane diagram will model an entire use case (including alternate flows)
- Typically a sequence diagram will model one specific flow through a use case (in detail)
Make sure the class diagram is essentially consistent with the CRC
cards. Also ensure the other diagrams can be supported by the class
diagram. If the sequence diagram says "system A asks system B for an
ID". That should be possible from the class diagram.
Grading Rubric
Also:
Management
Information Sheet
In this deliverable you will produce a UI mockup of your software. This can
be in any electronic form that works for you (actual software prototype,
PowerPoint, HTML, etc...). Many students have had excellent results with
Balsamiq Mockups. 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
Also:
Management
Information Sheet
Goal:
To produce
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:
- JUnit tests for 2 classes (these should be 2 of your main
classes that do significant work, not your simplest
classes!)
- System test descriptions for 3 use cases (or user stories)
Unit Tests
- For two classes in your class diagram create code stubs. These are
just classes with all methods present, but they do not need to do
anything. "return true", or "return -1", etc... Just make sure they
accept all the correct parameters and return the correct type as
described in your class diagram.
- Write a set of JUnit test cases for the classes. Turn in these test
cases. They should run and all fail (because your code doesn't work
yet).
- Ensure you cover both valid
and invalid inputs in a variety of forms.
- Unit tests must cover all methods in the class being tested
- Turn in your unit tests, code stubs and a screen shot showing the test results when you run the tests.
Note: I strongly suggest you use an IDE for this (Netbeans or
Eclipse). In Netbeans simply right click on the package and choose
"Test for existing class" and all of the infrastructure will be
generated. You don't want to do this by hand really. If you need help
-- ask!
System Tests
- Describe
which use case or user story is being validated.
- You may need multiple test cases for a single story...
don't forget the alternate flows, boundary cases, etc...
- The test case should follow the Sample
System Test
Case.
- Because
we are not running the test cases (since we don't have working code)
the "Actual Results" column will be blank and everything in the top
section will be blank except: Purpose, Pre-requisites(maybe), Required
configuration (if there is one)
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
Also:
Management
Information Sheet
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 on Blackboard!
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, why does it help
- Explain
your user stories/use cases
- Explain
your software designs
- Describe your risks and what happened as the class
progressed (as things got busier in the semester did problems occur? How did you solve them?)
- Describe your team's lessons learned and
how you would pursue a team software development task in the future
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.
Ensure everyone in the group presents something. Break the presentation into parts so that everyone has some part to present.
I will use
this
form to
grade the presentations. It provides more information about the
required presentation content. Make sure you check that your presentation hits all the points on the form!
Also:
Management
Information Sheet
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.
You will use a single notebook for your group for the entire semester.
It should be at least 1.5". Dividers of some sort should be included
for the following sections:
- Current Submission --- Described below.
- Grades --- Leave this section empty, I will add grade sheets to it.
- Team Formation
- SRS
- Schedule
- Design
- UI
- Test Cases
- Presentation Slides
Once you add something to notebook NEVER remove it. If you revise a deliverable, put the new one in front of the old one -- BUT LEAVE BOTH IN THE NOTEBOOK!
Current Submission Section
Current
Submission is just a log of what has been turned in. It should include
a sheet of paper with dates and
submissions/revisions. For example, for the first deliverable the paper
should have:
Date
Submission
Description of changes
1/28/2009
Team
Formation
Initial version
Management
Info Sheet Jane Doe
Here is a template you can use if it helps. CurrentSubmission
XLSX,
PDF
This document should be
added to for each deliverable or revision so I know what to grade as
"new". Never delete anything from the document, just add to it. For
example:
...
3/29/2009
Test Cases
Initial version
Team Formation
Added missing interview sheet for John Doe
Management Info
Sheet Carl Johnson