Evaluate the domain you selected, complexity of the problem, methods used, UML itself, Rose or Visio, team work, things to do more if you have more time, and things to do differently if you redo the project, etc
Proposal (Milestone1)
Your Milestone1 should be 3-5 pages in length. Study the sample proposal distributed. Your proposal must have the following components:
Identification
a. Title (short, but meaningful)
b. Project category (A&D, Life cycle, Research/Survey, Tool)
c. Name (List all team members)
d. Term and date
- The problem statement
1.1 Goals of the system
1.2 Context and importance of the system
1.3 Scope of the system
1.3.1 In-scope (Scope to be included)
1.3.2 Out-scope (Scope that will not be included)
- Requirements
2.1 Functional Requirements of the system
2.2 Data Requirements of the system
2.3 Business Rules and Logic
2.4 Non-Functional Requirements such as usability, reliability, interface, performance, security, etc.
2.5 Other important assumptions
- Examples of system input/output scenarios.
-
Knowledge Acquisition
· How you will learn about the problem?
· Is this a real problem, or one you have conjured up?
- Software and/or hardware involved in developing specifications or implementation (if you are working on Life Cycle projects)
-
Proposed Deliverables and the work plan
-
Known References
Examples of system input/output scenarios in VRS (Video Rental System):
· Example Input scenarios:
· A customer rents 2 DVDs and 1 Video tape
· A customer returns items, but one of them is overdue
· A customer pays by a credit card
· A customer pays with a gift certificate
· A customer wants to cancel a rent after completing the transaction
· A customer calls the store to reserve a DVD
· A staff adds a new DVD title
· A staff adds new DVDs of pre-added title
· Example Output scenarios:
· At the end of each day, the system prints a summary of all the transactions by item types and payment types
· System alters all rents which are over-due by more than 10 days or $20.
The following shows the typical contents of the final format of the A&D project report. Except those items marked as Optional, all other items are mandatory. Those in blue colors are mandatory and those in red are optional.
Example of A&D Project Documentation
Title page (title of your topic, all the member names, term identification) Contents (section and page number)
Introduction (1 page summary of the whole project)
System Analysis
(1) The Problem Statement
1.1 Goal,
1.2 Context and Importance,
1.3 Scope
1.3.1 In-scope
1.3.2 Out-Scope
(2) Requirements
2.1 Functional Requirements
2.2 Data Requirements
2.3 Business Rules and Logic
2.4 Non-Functional Requirements such as interface, performance, reliability, etc.
2.5 Other Important Assumptions
(3) Use Case Model
3.1 Actors and Their Goals
3.2 Use case diagram
3.3 Overview section of all use cases
3.4 Use case description in template (one primary use case per team member. Put each member name for each use case description)
3.5 Activity diagrams of the chosen primary use case (optional)
3.6 Validation & Discussion (modeling decisions, alternative solutions to the model and other important clarification)
(4) Class Model
4.1 Class diagram with classes and major attributes (Called Analysis class diagram or domain model)
4.2 Selected Class definitions for those whose class names are not intuitive
4.3 Selected Association definitions for those whose association names are not intuitive
4.4 Validation & Discussion (modeling decisions, scenarios used, alternative solutions to the model and other important clarification)
System Design
(5) A system sequence diagram of the chosen use case (Each member should have his/her own system sequence diagram for the chosen use case.)
(6) The sequence diagrams that expand the system sequence diagram. (Each member should have his/her own full sequence diagram(s) for the chosen use case.)
(7) A state diagram (optional)
(8) Design Class diagram with all the attributes and operations ( Rem em b er t h at V isio d oes n o t sav e b o t h an aly sis class d iagram an d d esign
class d iagram sep arately . Hen ce, y ou h av e t o sav e t h em in t o tw o d if f eren t f ile s .)
(9) Class diagrams with packages and dependencies (optional)
(10) Validation & Discussion
Physical Design
(11) Component diagrams (optional)
(12) Deployment diagrams (optional)
(13) ERD (optional)
(14) Relational Database Schema
(15) Discussion between differences between ERD and analysis class diagram (Optional)
(16) Data Dictionary (optional)
(17) Validation & Discussion
Applications Design
· Screen flow diagrams and Dialog flow diagram (optional)
· Screen prototypes (optional)
· Report prototypes (optional)
· Discussion
· Sample C++ or Java Class Specification (in logical form, optional)
(16) Evaluation of Analysis & Design (evaluation of the project, domain, diagrams, the UML and the modeling tools used, quality of the specification)
(17) Summary and Lessons learned
(18) References
(19) Appendix
A. Division of the work among team members
B. Experience (Individual member must write separately lessons learned )
C. Unsolved problems (Any questions related to A&D activities you still have)
Validation and Discussion should include:
· Explanation of the model so that readers can understand the model better rather than just a diagram
· Comparing multiple alternatives of the model and the justification of your chosen model
· Summarizing any remaining problems or issues regarding to the model
Evaluation of Analysis & Design should include
Evaluate the domain you selected, complexity of the problem, methods used, UML itself, Rose or Visio, team work, things to do more if you have more time, and things to do differently if you redo the project, etc
Incremental Documentation
A final comment: the best method for documentation is incremental documentation.
DO NOT WAIT UNTIL YOU COMPLETE YOUR SYSTEM. It is very easy to
forget the fresh idea you had by the time you finish your project. Write whenever you have some material that you need to include in your final report.
Grading Guidelines:
· Problem Statement, use case diagram, class diagram, design class diagrams, and relational schema are graded together for all the members . That is, all the members will
8
get the same grade for these components. Hence, all the members must collaborate to develop them.
· Use case description, system SQD, and full SQD are graded individually . That is, each member will get a different grade for these components as each member is responsible for his or her own use case description system SQD, and full SQD. Members of a team can help develop/review those model components of other team members, but each member is responsible for his/her own component for them. Note that SSQD and SQD must be based on the use case description chosen by each member.
· For other project types, you should submit a progress report when A&D projects submit use case diagrams and class diagrams for review.
Project Deliverable and Submission
All the projects must submit a soft copy:
(1) Create a report by consolidating all the materials into a single Word file including the final report, diagrams, programs, output, etc as outlined above. That is, copy and paste all the diagrams of all the members into the final report (Milestone 4). Organize them in a reviewer-friendly manner. Add page numbers.
(2) Create one zip file that includes the report file in Word, all the diagram (e.g., visio) files, or any other related files (e.g, codes, screen shots, output) used in the project.
(3) Use the naming convention of 355-18W-P-yourLastName_or_team_name- acronym-of-your-project.zip (e.g., 355-18W-PCCS.zip). That is, by reading your zip file name, I should be able to easily identify your term and project topic.
(4) Submit project and peer evaluation form to Blackboard Assignment folder of Week
- Use the naming convention of 355_18W_PEF_yourLastName_and_team_name-acronym-of-your-project.zip (e.g., 355_18W_PEF_Name_PCCS.doc)