ITM354 Group Presentation Grading Sheet

Total Page:16

File Type:pdf, Size:1020Kb

ITM354 Group Presentation Grading Sheet

ITM354 Group Presentation Grading sheet

Group Name:

Project Presentation Grade:

A. Group Coordination and Organization B. Time requirements and conciseness C. Delivery  Enthusiasm  Smile  Visual Aids  Creativity  Confidence  Overall professionalism: attire, attitude, setup  Presentation techniques  Eye-contact  Speech: volume, tone, pace, clarity  Poise  Innovative presentation methods  (-)Distracting filling words or habits??

D. Content Delivered:  Correctness  Organization of presentation material  Introduction  Raodmap  Transition  DB demonstration  Conclusion  Knowledge demonstrated  Self-learning efforts (extra credits) Presentation Notes

Please address the audience as key personnel from your sponsor company and consultants for that company who can judge your design. Make sure you act like professionals from a database consulting company (You all have a company name). Don't be in a “student mode" -- dress professionally, have a professional looking presentation and act/talk like a professional. You don't want to say you are "learning," "trying," etc. as a student would say. You want to do everything to impress.

In this presentation, you should highlight results from EACH design phase (see the final report specification). You should first introduce your application domain (give the business background using the top level Activity diagram), the objectives of your DBS (what problems to be solved, etc.), the design approach, the 7 RAD design steps that you took for completing the database system prototype, which your are presenting. You will focus on the 5 design phases for DB design within the overall context of DBS without getting into the detail of UI design and application programming in Phase 6. You can however, create markup web-based UI design and application programs for demonstration. You need to show your professional knowledge and concisely tell the audience what you have done (for each phase) and what the resulting schema/diagrams mean in a understandable way. You don't want to give the lengthy textbook explanation, but tell them the essence in a way that they can appreciate your professional knowledge and efforts. You then summarize what benefits the DB you designed and prototyped will give your client. You should always have a conclusion slide.

Here are some answers I gave regarding the logical and physical design (for the presentation and final report):

"The logical design issues in the proposal: what are you trying to achieve in this design phase (e.g., what a good logical design is), what are major considerations for the design and how you would approach it. In the presentation, you need to say these things too, but concentrate on the results. For instance, you de-normalize two relations to one relation in a lower NF for speeding up retrieval performance as they are read-only. Show the final design (e.g., the schema) and describe your design consideration."

"You should first mention the purpose of physical design and the major issues you considered for your system. You should focus on what is necessary for your project. For instance, there's no need to discuss clustering index if you don't use any. If you index on the primary key (in your table definition), then, you have already used the primary index and you should mention that. If you have created secondary indexes, then you should talk about what secondary indexes are and what they are for. Basically, you need to say what you have considered in this design phase and what the DBMS you select have done for you and which part of design you have done on top of the DBMS to meet the requirements. If the DBMS have sufficient performance (without your special programming), you can just said that and be sure to sound like an expert. Specifically, you could say that the DBMS you have selected allow primary index and you have created primary index for X, Y, Z tables, and you have created secondary index (if any) for R and Z for faster retrieval of certain data. If you don't have second indexes created, you can then justify that current performance of primary indexes is sufficient and does not require the creation of secondary indexes. In addition to index, you may have other hardware and software that will make the DBS performance better, such as bigger CPU, larger storage, faster disk, etc.. In addition, you can mention some of your query "optimization" here, such as your using subqueries to make SQL queries more efficient. (This can impress your client.)

Recommended publications