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:
Unique integer identifier for a 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.
The Second Deliverable: Physical Design
In this second deliverable, you will submit the logical design of your database. This is one step closer to your implementation. Here you finalize your attributes and make decisions such as what type of attributes you will have, how big they will be, what their domain is, and so on. Your report should include the following sections:
Restate briefly what your project is and how it will be used.
UML Diagrams for the Proposed System:
- Include lower-level Use Case diagrams for your project. The Use Case diagrams for this phase should be at the “kite” and “sea” levels, as described in your Systems Analysis & Design course.
- Enter a description for each actor and activity.
- Include additional UML diagrams as appropriate to convey important high-level information regarding the proposed solution.
Entity Relationship (ER) Diagram / Logical & Physical Data Model
Give me another copy of your ER diagram. As you continue to examine your project, you may have reconsidered some aspects of your design. Give me your current conceptual design. If your new design is significantly different from your previous design, you might want to give me both your old design and your new design, and point out what you changed and why.
Be sure that your design is in third normal form (3NF). If you feel that you must violate 3NF please document and justify this departure. Indicate the relation names, primary keys, foreign keys, and all attributes. Your logical data model should be documented using Visio, with appropriate data types selected for each field.
You should have your tables created with sample data in each one. Include the CREATE statements.
Include the SQL statements (along with a sample of output or expected output, where appropriate) that will be used by the application to create, read, update, and insert data. This is a significant undertaking, and while the actual SQL used may change as you go forward, this will help give you an idea of what you’ll need to do.
Include screenshots for all of the screens needed for all of your transactions and reports. Basic processes should be functional (or least appear functional) and should display all of the items that need to be seen by each user. Include in your deliverables a soft copy of the functioning version of your prototype.
Data Dictionary (updated)
Update your data dictionary to include all of the attributes in your relational model. Add columns to indicate what kind of attribute it is, where it is used, its data type, and whether it is acting as a key. Make sure that you include physical descriptions, characteristics, values, and meanings for each attribute.
Final Deliverable: The Whole Enchilada
You have already completed most of the documentation needed for the final deliverable. What’s needed now is for you to put them together into a single document.
This should consist of a single document describing your analysis and design for your project. You should have to do little or no new writing for this part. The main thing is to clean up any problems that you had on the previous deliverables and make the entire document flow smoothly. Remember, this is to be a professional-level document. For many of you, this is your last chance to “practice” before you submit something like this to someone who is paying you. A considerable portion of your grade will be determined by the structure, “flow,” and quality of your document.
The sections to be included are:
Statement of Scope
Final Data Model and Description
Data Dictionary (Final Version)
The data dictionary should include everything that is in your implementation. You should have entries for entities, all of each entity’s attributes, all queries, all forms and all reports. This is to help me figure out what a (for example) query does without having to open it up and check out the SQL.
DBA Guide (New)
We have addressed a number of additional topics during the semester. You need to apply these topics to your database project if applicable. This section should address such things as database security (system security and physical security), database maintenance, and so on. This section does not have to be very large, maybe a few paragraphs, but you need to address these issues as they apply to your client.
In addition, you need to address the issue of database conversion. Once they implement your database, how does your client enter the data they already have?
User Manual (New)
Give me a short user manual for your implementation You should tell me which is your main screen, what kind(s) of business process(es) it supports, and give me a walkthrough of its capabilities. Hint: Multiple screen shots are very helpful here.
“What I Would Do Differently” (New)
This is an important section of your deliverable. I expect that you learned something as the semester progressed. This means that you probably see something in your project as it sits now that isn’t quite right, and you would probably have done differently if you saw it earlier. There isn’t time to go back and fix it now, but you can at least tell me what it is and what you would change if you had to do the project all over again. This section applies to both your final deliverable and to your implementation.
THE WORKING DATABASE & APPLICATION
In this project you get to create a working database application containing everything from the basic tables to navigation screens, data entry forms, reports, and queries. You must use SQL Server, Teradata, or DB2 and may use an application development software tool of your choosing (VB, C#, Java, etc…). Your requirements for the project are complex enough that they should involve at least 3 complex (2 or more tables) queries. If they are not that complex, please add the appropriate number of complex queries to get the number up to 3.
I am concerned mostly about your thought processes. I want to see if you are looking at your database correctly. If your queries are not fancy, your forms are rather basic, and your reports have only the necessary information, that’s fine as long as you get the job done. Of course, good database design will be regarded more highly than fancy programming skills for this project.
Please attach your working database project as well as all final documentation and presentations through the assignment link on Blackboard.
Need a custom written plagiarism free essay? Click here to order now.