1. Case Study Update

It has been decided to split the implementation of the MICE system between a Database Team and your CS/ITDE System Development team. The Database Team has been given the briefing which you have seen in your Database module. GP2 will focus on activities to do with booking seats for performances, gaining entry to a performance and membership of the MICE club described in the MICE Case Study

The following update has been provided:

• The management of staff is NOT within the scope of GP2. So Employee data is NOT relevant to GP2. However, job roles (such as: manager, booking office clerk) may be relevant.
• Section 2 of the MICE case study describes the membership system. You should only consider customers making books for performances and the running of the membership scheme. Details of discount schemes, or other activities available to members, are NOT relevant at this stage of design

• Section 3 of the MICE Case Study describes the booking system and the entry system.
• Assume that MICE will have one web-based booking system available to all who need to use it. Members/cinema goers will be able to make bookings either directly by personally accessing the bookings web page, or by phoning a booking office of an individual cinema, or by booking through Central Advanced Ticket Sales (CATS). All users will use the same web-based booking system, which will be hosted on servers in CATS.

• Currently, ushers check booking details against the performance details before allowing entry to a performance. Eventually, they will be replaced by automated entry checkers, but the technology for this is not yet in place. However, the system should be able to accept a booking id and check whether it has the same the performance id to which the user wants to gain entrance and then, either allow or reject entry. Ushers may need to check bookings made for a performance.

• Note: A screen will only have one performance a day, all seats at a particular screen are the same price and seats are not numbered, so a booking is for a number of seats not for specific seats. However, the system should check that there are seats available, before making bookings.
• The DB team (your DB assignment) specifies, in some detail, a range of database queries. In GP2, you should NOT duplicate individual queries. However, you may consider broad categories of queries e.g. "management reports" or "performance enquiries"

2. Tasks and Outcomes

The tasks you need to complete for this assessment:

• Part A: Project Management
• Part B: Use Case Diagram
• Part C: TWO Use Case Descriptions
• Part D: Level 2 Data Flow Diagram
• Part E: Wireframes

Part A: Project Management [20 marks]

You will be expected to use project management software to support your teamwork. and should start using this from the start of your work on this assignment. Evidence for this should be available as appropriate screen shots and combined into a single document

• Communication - provides ways for members to communicate with one another. Produce:

• one combined screen shot showing short message sequences between team members at the start of this assignment, in the middle and at the end of the assignment. (we would expect to see some communication before the end of this term and in January).

• Kanban - provides a way of identifying and tracking the progress of project tasks. Produce:

• one starting screen shot to show disposition of tasks at the start of this assignment
• one midterm screen shot showing some completed and some to-be-completed tasks
• one final screenshot showing completed tasks

• Repository - allows team members to save their work in a central repository, so that they can both see and amend each other's contributions, or return to a previous version when necessary. Produce

• one screen shot from the middle of assignment showing contributions from team members to a central repository

You may us any appropriate software. For revision please see Unit 3 : L07 & L08

Note: You are only required to submit some evidence of these tools. However, in cases of disputes about relative contributions of team members, staff my request further evidence in support of your claims.

Part B: Use Case Diagram [25 marks]

In GP1 you identified and documented a subset of system requirements by using User Stories and Volere shells. At the clients request, a more complete set of the systems functional requirements is needed. Before you draw this diagram you should (Just as in Tutorial T07):

• identify human actors who will be using the MICE system
• list tasks they may wish to perform
• identify further non-human actors/other systems that may be involved

Draw a UML Use Case Diagram for the system to be implemented for MICE

The diagram should use appropriately labelled UML icons, to show:

• the main actors - those human/external systems who will be using the system
• possible use cases
• at least, ONE use case connected to others by <>
• at least, ONE use case connected to others by <>

Part C: TWO Use Case Descriptions [15 marks]

Using the Use Case Descriptions Template provided, document

• UCDescription1 - describe the activities of your use case for Cancel a membership
• UCDescription2 - describe the activities your use case for Make a booking

Note: a booking is for one performance and includes a main film goers name and a number of seats. The film goer may/may not be a MICE member entitled to discounts

Part D: ONE Level 2 Data Flow diagram. [ 15 marks]

A level 1 Data Flow Diagram has already identified the following functional areas:

• Manager processes (relating to managing performances)
• Customer processes (relating to bookings & membership)
• Usher processes (relating to entry to performances)

Draw a Level 2 Data Flow Diagram of processes which are likely to take undertaken by the Customer (ONLY).

These processes should:

• be consistent with Use Cases with the Customer as an actor in your diagram for Part B
• have "CATS" as the location
• show data flows from/to external sources/sinks
• show data flows from/to data stores within the system - these are likely to be Database tables but, at this stage, they do not need to be fully normalised
• Note: processes relating to managing performances belong to "manager processes" and should NOT be considered in this diagram