Software Engineering 2022

Section II (Short Answer)

Q.2. (i) Differentiate between Aggregation and Composition. Both are types of association in Object-Oriented design, but they differ in the strength of their relationship.

• Aggregation: This is a weak, "has-a" relationship where the child object can exist independently of the parent object. For example, a Department has Teachers. If the Department is destroyed, the Teachers still exist.
• Composition: This is a strong, "part-of" relationship where the child object relies entirely on the parent. They have a coincident lifetime. For example, a House is composed of Rooms. If the House is destroyed, the Rooms are also destroyed.

Q.2. (ii) What are the Drawbacks of waterfall model? The Waterfall Model is highly rigid, requiring one phase to finish completely before the next begins. Its main drawbacks include:

• Inflexibility: It is incredibly difficult and costly to accommodate changing customer requirements once the testing or coding phase has started.
• Late Testing: Testing only happens at the very end of the lifecycle, meaning major architectural flaws might not be discovered until it's too late.
• Delayed Delivery: The customer does not see a working version of the software until the very end of the project.

Q.2. (iii) Differentiate between integration and unit testing?

• Unit Testing: Performed by developers, this tests individual, isolated components or modules of code (like a single function or class) to ensure they work correctly on their own. It is typically a form of White-Box testing.
• Integration Testing: Performed after unit testing, this tests how those individual modules work together. It focuses on data flow, communication across interfaces, and ensuring that combined modules function as a unified system without crashing.

Q.2. (iv) What is Reverse Engineering in software maintenance? Reverse engineering is the process of analyzing an existing software system to understand its components, their relationships, and its underlying architecture. Developers take the compiled code or source code and work "backwards" to extract design diagrams, database structures, or requirements. This is heavily used in software maintenance to understand poorly documented legacy code before attempting to update or refactor it.

Q.2. (v) What are the elements of software state machine diagrams? State machine diagrams illustrate the dynamic behavior of a system based on its internal states. The key elements are:

• States: Represented by rounded rectangles (e.g., Idle, Processing).
• Transitions: Represented by solid arrows showing the movement from one state to another.
• Events/Triggers: The labels on the arrows that cause a transition to happen (e.g., buttonClicked).
• Initial State: Represented by a solid black circle indicating where the system begins.
• Final State: Represented by a solid black circle inside a hollow circle (a bullseye) indicating termination.

Q.2. (vi) Define the 4P's for software project management? The 4P's form the foundation of effective software project management:

1. People: The most critical factor; refers to recruiting, organizing, and managing a skilled development team.
2. Product: Defining the exact scope, objectives, and requirements of the software to be built.
3. Process: The framework or methodology chosen to develop the software (e.g., Agile, Waterfall).
4. Project: The daily administration, task scheduling, risk management, and monitoring required to deliver the product using the defined process.

Q.2. (vii) Why is primary goal of software development now shifting from producing good quality software to good quality maintainable software? Software typically spends 80% of its lifespan in the maintenance phase, not the initial development phase. Because business environments, user needs, and operating systems evolve rapidly, software must be constantly updated. If software is high-quality but hard to maintain (e.g., spaghetti code, no documentation), adding new features or fixing bugs becomes dangerously expensive and risks breaking the entire system. Therefore, maintainability is critical for long-term viability.

Q.2. (viii) Define the following terms: Inheritance and Polymorphism.

• Inheritance: An object-oriented concept where a new class (child) derives the attributes and methods of an existing class (parent). It promotes immense code reusability.
• Polymorphism: Meaning "many forms," this is the ability of different objects to respond to the exact same method call in their own unique way. For example, a draw() method will act differently if called on a Circle object versus a Square object.

---

Section III (Essay Type)

Q.3: Explain the spiral model of software development. What are the limitations of such a model?

The Spiral Model Explained The Spiral Model, created by Barry Boehm, is a highly risk-driven software development process. It combines the structured, systematic aspects of the Waterfall model with the iterative nature of prototyping. The project is visualized as a spiral, where each loop represents a phase of the development process.

Each loop in the spiral consists of four main sectors:

1. Objective Setting: Identifying the goals, alternative solutions, and constraints for the current iteration.
2. Risk Assessment and Reduction: Analyzing the alternatives to identify risks. Prototyping is heavily used here to test high-risk elements before committing to building them.
3. Development and Validation: Developing the actual software increment using a model appropriate for the current phase (e.g., Waterfall for a well-understood module).
4. Review and Planning: The customer evaluates the product. Based on feedback, the team plans the next phase of the spiral.

Limitations of the Spiral Model

• High Cost: Due to the extensive planning and continuous prototyping, it is an expensive methodology.
• Requires High Expertise: The success of the model relies almost entirely on the risk assessment phase. If the team lacks experts capable of identifying and analyzing major risks, the project will fail.
• Overkill for Small Projects: Because of its heavy structure, using it for small, low-risk, or simple web projects is a massive waste of time and resources.
• Complex Management: The spiral can theoretically go on indefinitely if limits and strict milestones are not strictly enforced by management.

---

Q.4: What is Scrum in software engineering? explain its features and steps.

What is Scrum? Scrum is the most widely used Agile framework in software engineering. It is designed to help small, cross-functional teams deliver functional software in a rapid, iterative, and highly adaptable manner. It breaks massive projects down into small, manageable chunks that can be completed in short timeframes.

Key Features of Scrum

• Timeboxed Iterations: Work is strictly contained within fixed time periods called Sprints.
• Empirical Process Control: Decisions are based on actual observation and user feedback rather than upfront predictive planning.
• Self-Organizing Teams: The development team decides how to accomplish the work rather than being micromanaged by a boss.

Steps and Artifacts in the Scrum Process

1. Product Backlog Creation: The Product Owner compiles a prioritized list of all desired features, requirements, and fixes needed for the product.
2. Sprint Planning: The team selects the highest-priority items from the Product Backlog and determines what they can realistically complete in the upcoming Sprint (usually 2-4 weeks). This creates the Sprint Backlog.
3. The Sprint: The team works exclusively on the Sprint Backlog. No new work can be added by external management during this time.
4. Daily Scrum (Stand-up): A brief, 15-minute daily meeting where team members state what they did yesterday, what they will do today, and identify any blockers.
5. Sprint Review: At the end of the Sprint, the team presents the working, completed software increment to the stakeholders for feedback.
6. Sprint Retrospective: The internal team meets to discuss the process itself—what went well, what went wrong, and how they can improve their efficiency for the next Sprint.

---

Q.5: Consider the case study above and create Use case diagram.

(For the exam, draw the standard UML Use Case Diagram layout using stick figures for actors and ovals for use cases. Below is the text-based blueprint of how that diagram must be structured).

1. Identify Actors (Stick Figures):

• Regular User
• Administrator

2. Identify Use Cases (Ovals):

• Log in
• Register
• Post new message
• Check statistics
• Create new thread
• Send private message
• Internal Authentication

3. Define Relationships (Arrows & Lines):

• <<include>> Relationships (Dotted arrows pointing to the included use case):

• Log in ----<>----> Internal Authentication

• Register ----<>----> Internal Authentication

• Actor to Use Case Associations (Solid lines connecting actors to ovals):

• Both Actors (Regular User & Administrator) connect to:

• Log in

• Register

• Post new message

• **Only Administrator** connects to:

• Check statistics

• Create new thread

• **Only Regular User** connects to:

• Send private message

---

Q.6: Draw a class diagram depicting classes, with names, attributes and methods along with proper relationship between classes.

(For the exam, draw three distinct rectangular boxes representing the classes. Use a hollow triangle arrow pointing from the child classes up to the parent abstract class to denote Inheritance).

Class 1: Duck (Abstract Parent Class)

• Name: <<abstract>> Duck (or write it in italics)

• Attributes:

• - weight: float (Private or Protected, depending on convention, but usually private with protected setter)

• Methods:

• + canFloat(): boolean

• + quack(): void <>

• + walk(): void

• # setWeight(w: float): void (Protected method, meaning only accessible to subclasses)

Class 2: RubberDuck (Child Class)

• Relationship: Solid line with a hollow arrow pointing to Duck (Inheritance).
• Name: RubberDuck
• Attributes: (Inherited, no need to redraw)
• Methods:
• + quack(): void (Implements abstract method)
• + walk(): void (Overrides parent method to do nothing)

Class 3: MallardDuck (Child Class)

• Relationship: Solid line with a hollow arrow pointing to Duck (Inheritance).
• Name: MallardDuck
• Attributes: (Inherited, no need to redraw)
• Methods:
• + quack(): void (Implements abstract method)
• + fly(): void (Unique feature for this specific duck)