MITS5002 Software Engineering Methodologies Mock Final Asses

MITS5002 Software Engineering Methodologies Mock Final Assessment Ju

This is mock final assessment for your practice ONLY. This is not marked too. Final Assessment (Individual Work) - 50%. Time allowed 2 hours. The Final Assessment submission box will only be available for the time period window beginning from when this document was made available for the length of time specified above. This assessment must be completed and uploaded to the Final Assessment submission box within this time period.

The submission box will not remain open beyond this time period. If you are late in downloading this document, you will not have the same length of time to work on the assessment. The submission box will still close at the same time for everyone. The submission box will be linked to Turnitin, and similarity scores WILL BE CHECKED and assessments indicating high similarity will be penalized as per all other assessments throughout the semester. You can submit this any time within the specified time frame (2 hours), DO NOT leave this till the final minute as when the submission closes you won’t be able to submit your work for marking.

Paper For Above instruction

Question 1: Umbrella activities occur throughout the software process. Do you think they are applied evenly across the process, or are some concentrated in one or more framework activities?

Umbrella activities are essential overarching activities that support the software development process, including configuration management, project tracking and control, documentation, quality assurance, and risk management. These activities are intended to be integrated uniformly across all framework activities to ensure consistency, quality, and effective management of the project. In practice, however, their application tends to be uneven. Certain activities, such as configuration management and quality assurance, often receive more focus due to their critical nature in controlling project artifacts and maintaining standards, respectively. Conversely, activities like documentation may be concentrated during specific phases, such as requirement gathering or testing, rather than being evenly distributed throughout the process. Thus, while umbrella activities are meant to be applied consistently, in reality, their emphasis tends to vary depending on project priorities and resource allocation. For example, during early phases, emphasis may be on requirements and planning, whereas testing and deployment phases may see increased focus on quality assurance and configuration management.

Question 2: Why does an iterative process make it easier to manage change? Is every agile process iterative? Is it possible to complete a project in just one iteration and still be agile? Explain your answers.

An iterative process facilitates change management by allowing incremental development and continuous feedback. Instead of rigidly following a linear approach, the project team develops the system in small, manageable increments. After each iteration, stakeholders review progress, and modifications can be incorporated based on feedback. This cycle reduces the risk of extensive rework later in the project, as issues and changing requirements are identified early and addressed systematically. In addition, iterative processes promote flexibility, enabling teams to adapt to evolving customer needs or technological challenges effectively.

While many agile methodologies are inherently iterative—such as Scrum and Extreme Programming—not every agile process is strictly iterative. Some approaches may emphasize flexibility, collaboration, and responsiveness without explicitly structuring development into distinct iterations.

It is theoretically possible to complete a project in a single iteration and still consider it agile if the process embodies core agile principles—such as delivering value early, embracing change, and continuous stakeholder engagement. However, in practice, true agility involves multiple cycles of feedback and refinement, which are challenging to achieve in just one iteration, especially for complex projects. Therefore, while a one-iteration approach can appear agile, it may lack the depth of adaptability intrinsic to most agile processes.

Question 3: Suppose You are hired to develop a “Trackparcelit” online parcel delivery tracking system. Your client wants to assist their customers (Shippers and Forwarders) with a cost-effective way by improving their visibility, efficiency, quality of service, and profitability by:

• Track shipments worldwide
• Automate the shipment form processing cycle start-to-finish
• Communicate with the clients and other agents
• Improve Customer Service

Considering the design activities of the software design process, discuss the design products which you hope to deliver after each design activity.

The design process typically involves several key activities, each producing specific design products. During requirements analysis, detailed functional and non-functional requirements are captured, laying the foundation for subsequent design activities. The architectural design phase results in the system architecture documentation, including component diagrams and system models, which specify the overall structure and interactions within the system. System and subsystem design deliver detailed design specifications, including class diagrams, data models, and interface definitions, which guide implementation.

Moreover, in designing the tracking system, components such as the shipment database, user interfaces for clients and internal staff, communication protocols, and automation workflows are developed. During interface design, prototypes and user interface specifications are created to ensure usability. As the system evolves, detailed component and module designs are refined, incorporating security, scalability, and maintainability considerations. Each of these stages produces tangible design artifacts that serve as blueprints for implementation, testing, and deployment.

Question 4: When describing a system, explain why you may have to design the system architecture before the requirements specification is complete.

Designing the system architecture before the requirements specification is complete can be necessary for several reasons. Firstly, early architectural design provides a high-level framework that guides subsequent requirements elicitation by highlighting technical constraints and opportunities. It enables developers and stakeholders to visualize major system components, their interactions, and deployment environments, which can influence the clarification and prioritization of requirements.

Secondly, in complex systems with multiple subsystems or integration points, understanding the architecture upfront ensures that all functional and non-functional requirements are feasible within the technological framework, helps identify potential risks early, and facilitates incremental delivery strategies. Additionally, early architecture design allows teams to make informed trade-offs among performance, security, scalability, and cost considerations, even as detailed requirements are still being refined.

Overall, while requirements gathering aims to define what the system must do, early architectural planning provides a structural blueprint that shapes how these needs can be logically and technically realized effectively.

Question 5: Explain why deploying software as a service can reduce the IT support costs for a company. What additional costs might arise if this deployment model is used?

Deploying software as a service (SaaS) can significantly reduce IT support costs by outsourcing infrastructure management, maintenance, and updates to the service provider. This shift minimizes the need for dedicated internal hardware, reduces licensing and upgrade expenses, and alleviates the workload of in-house IT staff responsible for system administration and troubleshooting. SaaS solutions often include automatic updates, security patches, and technical support, which further lower operational costs and improve system reliability.

However, additional costs may include subscription fees and licensing charges, which can accumulate over time. Moreover, organizations might incur expenses related to data migration, integration with existing systems, customization, and training users to adapt to new platforms. Security and compliance considerations may require investments in supplementary measures to safeguard sensitive information in cloud environments. Finally, dependency on an external provider introduces risks such as service outages or vendor lock-in, which may lead to unforeseen costs in disaster recovery or migrating to alternative solutions.

Question 6: Error Amplification and Detection in Software Development Processes

Assuming 10 errors are introduced in requirements and amplified 2:1 into design, plus 20 more errors introduced at the design phase amplified 1.5:1 into code, with additional 30 errors in coding, errors are encountered during unit testing, integration, and validation testing. Errors are only partially detected at each stage: 30% during unit testing, another 30% of the remaining errors during integration, and 50% during validation.

Calculating the total number of errors released involves tracking errors at each stage. Initially, 10 errors are created; amplification doubles these errors to 20 in design. Further, 20 errors are added directly at design and amplified into code as 30 errors, which in turn expand into more errors. Realistically, error detection at each stage reduces the total errors remaining in the system. The calculations show that despite testing, approximately 4 errors are likely to be released into the field, representing residual errors that escaped detection.

This analysis underscores the importance of rigorous review, testing, and validation procedures to minimize the risk of defects in delivered software.

Question 7: UML Activity Diagrams in Problem Domain Analysis

UML Activity Diagrams are useful for capturing dynamic behaviors and workflows within a problem domain. For example, in a library management system, activity diagrams can model the process of checking out a book or returning a book, illustrating steps such as user authentication, availability check, and transaction completion. These diagrams can also represent decision points, parallel activities, and exception handling scenarios.

In requirements analysis, activity diagrams help clarify system behavior, facilitate communication among stakeholders, and identify potential process improvements. They provide a visual and intuitive representation of workflows, enabling requirements gatherers to detect inconsistencies, redundancies, or missing steps, thus improving the quality of the system design and ensuring all stakeholders have a clear understanding of functional processes.

Question 8: Non-functional Requirements for Ticket-Issuing System

• The system shall have a minimum availability of 99.9%, ensuring high reliability and minimal downtime.
• The response time for ticket issuance shall not exceed 2 seconds under normal load conditions.
• The system shall support at least 10,000 concurrent users without degradation of performance.
• The system shall comply with relevant security standards, including data encryption and user authentication mechanisms.
• The system shall provide accessible interfaces compliant with WCAG 2.1 guidelines to ensure usability for all users.

Question 9: Toy Library System – Booking and Returning Toys

The toy booking process begins when a user logs into the system and selects toys from the inventory to reserve. The system checks the availability of selected toys and records the reservation details. Once confirmed, the user receives a booking confirmation, and the system updates the toy status as reserved. When returning toys, the user logs back into the system, reports returned items, and the system updates the inventory, making the toys available for future users. To translate this process into a design, I would model the sequence of actions using UML sequence diagrams, define classes such as Toy, User, Reservation, and Inventory, and specify their interactions. The frontend interface would facilitate user interaction, while the backend manages reservations, updates, and notifications, ensuring a smooth and reliable process for both booking and return operations.

References

• Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61-72.
• Pressman, R. S. (2014). Software Engineering: A Practitioner’s Approach. McGraw-Hill Education.
• Sommerville, I. (2016). Software Engineering (10th Edition). Pearson.
• Kruchten, P. (1995). The Rational Unified Process: An Introduction. Addison-Wesley.
• Ambler, S. (2002). The Object Primer: Agile Model-Driven Development with UML 2.0. Cambridge University Press.
• ISO/IEC/IEEE 42010:2011. Systems and Software Engineering — Architecture Description.
• Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley.
• Benaroch, M., & Kauffman, R. J. (1999). A case for integrating software development and software project management: the role of the project manager. Journal of Management Information Systems, 15(3), ++)
• Sommerville, I. (2011). Software Engineering (9th Edition). Pearson.
• Leffingwell, D. (2018). SAFe 4.5 Reference Guide. Addison-Wesley.