ASSESSMENT GUIDE
ICT602 SOFTWARE ENGINEERING
Semester3, 2025
Assessment Overview
Assessment Tasks and Learning Outcome Mapping
| Assessment ID | Assessment Item | When Due | Weighting | ULO# | CLO# for MITS | CLO# for GDITS |
| 1 | Research Report(Individual) | Session 4 | 20% | 1,2 | – | – |
| 2 | Software Requirements Specification Report (Group, 1,500words) | Session 6 | 30% | 1,2 | 1,2 | 1,2 |
| 3* | Part A– Software Design Specification Report (Group) | Session 10 | 30% | 3,4, 5 | 1,2,3,4 | 1,2,3,4 |
| Part B–Test Plan(Group) | Session 11 | 10% | 3,4, 5 | 1,2,3,4 | 1,2,3,4 | |
| Part C–Presentation(Group) | Session 12 | 10% | 3,4, 5 | 1,2,3,4 | 1,2,3,4 |
Note: *denotes Hurdle Assessment Item—students must achieve at least 40% in this item to pass the unit.
Referencing Guides
You must reference all the sources of information used in your assessments .The IEEE referencing style is required for this unit.
Refer to the VIT Library’s referencing guides for more information:
VIT Library Referencing–IEEE(PDF)
Academic Misconduct
VIT enforces strict academic integrity standards. All staff and students must adhere to VIT Policies, Procedures, and Forms.
Academic misconduct includes (but is not limited to):
- Plagiarism(using others’ work without proper referencing)
- Contract cheating(outsourcing work toot hers)
- Collusion(unauthorized collaboration)
- Fabrication or falsification of data
Penalties for misconduct can include:
- Reduced or zero marks for the assessment
- Suspension or exclusion from VIT
- Disclosure of misconduct findings to professional bodies(e.g., law, education)
Late Submissions
- Late submissions without approved mitigating circumstances will incur automatic penalties as soon as the deadline is reached.
- The specific penalties are applied according to VIT Policies, Procedures, and Forms.
Short Extensions and Special Consideration
Students may apply for Special Consideration in the following cases:
- Extension of the due date for an assessment (excluding examinations).
- Consideration for completed assessments, including end-of-unit examinations.
Application requirements:
- Requests must be submitted before the start time of the assessment due date.
- Requests must be emailed in writing to the teaching team.
- Supporting documentation (e.g., medical certificates) must be attached. For further details, refer to VIT Policies, Procedures, and Forms.
Inclusive and Equitable Assessment
Reasonable adjustments will be made to accommodate students with a documented disability or impairment.
Students should contact the unit teaching team for further information.
Contract Cheating Warning
Contract cheating includes purchasing or outsourcing assignments or examinations to another party. Risks and consequences:
- Reduced learning and poor preparation for employment.
- Being found guilty of academic misconduct.
- Assignments may be recycled by cheating services →detected by Turn it in.
- Penalties includes us pension and exclusion.
- Risk of personal and financial data theft.
- Exposure to black mail due to fraudulent behavior.
Grading Scheme
Your final grade will be determined according to the following scale: Grade Percentage
A 80%–100%
B 70%–79%
C 60%–69%
D 50%–59%
F 0%–49%
Assessment 1
Assessment Task: Research Report on Contemporary Software Development Practices Weighting: 20%of total unit marks
Due Date: Session4
Submission : Submit electronically via Moodle using the submission link provided under Assessments before the deadline.
Task Description
This is an individual written assessment where you are required to research and critically analyse
Contemporary software development practices used in the gaming software industry today . The
Purpose of this task is to demonstrate our understanding of software engineering concepts, apply them to real-world scenarios, and support our discussion with credible references.
You are required to choose ONE of the following for your report:
- A Software Development Model (e.g., Waterfall, Spiral, Incremental, Agile, Dev Ops).
- Provide a detailed explanation of the chosen model.
- Present a real-world successful case study where the model was applied.
- Present a real-world failed case study where the model was applied.
- Critically discuss the strengths, weaknesses , and possible improvements to the model.
Report Requirements
- Length: Approximately 1,500–2,000words.
- References: At least 5 credible academic or industry sources(APA or IEEE referencing style).
- Structure:
- Introduction
- Explanation of the chosen model/phase
- Case studies(success and failure)
- Critical discussion and analysis
- Conclusion
- Reference list
Important Information
- Late submission penalty: 20% of available marks per day, including weekends.
- Extensions: Only considered under exceptional circumstances in line with VIT policy.
- Academic integrity: Work must been tirely your own. All sources of information must be cited appropriately. Plagiarism or collusion will result in disciplinary action.
Marking Rubric is on the next page.
Marking Rubric (20 Marks Total)
| Criteria | A80–100% | B70–7G% | C60%-6G% | D50–5G% | F0–4G% |
Understanding of Concept(5marks) | Demonstrates exceptional understanding of the chosen model/phase with comprehensive detail and clarity. | Strong Understanding with min or gaps in explanation. | Adequate understanding, some are as lacking depth. | Basic understanding, Limited detail, some inaccuracies. | Very poor or no understanding shown. |
Case Studies(5 marks) | Provides two highly relevant, well- explained real-world examples with strong evidence and analysis. | Provides relevant Examples with good explanation and Some analysis. | Provides examples With basic explanation, limited analysis. | Provides weak or only Partially relevant examples, little analysis. | No real-world Examples provided or irrelevant cases. |
Critical Discussion (5marks) | Excellent critical Analysis of strengths, weaknesses ,and improvements ,with strong original insights. | Good critical analysis, with some insightful points. | Some critical discussion, mostly descriptive with limited in sight. | Mostly descriptive with Minimal critical thinking. | No critical discussion, purely descriptive or off- topic. |
| Research and Referencing (3 marks) | Uses5+ credible academic/industry references, cited Correctly and consistently. | Uses4–5references, mostly credible, with min or citation errors. | Uses3–4 references, mixed credibility, referencing inconsistent. | Usesfewerthan3 references, limited credibility, poor referencing. | No references, or all sources are unreliable/ unacknow ledged. |
| Presentation and Structure (2 marks) | Report is Exceptionally well- organized ,clear, professional ,and error-free. | Well-organised and clear, with only minor errors. | Adequate structure, some language/formattig issues. | Poorly structured, frequent errors, unclear presentation. | Very poor Organization , difficult to follow, numerous errors. |
Total:20marks(20%)
Assessment 2
This assignment will be completed in groups.
Marks: 30% of your total marks / grades.
Due Date: Session 6
Submission: There port of not exceeding 1500 words must be submitted in the Word format through the Moodle submission link for Assignment 2.Wesh all check you report for plagiaryism or similarity through Turn it in. No DRAFT submissions will be marked.
Lateness: A late penalty of 20% per day after the due date, including weekends, applies.
Authorship: This assignment is a group assignment; students are required to form a group of 4 for this assessment. The final submission must be identifiable as the group’s own work. Breaches of this
Requirement will result in the assignment not being accepted for assessment and may result in disciplinary action. Refer to the Academic Integrity Section below for more details.
Extensions: No extensions will be given in normal circumstances .An extension may be granted in special circumstances as per the VIT policy.
Student Statement: A completed electronic student statement is required to be accepted with the submission. It is created automatically when you upload or confirm your submission via the Moodle submission system.
ACADEMICINTEGRITY and PLAGIARISM (STANDARDWARNING)
Academic integrity is about the honest presentation of your academic work. It means acknowledging the work of others while developing your own insights, knowledge, and ideas.
You must:
- Acknowledge words, data, diagrams, models, frameworks and/or ideas of others you have quoted, summarized , paraphrased, discussed, or mentioned in your assessment through proper referencing.
- Provide a reference list of public at ion details soy our reader can locate the source. This includes material from Internet sites.
Failure to do so may result in accusations of plagiarism, as you would be passing off someone else’s work or ideas as your own.
INSTRUCTIONS
In this assessment, students will work in groups to submit a software specification document. The document must contain the following sections:
- Title Page
- Table of Contents
- Introduction
- System Overview
- Requirement Specifications
- Functional Requirements
- Non-functional Requirements
- Others
- User Interfaces
- System Interfaces
- Assumptions/Constraints
- References
- Contributions/Work Break down Agreement(WBA) The Work plan section must include:
- Student Name
- Contribution Description
- Percentage of Contribution
- Signed statement of acceptance
Case Study : Smart Healthcare Appointments Management System(SHAMS)
You and your team have been tasked with developing a Smart Healthcare Appointments Management System (SHAMS) designed for hospitals, clinics, and medical practices. The system must cater to patients, doctors, nurses, and administrators, offering a seamless healthcare experience.
Key functionalities include:
- Patient-facing features: Online appointment booking, prescription tracking, medical history access, and telemedicine integration.
- Doctor/Nurse tools: Digital consultation notes, e-prescriptions, patient health analytics, and scheduling dashboards.
- Administrator tools: Resource allocation, staff scheduling, billing and pay ment integration, and compliance reporting.
The system should provide:
- Functional requirements: Appointment booking, reminders, video consultations, patient record management.
- Non-functional requirements: High security for sensitive health data, fast response times, scalability for large hospital networks, and reliability during emergencies.
Additionally, the system must integrate with existing Electronic Health Record (EHR) systems, payment gateways, and third-party apps (e.g., Medicare, MyGov, health insurance portals).
The interface should be user-friendly, multilingual , and optimized for both desktop and mobile platforms to ensure accessibility for diverse patients and healthcare workers.
MARKINGSCHEME/GUIDE
This assessment contributes 30% to the final grade.
Report Layout and Formatting (10marks)
- Correct report layout (title page, TOC, required sections ,unit code/name, student IDs):4marks
- VIT logo included: 1mark
- Proper formatting, professional presentation: 5marks Report Content (70marks)
- Clear introduction: 5marks
- System overview and explanation of chosen development life cycle with justification: 10marks
- Requirement specifications(functional, non-functional, others):25marks
- Assumptions/constraints are appropriate and justified:10marks
- Software analysis C modelling with use case diagrams(correct syntax and semantics):20 marks Grammar(5marks)
- Correct spelling, punctuation, and grammar: 5 marks Word Limit (5marks)
- Within 1500 words: 5marks
References (10marks)
- References valid, reliable, from credible sources:5 marks
- Correct referencing format (IEEE): 5 marks
Total:100 marks(30%offinalgrade)
Assignment 2– Marking Rubric
Case Study: Smart Healthcare Appointment C Management System (SHAMS)
Weighting: 30% off in al grade
| Criteria | HD(High Distinction)80– 100% | D (Distinction) 70–7G% | C(Credit)60–6G% | P(Pass)50–5G% | F(Fail)0–4G% | Mark s |
| Report Layouts Formatting (10marks) | Report follows all formatting Requirements (title page, TOC, headings, IDs, VIT logo),professional layout, excellent Readability . | Minor formatting errors, mostly Professional, clear layout. | Formatting adequate, some errors in structure or presentation. | Basic layout present but multiple missing Elements or poor readability. | Incorrect layout, missing several key sections, Poor readability. | /10 |
| Introduction (5marks) | Clear, concise, and well-structured introduction with excellent on text And purpose. | Clear introduction with good context and purpose. | Adequate introduction, some clarity issues. | Weak introduction, lacks clear purpose or context. | Missing or irrelevant introduction. | /5 |
System Overviews SDLC Justification (10marks) | Excellent explanation of system purpose, scope, and chosen SDLC with strong justification. | Clear explanation with good justification of SDLC. | Adequate explanation of System and SDLC, some gaps in justification. | Basic overview with limited SDLC discussion. | Missing or unclear system overview, no SDLC justification. | /10 |
Requirement Specification s(Functional, Non- functional, Others)(25 marks) | Comprehensive, detailed, well- structured requirements; functional C non- functional c leZarly distinguished and relevant. | Clear and mostly complete requirements ;good distinction between categories. | Adequate Requirements ; some overlap or missing details. | Limited requirements; weak structure or relevance. | Missing, vague, or Incorrect requirements. | /25 |
Assumptions /Constraints (10marks) | Clear, logical, and realistic Assumptions and constraints fully justified. | Mostly clear and justified assumptions and constraints. | Adequate but with minor Inconsistencies . | Weak assumptions/ constraint s, limited justification. | Missing or irrelevant assumptions/constraint s. | /10 |
| Use Case Diagram(20 marks) | Diagram complete, correct, well labeled , Syntactically C semantically Accurate . | Diagram mostly correct with Minor errors. | Adequate diagram with some missing elements or clarity issues. | Weak diagram, significant errors or unclear. | No use case diagram or entirely incorrect. | /20 |
Grammars Writing Quality(5 marks) | Writing is fluent, well-structured ,free of Grammatical /spelling errors. | Writing is clear, minor errors present. | Adequate writing, some grammar/spelling issues. | Weak writing with Frequent errors affecting readability. | Poor writing with pervasive errors, unreadable. | /5 |
Word Limit(5 marks) | Within 1500 words, Concise and focused. | Slightly Exceeds word limit but still focused. | Noticeably Over /under word limit, affects clarity. | Major issues with word limit, impacts report quality. | Not with in required word Range . | /5 |
| References (10marks) | References are extensive ,from credible sources, perfectly in IEEE Format . | Good quality references, min or IEEE formatting errors. | Adequate references, some formatting/ reliability issues. | Limited references, weak formatting. | No references or inappropriate sources. | /10 |
| Total | /100 |
Assignment 3
System Design, Testing s Presentation Project
Team task—approx. 4– 5students per group Total marks: 50% of unit grade
- Part A—Design C Implementation: 30%
- Part B—Testing C Quality Assurance:10%
- Part C—Presentation C Demonstration:10%
Group submissions: report (s), source code repository link, and recorded video demonstration(one submission per group).
Due dates:
- Part A (Design C Implementation report+ code repo): Session 10
- Part B (Test plan + test evidence): Session 11
- Part C (Video presentation): Session 12
Late penalty: 20% per day after deadline (including weekends).Extensions only per institute policy and must be approved in advance.
Project brief (overview)
Your team will extend the case study used in Assignment 2 to design, build and test a fashione -retail platform (the same domain as Assignment 2 but with updated/extended requirements).The aim is to
Demonstrate sound object- oriented design, a suitable architectural pattern ,a working complex module implemented in Java, and a professional test plan and demonstration.
You must:
- Produce a conceptual class diagram for the entire system (Part A).
- Justify and apply an architectural pattern that suits an e-retail platform (Part A).
- Implement at least one complex module in Java—e.g., order processing with payment
Orchestrate on, product recommendation engine , inventory reservation with concurrency control, or user authentication + role management. Confirm your chosen complex module within the team and document it in the report.
- Provide clear instructions so markers can run your code locally (READ ME+ run script).
- Produce a comprehensive test plan and evidence of testing(Part B).
- Submit a single video where the entire group appears, introduces contributions and demonstrates the working module (Part C).
Note: AGUI is optional. A well –designed command-line app or API is acceptable if it clearly shows required functionality.
Part A — Software Design s Implementation (30%) Deliverables (submit together):
- Design report(max2,000words) containing:
- Updated functional/non-functional requirements (brief)—show any changes from Assignment 2.
A conceptual class diagram for the whole system(UML)showing classes and
Relationships. Attributes / methods optional but include methods where demonstrating inheritance, polymorphism, or design patterns.
- Discussion of chosen architectural pattern (one pattern per team)and why it fits the system (see guidance below).
- Design rationale: show how OOP principles and relevant design patterns are applied.
- Description of the complex module your team implemented and how it maps to the class diagram.
- Source code repository(public c or shared private link) containing:
- Java implementation of the complex module(and any supporting code).
- AREADME with clear run/ deploy instructions (OS, Java version ,build /run commands). Include sample data and steps the marker should follow.
- Short developer guide showing where in the code the main classes from the diagram are implemented.
Architecture guidance(chooses apply one)
Select an appropriate architecture and justify it. Possible choices(but not limited to):
- Layered/N-Tier (Presentation, Business, Data)—common fore-retail systems.
- Model–View–Controller(MVC)—if building a UI or web interface.
- Micro services (small, focused services + API gateway) — justify if you partition system into independent services.
- Event-driven/CQRS—if modeling complex order or inventory flows.
In your report, state which pattern you selected and why(scalability, separation of concerns, testability, complexity trade- offs).
Part B—Software Testing Report (10%)
Create a test plan and provide evidence of tests.
Required test plan sections (minimum)
- Objective : What testing aims to achieve for the module/ system.
- Scope: What is in/out of scope for testing (functional areas ,non-functional aspects).
- Test Types: Unit tests, integration tests, system tests, acceptance tests, performance/security tests — state which you applied.
- Test Environment: Hardware, OS, Java version , libraries, test data, any test harness or CI.
- Test Schedule: When tests were/will be executed (summary timeline).
- Roles and Responsibilities: Who in the team handled which tests.
- Test Deliverables: Test cases, test reports, coverage reports, result logs.
- Risks Mitigation: Key testing risks and how your educed them.
Evidence to submit
- At able of representative test cases (input, expected output, pass/fail).
- Executable unit test reports (J Unit or similar) and at least several integration test results.
- A short summary of test coverage (e.g., percentage), and screenshots/logs showing tests passing.
- If you’re an any performance or concurrency tests for the module, include their summary.
Important: simply showing the final correct output is not enough. Your test plan musts how test selection and justification.
Part C—Presentations Demonstration (10%) Video requirements:
- Length: ≤10minutes.
- All team members must appear on camera and introduce themselves and their contributions (camera on).
- Show the design→ code→ running system flow:
- Briefly show the class diagram and point to where those construct sexist in the code.
- Demonstrate the working complex module (run sample scenarios).
- Discuss testing highlights and any limitations.
- Include a short reflection on team collaboration and the Work Breakdown Agreement.
Work Breakdown Agreement (WBA)
Include a one-page WBA listing:
- Student name
- Contribution description
- Percentage contribution(approx.)
- Signature line(type d name is fine)and date
Markers will consider the WBA when adjusting individual marks.
Marking Rubric (detailed)
Below is the rubric used for marking .Total=100 marks (converted to 50%unit weighting per the distribution above).
Part A—Designs Implementation (Total 60 marks; maps to 30%unit grade)
- Conceptual Class Diagram(30 marks)
- Classes well chosen(6)
- Important domain concepts modeled (6)
- Only in-scope elements included ;out-of-scope excluded(4)
- Associations, multiplicities and dependencies shown correctly(6)
- Appropriate use of in heritance, aggregation/composition and design patterns where applicable(5)
- Syntax, readability and labeling (3)
Architectures Justification (10 marks)
- Appropriate architectural pattern selection and justification(6)
- Clear mapping of architecture to design/code(4)
Implementations Code Quality (20marks)
- Code matches design and diagram(6)
- Functionality completeness of the complex module(8)
- Coding standards :meaningful identifiers, comments, layout, README and run instructions (6)
Part B—Testing (Total 20 marks; maps to 10%unit grade)
- Test Plan Quality (10marks)
- Clear objectives, scope, test types and environment described(4)
- Roles, deliverables, schedule and risk mitigation(3)
- Test cases well-chosen and traceable to requirements(3)
Test Evidences Results (10marks)
- Unit/integration test reports and logs provided(4)
- Test coverage and interpretation(3)
- Performance/concurrency/security test evidence if applicable(3)
Part C—Presentations Demonstration (Total 20 marks ; maps to 10% unit grade)
- Group Presentations Participation(6marks)
- All members introduce themselves and clearly state contributions(3)
- Professional presentation style and team work evidence(3)
Design→ Code →Run Mapping (8marks)
- Clear demonstration of where design maps to code (4)
- Demonstrated running module and functionality (4)
Testing And Reflection (6marks)
- Demonstrated key test out comes and issues discovered (3)
- Reflection on what was learned and limitations (3)
Submission check list(what to upload/provide)
- Part A report (PDF) including class diagram and architecture justification.
- Link to source code repository (READ ME, run instructions included).
- Part B test plan document (PDF) + test evidence (logs/reports/screenshots).
- Part C video file or private link (≤10minutes).
- Work Break down Agreement (WBA).
- Student statement via Moodle (auto-generated on upload).
Additional assessment notes tips
- Use UML tools (e.g., draw.io, Star UML) for crisp diagrams. Include one image file of the class diagram embedded in the report.
- Keep the design report focused—clarity beats length.1,500 –2,000 words is appropriate.
For the complex module, choose something with clear behavior and testable scenarios (order processing, inventory locking under concurrency, secure log in and role checks, or a
Recommendation algorithm are good examples).
- Use Git and include meaningful commit history—this helps demonstrate contribution and development process.
- Markers will run your code— supply any sample data sets, credentials, or scripts the marker needs.
- Academic integrity rules apply—reference any external code/ libraries and do not plagiarise.
Assignment 3 Rubric—System Design, Testing Presentation
| Criteria | A(85–100%) | B(75–84%) | C(65–74%) | D(50–64%) | F(0–4G%) | Marks |
Part A1: Conceptual Class Diagram (30marks) | Comprehensive and accurate Class diagram. All major Domain concepts modelled; correct associations, inheritance, composition / aggregation. Fully aligned with requirements . Clear, neat, and professional. | Strong class Diagram with most relevant domain concepts and correct use of OO principles. Few minor errors/ omissions. | Adequate class Diagram covering most concepts. Some Missing / incorrect associations or limited application of OO principles. | Basic class diagram, but lacks coverage of several concepts, associations unclear, OO principles weakly applied. | Incomplete or Incorrect diagram, little/no use of OO Principles , unreadable or irrelevant. | /30 |
PartA2: Architectures Justification(10 marks) | Architectural pattern highly suitable, clearly justified, directly maps to system design and code. | Appropriate pattern chosen, Justification mostly clear, mapping to system/code is evident. | Reasonable pattern chosen, justification somewhat vague, partial mapping to design/code. | Weak Justification for chosen pattern, limited connection to design/code. | No clear architectural pattern, justification absent/incorrect. | /10 |
PartA3: Implementation and Code Quality (20marks) | Code fully implements Complex module and aligns with design. High coding standards: clear structure, meaningful names, comments, and excellent readability. Instructions Complete and easy to follow. | Code mostly implements module as per design. Good coding standards, min or issues. Instructions mostly clear. | Code partly implements module; moderate alignment with design. Acceptable coding standards, some unclear areas. | Minimal functionality, weak alignment with design. Poor readability or missing instructions. | No working code, or Plagiarized / unrelated implementation. | /20 |
Part B: Software Testing(20 marks) | Test plan comprehensive, structured, covers objectives, scope, environment, types, schedule, risks .Extensive test cases with evidence (logs, reports, screenshots).Test coverage strong. | Test plan complete With most sections. Good set of test Cases and evidence provided. Coverage adequate. | Test plan partially complete, some missing sections. Limited test cases/ evidence. Coverage weak in areas. | Minimal test plan With major Omissions. Few test cases, little evidence. Coverage unclear. | No test plan or test Evidence provided. | /20 |
Part C1: Group Presentations | All members participate equally, clear contribution | All members present, contributions | Most members present, contributions partly | Some members Missing or unclear | Very poor or absent presentation; | /6 |
Participation (6 marks) | Descriptions , professional And engaging delivery. | Mostly clear, good delivery. | clear, adequate delivery. | contributions, weak delivery. | Contributions not Acknowledged . | |
Part C2 :Design→ Code → Run Demonstration (8marks) | Clear and logical Demonstration connecting design→ code→ working system. Functionality show cased smoothly and convincingly. | Good Demonstration of design→ code→ system, mostly clear with minor gaps. | Partial Demonstration , design-to-code mapping somewhat vague. Functionality shown but limited. | Weak demonstration, unclear mapping of design to code, minimal functionality shown. | No demonstration of System or mapping. | /8 |
Part C3:Testing And Reflection(6 marks) | Strong demonstration of test Outcomes and thoughtful Reflection on limitations and learning. | Good Demonstration of Test outcomes, some reflection. | Adequate Demonstration of Test outcomes, limited reflection. | Minimal test outcomes shown, very weak reflection. | No testing shown, no Reflection. | /6 |
Mark Distribution
- Part A (Designs Implementation): 60 marks(→30%)
- Part B (Testing):20 marks(→10%)
- Part C (Presentation):20 marks(→10%)
- Total:100 marks (scaled to 50% of overall unit grade)