7COM1035 CW1B Tasks

7COM1035 CW1B Tasks
1 of 7
Animals R Us & Veterinary School System (AVSS) CW2: Teamwork

1. Introduction

This second assessment simulates working in a software development team with fellow students to implement the proposed Animals R Us & Veterinary School System (AVSS) introduced in the first assessment (CW1).

Details on the project case study and data model is in part 2 below. Details on the tasks and demonstration viva you will need to complete are in parts 3 and 4. The UATs to guide your implementation is in part 5 and a mark breakdown in part 6.

1.1. What the assessment work will involve

• Carry out project planning, teamwork and management • Review and refine the requirements specification • Implement a data model for the prototype • Implement the prototype using a PHP-based framework • Test the prototype • Demonstrate the prototype to the client

1.2. Challenges

• Planning, time management and teamwork (including leadership and negotiation) • Cope with a complex brief (with possible ambiguities and inconsistencies) from the client • Technical skills to produce the prototype and understanding how system components work • Interacting with the “client” on your solution via documentation and demonstration

1.3. Development of the prototype

The (prototype) application should be implemented using industry-standard web technologies: the server-side language PHP, and client-side technologies HTML, CSS and JavaScript. As introduced in class, one way of implementing such a prototype is using a WAMP stack (Windows, Apache, MySQL, PHP) and working with an existing PHP-driven framework.

One ready-made example of this is the development platform available on Canvas. This WAMP stack is called EasyPHP and the PHP framework used to build the example application is called CodeIgniter. The MySQL database can be managed in a web browser via the database tool phpMyAdmin (included in EasyPHP). Refer to class notes for information and support documentation on the technologies.

N.B. You MUST use the provided development platform for this assessment. You are welcome to explore additional template libraries to enhance the usability, such as Bootstrap for interface styling, but you must ensure this is integrated within the EasyPHP stack.

7COM1035 CW1B Tasks
2 of 7
2. Case study and data model

Re-read the AVSS case study attached in separate file ‘Veterinary school case study’.

Below is a data model as a starting point for your implementation. You will need to read the case study again and make assumptions to identify attributes, primary keys and foreign keys. For example, the ‘animalssInLesson’ entity should be implemented as a join table with a composite primary key with foreign keys from the ‘vetLesson’ and ‘animal’ entities.

It is very important you plan your implementation to cross-check against the User Acceptance Tests (UATs) in part 5, i.e. carry out development and testing concurrently.

You may also wish/need to expand the data model to include other relevant entities, such as those which serve primarily as a look-up table. For example, an additional, implemented table called ‘Title’ (with values Mr, Miss, etc.) if linked to an owner would allow the “title” values to appear as a dropdown menu when adding a new owner using the platform’s framework. This would enhance usability and minimise user input errors. Consult teaching resources for more examples.

3. Tasks and Roles

3.1. Tasks

There are two main deliverables: a) a report and b) a demonstration video, supported by a viva.

To be able to report/demonstrate, you will need to work with your team for this module (see Canvas) to implement AVSS using the EasyPHP platform. This will entail creating the database and carrying out the required object-relational mapping steps to tie the backend database to your frontend application. You should add a small amount of sample data records (add some fictional examples) in each table at the end for your submission. See the UATs in part 5 for a full list of what you should implement.
7COM1035 CW1B Tasks
3 of 7
As a backup, submit your completed application via a zip file of the EasyPHP stack, containing both your application and 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, before saving in your EasyPHP stack.

Marks are awarded for your report and demonstration as described below, not the EasyPHP stack.

A) Report

Provide a report organised into the 3 report sections listed below. Note: structure/layout [5 marks]: your report should be in PDF format and made up of around 3000 words. It should be presented professionally, such as labelled headings, page numbers, and numbered tables/figures, etc. Any references used should be provided using the UH Harvard format.

1. Project management and teamwork [10 marks] Provide details, and reflect, on how your team organised and communicated to keep the software development on track for the delivery of AVSS. This should include team roles/task distribution (see part 3.2 below) and evidence of suitable tools/technologies used to support the team’s communication, task scheduling (such as MS Project or Trello – see canvas practical notes for download info), software version control (such as a repository like Dropbox to manage different versions of the same file), etc.

Provide screenshots to support your discussion, which is expected to be between 500-1000 words.

In this section you should also provide TWO completed sprint cycle forms, signed by teaching staff • Use the provided documentation (see separate file ‘sprint cycle documentation’) to manage your team’s development plans and progress • Staff will review, and sign, sprint forms in class during scheduled sign off sessions ONLY

You should find that your completed sprint forms will help you add some reflections to this section, as you can refer to proposed tasks (sprint plan) against what really happened (sprint review).

2. Application of MVC architecture and database schema [10 marks] Provide an explanation of how the PHP-driven framework allows developers to adopt Object-Relational Mapping (ORM) to implement a system like AVSS conforming to the model-view-controller (MVC) architecture.

Provide screenshots of relevant folders/files from your AVSS implementation to demonstrate how the framework adopts the MVC structure for ORM. Also provide short code snippets from your AVSS implementation, which you should refer to in your explanations.

This discussion is expected to be between 500-1000 words.

You should also create, and submit, a database schema (diagram – not part of the word count) to reflect the final version of your implemented database. • This looks like an Entity Relationship Diagram (ERD) but depicts what is built and must match the database structure seen in phpMyAdmin (MySQL) within EasyPHP. • Ensure each table is depicted with its attributes (including data type and length) and relationships between tables. Primary and foreign keys must also be indicated. • Your diagram could be exported from a tool such as MySQL Workbench, which can also import/export the data structure from/to phpMyAdmin.
7COM1035 CW1B Tasks
4 of 7
3. System testing and UI evaluation [10 marks]

Testing [5 marks] Carry out TDD with Agile’s ‘test-first’ method against functional UATs (see part 5 below) as a guide to your test cases. Test concurrently with implementation in small batches, i.e. add a test case to the test plan before anything is coded, then implement the functionality, and finally run the test documenting the results.

Add your test documentation to this section of your report, ensuring you include the date of test, tester (team member who carried out the test), test case (UATs and/or descriptive), test data, expected result, and actual result (pass/fail).

Use a tabular format to document tests (not part of the word count), like the example below:

Test No
Date Tester Test Case Test Data Expected Result
Actual Result
1 21/01/20 H. Partou Login (UAT 3c).
Username “user01”. Password “test123”.
Redirect to homepage without errors.
“Page not found” on submit. Typo on location of homepage in button reference.
2 26/01/20 H. Partou Login (UAT 3c).
Username “user01”. Password “test123”.
Redirect to homepage without errors.
3 26/01/20 L. Smith
Validation on login form (UAT 2b).
Enter username “admin” but no password.
Error message displayed “Please enter password”.
… … … … … … …

You can place some similar tests in an appendix of your report if it demonstrates the same test across different database tables for example.

User interface (UI) evaluation [5 marks]:

Critically evaluate on the user interface of your final AVSS implementation. Consider both strengths and improvements needed. Refer to some (but not necessarily all) of Nielsen’s 10 Usability Heuristics with specific examples from your AVSS interface. For example, “once the button is pressed by table X, a confirmation message is displayed, which complies with Nielsen’s ‘visibility of system status’ heuristic’.

This discussion is expected to be between 500-1000 words.

B) Video (System Demonstration) [10 marks]

Produce a PC screen-capture video (using a tool such as ActivePresenter or Camtasia) demonstrating the features of AVSS and its capabilities. The video should be in a standard .avi or .mp4 format and last around 10 minutes in length. The video should ideally include a voiceover and textual annotations. In your video, present system functionality (functional requirements) and any usability, security, or other features (non-functional requirements) implemented in your AVSS implementation. Use the UAT listed in section 5 to determine what to capture in the video.
7COM1035 CW1B Tasks
5 of 7
This video is a showcase for your system and needs to prove that the system works as your team says it does, e.g. functionally demonstrated against UAT as listed.

You should imagine that if this video was presented to a real client, they would not be very impressed if the video was poorly executed and did not prioritise demonstrating system features against the UAT list. If the video just presents, for example similar updates for multiple tables, which basically show the same type of functionality, then this is wasting valuable opportunity within the time constraints of the video. Ensure there is sample data to showcase pre-populated drop-down menus for example.

It is already anticipated, given that the submission is a prototype, that some of the application may not be working as expected. A client would expect honesty from the video demonstration to reflect what progress was made towards the completed application.

3.2. Team Roles

With team assessments, all team members are expected to make equal contributions. This can take different forms, i.e. not just volume of work but also specialist skills, knowledge, and/or leadership. It would be expected that allocation of tasks (see part 3.1 above) would be distributed fairly. Some examples of different roles for this assessment are listed below:

• Project planning: leadership, organising team meetings, responsible for sprint documentation. • Testing: designing test plans, carrying out the tests, and documenting results. • Database implementation: required data and enhancements, e.g. custom queries. • ORM (object-relational mapping) implementation: map backend database tables to frontend tables (as objects) with appropriate data constraints on the application. • User interface implementation: enhance the user experience, e.g. colour scheme, workflow, error messages, system help, etc. • Advanced implementation: enhanced application functionality, such as login user profiles, batch/automated processing, etc. • Production of the demonstration video

N.B. You should plan for approximately equal contributions and we expect most teams will achieve this; however, where there are problems relating to contribution, students should inform the module tutors. If peer assessment indicates unequal contribution and the teaching team agrees, the team mark may be reduced in the case of individuals who have not contributed.

4. Demonstration viva

After the hand-in, your team must also attend a demonstration viva which will be scheduled with the module team (acting as the client). The system demonstration (via the produced video) will be followed by some Q&A (viva) led by the module team. These questions will be based on your system and supplied documentation, including team roles (see part 1.3 above for examples).

The demonstration slot for each team (system demonstration and Q&A) is up to 20 minutes (plus a few minutes for set-up).

N.B. Every member of the team needs to attend. Marks for the assessment cannot be awarded without a demo. 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 the module examiners (see part 3.2 above).
7COM1035 CW1B Tasks
6 of 7
5. User Acceptance Tests (UATs) – guide to implementation and testing

Animals R Us & Veterinary School System (AVSS)
Additions, editing and retrieval/display (via filter) of data via the system interface N.B. This section can all be achieved with the default framework implementation
 /  a) Add new condition b) Add new animal c) Indicate an animal’s availability for a lesson d) Associate animal with a condition for lessons e) Add new owner f) Associate owner with each animal they own g) Add new trainee (veterinary staff) h) Add new veterinary lesson on a given date/time i) Associate trainees for a lesson j) Associate animals for a lesson k) Edit data by changing an owner’s mobile phone number l) Edit data by changing the animal’s associated owner m) Display all animals suitable for a lesson based on their condition n) Display all animals in a given veterinary lesson 2 System’s interface and user experience: usability criteria  /  a) Colour scheme, visual design and layout b) User-centred workflow: users can complete actions in one place, e.g. do not need to look up what IDs represent from other tables
c) Error messages and/or user feedback messages are meaningful after user actions d) Help is available within the system, e.g. guide to navigation and functionality 3 Advanced system features Choose (some, but not likely all) features to implement  /  a) Disabling (de-activating) data, with the ability to re-activate for use in system tasks b) Prevent registering duplicate data (beyond a primary key constraint) c) Entry to interface via secure login, with customised views for users (access rights) d) Custom SQL: display a view which shows the results of counting all animals for each condition, listing condition types in alphabetical order.
e) Custom SQL: display a view which shows the results of listing each trainee and counting how many times the trainee has taken a veterinary lesson, ranked from most to least number of lessons.
f) Batch processing: update multiple records at once based on custom input criteria g) Interface, e.g. colour-coding to visually differentiate animal conditions (such as red for animals who are suitable for advanced lessons, and green for beginners’ animals)
h) Any other useful system features chosen by you