2021_22

5COM1053-61 CS/IT Development Exercise GP3: System Implementation Tasks This document gives details about the tasks you need to complete as a team. The assessment is based on the case study MICE (Mega Independent Cinema Experience ) system from previous assessments GP1-GP2. In your team, the aim is to produce an implementation (section 1.1) of the MICE System in the form of a web-based prototype alongside a supplementary team report (section 1.2). These team tasks are described below in part 1 with the key summary against mark weightings listed as User Acceptance Tests (UATs) in part 2. Teams must also attend a mandatory demonstration viva to attain marks, described in part 3. With all team assessments, members are expected to make equal contributions. This can take different forms, i.e., not just undertaking assignment work, but also organisation and leadership. Some examples of different team roles for this assessment include project management (including sprint documentation via Kanban), screen design or coding web pages, database management, user interface considerations and evaluations, testing, etc. N.B. Where there are contribution problems, students should inform module tutors. If module tutors deem there is evidence of an unequal contribution, the team mark may be reduced for individuals with a lower contribution.

1. Assignment Tasks

1. Web-based System Design and Implementation

Provide a Web-based prototype using the EasyPHP platform (a WAMP stack utilising Windows, Apache, MySQL, PHP) to implement dynamic screens. This entails creating the database (use of MySQL can be managed via phpMyAdmin within EasyPHP) and carrying out object-relational mapping (ORM) to tie the backend database to your frontend application. You will use both server-side (PHP framework) and client-side (HTML and CSS) technologies. Ensure the prototype includes the sample data, which is provided and additional data you might need to fully test your system e.g. fictional representative records in tables. For this part of your submission, include a zip of your completed EasyPHP stack from its root, and include a .SQL file of your database structure (within phpMyAdmin, click the root of your database and choose the export tab. Check the SQL file has both create and insert statements reflecting your database tables and sample data records). N.B. you MUST use the provided platform. You can use additional libraries to enhance usability, such as Bootstrap for styling, but must ensure this is integrated within EasyPHP. For guidance you should us:

1. GP3 MICE Implementation Case Study and Data Model
2. GP3 MICE Client Sample Data and Scenarios 21_22
3. User Acceptance Test (UAT)
4. L29 GP3 Briefing (more briefings will follow)

As well as lecture slides & videos for technical support

1. Documentation: Team Report

For the report, there are THREE tasks to complete and compile into one document as follows:

1. Evidence of 2 sprint cycles using Kanban Include a minimum of 4 screenshots of Kanban boards representing two sprint cycles: each having a sprint plan and sprint review. Kanban (columns for backlog [i.e. to-do], in progress, done) can be managed with any tool you like, e.g. Trello. Utilise Kanban to manage your progress on team tasks for this assessment listed in the UATs in part 2. The aim is for you to work on this assessment in two timebound sprints, each being a 1-3 week cycle of work.

Start with a board for Sprint Plan 1 by choosing some (but not all) tasks for this sprint, and place in the backlog column. Maximise transparency on the board by adding detail, images, etc. and include which team member(s) are planning to work on each task for this sprint (tools such as Trello allow for member allocation). Take a screenshot(s) labelled Sprint Plan 1. During the sprints cycle, keep track of tasks and allocations by updating the board via the in progress, and done columns against your own progress dates. At the end of the cycle, record the current state of work by taking a screenshot(s) labelled Sprint Review 1. Repeat for Sprint 2, taking screenshots for the Sprint Plan 2 and Sprint Review 2.

1. Updated E-R Diagram

This should show the relationships between your DB tables and may differ from the one provided in the Case Study specification

1. Evidence of testing For your implementation, your team should carry out testing with evidence. You will be given some sample data which you can use but may need to add some of your own data to fully test your system. A good approach would be to write a test (plan) before implementing a feature (use the UATs to guide you) against the expected result, implement the feature, then carry out the test recording the name of the tester, date of test, and actual result outcome (pass/fail). For your web prototype, you should represent dynamic testing of data, A possible tabular example is given below.

Test No	Test Description	Test Data	Expected Result	Actual Result	Date	Tester (team member)	Comments
Example for those choosing the web-based prototype
1	Login (UAT #X).	Username user01. Password test123.	Redirect to homepage without errors.	Fail	21/01/21	Woody Pride	Page not found on submit. Typo on location of homepage in button reference.
2	Login (UAT #X).	Username user01. Password test123.	Redirect to homepage without errors.	Pass	26/01/21	Buzz Lightyear

1. Written evaluation of the prototype In around 500 -1000 words, critically evaluate your prototypes interface (with screenshots of drilled down aspects of the interface) by considering some (but not necessarily all) of Nielsens 10 usability heuristics and WCAG (Web Content Accessibility Guidelines), referring to class notes. Include both aspects of strength, and aspects which may need further improvements to meet a heuristic(s) or WCAG constraint.

1. Demonstration Viva

After the hand-in, your team MUST attend a demonstration (demo) viva (Q&A), which will be scheduled with module tutors (acting as the client). Whilst the nature of this is not overly formal in nature, it is a formal, mandatory part of the assessment and should be treated like an exam. For the demo, module tutors will consider some of the UATs in part 2 to direct you in showcasing your prototype live. The prototype used for the demo, and what will be assessed, must only be what is submitted. The demo may be followed by Q&A led by module tutors. These questions will be based on your prototype and supplied documentation, and against team roles. You will also be expected to make a very short presentation (maximum 5 slides) to cover:

• team membership, roles and responsibilities
• evaluation of your system: what it does well, what still has problems, what was not implemented
• overall analysis and reflection on team working: lessons learnt; what you did right and what went wrong, lessons for the future

The slot (demo and Q&A) for each team is up to 20 minutes (plus a few minutes for set-up). N.B. Every member of the team needs to attend. Marks cannot be awarded to members without this. If you cannot attend and have extenuating circumstances, you should seek advice from module tutors. Following the demo, any alterations to the team mark, or marks for individuals (if there are concerns over contributions), will be at the discretion of module examiners and moderators.

1. Submission

1. Software: .zip file containing both the platform and your implementation
2. Team Reports

• Kanbans for 2 Sprint cycle
• Updated E-R diagram
• Evidence of testing
• Evaluation

1. Demonstration

• Presentation slides

1. Roles & Contribution Form

1. Marking Scheme Team Contribution

As a team you should consider and submit the GP3 Roles and Contributions Form posted with the assignment. This asks you to give a percentage contribution that each of you has made to this assessment. For example: Example (a): if there are five team members and you consider that everybody has contributed equally, then everyone should be allocated 20%. The total must of course be 100%. Example (b): if there are four members and you all agree that one person has contributed twice as much as everybody else, then he/she gets 40% and the other three get 20% each. If you all agree then you should complete a single team form in your submission. If you cannot agree, then each team member who disagrees should complete the form individually instead. 2.2 Marking Individual Individual student marks will be calculated on the assignment mark. No individual team member can score higher than the mark awarded for the assignment. Where a team member's contribution is significantly lower than that of other team members, they will be awarded only a proportion of the assignment mark.

Contribution difference from the norm	% of assignment mark
	90%
> 5% AND	70%
>=10% AND	50%
>=15% difference	0%

Example 1: Assignment mark = 60, 4 team members each assessed as contributing 25% (4 * 25 = 100%) Norm is 100/4 = 25%. All members contributing the norm Each team member gets 60 Example 2: Assignment mark 60, member1; 50%, member2: 20%, member3: 15%, member4: 12%, member5: 8% Norm is 100/5 = 20% member1 gets 60 [No student can get more than the assignment mark] member2 gets 60 [meets norm of 20%] member3 gets 60 * 0.90 = 54 [difference from norm member4 gets 60 * 0.70 = 42 [difference from norm between 5% and 10%] member5 gets 60 * 0.50 = 30 [difference from norm > 10%] N.B. If member5 was on 5%, they would get 0% The raw final mark out of 100 will be scaled to be worth 20% for the module overall. This is calculated by scaling the raw mark out of 100% to its equivalent mark out of 20%. For example, a raw total mark of 60 out of 100 means you accumulate 12% out of the possible 20% for the module, because 60 x 0.20 = 12. If you have team management problems, please seek advice from staff However, once teams are set, they cannot usually be changed.

Attachments:

fwdfaiyaz8723....zip