Team Formation | Software Requirements Spec | Design | Prototype | Test Cases | Project Review | Presentation

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.

You are starting a new small software company. This is your first project. You want to create something that people will use. You are the software team. 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.

Some sample ideas are:

• New software for your phone that tells you a song title if you record part of the song with your phone
• A bank teller's application to process deposits, withdrawals, and perform reporting for management
• A supermarket checkout system
• A networked tic-tac-toe (or checkers or any card game) game for 2 or more players
• A multiuser cell-phone treasure hunt where you use object recognition and a cell picture to "find" an object. (Note: You would need to make a simplifying assumptions here that the cell phone has a command "boolean result = isPicture("cow", picture)" for example.)
• Interesting past projects other students created
  • iTravel - iPhone time machine
  • Control interface for the Death Star
  • Deforestation Simulator
  • Home power monitoring solution
  • Simulator for distaster events to train first responders

Your project must have the  following characteristics:

• Multiple screens (at least 5) - 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.
• Multiple types of users (basic and power user, data entry and managers, etc...) that have different privileges/abilities

The project can be any type of software (web-based, desktop application, game, embedded app (mobile phone, PDA, etc..)). You can also choose to do this project based on an existing software application. Be creative, but keep it manageable. It can use hardware, but you are designing SOFTWARE. You can assume hardware exists and is compatible with your software. 

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.

Project Management - 10pts

For this project we will be using xp-dev.com. This is a project management web application. There are many tools out there, but this one is somewhat inexpensive (and I'm paying for it!).

For each deliverable I expect you to create a user story for the deliverable on xp-dev, then create tasks and assign them to specific team members. Who creates the tasks and lays them out? You decide... some teams have a single person "manage" the project, others pick a manager for each deliverable. You decide what works best for your team.

You may also use the forums and the Wiki if you want to. Team communication is frequently a problem. To establish multiple points of communication I would update the Wiki with team memberrs names/phone numbers and then have everyone subscribe to the forums for the project. Then, instead of emailing directly use forum posts to ensure everyone gets the messages. These are suggestions, based on previous teams... you do not have to use the Wiki and Forums. You are required to use the user stories and tasks on xp-dev.com.

At the end of the semester I will look at your site and assign a grade based on the overall usage of the tool.

Team Formation (approx 2-4 pages) - 10pts

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
• At least one time during the week you can meet in person if needed (all team members available)
• Two project ideas for the software you would like to design in order of preference. I expect this short description to be a few paragraphs per project. In the ideas include how you meet the requirements of multiple screen, user types, database, etc...put as much detail as you know.
• Any simplifying assumptions you know at the time. (You can make more later during the design phase if required.)
• The team interview sheets from each team member - turn this in on paper during class.
• Don't forget to update the Current submission sheet!

---

You must turn in this (and all future project deliverables) on xp-dev.com as described in How To Turn Things In


Software Requirements Spec (SRS) - 30pts

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
  • System requirements
  • Performance requirements
  • Usability requirements
• Be sure to include numbering scheme to allow traceability

A sample SRS template.

For the SRS you should complete all sections except #3.

Notes on Use Cases - Lessons learned from previous classes
Notes on Requirements - Lessons learned from previous classes

Don't forget to update the Turn-In Sheet!

Grading Rubric
NOTES:
- Revision history should have names and what they did, not just the Team Name
- Table of Contents should be correct




Implementation Schedule (1-2 pages) - 10pts

NOTE: We are NOT doing the schedule during Spring 2010 -- skip it!

Goal: To create a schedule, cost estimation and critical path for remainder of the project.

See description of the software schedule.


Software Design - 25pts

This will be a high level object design of your project.
You will turn in:

• CRC cards for your project
  • Note: These can be drawn in Word/Excel, or if you use Netbeans 6.8 the SDE plugin has an option for CRC cards. (You do not need to fill in stereotypes or attributes).
• A UML class diagram at the analysis level - Ensure you include 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.

Forget to update the Turn-In Sheet... but all your work won't count for anything.

 Grading Rubric


Prototype UI  - 15pts

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...). 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.

Previous students have liked Balsmiq, however the three below it are new... maybe one is better?

- Balsamiq Mockups - Comments: popups every 5 minutes get annoying

- Mockflow - Tried it? Email me comments

- Mockingbird - Tried it? Email me comments

- Serena Prototype Composer - Windows only. Tried it? Email me comments

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

By now you should be a master of the Turn-In sheet... try editing it with your eyes closed

System/Integration Test Cases - 20pts

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.
• Sample Unit Test

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

How did you forget the Turn-In Sheet last time?

 
Project Team Review (3-5 pages) - 15 pts

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!

Finally... no turn in sheet needed (because you turn this in on Blackboard!)

Presentation (approx 10 slides) - 15pts

Each group will present their project for 10-20 minutes. The presentation should include:

1. Project overview - what software you're developing and how it is used
2. Explain your user stories/use cases
3. Explain your software designs
4. 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? What tools did you use?)
5. Show your GUI prototype
6. 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!

Don't forget the final Turn-In Sheet

Grading

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.


How to turn things in


You will use a project on xp-dev.com. Once I have your team emails I will setup a project there for you.

To turn in your work:

1. Figure out a tag name, something creative like "TurnIn1" or TurnIn2, TurnIn3, etc...
2. Update the current submission document to tell me what has changed and what the tag is (what should I be grading?). If it's not labeled, it won't be graded.
3. Apply the tag to the trunk using SVN

- I will add in files with comments and your grades for each deliverable.

Turn In Sheet
The turn in sheet 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:

Tag              Submission                  Description of changes
TurnIn1           Team Formation                 Initial version
                           

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 turn-in sheet, just add to it. For example:

See this PDF for an example of what it may look like after a few submissions.