Dynamic Modelling, Screen Design and
Test Plan
1. TIMELINES AND EXPECTATIONS
Due date: Monday, Week 11, 11:55pm Weighting: 20%, maximum mark: 100.
Minimum time expectation: 40 hours [4 out of the 40 hours are the contact hours from week 6 to week 10].
You will be working with your team member(s) from assignment 1.
Your assignment will be assessed by your tutor or lecturer if your lecturer is also your tutor. You will receive your mark and written feedback via Moodle two weeks after the due date or submission, whichever is later.
2. INTRODUCTION
In this assignment you will model the behaviour of systems or subsystems for two of your most complex use cases using two UML diagrams (activity diagram and system sequence diagram) and write the extended use case description. You must also submit test plans and screens developed using InVision.
Section 3 describes the motivation behind the design of this assignment. Section 4 provides information on how and what to submit (note that Moodle has been setup so there is only one submission from each group). Section 5 explains the tasks for individual and group work. You will find the criteria for marking your submission in Section 6.
3. MOTIVATION.
The purpose of the assignment is to ensure that you know:
1. How to write extended use case texts.
2. How to model the dynamic aspect of a system using UML (activity diagram and system sequence diagram).
3. How to develop screen prototypes to assist analysis.
4. How to develop quality test plans.The assignment addresses the following learning outcomes:
K1. Explain how models are used to assist in analysing and modifying existing business systems;
K2. Define various roles involved in the processes of system analysis;
K3. Describe techniques used to gather required information for system analysis;
K4. Explain the various stages of the system development life cycle;
S1. Identify appropriate models for given scenarios;
S2. Develop various models using a professional CASE tool;
S4. Perform Object Oriented Analysis and Design to construct various object models used to communicate the scope and requirements of the project.
A1. Write integrated reports, using appropriate models, providing detailed analysis of given textual scenarios.
4. HOW AND WHAT TO SUBMIT
1. Moodle has been set up so each group submits only one document – anyone from a team can submit.
2. Open your Federation University OneDrive account. If you have never used it, or are not sure how:
? First login to your Federation University student email account.
? Click the nine dots in the top left corner and select OneDrive.
? OneDrive should open starting the files menu.
3. Sharing the Folder from OneDrive with your Marker
1. Right-click on the Directory that contains the group report and Invision files of all your team members in OneDrive.
2. Click -Copy link-.
3. Click the button -People with existing access can use the link-.
4. Change it to -People in Federation University Australia with the link-.
5. Untick -Allow Editing- - as you do not want anyone changing your file.
6. Click Apply.
7. Copy the link that is created.
8. It will be a very long link starting with -https://federationuniversity-my.sharepoint.com-
9. Download the file “Assignment2Submission.txt” from the Moodle shell
10. Open Assignment2Submission.txt
11. Paste the link for your file from OneDrive in to Submission.txt
12. Save Assignment2Submission.txt
4. Submit Assignment2Submission.txt via Moodle Shell.
As a general guide to how the document should look, think about your target audience, which in this case is another system analyst and a quality assurance (QA) team who will work with the system. Remember that everyone is busy and overloaded with information, so please include only the most essential information: be brief but clear. The QA team will use the test plans to develop automated system tests. We expect the GoogleDoc document to have the following information:
1. The name of the organisation you are modelling.
2. The name and student ID of each team member and the name of the system or subsystem modelled.
3. For each member, the extended use cases, activity diagrams, and system sequence diagrams for two of the most complex use cases.
4. For each member, the test plan for the use case chosen in step 4 – in other words, the test plan must be for the same use case as for the screen design.
5. ASSESSMENT DETAIL
This assignment has group work and individual work components. Please note although we require only one report for the group and individual components, we will be able to track your contribution to the group work component. The following sections describe the tasks for the individual and group work.
Task 1 - Individual work [95 marks]
With reference to the model you built as a group, document the following:
1. The identification of the system or subsystem you were working on.
2. Find two of the most complex use cases you have submitted in assignment one. The use cases must not be from the written case study in assignment 1. Also make sure at least one of the use case is used by internal users (not customers), because we want to avoid students taking screenshots of existing applications and submitting the screens. For each use case:
a. Describe the process for each use case in plain English as in Tutorial Six.
b. Then, develop an extended use case from the description.
c. Finally, develop the activity diagram and system sequence diagram.
2.1 Each activity diagram must have at least one decision making, parallelism or loop. If the diagram has no such features your extended use case might be incomplete: you must revisit your use case to ensure that it is complete.
2.2 Each system sequence diagram must have at least one of the following: a loop, optional or alternate frames. If the diagram has no such a frame you must revisit your use case to ensure that it is complete.
3. Develop the screen prototype and test plan for one of the use cases selected in step 2 above. The test plan must be for the same use case as for the screen design.
Task 2 - Group work [5 marks]
Consolidate all three subsystems into one report: the plain English description of the use cases, extended use case texts, activity diagrams, system sequence diagrams, the filenames of the Invision screens and test plans. The report must have a title, all three subsystems and the student responsible for the subsystem.
6. MARKING CRITERIA
INDIVIDUAL WORK – YOUR OWN SYSTEM ONLY Max
1 English like description of two of the most complex use cases.
10mks
2 Extended Use Cases.
Each extended use case can be computerised and is an elementary business process. Both extended use cases will be used to develop activity diagrams and system sequence diagrams and one of them will be used for design of screen(s) and creation of a test plan. Must include all entries of an extended use case as described in Week 6 material; however, you may or may not have any related use cases. Each entry is described clearly and is easy to understand. No obvious spelling errors.
20mks
3 Activity Diagrams.
Must identify the corresponding use case name for each activity diagram. Each diagram is complete: correctly describes the flow of activities in the corresponding extended use case between all actors and the system. The activity diagram notation is correct.
Each activity diagram has at least one decision making, parallelism or loop. 15mks
4 System Sequence Diagrams.
Must identify the corresponding use case name for each system sequence diagram (SSD). Each diagram is complete and correct: correctly shows the flow of input messages, input and output data between all actors and the system. The flow of input messages must correspond to the extended use case, and the name of each input message follows the verb-noun syntax. The SSD notation is correct.
Each system sequence diagram has at least one of the following: a loop, optional or alternate frames. 15mks
5 Screen Design.
Must provide screen design(s) so users can complete the task for one use case: users can enter all information required. Screens must not be from an existing application. Screen design(s) must correspond to the system sequence diagram. As in the top level screen design, the screen must incorporate best practice in screen design.
20mks
6 Test plan.
Test cases are easy to follow and comprehensive. Please see Week 7 slides and ITECH2002_Assignment2_TestPlan.xlsx.
The test plan must be for the same use case as for the screen design. Each test case is numbered and the guideline is correctly identified. Each test case has a short description, test data and expected output.
Use all guidelines (Right-BICEP and CORRECT Boundary) and provide justification for guidelines that are not applicable; the justification must be reasonable and appropriate. Note that some guidelines may have multiple test cases (for example in Week 7 slides, RIGHT_BICEP). Test cases can be easily used for writing automated tests; if they cannot be automated, please provide appropriate justification.
15mks
GROUP WORK Max
7 Presentation of Report.
Report is complete, markers do not have to follow any external links but they are provided as references. Report is easy to read and looks professional (for example, must have a title). It must be clear what organisation is being modelled and who the contributors are (name and student ID). It should also be clear which subsystem each member is responsible for.
5 mks
End of Assignment Two Specification