15 - Initial Project Plan / SRS / SDS

This initial deliverable for the project will be evaluated by assigning 0 to 1 point to each of the following fifteen bullets based on how well each was completed.

Project Plan

• A management plan. How is your team organized? How is the work divided among team members? How does your team make decisions? How will your team meet and how will it communicate.
• Work breakdown schedule (with > 10 milestones) and project schedule (who will do what).
• Monitoring and reporting: How individual and project progress will be monitored to keep track of who did what and when did they do it?
• A build plan. What is the sequence of steps you will take to build the system? When will each "build" of the system take place
• A rationale for the build plan. Why have you broken the system into these parts, and why have you chosen these particular steps to build the system? What are your risks and your risk reduction strategies?
  

SRS

• Problem statement - Clear and concisely, what is the problem to be solved? The problem, including the task requirements, should be described independently of the solution, the piece of software you will build.
• Description of User - Who are the users? What will they expect? What will they know already? What are their current technology usage patterns?
• Scenarios or Use Cases - Three specific, different, realistic scenarios.
• Detailed Description of Requirements - Expand the problem statement and generalize from the use cases. Include at least 20 specific and measurable requirements. At least 6 should be non-functional requirements.
• Both functional and non-functional requirements should be split between absolutely required and not absolutely required requirements. A reasonable number of absolutely required requirements are identified, well-specified but attainable.

SDS

• A description of the product you intend to build. This should describe the externally visible behavior of your product as precisely as possible, but it should be concise and clear.
• An overall design description. What are the major parts of your system, and how do they fit together?
• System structure is clear.
• Each major subsystem should be explained using a separate static model and dynamic model. All diagrams must be clear and understandable.
• Design Rationale. Why did you chose this particular design? What are the main organizing principles that you used to break your system into parts?

Good Writing

Throughout all sections: Good Writing (From Syllabus) Structure the paper so that the main ideas are clearly accessible. Communicate individual ideas effectively. All spelling and grammar must be standard and correct.

50 - Functionality

Robustness: 15 points

15 = absolutely bulletproof piece of software

13 = robust under reasonable use

11 = minor bugs, works well enough to be usable

7 = major bugs interfere with normal use

0 = doesn't run

Feature Set: 15 pts

15 = WOW! Exceptional.

13 = All needed features and some pleasant surprises

10 = Adequate for the intended purpose

7 = Missing features interfere with normal use

Ease of setup: 10 pts

10 = a snap to install - on a par with highly automated installers

9 = easy to install

8 = a little cumbersome, but installed without major problems

6 = major difficulties installing

0 = couldn't install

Ease of use: 10 pts

10 = couldn't ask for more

9 = Quite usable, but could be improved

8 = Adequate usability, won't discourage normal use

5 = Usability problems interfere with normal use

0 = Completely unusable

20 - Final Project Plan, SRS, and SDS

Final Project Plan - 5 pts

5 = All problems identified in the initial Project Plan have been fixed. Report clearly indicates who did what, when they did it. There is a record of when meetings were held, who attended, the agenda, and what was accomplished and agreed upon at each meeting. A series of updated project plans continues to show all of the major project milestones and deliverables.

3 = A plan was in place and followed. Tasks and roles were assigned, but it is not clear who did what, when they did it, and how long everyone spent on each task (from assigned date to completed date, as well as time on task).

0 = No final updated report of the project management is provided.

Final SRS and SDS - 15 pts

This document should include an updated SRS and SDS, as well as additional detailed technical documentation that would be required to fully understand, modify, and extend the system.

15 = All problems identified in the initial SRS and SDS have been fixed. Exceptionally complete and useful design documentation; with a small amount of study I could easily port, extend, or modify the system. The system is organized in a way that makes it exceptionally easy to extend or modify, and each part of the system is specified precisely enough that it could be modified or replaced without studying other parts of the system. Anticipated changes (e.g., features or generalizations that did not make it into this version) are documented. The SRS has been updated to reflect how the requirements have evolved, and the SDS has been updated to reflect the updated SRS. The SDS matches what was actually built and turned in. All source code is well-commented.

13 = Good design documentation, adequate for maintaining and extending the system. Most changes that might be anticipated would be easy, and the documentation of each part of the system is adequate. Some changes may not be quite as localized as one would like, but non-localized changes are reasonably simple, and the documentation is adequate to determine what must be changed. Documentation includes some anticipated changes for future versions of the system.

11 = Adequate design documentation, with some things that could be improved. Some changes may be more difficult to make than they should be.

8 = Some major problems in design documentation, or some things that should be localized or easily configurable are inappropriately hard-wired in the application.

0 = Technical documentation is inadequate, to the point that the only practical way to determine how to make a change is to read the source code.

15 - Documentation

README.txt: 5 pts

This should be a text file, submitted with the source code, explaining what are the files being submitted, who are the authors, the class name and assignment, and what needs to be done to both compile the source code and run the program. The file should still work a year from now, in case a future 422/522 instructor is given a directory containing these files. The file should list the version of the compiler and any other software that was used, and any additional setup that may be required.

5 = complete overview with overview description and complete manifest including guide to other documents

4 = very good README

3 = adequate README, but either some inappropriate choices of what to put in or leave out

minor organizational problems that make it less useful than it would otherwise be

2 = README exists, but has flaws that limit its usefulness

0 = README doesn't exist or is useless

Documentation - installation, tutorial, reference: 10 pts

This should include everything a user needs to install and use the system.

10 = really professional standards, on a par with the best commercial software

9 = Good solid documentation for both tutorial and reference use; not quite professional standards, but very good for a short project

8 = adequate user documents for both tutorial and reference use

6 = not very useful, due to flaws, omissions, or poor organization

4 = barely useful at all

0 = no user documentation, or useless documentation