Software Engineering · Quiz 2 · Jan 2025

An **Integrated Development Environment (IDE)** provides comprehensive facilities for software development, typically including a source code editor, build automation tools, and an integrated debugger. - **PyCharm**, **Thonny**, and **Visual Studio Code** (with extensions) provide code editing, execution, and debugging environments. - **TextEdit (Mac)** is a simple built-in plain text and rich text editor/word processor for macOS and is **not** an IDE. **Answer: D (TextEdit (Mac))** A: **Incorrect:** Visual Studio Code is a widely used source-code editor/development environment with integrated debugging and build tools. B: **Incorrect:** PyCharm is a dedicated Python Integrated Development Environment (IDE) developed by JetBrains. C: **Incorrect:** Thonny is a beginner-friendly Python Integrated Development Environment (IDE). D: **Correct:** TextEdit is a basic macOS text editor, not an Integrated Development Environment.

Let us evaluate both statements about Git commands: - **Statement 1**: `git pull` fetches changes from the remote repository and automatically merges them into the current local branch (equivalent to `git fetch` followed by `git merge`). Thus, **Statement 1 is correct**. - **Statement 2**: `git fetch` only downloads commits, files, and refs from the remote repository into your local repository's remote-tracking branches; it **does not** automatically merge them into your current working branch. Thus, **Statement 2 is incorrect**. **Answer: A (Statement 1 is correct, Statement 2 is incorrect.)** A: **Correct:** `git pull` fetches and merges automatically, whereas `git fetch` only retrieves changes without merging. B: **Incorrect:** Statement 1 is true and Statement 2 is false. C: **Incorrect:** Statement 2 is false because `git fetch` never automatically merges into the current branch. D: **Incorrect:** Statement 1 accurately describes `git pull`.

Because the payment processing service is a **third-party component**, the engineer does not have access to its internal source code and must diagnose the integration issue by examining external specifications, API documentation, inputs/outputs, and example usage. This approach is called **blackbox debugging**. **Answer: D (Blackbox debugging)** A: **Incorrect:** Input manipulation involves systematically varying inputs to observe output changes rather than reviewing API documentation. B: **Incorrect:** Backwards debugging traces program execution backward from the point of failure through internal source code. C: **Incorrect:** Forwards debugging traces program state forward from an initial input through internal code statements. D: **Correct:** Investigating a third-party service via its external API documentation and examples without inspecting its internal code is blackbox debugging.

An **unstructured interview** is an exploratory, conversational interview in which the interviewer does not follow a predetermined script of questions, instead asking open-ended questions and adapting follow-up questions dynamically based on the interviewee's responses. **Answer: C (Unstructured interview)** A: **Incorrect:** A structured interview strictly follows a predefined list of closed or standardized questions. B: **Incorrect:** A semistructured interview uses a predefined set of core questions combined with some spontaneous follow-up questions. C: **Correct:** Asking open-ended questions without a predefined list in a free-flowing conversation defines an unstructured interview. D: **Incorrect:** Questionnaires are written survey forms rather than interactive spoken conversations.

**Procedural cohesion** occurs when elements/functions of a module are grouped together because they always follow a specific sequence of execution (one after the other to accomplish a workflow), even though they perform distinct tasks (`UpdateStock()`, `GenerateInventoryReport()`, `SendLowStockNotification()`) and do not necessarily pass the output of one directly as the input to the next. **Answer: B (Procedural cohesion)** A: **Incorrect:** Coincidental cohesion occurs when functions in a module have no meaningful relationship or execution order at all. B: **Correct:** Functions grouped together because they are executed one after another in a fixed procedural order exhibit procedural cohesion. C: **Incorrect:** Communicational cohesion occurs when all functions operate on the same input or output data structure without requiring a specific order. D: **Incorrect:** Sequential cohesion requires the output of one function to serve directly as the input to the next function like an assembly line.

Let us analyze both **cohesion** and **coupling** in the given e-commerce design: - **High Cohesion**: Each module focuses on a single, well-defined responsibility (one manages product listings, one processes orders, and one handles payments). - **High Coupling**: All modules directly access and update a **shared order database** (common/shared-data coupling), meaning changes to the database schema or shared tables affect all modules. Therefore, the modules have **high cohesion and are highly coupled**. **Answer: A (The modules have high cohesion and are highly coupled.)** A: **Correct:** Each module has a focused single purpose (high cohesion), but sharing a common database directly creates strong interdependence (high coupling). B: **Incorrect:** Since each module focuses on its own dedicated task, cohesion is high, not low. C: **Incorrect:** Sharing a central database directly makes the modules tightly coupled, and single-purpose modules have high cohesion. D: **Incorrect:** Direct reliance on a shared database for reading and updating state creates high (tight) coupling rather than loose coupling.

In UML, **interaction diagrams** (which include **sequence diagrams** and **communication diagrams**) model the dynamic interactions and chronological sequence of message exchanges among objects or parts of a system. **Answer: D (Interaction diagram)** A: **Incorrect:** Class diagrams model the static structure of classes, attributes, methods, and relationships. B: **Incorrect:** State machine diagrams model the states of a single object and transitions triggered by events. C: **Incorrect:** Activity diagrams model workflow and control/data flow from activity to activity. D: **Correct:** Interaction diagrams (such as sequence diagrams) model the sequence of message exchanges among system components.

In Agile/Scrum project management, a **sprint retrospective** is held at the end of a sprint for the team to reflect on and evaluate the just-concluded sprint—including team dynamics, processes, workflows, and tools—and identify improvements for future sprints. **Answer: D (To evaluate the last sprint - team dynamics, processes, tools etc.)** A: **Incorrect:** Deciding which work to do in the current sprint and how to accomplish it is the objective of **Sprint Planning**. B: **Incorrect:** Prioritizing work in the product backlog is part of **Backlog Grooming/Refinement** by the Product Owner. C: **Incorrect:** Demonstrating completed work to stakeholders is the purpose of the **Sprint Review**. D: **Correct:** The Sprint Retrospective evaluates how the last sprint went regarding people, relationships, processes, and tools.

**Step 1: Recall the formula for Risk Exposure (Assessed Risk).** \[\text{Risk} = \text{Probability} \times \text{Impact}\] **Step 2: Substitute the given values and solve for Impact.** Given \(\text{Risk} = 1.8\) and \(\text{Probability} = 0.9\): \[1.8 = 0.9 \times \text{Impact} \implies \text{Impact} = \frac{1.8}{0.9} = 2\] **Answer: B (2)** A: **Incorrect:** 16.6 is not obtained from the risk exposure relationship \(\text{Risk} = \text{Probability} \times \text{Impact}\). B: **Correct:** Dividing the assessed risk (1.8) by the probability (0.9) gives an impact of \(1.8 / 0.9 = 2\). C: **Incorrect:** An impact of 3 with probability 0.9 would yield a risk of \(2.7 \ne 1.8\). D: **Incorrect:** 0.17 is not the ratio \(1.8 / 0.9\).

In a **peer-to-peer (P2P) architecture**, each participating device (node/peer) acts as both a client and a server, storing files locally and exchanging data directly with other peers without relying on a centralized server. **Answer: D (Peer-to-peer architecture)** A: **Incorrect:** A client-server system relies on a central server to store files and service client requests. B: **Incorrect:** Pipe and filter architecture processes streams of data through sequential transformation stages. C: **Incorrect:** Model-View-Controller (MVC) separates user interface, business logic, and data control within an application. D: **Correct:** Direct decentralized file sharing between user devices without a central server is the hallmark of peer-to-peer architecture.

Because the software tool is being built by the company specifically for **its own developers** within the same organization, the users/clients of the system are **internal users**. **Answer: B (Internal users)** A: **Incorrect:** External users are customers or end-users outside the organization developing the software. B: **Correct:** Employees and developers within the same company using an in-house tool are internal users. C: **Incorrect:** The primary users interacting with the version control and bug tracking tool are human developers, not just software components. D: **Incorrect:** Internal users accurately describes the company's own developers.

**Beta testing** is a type of user acceptance testing performed by real end-users in their actual real-world environment prior to the final commercial release, allowing the organization to gather practical feedback and uncover field defects. **Answer: D (Beta testing)** A: **Incorrect:** System testing is conducted internally by the testing team in a controlled test environment. B: **Incorrect:** Integration testing verifies interfaces and interactions between combined software modules. C: **Incorrect:** Alpha testing is performed at the developer's site in a controlled environment before external release. D: **Correct:** Beta testing releases the nearly finished product to real external users to evaluate it in real-world scenarios.

Sharing the application with a predefined group of customers to identify bugs (such as incorrect driver location tracking) before general release is **beta testing**, which is part of the **Testing phase** of the Software Development Lifecycle (SDLC). **Answer: D (Testing phase)** A: **Incorrect:** Requirement gathering defines what features the app should have before building it. B: **Incorrect:** The development phase focuses on writing the code rather than customer validation testing. C: **Incorrect:** The design phase creates architectural and UI blueprints before implementation. D: **Correct:** Releasing the app to a predefined group of customers to uncover defects is beta testing within the Testing phase. E: **Incorrect:** Maintenance occurs after full production deployment to the general public.

Under the **SMART** criteria for agile tasks and user stories (**S**pecific, **M**easurable, **A**chievable, **R**elevant, **T**ime-boxed), breaking down a large user story that cannot fit within a single 1–2 week iteration into smaller, manageable stories ensures that each story is **Achievable** within the iteration. **Answer: C (Achievable)** A: **Incorrect:** Specific means the story clearly states what needs to be done without ambiguity. B: **Incorrect:** Measurable means there are clear acceptance criteria to verify completion. C: **Correct:** Subdividing an oversized user story into smaller pieces ensures the team can realistically complete it within one iteration (Achievable). D: **Incorrect:** Relevant means the user story delivers business value aligned with project goals. E: **Incorrect:** Timeboxed means fixed to a specific duration, whereas splitting the scope makes the workload achievable.

According to Jakob Nielsen's usability heuristics, **Visibility of system status (Show status)** requires the system to always keep users informed about what is going on through appropriate feedback within a reasonable time (such as real-time order and delivery progress updates). **Answer: D (Show status)** A: **Incorrect:** User control and freedom refers to providing easy undo/redo or cancellation options. B: **Incorrect:** Flexibility and efficiency of use refers to accelerators and shortcuts for experienced users. C: **Incorrect:** Recognition over recall refers to making options and actions visible so users do not have to remember information across screens. D: **Correct:** Failing to provide real-time updates on order and delivery progress violates the 'Show status' (visibility of system status) heuristic.

The **Adapter design pattern** (a structural pattern) allows classes with incompatible interfaces or data formats—such as payment gateways providing EUR and INR amounts—to work seamlessly with an existing class (`PaymentProcessor`) that expects a specific interface/currency (USD) by converting the interface/data in an intermediary wrapper. **Answer: C (Adapter design pattern)** A: **Incorrect:** The Factory pattern is a creational pattern used to instantiate objects without specifying their exact concrete classes. B: **Incorrect:** The Builder pattern is a creational pattern used to construct complex objects step by step. C: **Correct:** The Adapter pattern converts the incompatible currency interface of external payment gateways into the USD interface expected by `PaymentProcessor`. D: **Incorrect:** The Facade pattern provides a simplified high-level interface to a complex subsystem rather than converting incompatible interfaces.

The **Interface Segregation Principle (ISP)** states that no client should be forced to depend on or implement methods it does not use. Because `SmartDevice` is a "fat" interface containing `play_music()`, classes like `SmartLight` and `SmartThermostat` are forced to implement `play_music()` even though they have no music functionality. Splitting `SmartDevice` into smaller, role-specific interfaces resolves this violation. **Answer: C (Interface segregation principle)** A: **Incorrect:** The Open-Closed Principle states that software entities should be open for extension but closed for modification. B: **Incorrect:** The Liskov Substitution Principle focuses on behavioral substitutability of subtypes for their base type. C: **Correct:** Forcing `SmartLight` and `SmartThermostat` to implement the unused `play_music()` method from a fat interface violates the Interface Segregation Principle. D: **Incorrect:** The Dependency Inversion Principle states that high-level modules should depend on abstractions rather than low-level concrete details.

Let us classify each requirement: - **Requirement 1** (*support at least 500 simultaneous user logins*): Specifies scalability/capacity performance \(\implies\) **Non-functional requirement**. - **Requirement 2** (*allow users to view available doctors and appointment slots*): Specifies a core system feature/behavior \(\implies\) **Functional requirement**. - **Requirement 3** (*notify users when an appointment is booked*): Specifies an action/output behavior of the app \(\implies\) **Functional requirement**. - **Requirement 4** (*process payments within 3 seconds*): Specifies a response-time performance constraint \(\implies\) **Non-functional requirement**. Therefore, **Requirements 2 and 3 are functional requirements, whereas requirements 1 and 4 are non-functional requirements**. **Answer: B (Requirements 2 and 3 are functional requirements, whereas requirements 1 and 4 are non-functional requirements.)** A: **Incorrect:** Requirement 1 (500 concurrent logins) is a non-functional capacity/scalability requirement. B: **Correct:** Viewing doctors/slots (2) and sending booking notifications (3) are functional behaviors, while concurrency capacity (1) and response time (4) are non-functional. C: **Incorrect:** Reverses the definitions of functional and non-functional requirements. D: **Incorrect:** Requirement 3 (notifying users upon booking) is a functional requirement, not a non-functional one.

**Step 1: Recall the shortcut formula for Cyclomatic Complexity \(M\).** \[M = P + 1\] where \(P\) is the number of predicate (decision/branching) statements in the function. **Step 2: Count the decision statements in `classify_numbers(numbers)`.** 1. `for num in numbers:` (loop condition) 2. `if num > 0:` (first conditional branch) 3. `if num < 0:` (second conditional branch) Since there are \(P = 3\) decision predicates, the cyclomatic complexity is: \[M = 3 + 1 = 4\] **Answer: B (4)** A: **Incorrect:** 3 is the number of predicate statements (`for`, `if`, `if`), forgetting to add 1. B: **Correct:** With 3 decision points (`for num in numbers`, `if num > 0`, `if num < 0`), \(M = 3 + 1 = 4\). C: **Incorrect:** `else:` clauses do not introduce new decision predicates; \(M = 4\). D: **Incorrect:** Overcounts the number of independent paths through the function.

Reviewing existing **documentations** (document analysis) involves gathering detailed requirement information from existing written records, manuals, standard operating procedures, business rules, steps, and regulatory documents related to a task or system. **Answer: D (Documentations)** A: **Incorrect:** Questionnaires collect survey responses from stakeholders rather than analyzing recorded manuals and regulations. B: **Incorrect:** Interviews involve direct one-on-one or small-group questioning of stakeholders. C: **Incorrect:** Focus groups gather interactive feedback from a moderated group of users. D: **Correct:** Documentations (document analysis) extracts requirements from existing recorded procedures, rules, and regulations.

**Step 1: Identify the COCOMO project type.** The mobile app monitors and controls traffic systems in **real-time**, requires integration with **multiple hardware devices**, and enforces **strict security protocols**. In Boehm's COCOMO model, real-time hardware-coupled control systems with tight constraints are classified as **Embedded projects** (\(a = 3.6, b = 1.20\)). **Step 2: Calculate the size in KLOC.** \[\text{Size} = 1,00,000\text{ lines} = 100\text{ KLOC}\] **Step 3: Compute the initial estimated effort \(E_i\).** \[E_i = a \times (\text{KLOC})^b = 3.6 \times (100)^{1.20}\] Since \(100^{1.20} = (10^2)^{1.20} = 10^{2.4} \approx 251.1886\): \[E_i = 3.6 \times 251.1886 \approx 904.28 \approx 905\text{ person-months}\] **Answer: D (905 person-months)** A: **Incorrect:** 303 person-months uses the Organic project constants (\(2.4 \times 100^{1.05} \approx 302.1\)). B: **Incorrect:** Does not match any of the three COCOMO project formulas for 100 KLOC. C: **Incorrect:** 522 person-months uses the Semi-detached project constants (\(3.0 \times 100^{1.12} \approx 521.3\)). D: **Correct:** As an Embedded project (\(a = 3.6, b = 1.20\)), initial effort is \(3.6 \times 100^{1.20} \approx 905\text{ person-months}\).

**Step 1: Recall the Intermediate COCOMO formula for final adjusted effort.** \[\text{Final Effort } E = \text{Initial Effort } (E_i) \times \text{Effort Adjustment Factor (EAF)}\] **Step 2: Substitute \(E_i = 905\text{ person-months}\) and \(\text{EAF} = 1.88\).** \[E = 905 \times 1.88 = 1701.4 \approx 1702\text{ person-months}\] (Or using unrounded \(E_i = 904.28\): \(904.28 \times 1.88 = 1700.05\), and \(905 \times 1.88 = 1701.4 \approx 1702\).) **Answer: C (1702 person-months)** A: **Incorrect:** 305 person-months ignores the Embedded project effort and EAF. B: **Incorrect:** 570 person-months is \(303 \times 1.88\), which uses the Organic initial effort instead of Embedded. C: **Correct:** Multiplying the Embedded initial effort (\(905\text{ person-months}\)) by \(\text{EAF} = 1.88\) gives \(1702\text{ person-months}\). D: **Incorrect:** 982 person-months is \(522 \times 1.88\), which uses the Semi-detached initial effort instead of Embedded.

A **technical risk** threatens the quality and timeliness of the software to be produced due to design, implementation, interface, verification, or external component limitations. Because the route optimization system relies on a third-party mapping API that may have technical shortcomings, this is a **technical risk**. **Answer: B (Technical risk)** A: **Incorrect:** Project risks threaten the project plan (budget, schedule, staffing, resources). B: **Correct:** Potential shortcomings in a third-party API used for core functionality constitute a technical risk. C: **Incorrect:** Business risks threaten the market viability of the software product. D: **Incorrect:** Technical risk is the exact category for this scenario.

To mitigate the technical risk of potential shortcomings in an external third-party mapping API, the development team should conduct **benchmarking and regular inspection** to verify that the external component meets performance, accuracy, and reliability requirements. **Answer: B (By benchmarking and regular inspection to verify that the external component is up to the mark.)** A: **Incorrect:** Hiring experienced developers addresses staffing/skill risks, not defects in a third-party API. B: **Correct:** Benchmarking and regular inspection directly evaluate whether the external API performs as required. C: **Incorrect:** Client communication and prototyping address requirement gathering risks. D: **Incorrect:** Market exploration addresses business viability risks.