Work as part of a team to develop an RDBMS / database centric system based on the case study below. Hand-in a final synoptic supportive report detailing the planning, development, implementation, and testing with a suitable, relevant discussion and conclusion about the system produced and include individual contribution of each team member. Also there should be evidence of an integrated systems developmental approach.
Deliver a presentation at the end explaining your system and answering questions.
You will form a group (of maximum 5 students) to plan, develop, implement and presentation an RDBMS / database-centric system incorporating evidence of an integrated systems developmental approach. Marking of this assignment will comprise of:
A. 55% of Assessment 2 for the (ie. web database) system itself and its presentation
B. 45% of Assessment 2 for the documentation of development supporting report (max. 1800 words per student)
An assessed presentation/demonstration will be scheduled and evidence of individual contribution must be included in the report.
Individual Q&A as part of presentation will be used to award individual grades.
Students are expected to spend 40 hours for preparation and 8 hours for the completion of the assessment (including artefact).
Introduction to the electronic "one-stop" services shop scenario:
Notes of Guidance:
Students will form a small group with whom they will work in a collaborative manner throughout the task (unit). These groups will be formally formed in/by Week 3. Changes to group membership cannot then be subsequently made without client (staff) approval. It is vital that you form a group comprising a mix of suitable skills since the task involves the building of a "Student Information Kiosk". The system will be implemented using Oracle database and may be developed with Oracle APEX or another front end (if agreed upon with the lecturer / ’client’). The task is a demanding one involving the implementation of the overall "Kiosk" scenario.
Note the following is only given as a brief introductory overview and is not to be regarded as a definitive description. Groups should be formed around a normative size of 5 persons.
"KIOSK" SCENARIO - A SHORT SUMMARY
A Student Information Kiosk (SIK) system is to be designed to allow students to access an electronic "one-stop" service shop. The SIK will aim to provide up-to-date information about all events taking place on campus (i.e. student nights, sources of support , clubs, guest lectures, workshops, as well as selected data that seeks to place the student within the context of the local community/services/discounted shopping/special offers/gym/sports activities). An important focus of the system is to enable students (both home and overseas) to gain access to sources of support, learn about Luton as a community. Thus, selected information sources of local services such as: student bank account providers, sports activities, cultural activities etc. should be included and searchable by students. Each student's personal details must be recorded. The system needs to be able to support several "levels" of user. Namely "Admin" user access will have full system privileges, thus enable all data sets to be updated. Each student will have access and be able to change only to their own personal details. Other access types such as "Guest" may also be needed, that do not require individual log-in but provide "generic" information to users, for example a "Kiosk" placed in a space within or near the University campus.
The prototype system will be developed for a desktop workstation but the visual design and usability style must be potentially portable for a range of target platforms (such as a touch screen Kiosk). So whilst your prototype is for a desktop PC you need to bear in mind the eventual target devices and usability contexts of the final solution.
Note an integral part
of this task is for you to work collaboratively as a team and to gather
requirements from "real" potential users of the system (i.e. students
on campus), not simply build a system that matches your own set of
requirements. Staff will also act as client and will meet formally with each
group on a regular basis during normal practical sessions so as to provide you
with additional inputs and a set of more detailed requirements. It is vital
that you formally document these and keep a detailed log of all meetings with
clients and users. It is important to capture the source of requirements throughout
the task. Naturally the set of