CET211 (Intermediate S.D) PPW2 Task and Submission
- Details
- Category: Level 2, Intermediate Software Development
- Published: Monday, 25 January 2021 14:47
- Hits: 839
Task
CET211
Professional Practice Week 2
Monday 14thto Friday 18thJanuary, 2019
Schedule of events
|
Date |
Time |
Description |
Location |
|
Monday |
9:00 AM |
PPW2 Release |
PR007 |
|
Tuesday |
1:30 - 2:30 |
Tutorial Support |
Cell A |
|
Thursday |
11:30 -12:30 |
Tutorial Support |
Cell D |
|
Friday |
17:00 |
PPW2 Submission |
Via Canvas |
Monday9 AM – PPW2 Release
- At 9am on Monday you will be issued with the problem specification for professional practice week 2,via canvas.
- The schedule of events offered above shows when staff are available for academic support and informal feedback.
- All PPW2 work should be zipped and uploaded to Canvas by the submission deadline, which is Friday 18thJanuary at 17:00 hrs.
Full details of your assessment, and associated marks, are available on the following pages.
CET211 IntermediateSoftware Development
Professional Practice Week 2
(2018/19)
Professional Practice Week 2 contributes 60% to your final module mark and assesses learning outcomes 1, 2,3 & 4.
PPW2 is designed to reflect on and assess all learning outcomes for CET211. You will be given a series of programming and related modelling tasks. Specifically, you will be asked to make code modifications and model the architecture of your system once all changes have been incorporated.This assignment is worth 60 marks in total and contributes 60% to your final module mark.
Modifications are listed as tasks in a scrum burndown chart.There are 4 mandatory tasks and 2 desirable tasks. You may choose the order in which you complete each task, but you must complete all mandatory tasks plus one desirable task, for a total of 60 marks. We anticipate this assessment will constitute a maximum of 35 hours of work. You must submit all tasksas a single zip folder on canvas, by Friday 18thJanuary, 17:00 hrs.
Scenario
Sunderland Despatch Agency (SDA) is a company which offers parcel collection and delivery services to local companies in the North East region. They have been using a prototype system for managing parcel deliveries, including delivery of boxes and poster tubes, for a number of months.
The system allows generation of a list of parcels which are due for despatch. As a result of system testing and end user evaluations, they 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 desiredcode 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 SDA. It is your responsibility to complete and submit the revised system (and related documentation) by Friday 18thJanuary, 17:00 hrs.
Burndown Chart
|
Task Name |
Task No |
Task Description |
Status |
Estimated Effort in Hours |
|
1. Add Item |
1.1 |
Create a second Form(Form 2) to allow new Parcels to be added by the user. |
Mandatory |
3 |
|
|
1.2 |
Integrate new form into existing code base- the despatch list on Form 1 should be updated when a new parcel is added. |
3 |
|
|
2. Persist Data |
2.1 |
Serialize Despatch List when application closes. |
|
3 |
|
|
2.2 |
Deserialize Despatch List when application opens. |
|
3 |
|
|
2.3 |
Write Unit Tests to Demonstrate that Serialization and Deserialization work correctly. |
Mandatory |
6 |
|
3. Validate |
3.1 |
Ensure system is robust against incorrect user input. |
Mandatory |
3 |
|
|
3.2 |
Throw Custom Exception (SundayException) if the expected delivery date is a Sunday. |
5 |
|
|
|
4.1 |
Amend details of existing parcel on the despatch list. |
|
3 |
|
4. Edit Delivery |
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 delivery 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 completed system in its entirety. |
Mandatory |
3 |
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 2017), 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 delivery functionality, but basic compilation errors evident. |
Basic attempt at edit delivery functionality, but incomplete (for example changes do not persist). |
Good attempt at edit delivery functionality, but lacking in some areas |
Excellent implementation, which provides a realistic simulation of edit functionality. |
|
Edit Delivery |
||||
|
|
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 ForParcel Costing and Guidance on Task 5
Parcelcosts are calculated as:
totalCost = weightInKilograms * 2.80.
Poster Tubecosts are calculated as:
totalCost = 1.50 + (height / 100) * 5
Boxcosts are calculated the same as Parcel costs. However, if the overall volume of the box exceeds 2, 500 cm2 an additional cost is added (of £1.20 per kilogram).
Costing functionality should be implemented as an Interface. At a minimum, the Interface should have the following (You may extend it if needed):
Demonstration of how the system can utilise ICostable to generate event costs should be achieved via use of a CostCalculator class. A suggested approach is illustrated in the UML Class diagram provided below. When modelling your final system (Task 6) you should illustrate the relationship between your inheritance hierarchy and the model shown below (or your own model if it differs). You should also expose this functionality to the user, for example via a button which results in all costs being displayed.
Submission
UML Diagrams
Code