Assessment Details and Submission Guidelines
Unit Code BN209 Unit Title Software Engineering Assessment Type Group Assignment Assessment Title Assignment 2 Purpose of the assessment (with ULO Mapping) This assignment assesses the Unit Learning Outcomes below; students should be able to demonstrate their achievements in them: a. Determine system requirements through requirements elicitation and workshops. b. Explain the process for, and execute, verification and validation of system requirements. c. Apply use case, data and process modelling techniques to specify system requirements. d. Compare and contrast different software engineering process models: waterfall, evolutionary, spiral, prototyping. f. Explain and properly utilise various types of software tests. g. Define system specifications including technical, economical and operational feasibility. Weight 25% Total Marks 100
Word limit 30 – 35 A4 pages Due Date Week 11 Friday, 1st June 2018, (11:55 pm)
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 APA referencing style. Extension If an extension of time to submit work is required, a Special Consideration Application must be submitted directly to the School's Administration Officer, in Melbourne on Level 6 or in Sydney on Level 7. You must submit this application three working days prior to the due date of the assignment. Further information is available at: http://www.mit.edu.au/about-mit/institute-publications/policies-procedures-andguidelines/specialconsiderationdeferment Academic Misconduct
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 at: http://www.mit.edu.au/aboutmit/institute-publications/policies-procedures-and-guidelines/PlagiarismAcademic-Misconduct-Policy-Procedure. For further information, please refer to the Academic Integrity Section in your Unit Description.
Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 2 of 6
Purpose of the assessment:
The purpose of this assignment is to prepare a consolidated version of Extended SRS Analysis and Design Document for your project (i.e., the same project that you have chosen for Assignment #1).
Task
Students to finalise SRS analysis and design document that they started in Assignment 1 and present their final work in week 12 during the laboratory session.
Students submit 'Extended SRS Analysis and Design Document, which contains the following design elements (using UML notations):
1. Assignment #1 Progression: SRS document updates according to the changes in your ongoing project 2. Recommended software engineering process model for your project,
(waterfall/evolutionary/spiral/prototyping) and factors for selecting the process model 3. Select any requirement verification method, and verify the user requirements with stakeholder 4. Context Diagram for the complete overall system 5. Identify all the actors and use cases for your system 6. Fully developed use case description for any 2 use cases scenarios of your choice 7. Activity diagram for an any 2 scenarios of your choice 8. Sequence diagrams for any 2 scenarios of your choice 9. Class diagram for the complete overall system 10. Verify user requirements with stakeholder and report requirement verification process adopted for
your project 11. System Specification including technical, economical and operational feasibility 12. Software testing and acceptance criteria 13. Proposed deployment strategy 14. Final copy of the “Project Activity Journal” that shows weekly progress of team work
References and appendices
• Reference sources must be cited in the appropriate section of the document. • All cited references must be in IEEE style • List all the appendices
Team submission:
Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 3 of 6
This is a group assignment, but only one member from a group will upload the ONE ZIP FILE on MOODLE.
Submission guidelines:
The report should have a consistent, professional, and well-organised appearance.
1. Your report should include the following:
The cover page must identify students’ (name and number), teaching staff, and assignment. The assignment must use 1.5 spacing, 11-pt Calibri (Body) font with appropriate section headings.
2. The assignment must be submitted in soft (electronic) copy under Moodle. The pages of the assignment must be clear on each page.
Marking criteria:
Sections Included in the Report Marks
Assignment #1 Progression: SRS document updates according to
the changes in your ongoing project
10
Recommended software engineering process model for your
project, (waterfall/evolutionary/spiral/prototyping) and factors
for selecting the process model
10
Context Diagram for the complete overall system 5
Use Case Diagram (Entire System)
5
Fully developed use case description for any 2 use cases scenarios
of your choice
10
Activity diagram (Any 2 scenarios) 5 + 5
Sequence diagram(s) (Any 2 scenarios) 5 + 5
Design Class Diagram (Entire system) 5
User requirement verification process 5
System Specification including technical, economical and
operational feasibility
10
Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 4 of 6
Software testing and acceptance criteria 10
Final copy of the “Project Activity Journal” that shows weekly
progress of team work
10
Total 100
Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 5 of 6
Marking Rubric for SRS document:
Grade/Mark
HD 80% -100%
D 70%-79%
C 60%-69%
P 50%-59%
Fail Assignment #1 Progression: SRS document updates according to the changes in your ongoing project /10
Update all the elements and diagrams according to the change in project
Most of the elements and diagrams update according to the change in project
Some elements and diagrams update according to the change in project
No update of ambiguous changes not relating with project
Poor, not acceptable
Recommended software engineering process model for your project /10
Good analysis of different software engineering models and selection criteria for recommended model clearly outlined
Most SE models are analysed and recommendation clear
Correct, with some deficiencies
No justification/explanati on for proposed software engineering process model
Poor, not acceptable
Context Diagram for the complete overall system /5
Diagram defines the boundary between the system and its environment, the entities that interact with it. All elements present. Diagram well designed.
Diagram defines the boundary between the system and its environment, the entities that interact with it. Most elements present. Diagram well designed.
Diagram defines the boundary between the system and its environment. Some elements are missing. Diagram not properly designed.
Diagram does not clearly define the boundary between the system and its environment. Some elements are missing. Diagram not properly designed.
Poor, not acceptable
Use Case Diagram (Entire System) /5
All actors and use cases are defined accurately with proper notations
All actors and use cases are defined partly with proper notations
All actors and use cases are defined partly with wrong notations
Missing few use cases diagrams for entire system.
Poor, not acceptable
Fully develop use case description (Any 2 use cases) /10
Both use cases with all relevant elements definitions
Both use cases with partly relevant elements definitions
Both use cases with few partly relevant elements definitions
Both use cases with ambiguous relevant elements definition
Poor, not acceptable
Activity diagrams (Any 2 scenarios) /10
Both scenarios are relevant with proper defined activities definition
Both scenarios are partly relevant with defined activities definition
Both scenarios are relevant with few partly defined activities definition
Both scenarios are relevant with ambiguous defined activities definition
Poor, not acceptable
Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 6 of 6