Scenario
Sunderland Karting Association (SKA) is a local agency who organise Go Karting races in the North East region. SKA keeps records of all upcoming races in the area and have been using a prototype system for managing scheduled races, specifically Pedal and Motor Races.
The system presently allows generation of a list of races which are scheduled to happen. As a result of system testing and end user evaluations, SKA have identified a number of modifications which require development.
The prototype system has been implemented within an agile framework, and extensions will be implemented using the same software development methodology. To this effect, all desired code extensions have been summarised in the burndown chart provided below. A description of each task has been provided within the chart.
You have been tasked with implementing and documenting all listed mandatory changes, plus one desirable task. You may choose to either update your original form-based prototype from professional practice week 1, or to use the code base on Canvas which has been provided by SKA. It is your responsibility to complete and submit the revised system (and related documentation) by Friday 17th January, 09:00 hrs.
Burndown Chart
|
Task Name |
Task No |
Task Description |
Status |
Estimated Effort in Hours |
|
1. Add Item |
1.1 |
Create a second Form (Form2) to allow new Races to be added by the user. |
Mandatory |
3 |
|
|
1.2 |
Integrate Form2 into existing code base- the Race list on Form 1 should be updated when a new race is added. |
3 |
|
|
2. Persist Data |
2.1 |
Serialize Race List when application closes. |
|
1.5 |
|
|
2.2 |
Deserialize Race List when application opens. |
|
1.5 |
|
|
2.3 |
Write Unit Tests to Demonstrate that Serialization and Deserialization work correctly. |
Mandatory |
3 |
|
3. Validate |
3.1 |
Ensure system is robust against incorrect user input. |
Mandatory |
3 |
|
|
3.2 |
Throw Custom Exception (MaxCapacityExceeded) if the Race capacity is greater than 50. |
3 |
|
|
|
4.1 |
Amend details of existing race on the list. |
|
3 |
|
4. Edit Race Details |
4.2 |
Update form and save changes to the list via serialization. |
Desirable |
3 |
|
|
5.1 |
Demonstrate the use of an Interface to allow extensible calculation of race costs (See rules for costing provided in Appendix.) |
|
3 |
|
5. Implement ICostable |
5.2 |
Evidence above extensibility through addition of a utility class (See suggested UML model in Appendix). |
Desirable |
3 |
|
6. Model |
6.1 |
Create UML Model to represent the system in its entirety (with no suppression of relevant information). |
Mandatory |
4 |
Submission details
Hand drawn UML diagrams are acceptable but must be neat and clearly legible and then scanned for online submission. You may use a UML drawing tool e.g. Software Ideas Modeller for this task but if you do so then the UML notation used must be consistent with that covered in the module and you should export the diagram to an image file which can be embedded within the report document. Programming deliverables should be submitted as a single Visual C# solution (version 2019), containing your application, associated .dat files, and .sln file.
Important Information
You are required to submit your work within the bounds of the University Infringement of Assessment Regulations (see the Programme Handbook). Plagiarism, paraphrasing and downloading large amounts of information from external sources, will not be tolerated and will be dealt with severely. Although you should make full use of any source material, which would normally be an occasional sentence and/or paragraph (referenced) followed by your own critical analysis/evaluation. You will receive no marks for work that is not your own. Your work may be subject to checks for originality which can include use of an electronic plagiarism detection service. You are not expected to put your commentary report through Turnitin (however the module leader reserves the right to do so if they deem it necessary). Where you are asked to submit an individual piece of work, the work must be entirely your own. The safety of your assessments is your responsibility. You must not permit another student access to your work. Where referencing is required, unless otherwise stated, the Harvard referencing system must be used (see the Programme Handbook).
Marking Criteria
|
Task 1 |
Some attempt but basic compilation errors evident. |
Some attempt, but needs improvement or is lacking multi form functionality |
Good use of multi-form controls that provide a basic simulation of add event functionality |
Excellent use of multi-form controls that provides a realistic simulation of all required functionality. |
|
Add Item |
||||
|
0 |
1 to 3 |
4 to 5 |
6 to 7 |
8 to 10 |
|
Task 2 |
Some attempt at data persistence but not using serialization. |
Some attempt at serialization but minor errors or omissions present. |
Successful use of serialization but lacking in some areas. |
Excellent use of serialization. |
|
Persist Data (Development) |
|
|
|
|
|
0 |
1 to 3 |
4 to 5 |
6 to 7 |
8 to 10 |
|
Task 2 |
Some attempt but basic compilation errors evident. |
Basic attempt at a single unit test. |
Good set of unit tests but lacking in some areas. |
Excellent set of unit tests which thoroughly tests the file-reading aspects of the system. |
|
Persist Data (Unit Tests) |
||||
|
0 |
1 to 3 |
4 to 5 |
6 to 7 |
8 to 10 |
|
Task 3 |
|
|
|
|
|
Validate |
Some attempt at exception handling but basic errors evident |
Basic use of exception handling but lacking customised exception class |
Good use of exception handling and customised exception class (though lacking in some areas). |
Excellent use of exception handling with appropriate customised exception class |
|
|
1 to 3 |
4 to 5 |
6 to 7 |
8 to 10
|
|
Task 4 |
Some attempt at edit race functionality, but basic compilation errors evident. |
Basic attempt at edit race functionality, but incomplete (for example changes do not persist). |
Good attempt at edit race functionality, but lacking in some areas |
Excellent implementation, which provides a realistic simulation of edit functionality. |
|
Edit Race |
||||
|
|
1 to 3 |
4 to 5 |
6 to 7 |
8 to 10 |
|
Task 5 |
Some attempt at implementing interface and utility class, but basic compilation errors evident. |
Basic attempt at implementing interface and utility class, but minor omissions or errors evident |
Good attempt at implementing interface and utility class, but lacking in some areas |
Excellent implementation which provides a realistic implementation of an Interface and utility class. |
|
Implement ICostable |
||||
|
|
1 to 3 |
4 to 5 |
6 to 7 |
8 to 10 |
|
Task 6 |
|
|
|
|
|
Model |
Attempt made to correctly identify and structure classes, but with limited success. |
Diagram virtually correct in structure. |
Diagram virtually correct in structure and function (though lacking obvious methods or attributes). |
Diagram correct in structure and function |
|
|
1 to 3 |
4 to 5 |
6 to 7 |
8 to 10 |
Appendix One
Conditions For Race Costing and Guidance on Task 5 and 6
Pedal Race costs are calculated based on the maximum number of participants, the cost of the race per person, and the addition of a 20% staffing overhead:
totalCost = ( Capacity * Cost ) * 1.2
Motor Race costs are calculated equivalent to Pedal Races, but with an additional Insurance premium of £500:
totalCost = 500 + ( (Capacity * Cost) * 1.2)
CS 340 Milestone One Guidelines and Rubric Overview: For this assignment, you will implement the fundamental operations of create, read, update,
Retail Transaction Programming Project Project Requirements: Develop a program to emulate a purchase transaction at a retail store. This
7COM1028 Secure Systems Programming Referral Coursework: Secure
Create a GUI program that:Accepts the following from a user:Item NameItem QuantityItem PriceAllows the user to create a file to store the sales receip
CS 340 Final Project Guidelines and Rubric Overview The final project will encompass developing a web service using a software stack and impleme
