General Outline of the Project
So far in the semester we’ve focused on rather abstract aspects of databases such as data modeling, functional dependencies, and normalization. This project allows us to shift gears and explore more managerial aspects of databases. One of the best ways to learn something is to try to put this new knowledge into practice. Building database tables, queries, forms, and reports is relatively easy. However, developing and maintaining standards, ensuring that the database is properly documented and keeping to a firm deadline is pretty difficult (as you will discover).
The team size is ideally three or four members. Teams of two are discouraged due to the amount of work to be done and the short time period allowed. I suggest that you divide the extensive work required equitably among the team members while at the same time relying on the special strengths of each team member to allow the project to be completed within the strict time limits. Please note that this project requires extensive use of computers and that the computer lab becomes increasingly crowded as the semester progresses.
The deliverables have been broken up into a project proposal and three main sections:
Project Proposal (Due February 18)
- Conceptual Design (Due March 11)
- Physical Design (Due April 8)
- Final Project (Due May 1)
Each team should submit one copy of deliverable through the Assignment link on Blackboard. Handwritten material will not be accepted. Remember, professionalism and appearance rarely cover mistakes; however, they do make mistakes seem more tolerable. In addition, a peer evaluation sheet will be completed by each person at the time each deliverable is due. This evaluation will cover your team members’ contribution on the previous phase of the project and have a DIRECT bearing on your individual scores for the final project. I will use all three evaluations from your three milestones to determine your overall contribution to the project.
The grade distribution for the project will be approximately:
Deliverable 1 – Conceptual Design 25%
Deliverable 2 – Physical Design 25%
Deliverable 3 – Final Project & Presentation 50%
General Guidelines for Database Curriculum Integration
While it may be possible or even desirable in some cases to propose and design a system with more limited database requirements, it is important in this case to be sure that your proposed system effectively applies and hones the knowledge you gain through your participation in this course. Therefore, all projects should comply with the following guidelines. Exceptions will be considered on a case-by-case basis, but any deviation from the standard will require significant effort redirected and applied within the project to another key learning objective of the course.
- The data model should contain at least 10 tables, and should be normalized to 3NF. Any deviation from 3NF must be justified to and approved by the instructor.
- Physical table definitions should include a range of data types, including but not limited to: integer, decimal, string (varchar), and date
- Databases will be implemented on the MS SQL Server 2012 or Teradata platform.
- The user interface should contain at least:
- 2-3 screens for “data management” (inserting/maintaining/reviewing records)
- 2-3 screens for reports & decision support
- Databases should be loaded with at least 1000 records (data loading/conversion – manual entry is highly discouraged).
- Queries should include basic insert, update, select, and (optionally) delete commands; at least 3 “complex” queries are required which access 2 or more tables.
The First Deliverable: Conceptual Design & Non-Functional Prototype
For the first deliverable, you need to submit your analysis and the conceptual design of your database. This roughly maps to the Planning and Analysis portions of the SDLC that you experienced in ISYS 3293. Your report should include the following sections:
A short, written overview of the project proposed. This is a managerial statement that should not be more than a half a page long (12 pt font, doubled space). The summary should address the business problem or opportunity identified, an overview of the project, and how the project addresses the problem or opportunity.
Statement of Scope
Write a statement explaining the scope of the proposed project. This statement should include:
- Systems Request Form (complete the form provided)
- General project information: List the project name, sponsor, project team
- Problem/opportunity statement: Identify and briefly explain potential problems/opportunities
- Project objectives: List the objectives the client hopes to achieve with this system (Remember objectives must be measurable)
- Project description: Write a brief description of the project; include the purpose of the project
- Identification of users: Who is directly and indirectly affected by this project?
- Benefits: What are the tangible and intangible benefits?
- Constraints: What are possible constraints or limitations imposed on this project?
- Duration & Estimates: How long will the project take? Spend a little bit of time, research a methodology for estimating the project effort, and provide a realistic estimate.
- Costs: How much will the project cost? What are the tangible and intangible costs?
- Feasibility & Risk Assessment: consider different aspects of the project – is the project feasible given the constraints, estimates, and costs provided above?
- Scope Proposal: based on the information collected and documented above, provide a managerial summary specifying what features are in scope, and what features are out of scope.
Provide a GANTT chart which encompasses all of the activities/tasks of Milestones 1, 2 & 3. Identify which team member or the whole team performed the activities/tasks. I realize that these tasks and resource assignments are subject to change but at least you will start out with a plan. The GANTT chart and work plan should be included in the Appendix. Note: the dates should correspond to project milestone due dates.
Your database will support one or more business processes. Who are the users? What do they see (these end up being your attributes)? What sort of stuff will your database be used to keep track of? What do they do with what they see (these end up being your processes)?
This represents the primary output of your requirements gathering activities. A clearly specified set of requirements makes developing the database much easier. For this project you will need to make inferences (assumptions) from the information provided and document those inferences/assumptions clearly. I suggest that you start working on this section right away!
- For your sources of facts, use:
- existing paperwork, documents, or web sites;
- Produce a narrative of the facts gathered.
- This document should explain, in paragraph format, the study of the current system (i.e., the narrative describes the findings from the facts gathered). What does the current system do? How does the current system operate? What activities must be done? Who does the different activities? When and where are the activities done?
- This narrative should be DETAILED! All information that is relevant to the development of the to-be system needs to be included. Exactly how is each step currently accomplished and how will it change in the to-be system? What are the processes and how are they accomplished, step-by-step?
- These are the specific requirements for your database as outlined by the client. You and the client should discuss these requirements at length and come to an agreement of what your system has to do. How will your database structure support the user requirements?
Entity Relationship (ER) Diagram
Provide an ER diagram that shows your database’s entities and relationships. You should use the Visio Database Model diagram template to draw your model.
In addition to the graphical representation, walk me through the database. Tell me, in text, what your diagram is telling me. Don’t give me a verbatim translation (“each customer has many orders; each order is for one customer”). Explain this as you would to an intelligent, but not database-literate, client. The ER diagram and explanation are the formalization of the requirements in the previous section. Being able to describe this to a client lets them know that you understand what they need.
UML Diagrams for the Proposed System:
- Include high-level Use Case diagrams for your project as you see it now. The Use Case diagrams for this phase should be at the “white” level, as described in your Systems Analysis & Design course.
- Complete a use case template for each activity.
- Include additional high-level UML diagrams as appropriate to convey important high-level information regarding the current process and/or proposed solution.
Data Dictionary (Preliminary)
You need to document your entities and any attributes that you have identified so far. This is done in the data dictionary. The complete data dictionary will be more extensive, but this will be a good start at documenting your database.
The data dictionary at this point should include all attributes and should have the fields in the example below, at a minimum:
|Attribute Name||Used In||Description|
|DepartmentID||Department, Employee||Unique integer identifier for a department|
|DepartmentName||Department||Text description of a department|
A series of screenshots with walkthroughs and/or a Visual Studio project containing a pseudo-functional (navigable) copy of the application. It does not have to connect to a database and actually “do” anything yet, but should provide a good initial glance at how the system will work.