Group C — Long / Numerical Questions (15 Marks Each)

Master Answer: Cyclomatic Complexity & Basis Path Testing

Part (a) Calculate Cyclomatic Complexity V(G)

Given: Edges \(E = 14\), Nodes \(N = 10\), Connected Components \(P = 1\).

Using the Edge-Node formula:

\[ V(G) = E - N + 2P \]

\[ V(G) = 14 - 10 + 2(1) = 4 + 2 = 6 \]

The Cyclomatic Complexity is 6. This means there are exactly 6 independent paths through the program flow graph.

Independent Paths (Assumed based on standard loops/branches):

1. Path 1: 1 → 2 → 10 (Direct exit)
2. Path 2: 1 → 2 → 3 → 8 → 9 → 10
3. Path 3: 1 → 2 → 3 → 4 → 7 → 8 → 9 → 10
4. Path 4: 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10
5. Path 5: 1 → 2 → 3 → 8 → 2 → ... → 10 (Loop iteration)
6. Path 6: 1 → 2 → 3 → 4 → 7 → 4 → ... → 10 (Inner Loop iteration)

Part (b) Design Test Cases using Basis Path Testing

Basis Path testing guarantees that every statement and every branch is executed at least once.

• Test Case 1 (for Path 1): Input values that cause the program to hit the very first error/exit condition (e.g., passing a Null pointer).
• Test Case 2 (for Path 2): Input values that bypass the inner loops entirely.
• Test Cases 3-6: Inputs designed specifically to force the execution to walk through the various loop combinations and internal if/else branches identified in paths 3 through 6.

Part (c) Black-Box vs White-Box Testing

Master Answer: Software Estimation (COCOMO & FP)

Part (a) Basic COCOMO Calculation

Given: Size = 32 KLOC. Mode = Organic. Constants: \(a = 2.4, b = 1.05, c = 2.5, d = 0.38\).

1. Effort (E):
   \(E = a \times (KLOC)^b\)
   \(E = 2.4 \times (32)^{1.05} = 2.4 \times 38.05 = \mathbf{91.32 \text{ Person-Months}}\)
2. Development Time (Tdev):
   \(T_{dev} = c \times (E)^d\)
   \(T_{dev} = 2.5 \times (91.32)^{0.38} = 2.5 \times 5.54 = \mathbf{13.87 \text{ Months}}\)
3. Average Staffing (SS):
   \(SS = \frac{E}{T_{dev}} = \frac{91.32}{13.87} = \mathbf{6.58 \text{ Persons (round up to 7)}}\)

Part (b) Function Point (FP) Calculation

Given parameters and their standard weights:

• External Inputs (Simple: weight 3): \(10 \times 3 = 30\)
• External Outputs (Average: weight 5): \(12 \times 5 = 60\)
• External Inquiries (Complex: weight 6): \(8 \times 6 = 48\)
• Internal Logical Files (Average: weight 10): \(4 \times 10 = 40\)
• External Interface Files (Simple: weight 5): \(6 \times 5 = 30\)

Step 1: Unadjusted Function Points (UFP)

\(UFP = 30 + 60 + 48 + 40 + 30 = \mathbf{208}\)

Step 2: Value Adjustment Factor (VAF)

Given \(\Sigma F_i = 45\).

\(VAF = 0.65 + (0.01 \times \Sigma F_i) = 0.65 + (0.01 \times 45) = 0.65 + 0.45 = \mathbf{1.10}\)

Step 3: Final Adjusted Function Points (FP)

\(FP = UFP \times VAF = 208 \times 1.10 = \mathbf{228.8 \text{ FP}}\)

Master Answer: DFD and UML for Online Examination System

Part (a) Data Flow Diagrams (DFD)

Level 0 Context Diagram:

Level 1 DFD:

Decomposes the main system into:

1. Process 1.0 (Auth): Validates Student credentials against User DB.
2. Process 2.0 (Exam Engine): Retrieves questions from Question DB and serves them.
3. Process 3.0 (Evaluation): Compares submitted answers against Answer Key DB.
4. Process 4.0 (Reporting): Generates scores and saves to Results DB.

Part (b) UML Class and Sequence Diagram

Class Diagram:

Master Answer: Software Test Plan and Test Cases

Part (a) Test Plan for E-Commerce Shopping Cart

A Software Test Plan outlines the testing strategy, scope, resources, and schedule.

• Scope: Adding items to cart, updating quantities, removing items, calculating totals (including tax/shipping), and proceeding to checkout.
• In-Scope Testing Types: Functional Testing, UI Testing, Integration Testing (Cart to Payment Gateway), Performance Testing (handling Black Friday loads).
• Test Environment: Staging server mirroring production. Browsers: Chrome, Firefox, Safari. Devices: Desktop, iOS, Android.
• Entry/Exit Criteria: Entry: Code freeze achieved. Exit: 100% of Critical/High severity bugs resolved, 90% test case pass rate.

Part (b) Test Cases using Equivalence Partitioning & BVA

Scenario: Credit Card Expiration Date (Month: 1-12, Year: 2026-2035)

Master Answer: Agile Scrum Framework

Part (a) & (b) End-to-End Scrum Workflow

Scrum is an iterative framework operating in time-boxed Sprints (1-4 weeks).

• Sprint Planning: The entire team selects high-priority items from the Product Backlog and moves them to the Sprint Backlog, agreeing on a Sprint Goal.
• Daily Standup (Daily Scrum): 15-minute sync-up to discuss progress, daily goals, and blockers.
• Sprint Review: At the end of the sprint, the team demonstrates the potentially shippable product increment to stakeholders.
• Sprint Retrospective: Internal team meeting to discuss what went well, what failed, and how to improve processes for the next sprint.
• Backlog Refinement (Grooming): Ongoing activity where the Product Owner adds detail, estimates, and order to items in the Product Backlog.

Part (c) Agile vs Traditional Waterfall

Master Answer: PERT/CPM and Critical Path Method

Part (a), (b), (c) Calculating Critical Path

Imagine a project with the following sequential network:

• A (Start, 3 days)
• B (Depends on A, 4 days)
• C (Depends on A, 2 days)
• D (Depends on B and C, 5 days)

Step 1: Forward Pass (Calculate ES & EF)

Formula: \(EF = ES + Duration\)

• A: ES=0, EF=3
• B: ES=3, EF=7
• C: ES=3, EF=5
• D: ES = max(EF of B, EF of C) = max(7, 5) = 7. EF = 7 + 5 = 12.

Project Completion Duration = 12 days.

Step 2: Backward Pass (Calculate LS & LF)

Formula: \(LS = LF - Duration\)

• D: LF=12, LS=7
• B: LF=7 (from D), LS=3
• C: LF=7 (from D), LS=5
• A: LF = min(LS of B, LS of C) = min(3, 5) = 3. LS=0.

Step 3: Total Float (Slack)

Formula: \(Float = LS - ES\) (or \(LF - EF\))

• A: 0 - 0 = 0
• B: 3 - 3 = 0
• C: 5 - 3 = 2 (Task C can be delayed by 2 days without affecting the project)
• D: 7 - 7 = 0

Critical Path: The path with ZERO Float. Therefore, the Critical Path is A → B → D.

Master Answer: OOAD and UML for ATM System

Part (a) Object-Oriented Analysis and Design (OOAD)

OOAD models a system as a group of interacting objects. Analysis (OOA) focuses on understanding the problem domain and identifying objects (Nouns in requirements). Design (OOD) defines the software architecture, class attributes, methods, and relationships (inheritance, polymorphism, encapsulation).

Part (b) UML Diagrams for ATM

Use Case Diagram:

Activity Diagram (Withdrawal Flow):

Master Answer: Software Risk Management

Part (a) Risk Management Phases

Risk Management involves identifying, analyzing, and mitigating threats to a software project's schedule, cost, or quality.

• Identification: Creating a checklist of all possible project, technical, and business risks.
• Projection (Analysis): Estimating the Probability (\(P\)) and Impact (\(I\)) of each risk. Risk Exposure \(RE = P \times I\).
• RMMM (Mitigation, Monitoring, and Management): Creating actionable plans to deal with the prioritized risks.

Part (b) Risk Projection Matrix & RMMM for a Banking App

Master Answer: CMMI Framework

Part (a) What is CMMI?

Capability Maturity Model Integration (CMMI) is a process improvement training and appraisal program administered by the CMMI Institute. It guides organizations to streamline processes, encouraging a culture of continuous improvement.

Part (b) The 5 Maturity Levels

1. Level 1: Initial
   • Characteristics: Unpredictable, chaotic, reactive. No standard processes. Success depends on individual heroism.
   • Process Areas: None.
2. Level 2: Managed
   • Characteristics: Processes are planned and executed at the project level. Basic project management exists.
   • Process Areas: Requirements Management, Project Planning, Configuration Management.
3. Level 3: Defined
   • Characteristics: Processes are well characterized and standardized across the entire organization.
   • Process Areas: Organizational Training, Risk Management, Decision Analysis.
4. Level 4: Quantitatively Managed
   • Characteristics: The organization uses statistical and quantitative techniques to precisely control process performance.
   • Process Areas: Quantitative Project Management, Organizational Process Performance.
5. Level 5: Optimizing
   • Characteristics: Focus is on continuous, proactive process improvement through incremental and innovative technological improvements.
   • Process Areas: Causal Analysis and Resolution, Organizational Performance Management.

Master Answer: SQA and Defect Metrics

Part (a) Software Quality Assurance (SQA)

SQA is the umbrella activity ensuring that software processes and products conform to standards (like ISO 9001). The SQA plan defines the audits, code reviews, testing strategies, and configuration management rules.

Quality Metrics: Metrics used to measure quality include Defect Density, Mean Time To Failure (MTTF), Cyclomatic Complexity, and Test Coverage percentage.

Part (b) Calculating Defect Removal Efficiency (DRE) and Defect Density

Scenario: During development and testing (before release), the QA team finds \(E = 85\) defects. After release, end-users report \(D = 15\) defects. The software size is 50 KLOC.

1. Defect Removal Efficiency (DRE):

   DRE measures the percentage of bugs caught internally before they reach the customer.

   \[ DRE = \frac{E}{E + D} = \frac{85}{85 + 15} = \frac{85}{100} = 0.85 \]

   The DRE is 85%. (A DRE approaching 1.0 indicates a highly effective QA process).

2. Defect Density:

   Defect Density measures the total number of known defects relative to the size of the software.

   Total Defects = \(E + D = 100\).

   \[ Defect Density = \frac{\text{Total Defects}}{\text{Size in KLOC}} = \frac{100}{50} = \mathbf{2.0 \text{ defects/KLOC}} \]

Master Answer: Software Maintenance and Re-engineering

Part (a) Software Maintenance Process Model

The IEEE maintenance process involves the following steps:

1. Identification & Classification: A change request (bug report or feature request) is submitted and classified (Corrective, Adaptive, Perfective, Preventive).
2. Analysis: Evaluating the impact of the change on the existing system, estimating cost, and determining feasibility.
3. Design: Designing the modifications required in the architecture and modules.
4. Implementation: Writing the new code or modifying existing code.
5. Regression Testing: Running extensive tests to ensure the new changes haven't broken any existing, working functionality.
6. Acceptance & Delivery: Deploying the updated software to users.

Part (b) Software Re-engineering Lifecycle

Re-engineering revamps a legacy system to a modern architecture without changing its core business logic.

• Reverse Engineering: The process of analyzing the legacy source code to extract high-level design representations (like Class Diagrams or DFDs) since original documentation is often missing or outdated.
• Restructuring: Code restructuring involves cleaning up "spaghetti code" into structured programming blocks. Data restructuring involves normalizing old flat files into modern relational database schemas.
• Forward Engineering: Using the recovered and restructured design models to generate new source code in a modern language (e.g., migrating from COBOL to Java/Spring Boot).

Master Answer: Enterprise System Testing

Part (a) System Testing Overview

System Testing evaluates the complete, fully integrated software system to verify compliance with its specified requirements. It is an end-to-end Black-Box testing phase conducted on an environment that closely mirrors production.

Part (b) Test Strategies and Scenarios

Master Answer: Software Architecture & Evaluation

Part (a) Architecture Evaluation Method (ATAM)

The Architecture Tradeoff Analysis Method (ATAM) evaluates software architectures relative to quality attribute goals (Performance, Security, Modifiability, etc.).

• Scenarios: ATAM uses specific scenarios (e.g., "A new payment gateway must be added in 2 weeks") to test the architecture.
• Sensitivity Points: Architectural decisions that significantly affect one or more quality attributes (e.g., Using a central database is highly sensitive to scalability).
• Trade-offs: Decisions that positively impact one attribute while negatively impacting another (e.g., High encryption improves Security but degrades Performance).

Part (b) Layered vs Microservices Architecture

Master Answer: OOAD Principles and Patterns

Part (a) SOLID Principles

• Single Responsibility: A class should have only one reason to change. (e.g., An Invoice class should only handle invoice logic, not printing logic).
• Open/Closed: Open for extension, closed for modification. (e.g., Use an Interface Shape and implement Circle and Square, instead of modifying an AreaCalculator with if/else statements).
• Liskov Substitution: Subclasses should be replaceable for their base classes. (e.g., A Penguin class inheriting from Bird violates LSP if Bird has a fly() method, because penguins can't fly).
• Interface Segregation: Many client-specific interfaces are better than one general-purpose interface.
• Dependency Inversion: Depend on abstractions, not concretions. (e.g., Depend on IDatabase instead of MySQLDatabase).

Part (b) Core Design Patterns

• Singleton (Creational): Ensures a class has only one instance globally.
  Implementation: Private constructor, static private instance variable, static public getInstance() method. (Used for Database Connection Pools).
• Factory Method (Creational): Defines an interface for creating an object, but lets subclasses decide which class to instantiate. (e.g., A VehicleFactory that returns a Car or Truck object based on input).
• Observer (Behavioral): Defines a one-to-many dependency so that when one object (Subject) changes state, all its dependents (Observers) are notified automatically. (Used in GUI event listeners or Publish-Subscribe systems).

Master Answer: Detailed Function Point Analysis

Part (a) FPA Methodology

Function Point Analysis measures software size based on external user interactions and internal logical data. It is independent of the programming language used.

The 5 parameters are EI (External Inputs), EO (External Outputs), EQ (External Inquiries), ILF (Internal Logical Files), and EIF (External Interface Files). Each is weighted (Simple, Average, Complex). UFP is the sum. Then, 14 General System Characteristics (GSCs) are rated from 0 to 5 to calculate the VAF.

Part (b) Hospital Management System Calculation

Assume the following counts and average weights for the Hospital System:

• EI (Admit Patient Form): count 15 × weight 4 = 60
• EO (Patient Discharge Bill): count 10 × weight 5 = 50
• EQ (Search Patient Record): count 12 × weight 4 = 48
• ILF (Patient DB, Doctor DB): count 5 × weight 10 = 50
• EIF (Insurance API): count 2 × weight 7 = 14

Unadjusted Function Points (UFP) = 60 + 50 + 48 + 50 + 14 = 222

Assume the sum of the 14 GSC ratings (\(\Sigma F_i\)) is 35 (moderate complexity).

Value Adjustment Factor (VAF):

\[ VAF = 0.65 + (0.01 \times \Sigma F_i) = 0.65 + (0.01 \times 35) = 0.65 + 0.35 = \mathbf{1.00} \]

Final FP = \(UFP \times VAF = 222 \times 1.00 = \mathbf{222 \text{ FP}}\)

Master Answer: Software Configuration Management (SCM)

Part (a) SCM Process

SCM is the discipline of managing and controlling changes in the software evolution process. It ensures that team members don't overwrite each other's work and that previous stable versions can be restored if needed.

Part (b) SCM Components

• Repository Management: The central database (like Git/GitHub) where all code, assets, and historical versions are stored.
• Baselines: A milestone in the SDLC representing an approved, stable version of a document or codebase. Once baselined, changes require formal approval. (e.g., The final SRS document is Baseline 1).
• Branching/Merging: Developers create isolated copies ("branches") of the code to work on new features. Once complete and tested, the branch is "merged" back into the main trunk (master branch).
• Change Control Board (CCB): A committee that reviews, evaluates, approves, or rejects proposed changes to baselined configurations based on cost, risk, and impact.
• Configuration Audits: Verifying that the software product actually satisfies its baselined requirements and that all approved changes were implemented correctly.

Master Answer: Cleanroom Software Engineering

Part (a) Cleanroom Methodology

Cleanroom software engineering is a formal, highly rigorous approach that emphasizes defect prevention rather than traditional compile/test defect removal. It aims to develop software with a certified level of reliability.

Part (b) Key Pillars

1. Formal Specification: Requirements are defined using rigorous mathematical models (State-box, Clear-box). This eliminates ambiguity entirely.
2. Non-Execution Verification: Programmers write the code but are forbidden from compiling or executing it. Instead, they use mathematical correctness proofs and formal technical reviews to verify the logic. The idea is to write code flawlessly the first time.
3. Statistical Quality Certification: Once the code is verified mathematically, an independent testing team compiles it and runs statistical usage testing. Test cases are generated based on the probability distribution of actual user behavior. The reliability of the software is then mathematically certified (e.g., 99.99% reliable) based on the test results.

Master Answer: Software Reliability Models

Part (a) Reliability Models Overview

Reliability models predict the probability of failure-free operation based on historical fault detection data.

• Jelinski-Moranda Model: Assumes that there are \(N\) total initial faults in the software. Every time a fault is discovered and fixed, the overall failure rate drops by a constant step. It assumes all faults contribute equally to the failure rate.
• Basic Execution Time Model (Musa): Models reliability based on actual CPU execution time rather than calendar time. As failures occur and are fixed, the intensity of failures decreases exponentially.

Part (b) Reliability and Hazard Formulas

• Hazard Rate \(Z(t)\): The instantaneous rate of failure at time \(t\), given that the system has survived up to time \(t\). For a constant failure rate \(\lambda\), \(Z(t) = \lambda\).
• Reliability \(R(t)\): The probability that the system survives without failure for a duration \(t\).
• Relationship: For a constant hazard rate \(\lambda\) (meaning failures occur randomly over time), reliability follows an exponential decay distribution:
  \[ R(t) = e^{-\lambda t} \]
• MTTF: The Mean Time To Failure is the inverse of the constant hazard rate: \(MTTF = \frac{1}{\lambda}\).

Master Answer: Component-Based Software Engineering

Part (a) CBSE and COTS

CBSE focuses on building systems by integrating pre-existing, reusable software components rather than writing everything from scratch. COTS (Commercial Off-The-Shelf) components are pre-built, third-party software packages (like an Oracle Database or a Stripe Payment Gateway SDK) that can be bought and integrated directly.

Part (b) Domain Engineering vs Composition

• Component Domain Engineering: The process of actually creating the reusable components. This involves identifying common functionalities across multiple applications in a specific domain, designing generalized components, and cataloging them in a repository for future use.
• Component Composition (Integration): The process of assembling the system using these components.
  Issues include:
  • Architectural Mismatch: The COTS component might assume a different architectural style (e.g., event-driven vs procedural) than the main system.
  • Interface Incompatibility: The component's API might require data formats or parameter types that differ from what the system provides. (Often solved using the Adapter Design Pattern).
  • Vendor Lock-in: Relying heavily on a proprietary COTS component makes it difficult to switch to a competitor later.

Master Answer: Case Study - Food Delivery Mobile App

Part (a) SDLC Trace

1. Elicitation: Interviews with restaurant owners and surveys with potential users.
2. Analysis & Design: Creating UML diagrams, defining microservices, designing UI/UX mockups.
3. Development: Building the Android/iOS frontend in Flutter and the backend in Node.js.
4. Testing: Unit testing APIs, Load testing the order matching algorithm, UI testing the app.
5. Deployment: Releasing to App Store/Play Store and monitoring via CI/CD pipelines.

Part (b) System Artifacts

1. SRS Outline:

• Functional: User registration, Restaurant menu browsing, Cart management, Live GPS tracking, Payment gateway integration.
• Non-Functional: 99.9% uptime, API response under 200ms, Secure credit card tokenization.

2. Level 1 DFD:

3. Architecture (Microservices): User Auth Service, Restaurant Catalog Service, Order Matching Service, Live Tracking Service, Payment Service.

4. Test Strategy: Automated unit tests for cart logic. Integration tests for Bank Gateway APIs. Field testing GPS tracking accuracy on physical mobile devices.

Master Answer: Intermediate COCOMO Cost Drivers

Part (a) Effort Calculation with Cost Drivers

The Intermediate COCOMO model refines the Basic model by introducing 15 Cost Drivers (Cost Multipliers) categorized into Product, Computer, Personnel, and Project attributes. These include things like "Required Reliability" or "Analyst Capability".

Formula:

\[ Effort = a_i \times (KLOC)^{b_i} \times EAF \]

Where \(EAF\) (Effort Adjustment Factor) is the product of all 15 Cost Driver Multipliers. (Note: The problem states they sum to 1.15, but traditionally EAF is a product. Assuming the prompt implies the final calculated \(EAF = 1.15\)).

Assuming an Organic project (Constants: \(a_i = 3.2, b_i = 1.05\)) and size = 32 KLOC:

\[ Effort = 3.2 \times (32)^{1.05} \times 1.15 \]

\[ Effort = 3.2 \times 38.05 \times 1.15 = 121.76 \times 1.15 = \mathbf{140.02 \text{ Person-Months}} \]

Notice the effort is significantly higher than the Basic model due to the penalty of the cost drivers (\(EAF > 1\)).

Part (b) Basic vs Intermediate vs Detailed COCOMO

• Basic COCOMO: Computes software development effort (and cost) as a function of program size expressed in estimated lines of code (KLOC). It is good for quick, rough estimates.
• Intermediate COCOMO: Computes effort as a function of program size and a set of 15 "Cost Drivers" that include subjective assessments of product, hardware, personnel, and project attributes.
• Detailed COCOMO: Incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each specific step of the software engineering process (e.g., Analysis, Design, Coding, Testing).

Master Answer: White-Box Path Testing

Part (a) Path Testing for Nested Loops

Path testing nested loops requires generating test cases that test the boundary conditions of the loops. Specifically: bypassing the loop entirely, executing the loop exactly once, executing the loop a typical number of times (\(m\)), executing the loop \(max-1\) times, and executing the loop exactly \(max\) times.

For nested loops, you hold the outer loop at a minimum value, test all bounds of the inner loop, then hold the inner loop at a typical value and test the bounds of the outer loop.

Part (b) 100% Branch and Statement Coverage

Assume the following code block:

• To achieve 100% Statement Coverage: We need to execute lines 2, 4, and 7.
  Test Case 1: A = 10, C = 0 (Executes lines 1, 2, 6, 7, 9)
  Test Case 2: A = 1, C = 1 (Executes lines 1, 3, 4, 6, 9)
  Statement Coverage achieved in 2 test cases.
• To achieve 100% Branch Coverage: We must evaluate (A>5) as True and False, and (C==0) as True and False.
  Test Case 1 (T, T): A = 10, C = 0
  Test Case 2 (F, F): A = 1, C = 1
  Branch coverage is also achieved with these same 2 test cases.

Master Answer: Agile Metrics and Estimation

Part (a) User Stories, Story Points, and Velocity

• User Story: A short, simple description of a feature told from the perspective of the user. Format: "As a [type of user], I want [some goal] so that [some reason]."
• Story Points: A relative unit of measure (usually Fibonacci numbers: 1, 2, 3, 5, 8, 13) used to estimate the effort required to fully implement a User Story. It accounts for volume, complexity, and uncertainty.
• Velocity: A metric that calculates how much work (in total Story Points) a team successfully completes during a single Sprint. It is used to forecast how many sprints it will take to clear the backlog.

Part (b) Planning Poker and Burndown Charts

• Planning Poker: A consensus-based estimation technique. The Product Owner reads a User Story. Developers privately select a card with a Story Point value. Everyone reveals their cards simultaneously. If estimates vary wildly (e.g., someone plays a 2 and another an 8), they debate their reasoning and re-vote until consensus is reached. This prevents anchoring bias.
• Burndown Chart: A visual graph showing the amount of work remaining (Y-axis, usually in Story Points or Hours) versus time (X-axis, days in the sprint). An "Ideal Trend" line is drawn diagonally down to zero. If the actual remaining work line sits above the ideal line, the team is behind schedule.

Master Answer: Formal Specification & Z Notation

Part (a) Algebraic vs Model-Based Specification

• Algebraic Specification: The system is specified in terms of operations and algebraic equations that define the relationships between those operations (axioms). It is highly abstract and doesn't rely on underlying state variables.
• Model-Based Specification (Z Notation): The system is modeled using mathematical entities like sets, sequences, and relations. It explicitly defines a "State Space" (variables) and how specific operations mutate that state.

Part (b) Z Specification for a Stack

In Z Notation, a specification is written in visual boxes called "Schemas".

(Note: In actual Z notation, mathematical symbols are used. \Delta indicates a state change. ? denotes an input. ' denotes the state after the operation).

Master Answer: UI/UX Engineering and Accessibility

Part (a) Principles and WCAG Standards

UI (User Interface) focuses on the visual layout and interactivity. UX (User Experience) focuses on the overall feel, flow, and logical journey of the user.

WCAG (Web Content Accessibility Guidelines): Principles to make software accessible to people with disabilities.

• Perceivable: Provide text alternatives for images (screen readers). Ensure high color contrast for the visually impaired.
• Operable: Make all functionality available from a keyboard (no mouse trap). Do not design content that causes seizures (no fast flashing).
• Understandable: Text must be readable. Error messages must explicitly state the problem and how to fix it.
• Robust: Content must be compatible with current and future assistive technologies.

Part (b) E-Learning Portal UI State Transition

State Transition Diagram:

Master Answer: DevOps and Automated Pipelines

Part (a) DevOps Culture

DevOps bridges the historical wall between developers (who want to push new features fast) and operations (who want stability and no changes). It relies on heavy automation, continuous monitoring, and a cultural shift towards shared responsibility.

Part (b) CI, CT, and CD Pipeline

• Continuous Integration (CI): Developers push code to GitHub. A CI server (like Jenkins or GitHub Actions) detects the push, automatically pulls the code, and builds the application.
• Continuous Testing (CT): Immediately after the build, automated Unit, Integration, and Security tests run. If any test fails, the pipeline halts, and the developer is alerted immediately.
• Continuous Deployment (CD): If all tests pass, the pipeline automatically packages the application (e.g., into a Docker container) and deploys it to the Production cloud environment (like AWS or Kubernetes) with zero downtime.

Master Answer: Software Fault Tree Analysis

Part (a) FTA vs FMEA

• Fault Tree Analysis (FTA): A Top-Down deductive analysis. You start with a catastrophic system failure (the "Top Event") and work backward through a logic tree (using AND/OR gates) to identify all the possible root causes that could lead to that failure.
• Failure Modes and Effects Analysis (FMEA): A Bottom-Up inductive analysis. You look at individual components at the lowest level, assume they fail (Failure Mode), and analyze what effect that failure will have on the overall system.

Part (b) Fault Tree for Medical Device Failure

Top Event: Pacemaker Delivers Fatal Shock

In this Fault Tree, the catastrophic event can happen if EITHER the software miscalculates OR the hardware relay breaks. For the software to miscalculate fatally, the sensor must read wrong AND the failsafe logic must simultaneously fail.

Master Answer: Static Analysis and Code Inspection

Part (a) Static Analysis & Linters

Static Analysis evaluates source code without executing it. Linters are automated tools (like SonarQube or ESLint) integrated into the IDE or CI pipeline. They enforce naming conventions, find dead code, detect memory leaks, and flag security vulnerabilities (like hardcoded API keys).

Code Review Checklists: Human reviewers use checklists during Pull Requests to check things automation cannot: Is the business logic correct? Is the architecture sound? Are the tests meaningful?

Part (b) Code Inspection Protocol

Formal Code Inspection (Fagan Inspection) involves strict roles:

1. Author: Wrote the code, listens and answers questions, but does not lead the review.
2. Moderator: Chairs the meeting, ensures the team stays on track, and logs defects.
3. Reader: Reads the code aloud line-by-line, explaining what it logically does.
4. Reviewers/Inspectors: Follow along and flag discrepancies between what the Reader says the code does and what the SRS requires.

Defect Tracking: Any identified bug is logged into a tracker (like Jira) with a unique ID, severity level, steps to reproduce, and assigned back to the Author for fixing.

Master Answer: Use Case Points (UCP) Estimation

Part (a) UCP Methodology

Use Case Points (UCP) is a software estimation technique used early in the SDLC when requirements are captured as UML Use Cases. It calculates size based on the complexity of Actors and Use Cases, modified by technical and environmental factors.

Part (b) UCP Calculation Formula

1. Calculate UAW (Unadjusted Actor Weight): Count the number of Simple (weight 1), Average (weight 2), and Complex (weight 3) Actors in the system. Sum them.
2. Calculate UUCW (Unadjusted Use Case Weight): Count the Use Cases based on the number of transactions they contain. Simple (weight 5), Average (weight 10), Complex (weight 15). Sum them.
3. UUCP (Unadjusted Use Case Points):
   \(UUCP = UAW + UUCW\)
4. Apply Factors: Evaluate 13 Technical Factors to get the TCF, and 8 Environmental Factors (team experience) to get the EF.
5. Final UCP:
   \(UCP = UUCP \times TCF \times EF\)
6. Calculate Effort: Multiply the final UCP by a productivity factor (e.g., 20 man-hours per UCP) to get the total estimated project hours.

Master Answer: Legacy System Modernization

Part (a) Modernization Strategies

Legacy systems are old, brittle, but mission-critical applications. Modernizing them reduces maintenance costs and allows integration with cloud technologies.

Part (b) Comparison of Strategies