Project Description
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, and testing. Unfortunately due to time constraints you will not be implementing the actual software. Meaning you will not write any software for this project.  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. :-)

You are encouraged to choose your own project however it needs to have the following characteristics:
- Multiple screens (about 3-7 screens)
- Data storage and retrieval in a database
- Multiple types of users (basic and power user, data entry and managers, etc...) that have different privileges

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. 

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

Team Formation (approx 1 page)
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.

Deliverable: A short written document (email is fine) including:

• Your team (company) name 
• Your team members name's and preferred email addresses
• Two project ideas for the software you would like to design in order of preference. I expect this short description to be about 4-5 sentences per project. Include any simplifying assumptions you know at the time. (You can make more later during the design phase if required.)

Project Statement (2-4 pages)
Your next deliverable is a detailed project statement. This should describe in more detail what the software is and what it will do. Do not make assumptions about what people already know. For example, don't say "this is an email system like Outlook". The objective of this document is to get upper-management buy-in that this project will be good for your company.

The project statement should include:

• A detailed description of the software
• A conceptual mock-up of a possible user-interface (this doesn't need to be complete, just an overall feel for how the user may interact with your system)
• Who will use it (number of users, types of users, etc...)
• What other systems or applications it will interact with (databases, other software programs, etc...)
• Who you believe the stakeholders are
• Why you feel this software will be profitable for your company
• An initial high level schedule (include the time required for requirements, design, implementation, testing and deployment, including an estimate of the number of software developers you'll want on the team).

Software requirements specification (7-10 pages)
The software requirements specification will add more formality to your project statement. 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. A sample SRS template. Grading Rubric

The requirements spec should include:

• Use cases
• Include the main use cases for your software
• 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
• Requirements Validation Plan - If you had real people to talk to, how would you validate your requirements?
• Who would you talk to? What questions would you ask them?
• What elicitation methods would you use?

NOTES:
- Revision history should have names and what they did, not just the Team Name
- Table of Contents should be correct
-
Software High Level Design Specification (SRS with more information)
Goal: To complete the high level design of the software. The high level specification is used to bridge from requirements to the implementation design. For this class we will update the Software Requirements Specification with more diagrams to create the high level design spec.

The software design specification should include everything from the SRS and:

• All use cases for the system including the use case diagram (may be more than one) and accompanying use case descriptions (see template)
• Class diagrams showing all the modules needed to satisfy the requirements
• Interaction diagrams to describe flow of events through at least three use case. Including:
• At least one activity diagram (with swimlanes)
• At least two sequence diagrams 
• Then one state diagram or data flow diagram for your system.

- Class names should be nouns
- States in a state diagram should be verbs (you're doing something in the state)

Implementation Schedule (1-2 pages)
Goal: To create a schedule for the design phase through the end of the proj

See description of the software schedule.

Metrics
Goal: To produce a set of metrics you will track as the project moves throughout the different stages of the lifecycle. These metrics will include both process metrics (chapter 22) and technical metrics (chapter 15). In addition the reason behind the metrics you've chosen to collect should be stated and a plan to take action based on the metrics.

System/Integration Test Cases
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:
- Unit test descriptions for 3 classes (these should be 3 of your main classes that do significant work, not  your three simplest classes!)
- System test descriptions for 5 use cases
- System test description for 2 non-functional requirement

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.

System Tests
- Describe which requirements are being validated which Use Case is being tested.
- The test case should follow the Sample System Test Case.
- Make sure to enter the requirements validated by each test or a single step as appropriate.
- Make sure to add in the alternate flows


Project Team Review (3-5 pages)
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!

Presentation (7-12 slides)
Each group will present their project for 10 minutes. The presentation should include:

1. Project overview - what software you're developing and how it is used
2. Explain your requirements diagrams (use-cases) and validation plan
3. Explain your software designs
4. Describe your implementation schedule
5. Describe your team's lessons learned and how you would pursue a team software development task in the future

The presentation slides for 2-4 should 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.

Grading
The project is a significant portion of your overall grade in the class. Each student is expected to participate equally in the project. The final grade on the project will be an average of the grades on all project deliverables, the presentation, and your individual contribution to the project overall. 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.