Assessment Details and Submission Guidelines
Unit Title Software Engineering
Title Assignment 2
Purpose of the assessment
Mapping) This assignment assesses the following Unit Learning Outcomes; ; students should be able to demonstrate their achievements in them:
a.Determine system requirements through requirements elicitation and worksho ps.
b. Design processes for verification and validation of system requirements.
c. Use appropriate modelling techniques to specify system requirements.
d. Produce and communicate to others the functional specifications of a system.
f. Produce a system implementation, and design and implement integration and testing plans.
g. Investigate state of the art software engineering techniques and technologies, and their scope of applicability for Software Engineering.
Total Marks 90
Word limit 2000 words
Submission Guidelines • All work must be submitted on Moodle by the due date along with a completed Assignment Cover Page.
• The assignment must be in MS Word format, 1.5 spacing, 11-pt Calibri (Body) font and 2 cm margins on all four sides of your page with appropriate section headings.
• Reference sources must be cited in the text of the report, and listed appropriately at the end in a reference list using IEEE referencing style.
Extension • If an extension of time to submit work is required, a Special Consideration Application must be submitted directly on AMS. You must submit this application three working days prior to the due date of the assignment. Further information is available at:
• Academic Misconduct is a serious offence. Depending on the seriousness of the case, penalties can vary from a written warning or zero marks to exclusion from the course or rescinding the degree. Students should make themselves familiar with the full policy and procedure available.
Students should form groups of three or four members for this assignment. You need to mention group details in your assignment.
Accommodation booking system for working holiday program
Australia is a popular place for the working holiday travelers. The working holiday program allows young people to travel and work in various international cities for a limited time (i.e. less than 12 months).
The organizers of the working holiday program were impressed with the recent advent of Airbnb. The working holiday organizers hired you as an IT contractor to develop an online accommodation booking system (OABS) for the working holiday travelers with the following requirements:
? Youth can register on OABS
? Youth can search and book available rooms
? Youth can make a group booking (their selected leader to make a booking)
? Youth can select the dates for their travel (and accommodation)
? Youth can pay for their accommodation in advance
? Youth can cancel their booking with 2 weeks’ notice
? Youth can share review comments about their past hosts on the OABS social network (with ratings) For host:
? A host can register on OABS
? A host can provide information about their accommodation facilities
? A host can promote their services with extra service packages (e.g. travel voucher)
? A host can receive the payments through OABS
? A host can refuse the booking and withdraw from OABS service at any time given 2 weeks of notice
? A host can share review comments about their past visitors on OABS social network (with rating) For admin:
? Admin can approve or reject youth or host registration
? Admin can send a private message to youths or hosts
? Admin can put the approved hosts on the reserve list
? Admin can upgrade the reserved hosts to the active hosts on OABS when the available rooms run out ? Admin can cancel the room booking
? Admin can refuse the decision by the host
? Admin can promote the hosts with high ratings on their OABS website
You are given the class diagram as shown in Figure 1.
Figure 1: Class diagram for OABS
Complete the following tasks:
1. For the use case Add new host by admin, write a fully developed Use Case Description and draw a System Sequence Diagram (SSD). Interpret the classes that are associated with a host in the domain model to understand the flow of activities and repetition involved.
2. For the use case Book a reservation by youth, write a fully developed Use Case Description and draw a State Transition Diagram. Review the classes that are associated with a reservation in the domain model to understand the flow of activities and repetition involved.
3. Draw an Activity Diagram to show the flow of activities for the use case Add a new host.
Note: This activity diagram is based on the updated problem domain model.
4. Propose a prototyping tool and its basic specifications to verify the client requirements of AOBS system.
5. Construct XML documents representing the classes involved in the case study.
1. This is a group assignment, so you must include a declaration of the percentage contribution of each team member in your submission.
2. Your report should include the following:
• The cover page must identify students’ (name and number), teaching staff, and assignment.
• The assignment must use 12 point font size minimum and at least single line spacing with appropriate section headings.
References and appendices
• Reference sources (minimum of 10 references) must be cited in the appropriate section of the document.
• All cited references in IEEE style
• List all the appendices
1. The assignment must be submitted in soft (electronic) copy under Moodle. The pages of the assignment must be clear on each page.
Example of marking criteria is shown in following table. Marks are allocated as follows:
Note: The marking criteria varies for each assignment
Section to be included in the report Description of the section Marks
Use cases Identify at least 5 major use cases 10
Use case descriptions Identify 1 main scenario and 2 exceptional scenarios 10
State chart diagram(s) At least 1 diagrams 10
Sequence diagram(s) At least 1 diagrams for ANY 2 use cases 10
Activity diagram Complete solution 10
Class Diagram Complete solution 10
Verification Verify the user requirements using any selected method 5
XML files Express all the project entities using XML 20
Reference style Follow IEEE reference style 5
Grade / Marks HD 80% - 100% D 70% - 79% C 60% - 69% P 50% - 59% Fail 50
Excellent Very Good Good Satisfactory Unsatisfactory
Use cases All major use cases (minimum 5) are identified and correct notations used Most use cases are identified (minimum 3 )and correct notations used Generally good, some of the use cases are identified Some understanding about the use case diagrams. Quite a reasonable number of use cases are identified Poor, not acceptable
Use case descriptions All main steps are identified for ANY use case, and 2 correct exceptional scenario Most of the steps are correct in both main and the exceptional scenarios Generally good, some of the steps are identified Somewhat good, but not very accurate Poor, not acceptable
State chart diagram(s) 2 correct diagrams, and correct notations used Mostly both diagrams are correct, but not that excellent Generally good Diagrams with errors Poor, not acceptable
Sequence diagram(s) 2 correct diagrams, and correct notations used Mostly both diagrams are correct, but not that excellent Generally good Diagrams with errors Poor, not acceptable
Activity diagram Excellent work with correct notations Good solution, but with a few mistakes Good solution, but with many mistakes Somewhat good, but not very accurate Poor, not acceptable
Class Diagram Most of the classes are identified, and their relationships are
accurate Good solution, but with few mistakes Good solution, but with many mistakes Somewhat good, but not very accurate Poor, not acceptable
Verification Correct method is selected and excellent validation Very Good validation Good validation Somewhat good, but not very accurate Poor, not acceptable
XML files Excellent work Very good work Good work Somewhat good, but not very accurate Poor, not acceptable
Reference style Use of correct referencing style, references are up to date Use of correct referencing style, but with mistakes Use of referencing style, but with mistakes Somewhat good, but not very accurate Poor, not acceptable