This assignment assesses the Unit

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% (20 Marks Report and 5 Marks Presentation) Total Marks 100 Word limit 30 35 A4 pages Due Date Week 11 Sunday, 30th September 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 IEEE referencing style. Extension If an extension of time to submit work is required, a Special Consideration Application must be submitted directly to the Schools 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-and guidelines/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/about-mit/institute publications/policies-procedures-and-guidelines/Plagiarism-Academic-Misconduct Policy-Procedure. For further information, please refer to the Academic Integrity Section in your Unit Description. Prepared by: Samira Baho Moderated by: DR Sihui (Sue) Zhou July, 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: This is a group assignment, but only one member from a group will upload the ONE ZIP FILE on MOODLE. Prepared by: Samira Baho Moderated by: DR Sihui (Sue) Zhou July, 2018 Page 3 of 6 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# and project title. 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 Software testing and acceptance criteria 10 Final copy of the Project Activity Journal that shows weekly progress of team work 10 Prepared by: Samira Baho Moderated by: DR Sihui (Sue) Zhou July, 2018 Page 4 of 6 Report logical structure, grammar and spelling 5 Reference IEEE Style 5 Total 100 Prepared by: Samira Baho Moderated by: DR Sihui (Sue) Zhou July, 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 <50 Excellent Very Good Good Satisfactory Unsatisfactory 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 Sihui (Sue) Zhou July, 2018 Page 6 of 6 Sequence diagram(s) (Any 2 scenarios) /10 Both scenarios are relevant with proper defined sequence definition Both scenarios are partly relevant with proper defined sequence definition Both scenarios are partly relevant with few partial defined sequence definition Both scenarios are partly relevant with ambiguous defined sequence definition Poor, not acceptable Class diagram (Entire system) /5 All classes are defined accurately with proper relationship notations All classes are defined partly with proper relationship notations All classes are defined partly with wrong relationship notations All classes are defined ambiguously with wrong notations Poor, not acceptable User Requirement Verification /5 Requirement validation technique followed; well explained and customer involvement and approval documented. Requirement validation technique followed; clear and customer involvement mentioned Requirement validation technique followed clear but customer involvement and approval not documented Requirement validation technique followed clear, with some obvious shortcomings. Poor, not acceptable Software testing and acceptance criteria /10 Well defined and planned software testing and acceptance criteria clear Software testing and acceptance criteria clear Correct, with some deficiencies Software testing criteria partly correct, with some obvious shortcomings. Poor, not acceptable Project Activity Journal /10 Developed accurately with all group members participation Developed partly with all group members participati on Developed partly with some group members participation Developed ambiguously Poor, not acceptable Report Layout and presentation /5 Writing demonstrates a sophisticated clarity, conciseness, and correctness; includes thorough details and relevant data and information; extremely well organized Writing is accomplished in terms of clarity and conciseness and contains only a few errors; includes sufficient details and relevant data and information; well-organized Writing lacks clarity or conciseness and contains numerous errors; gives insufficient detail and relevant data and information; lacks organization Writing is unfocused, rambling, or contains serious errors; lacks detail and relevant data and information; poorly organized Report unfocused, contains grammatical and spelling errors. Very hard to understand. Reference /5 Uses IEEE guidelines accurately and consistently to cite sources Uses IEEE guidelines with minor violations to cite sources Reflects incomplete knowledge of IEEE guidelines Does not use IEEE guidelines No Reference

Pssst…We can write an original essay just for you.

Any essay type. Any subject. We will even overcome a 6 hour deadline.

<< SAVE15 >>

Place your first order with code to get 15% discount right away!

Impressive sample results