SE

SE 12-Mark Answer Sheet: Optimal Strategy

Combination: Q21(a) • Q22(b) • Q23(a) • Q24(a) • Q25(a)

Question 21 (a) • 12 Marks

Prescriptive Software Process Models

Strategy: 4 Visual Blocks + Clear Scenarios

1. Classic Waterfall Model

Linear-Sequential
Communication Planning Modeling / Design Construction Deployment
  • Phases: Communication → Planning → Modeling → Construction → Deployment.
  • Key Characteristic: Strict phase containment; output of one phase forms the direct baseline input to the next.
  • Drawback: Inflexible to changing requirements; working software arrives very late.
Context of Use: Clear, stable, well-understood requirements with established tech stack (e.g., Banking Core, Payroll calculation engine, Military control system).

2. Prototyping Model

Iterative Discovery
1. Listen 2. Quick Design 3. Build Prototype 4. Customer Evaluation Iteration Feedback
  • Phases: Communication → Quick Design → Build Prototype → Customer Evaluation → Refinement loop.
  • Key Characteristic: Prototype is built to clarify ambiguous requirements, then discarded or evolved.
  • Drawback: Stakeholders may mistake quick mockup for production code; design shortcuts taken.
Context of Use: High customer ambiguity, novel user interfaces, AI/ML UX explorations, where customer cannot specify exact functional inputs upfront.

3. Incremental Process Model

Staged Delivery
Increment 1: Core Product (MVP) Delivery 1 Increment 2: Secondary Features Delivery 2 Increment 3: Advanced Optimization Final Release
  • Mechanism: Combines linear waterfall elements iteratively. Produces operational releases in staggered increments.
  • Key Characteristic: Increment 1 delivers the "Core Product"; subsequent increments add enhanced capabilities.
  • Advantage: Early return on investment; early customer feedback on live product.
Context of Use: Large commercial web applications (e.g., E-commerce store launching Cart/Checkout first, followed by Loyalty points & Recommendations in later releases).

4. Spiral Model (Boehm)

Risk-Driven
Q1: Objective & Alternative Identification Q2: Risk Analysis & Prototyping (CRITICAL) Q3: Engineering & Product Construction Q4: Review & Next Phase Planning
  • 4 Distinct Quadrants: Determine Objectives → Identify & Resolve Risks → Development & Testing → Plan next iteration.
  • Key Characteristic: Angular dimension represents progress; radial distance represents cumulative cost.
  • Crux: Explicit Risk Analysis at every cycle. If risk is too high, project terminates immediately.
Context of Use: High-risk, expensive, mission-critical systems where failure is catastrophic (e.g., Space flight avionics, medical surgical robotics, defense nuclear monitoring).
Question 22 (b) • 12 Marks

UML Models: Online Food Ordering System

Strategy: 2 Detailed SVG Diagrams (Instant Full Marks)

Part 1: Use Case Diagram (Shows boundary, actors, relationships, <<include>> / <<extend>>)

6 Marks Component
ONLINE FOOD ORDERING SYSTEM BOUNDARY Customer Restaurant Delivery Partner Browse & Search Menu Place Food Order Make Payment Apply Coupon / Deal Accept / Prepare Order Pick Up & Deliver Order Track Live Delivery <<include>> <<extend>>

Part 2: Class Diagram (UML 3-box notation: Class Name, Attributes, Methods + Multiplicities)

6 Marks Component
Customer - customerId: int - name: String - email: String - deliveryAddress: String + browseMenu(): List + placeOrder(): Order + trackDelivery(): Status Order - orderId: int - orderDate: Date - totalAmount: double - status: OrderStatus + calculateTotal(): double + updateStatus(s: String) + cancelOrder(): boolean Restaurant - restaurantId: int - name: String - address: String - isAvailable: boolean + acceptOrder(o: Order) + updateMenu() + dispatchOrder() FoodItem - itemId: int - itemName: String - price: double - quantity: int + getSubTotal(): double + checkStock(): boolean Payment - paymentId: String - amount: double - method: PaymentMode - paymentStatus: String + processPayment(): bool + refundPayment(): bool 1 0..* places > 1..* 1 assigned to > 1 1..* (contains) 1 1
Question 23 (a) • 12 Marks

Design Objectives, Metrics, Modularity, Coupling & Cohesion

Strategy: Structured Tables & Hierarchies

1. Design Objectives

  • Correctness: Meets every specification accurately.
  • Understandability & Maintainability: Easy to read, debug, and upgrade.
  • Modularity & Reusability: Autonomous components reused elsewhere.
  • Efficiency: Minimal computation & memory overhead.

2. Key Design Metrics

  • Cyclomatic Complexity V(G): Measures independent linear paths; optimal is ≤ 10.
  • Fan-in / Fan-out: High fan-in (good reuse); low fan-out (low coupling).
  • Information Hiding: State encapsulation behind clean public interfaces.

3. Cardinal Rule of Modularity

"HIGH COHESION & LOW COUPLING"

Guarantees isolated fault domains, independent testability, and parallel feature development.

Cohesion: Intra-module Strength

Low (Worst) → High (Best)
Type Quality Clear Definition & Example
1. Coincidental WORST Tasks grouped randomly with zero relationship.
e.g., A single "Util" class containing printReceipt(), calculateSqrt(), sendSms().
2. Logical POOR Elements execute logically similar tasks based on a flag.
e.g., outputAll(int flag) that outputs either to printer, disk, or network.
3. Temporal MEDIOCRE Elements combined solely because they execute at the same time.
e.g., startupInit() resetting counters, opening DB, and rendering splash screen.
4. Procedural FAIR Executed in a specific sequence of steps, but on different data.
5. Communicational ACCEPTABLE All tasks operate on the exact same input/output dataset.
e.g., generateReport() updates customer file and prints customer ledger.
6. Sequential GOOD Output of one internal operation directly feeds the next operation (assembly line).
7. Functional BEST Every element contributes strictly to a single, well-defined mathematical/business goal.
e.g., calculateCosine() or verifyPasswordHash().

Coupling: Inter-module Interdependence

High (Worst) → Low (Best)
Type Quality Clear Definition & Example
1. Content WORST (TIGHT) One module directly accesses or modifies the private code/memory of another module.
2. Common HIGH RISK Multiple modules share direct read/write access to identical global data variables.
3. External MODERATE Modules tied to external device format, OS API, or specific network communication protocol.
4. Control FAIR One module controls the execution flow of another by passing a flag (e.g., whatToExecute(doBranchB)).
5. Stamp GOOD Modules share an entire composite data structure (e.g., entire Employee record), even when only 1 field is needed.
6. Data BEST (LOOSE) Modules communicate strictly via simple, primitive scalar parameters (e.g., calculateTax(salary, taxRate)).
Question 24 (a) • 12 Marks

Design Patterns: MVC & Publish-Subscribe

Strategy: 2 Concise Patterns with Clear Interaction Flows

1. Model-View-Controller (MVC)

Architectural Pattern

Decouples core business logic and state from user interface presentation and input handling.

User 1. Interacts Controller Handles Input/Logic Model State & DB Rules View Renders UI 2. Updates State 3. Notifies Update 4. Sees UI
Model: Holds raw data, validation schemas, and database operations. Independent of UI.
View: Visual representation of data (HTML, JSON, UI components). Observes the model.
Controller: Intercepts requests, translates user actions into Model updates.
Real-world Application: Django, Spring Boot, ASP.NET MVC, React-Redux web apps.

2. Publish-Subscribe (Pub-Sub) Pattern

Messaging Pattern

Complete spatial, temporal, and synchronization decoupling between message producers and consumers.

Publisher A Publisher B Event Broker Topic: OrderCreated Topic: PaymentDone Email Service Inventory Svc Analytics Svc
Publisher: Emits domain events to named topics without knowing who consumes them.
Message Broker / Event Bus: Routes messages, filters topics, guarantees persistence.
Subscriber: Registers interest in specific topics; reacts independently upon arrival.
Real-world Application: Apache Kafka in Uber tracking, RabbitMQ in banking, AWS SNS/SQS.
Question 25 (a) • 12 Marks

Testing Techniques & Railway Reservation Test Suite

Strategy: Crisp Definitions + Complete Standard Test Table
01. Unit

Tests smallest standalone component/function in isolation using stubs & drivers.

02. Black Box

Functional testing purely against inputs & expected outputs with no internal code visibility.

03. White Box

Structural testing verifying branch coverage, path execution, conditions, and loops.

04. Integration

Validates data interfaces and RPC calls between combined modules (Top-down / Bottom-up).

05. System

End-to-end evaluation of fully integrated software against complete SRS specifications.

06. Regression

Rerunning prior test suites to ensure bug fixes or modifications haven't broken working features.

Sample Test Cases: Railway Reservation System (IRCTC-Style)

Examiner Preferred Format
Test ID Test Scenario / Description Input Data / Precondition Expected Output Type Status
TC_RR_01 Valid User Authentication User: "john_doe", Pass: "SecurePass@123" Dashboard loads; Session JWT created. Black Box Pass
TC_RR_02 Train Search: Identical Stations Src: "NDLS", Dest: "NDLS", Date: Tomorrow Error: "Source and Destination cannot be identical." Boundary Pass
TC_RR_03 Max Passenger Limit Validation Input: Add 7 passenger details in 1 ticket Error: Maximum 6 passengers allowed per ticket. Equivalence Pass
TC_RR_04 Senior Citizen Concession Calculation Age: 65, Gender: Male, Base Fare: $1000 Fare calculates 40% discount = $600 + taxes. Unit Test Pass
TC_RR_05 Concurrency Booking Lock (Race Condition) 2 users click 'Book' simultaneously for 1 seat User 1 gets CNF (Confirmed); User 2 gets WL (Waitlist). Integration Pass
TC_RR_06 Payment Gateway Failure & Seat Rollback Bank simulates HTTP 500 timeout during debit DB transaction rollback; seat released back to inventory. System Test Pass