Software Development Project
Spring Semester, 2011
DUE Thursday, February 17, 2011 at 11:30am

Phase 2 - Requirements Development, Architecture, Design, and Implementation Plan

In this phase, your team will develop and present the details of your project's functional and nonfunctional requirements, its overall architecture, design, and implementation plan.
The biggest mistake that most teams make during the phase is submitting an inconsistent phase report –use cases that do not match the class/E-R diagram, which do not match the storyboards or site map. Success in this phase results from careful planning, completing work well ahead of the due date, and careful review of all deliverables by all team members.

The project report must contain the following sections. Weights for credit are shown in parentheses. Your work must be complete, correct, convincing and in conformance with the instructions and guidelines given in the Phase Report Format and Professionalism section of the class syllabus. 

1. Executive summary (described in class syllabus)

2. Use Cases (10%)
Complete and correct your use case diagrams and narratives from Phase 1. Fill in all missing details and indicate all preconditions, postconditions and triggers for each use case. Indicate any substantive or consequential deviations, modifications, or omissions from the set of use cases you presented in Phase 1.

3. Test Cases (5%)
Provide an initial set of test cases for the system. There must be a minimum of one test case per use case and many use cases will require multiple test cases. Test cases are required to cover the most likely conditions as well as boundary conditions, extreme use, and potential abuse of the system. Test cases should use a similar template to the test cases in 67-272; that is, for each case there must be a test purpose or intent, test data and expected results, plus an area to later write in the date the test case was run (and returned the specified results) and name of the team member conducting the test.

4. Nonfunctional Requirements (5%)
List and discuss any realistic nonfunctional requirements (security, performance, accessibility, ease of use, ease of learning, maintainability, etc.) and any realistic system operational constraints (operating system, database engine, hardware, software components) your system must satisfy. Indicate how you can verify that the non-functional requirements have been met. Discuss any maintenance and your system would need after initial deployment.

5. Information Architecture and Site Layout (25%)
a. Provide a storyboard, prototype, or screen shots that will clearly demonstrate the look and feel of your system's main levels of functionality. Your documentation, while not necessarily complete in every design or graphic detail, must show at least FOUR different, interesting and meaningful use cases (not to include login/logout) in full depth. Populate your storyboard, prototype, or screen shots with sufficient, realistic data so that it is convincing. (10%)

b. Create a content model or a detailed site map showing the flow of screens, web pages, etc. that a user will experience using your system. (15%)

c. Discuss and justify any design issues or design decisions that are not obvious.

6. Class Diagrams and Database Design (30%)
a. Draw a detailed class diagram or entity-relationship diagram for your system.
Show all classes, relationships, attributes, and multiplicities. Show methods if appropriate for an object-oriented implementation, but do not show them otherwise. Use UML or ERD notation. (15%)

b. Create a data model in third normal form (or higher) for the database structure you propose. Use proper notation to document your database schema and identify all primary and foreign keys. (5%)

c. Create detailed data dictionary entries for all attributes in your 3NF model. (10%)
Entries must be detailed, precise and unambiguous. Keep in mind that the concepts and attributes you are working with may have obvious meaning for you; however, for your end users, instructors, etc. they might not be so apparent. For each attribute, include the following information:
• One or two sentences clearly describing the attribute. Your description must be clear, unambiguous, precise and meaningful in the context of your system.
• The type of the attribute (character, numeric, date/time, etc.).
• Any restrictions on the attribute's values, relationships, or dependencies with other attributes.
• Default values, if any.

7. Detailed Project Implementation Plan (10%)
During the next three phases, you will complete your project in stages. List, by phase, all use cases or other functionality (database queries, stored procedures, "back-end"objects, etc.) that will be developed and delivered in each of these three phases. Normally you would implement the main GUI elements and primary use cases first, since you are expected to have a demonstrable look-and-feel prototype in place for phase 3. (Since each project is different, however, the depth of the prototype is not specified.) Look ahead to the coming phases to see what will be required as your system takes shape. Your implementation plan must be realistic, specific and achievable. For each item to be completed or implemented for Phase 3, indicate which team member(s) will be responsible for completion of that item.  Indicate when this item will be completed. Designate one or more backups for technical items. Backups will be responsible, at a minimum, for reviewing designs, code, test plans and technical documentation. Backups must be prepared to assume primary responsibility if needed.

Assigning one or two individuals to perform the bulk of the technical work throughout the term is unacceptable. As indicated in the course syllabus, all members of the team must contribute in meaningful and significant ways to the technical work during the semester. Do not enable any member of the team to avoid this obligation or to complete the term without the opportunity to further develop his or her technical competence. 

8. Project Management Section (15%)
a. Time Accounting: Summarize (graph) the weekly time commitment (expected/planned and actual) for each team member and for the team as a whole.
Break down time spent on each of the major activities; explain unusual or unexpected findings. Briefly (and realistically) describe each person's contributions to the team's work during this phase.

b. Feasibility Update: Update your analysis of the project's feasibility and estimates of its feasibility, difficulty and effort. Comment on any significant changes to your original thinking on these points. Discuss any substantial or consequential deviation from your project vision or project plan. Identify any slippage in work plans (actual vs. estimated).

c. QA Manager's Report: Discuss the relevance/usefulness of your team's process and estimate the Cost of Quality (COQ) as a percentage of effort in this phase. Simply, COQ represents the costs which are incurred due to a lack of quality and those which are incurred in the achievement of quality. (The costs of achieving quality and the costs due to lack of quality have an inverse relationship to one another: as the investment in achieving quality increases, the costs due to lack of quality decrease.)  Specifically, address all effort devoted to defect prevention, defect appraisal, and defect correction, as these are the main components of COQ.

Defect Prevention includes efforts to prevent defects from entering your work.
Defect prevention may include efforts for design/code/documentation inspections or walkthroughs, pair programming, use of programming and documentation standards, team training, collection and analysis of metrics, process improvements.
Defect Appraisal includes efforts to discover the condition, or quality of your work.
Defect appraisal may include activities such as team testing, external user testing, audit meetings, analysis of defect projections, etc.
Defect Correction includes efforts to deal with problems in your work. Defect correction may include efforts for rework and retesting of design, code or documentation.

Describe the team's methodology for ensuring quality of all work products and team processes. Indicate any deficiencies in team process or individual practice that detracts from product or process quality. Indicate how these deficiencies will be remediated.

d. Project Metrics: Summarize (graphs are helpful) and comment on the team's metrics gathered to date.

e. Risk Management: Discuss any updates needed to your project risks and risk management plan. If any early warnings have occurred, so indicate and discuss how you have, or will, deal with them.

f. Problem Status: Identify and discuss any significant problem(s) (quality, technical, organizational, team members, environmental, etc.) that your team has encountered in completing this phase of the project, or that may, in any way, affect the successful completion of your term project. Identify any potential problems you anticipate before completion of the next phase(s) of the project. Discuss the status of any problems identified in the previous phase as "open."

Last Updated 01/01/2011  [rsw]