Web代写:INFS3605 Undergraduate Coordinator Information System



Project Aim and Learning Outcomes

The aim of this project is to provide a throwaway prototype to facilitate further discussion amongst staff regarding the future development of the undergraduate coordinator information system. This project aims to provide students with an experiential learning scenario (an agile scrum project) that has potential to impact for real-world systems. By successfully completing this group assignment, you should be able to:

  • Critically assess problem case and create a viable solution.
  • Present a group solution in a professional and timely manner.

Undergraduate Coordinator Information System

Academic advising is a form of teaching that both stimulates and supports students in their quest to identify and achieve personal, educational, and career goals. It is a systematic process based on close advisor-student relationships intended to aid students in acquiring skills and attitudes that promote their intellectual, social, and personal development. Through advising, students are taught to:

  • take ownership of their learning
  • be accountable for their choices
  • generate solutions to problems, and
  • recognize and meet expectations for success within their degree.

Academic advising is part of the responsibilities of the undergraduate (UG) coordinator for the School of Information Systems and Technology Management (ISTM) within the Business School.
The UG coordinator is appointed by the Head of School for a minimum term of two years. The main responsibility of the UG coordinator is to provide undergraduate students advice and to represent the School of ISTM on relevant Business School committees. Primarily, the UG coordinator is a first point of contact for ‘local resolution’ of student issues/complaints within the school.
A lecturer or other member of staff (e.g. admin or tutor) may refer a student to contact the UG coordinator (typically by email) to arrange a consultation. On occasion, students arrange a consultation on their own initiative. The purpose of the consultation varies on a case-by-case basis. The UG coordinator is required to make decisions on situations involving - but not limited to – matters such as:

  • course enrolment
  • career guidance including degree programs of study
  • advanced standing (also known as credit transfer)
  • approval and advice relating to international exchange
  • incidents such as issues/problems with student attendance or performance
  • in a course monitoring and managing plagiarism and other discipline related cases

During the consultation, the UG coordinator will typically review a student’s academic statement, take notes and provide recommendations or advice to the student. Meetings typically last between 15 and 30 minutes. Depending on the nature of the consultation, another member of staff or another student may be present during the consultation. It is also possible that a student does not attend a consultation appointment, in which case the UG coordinator is still required to record information about a specific incident/case.
The UG coordinator may need to keep track of their consultations with individual students over the course of the student’s degree. Some consultations have a higher priority than others and need to be closely monitored and may require follow-up appointments at a later date.
The UG coordinator requires an Information System to manage the information about consultations from January 2017 onwards. For this project, the scope is limited to the undergraduate coordinator for ISTM. Currently, it is envisioned that only the UG coordinator will have access to this system. However, this scope may change in the future.
The proposed system will require basic CRUD and reporting functionalities. Reporting functionalities may include general reports on all consultations over a given period or simply a report detailing information about a specific student or a specific consultation. It is also important that the UG coordinator has the ability to easily search through their records and are alerted to any important follow-up appointments with students.
Given the confidential nature of student consultations with the UG coordinator, it is important that the system is secure (requiring the UG coordinator to log in with a username and password). At minimum, the proposed system will need to operate on both Windows and Mac operating systems.


For this first assignment, you team is required to develop a detailed (and initial) product backlog (Excel file) for your proposed solution to the UG coordinator information system. In addition, your team is required to create a project document.

Product backlog

The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product/software that you and your team will develop throughout the semester. This is typically presented via ‘user stories’. The most important items are shown at the top of the product backlog so the team knows what to deliver first. For this, you will need to first brainstorm with your group, do some online research (on topics such as ‘user stories’, ‘estimations’, and ‘definition of done’) and consult with your lecturer and tutor (particularly in the week 03 workshop). The product backlog should be presented as an excel file but the exact layout and format of the product backlog needs to be developed by for team (this will also require some research by your team, particularly the product owner). Later on in the semester, online tools such as Trello will be used by your team to capture and monitor user stories within a given sprint.

Project document

The project document that accompanies your product backlog is used as an initial document to define your team’s project for the semester. The project document becomes the “landing page” for everything related to your project. Having something that is the central go-to location saves your team members time in accessing this information and gives them a concise view. This includes, but is not limited to, the following items:

  • Project timeline, communication and meeting plan for the semester.
  • Roles of project team members (including justification for selection of roles)
  • Proposed technologies: You are free to choose any technology to design the system (e.g., SharePoint, Oracle, Java, javaDB, PHP, JSP, MySQL, prototyping tools etc.). You need to present and justify your technology choices (e.g., different features may require different technologies).
  • Scope: Keep the team focused on the work at hand by clearly calling out what you’re not doing. Flag things that are out of scope at the moment, but might be looked at later.
  • Initial assumptions and constraints (list the technical, business, or user assumptions your team might be making early on in the project).
  • Target first release: When is it projected to ship (i.e. what Sprint)? And how has this projection been estimated?
  • Outstanding Questions: As the team understands the problems to solve, they often have questions. Create a table of “things we need to decide or research” to track these items.

The minimum style requirements for the project document is as follows:

  • The document should be typed (word document and excel) and provide sufficient margin areas for markers comments
  • Font size 12 (Times new Roman)
  • Page numbers must be included in your document
  • There should be double or 1 1⁄2 spacing between lines
  • The document should include a cover page that includes your team name, log and student name and number of each team member
  • The document should also include a table of contents

It is important that your project document is well presented. Your document should be clearly structured, with paragraphs clearly connected, coherent and appropriately written. There is no Word limit for the project document. It is advised that your document be reviewed and editing by each member of your team prior to submission.