Reference no: EM131497174

Fundamentals of Software Engineering Assignment

Related objectives from the unit outline:

• Apply concepts and strategies associated with each phase in the engineering of software.
• Demonstrate best practice in software processes and in the quality of the developed software by applying appropriate concepts, strategies and techniques in the various phases of software engineering.
• Develop appropriate artefacts/deliverables for each phase involved in the engineering of software.

Task: Automatically Modelling Security Requirements

In Assignment, you drew a Misuse Case Diagram by generating candidate misuse cases using a STRIDE matrix. Given that the number of misuse cases could be large, is there a way to automatically generate a complete set of candidate misuse cases from information contained in a Use Case Diagram and/or a STRIDE matrix and then prune them, leaving a smaller set of viable misuse cases?

You should ask questions on the unit discussion board about the assignment in order to clarify ambiguities.

Teams

Team size 3-4 people. It is very important that each team member is assigned to a specific part of the assignment and that this is recorded on the submitted assignment. Ensure that your team uses a shared document repository (suggest one with version control) and that you provide your lecturer with access to this repository by Friday 12/5/2017. By the same date, please provide the names/student numbers of your team members. All versions of all documents must be placed in the repository. Use the following structure: TeamNNN\minutes, TeamNNN\build (the code), TeamNNN\docs, TeamNNN\refs.

Key Deliverables

You need to submit several deliverables for this assignment in the areas of feasibility (F) requirements (R), project management (PM), design (D), implementation (I) and testing (T).

F - Research on the techniques you could use to solve the problem;

R -  A list of the Requirements;

D -  A design artifact (e.g., a class diagram);

PM - Minutes of meetings held (template in Appendix 1);

PM - A peer assessment of the contribution of each of your colleagues to the system (this may contribute to your assessment) - template in Appendix 2;

I - The system itself (which need not be fully  functional);

I - A 'readme' file which will explain how to install, configure and run the system. Note: This document shall be designed to assist your lecturer in assessing your deliverables - it is not intended to be a user manual; and

T - A test plan showing how you intend to show that your system conforms to the requirements (test case template in Appendix 3).

The System Prototype -

You may choose any development system to build your prototype (e.g. Java, Visual Basic, Python, Swift etc.) as long as it can be demonstrated, delivered and marked as an assessable item. If, however, you choose a development environment that is not readily available (i.e. in the labs), then you are responsible for providing a legal copy of the environment otherwise your submission will not be assessed. Given that the prototype need not be fully functional to gain a passing grade, the use of stubs to indicate call/return values is recommended. You are welcome to use code from other sources provided that the code is available for non-commercial use and you acknowledge the source.

Meetings

Do not leave the compilation of minutes to the end of the project - it is an on-going activity. This deliverable is marked on a pass/fail basis, with a fail resulting in the loss of up to five (5) marks. Record your minutes by starting a thread on the unit discussion board in BlackBoard with the heading "Team#nnn - Minutes, where nnn is your team number. Five meetings are the minimum expected.

Note that each item on the action list must have a unique identifier across the life of the project. Further, at any time before the final submission date, you may be asked to provide evidence that the minutes are a true record of the progress of your team. Failure to do so will result in a five (5) mark penalty.

Peer Assessment

Each person's peer assessment (Word document) should be submitted to BlackBoard by the same date/time as other deliverables. Any team member who does not submit a valid peer assessment by the due date/time will receive a mark of zero (0) for the assignment.

PCN Case Study

Palladium Chain Nursing (PCN) wish to build a tablet-based app that allows health care professionals (HCPs) to sign up patients on-site. They have commissioned you, as an experienced security requirements engineer, to provide some initial models for their app. On start-up, the tablet performs a self-check to ascertain whether its operating system or the app have been tampered with. If the computed check sum does not match the checksum stored on a smart device that is connected to the tablet prior to start-up, then the tablet powers down again. The app must let an HCP authenticate to the PCN Health Server, where the patient records are also stored. Following authentication, an HCP can be authorised to create, modify or delete a patient record (with an appropriate audittrail). To create a record, the HCP asks the patient salient details and inputs the details into a form generated by the app. Following the creation of a patient record, an HCP can use the app to create a service contract between PCN and the patient. As part of the service contract, the patient's health insurance fund may be optionally contacted by the app to confirm that the patient has the correct level of health insurance cover to allow him/her to be able to cover the cost of the service contract. To finalise the contract, the patient signs the form on the tablet in the appropriate place on the form. At that point the service contract is considered active once the data captured on the app is sent to the PCN Health Server.

Attachment:- Assignment File.rar