Ans: Software Engineering is, per IEEE 610.12, the application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of software. It differs from mere programming by using engineering principles, defined processes and measurement to build large, reliable software economically within schedule and budget.

Ans: The Software Development Life Cycle (SDLC) is the structured sequence of phases — requirement analysis, design, coding, testing, deployment and maintenance — through which a software product passes from conception to retirement. It defines the deliverable and the verification criterion of each phase, so that progress is visible and controllable.

Ans: The Waterfall Model is a linear sequential life-cycle model in which each phase must be completed and its output document baselined before the next phase begins, with no overlapping of phases. It is chosen only when requirements are fixed, well understood and unlikely to change, since it produces no working software until late.

Ans: The Spiral Model (Boehm) is a risk-driven, evolutionary meta-model in which the product is developed in a series of spiral cycles, each cycle passing through four quadrants: objective setting, risk analysis and prototyping, engineering/development, and planning of the next cycle. Explicit risk analysis in every cycle makes it suitable for large, expensive, high-risk projects.

Ans: The Prototyping Model builds a quick, partially functional working model of the system so that the customer can evaluate it and refine the requirements through feedback, after which the prototype is either discarded (throwaway) or evolved into the product. It is chosen when the customer cannot state the requirements precisely at the outset.

Ans: Agile is an iterative and incremental development approach that delivers working software in short time-boxed iterations with continuous customer involvement and welcome of late requirement changes. The Agile Manifesto values individuals and interactions, working software, customer collaboration and responding to change over processes and tools, comprehensive documentation, contract negotiation and following a plan.

Ans: A Sprint is a fixed time-box in Scrum (usually 2–4 weeks, never more than one month) at the end of which a “Done”, potentially shippable product increment is delivered. Its scope is frozen once the Sprint begins, and each Sprint ends with a Sprint Review and a Sprint Retrospective.

Ans: The Product Backlog is the single, ordered and continuously evolving list of all known requirements, features, enhancements and fixes for the product. It is owned and prioritised by the Product Owner, and it lives for the entire life of the product.

Ans: The Sprint Backlog is the subset of Product Backlog items selected for the current Sprint together with the task-level plan for delivering them as an increment. It is owned by the Development Team (not the Product Owner) and exists only for the duration of that one Sprint.

Ans: The Software Requirement Specification (SRS) is the formal document that completely states the functional and non-functional requirements agreed between customer and developer, and acts as the contract and the baseline for design, testing and validation. A good SRS is complete, consistent, unambiguous, verifiable, modifiable and traceable — it says what the system must do, whereas the Software Design Document (SDD) says how it will do it.

Ans: A Functional Requirement specifies what the system must do — a particular service, behaviour or input-to-output transformation that the system shall perform. Example: “The ATM shall dispense cash after successfully verifying the customer’s PIN.”

Ans: A Non-Functional Requirement (NFR) specifies a quality attribute or constraint on how well the system performs its functions — performance, reliability, security, usability, portability, maintainability. It generally applies to the system as a whole rather than to one function, and must be stated in a measurable form, e.g. “response time shall be under 2 seconds for 95% of queries”.

Ans: Requirement Elicitation is the first activity of requirement engineering, in which requirements are discovered and gathered from stakeholders, existing systems and documents. Common techniques are interviews, questionnaires, brainstorming, FAST (Facilitated Application Specification Technique), observation, use-case workshops and prototyping.

Ans: A Use Case in UML is a description of a complete sequence of interactions between an actor and the system that yields an observable result of value to that actor. It is drawn as an ellipse in a use-case diagram and may be related to other use cases by «include», «extend» or generalisation.

Ans: A Data Flow Diagram (DFD) is a structured-analysis tool that graphically depicts the flow and transformation of data through a system using four symbols: process (bubble), data flow (arrow), data store (open rectangle) and external entity (square). The Level 0 (context) diagram shows the entire system as a single process with its external entities and no data stores, while the Level 1 DFD explodes that single process into its major sub-processes and data stores.

Ans: Cohesion is an intra-module measure of the degree to which the elements inside a single module belong together and contribute to one single, well-defined task. Its types run from worst to best as: coincidental, logical, temporal, procedural, communicational, sequential and functional cohesion (best).

Ans: Coupling is an inter-module measure of the degree of interdependence between two modules, i.e. the strength of the connection between them. Its types run from best (loosest) to worst as: data coupling (best), stamp, control, external, common and content coupling (worst).

Ans: High cohesion with low coupling is the fundamental goal of modular design: each module performs one well-defined function internally, while interacting with other modules as little as possible and only through simple, well-defined data interfaces. Such a design is easier to understand, test independently, reuse and maintain, because a change in one module produces little ripple effect on the others.

Ans: Modularity is the decomposition of software into separately named and addressable components (modules) that can be designed, coded and tested independently and then integrated to satisfy the requirements. Pressman notes that the effort per module falls as the number of modules grows while the integration effort rises, so there is an optimum number of modules giving minimum total cost.

Ans: Software Architecture is the overall structure of the system — the set of software components, their externally visible properties and the relationships and interactions among them. It represents the earliest and hardest-to-change design decisions; common architectural styles are layered, client–server, pipe-and-filter, repository (data-centred) and MVC.

Ans: Cyclomatic Complexity, proposed by McCabe, is a quantitative measure of the logical complexity of a program, defined as the number of linearly independent paths through its control flow graph. It gives the upper bound on the number of test cases needed for basis-path testing and the lower bound on the number of paths that must be executed for branch coverage; a module with \( V(G) > 10 \) is regarded as too complex and a candidate for redesign.

Ans: For a control flow graph \( G \), McCabe’s formula is \( V(G) = E - N + 2P \), where \( E \) = number of edges, \( N \) = number of nodes and \( P \) = number of connected components (\( P = 1 \) for a single program, giving \( V(G) = E - N + 2 \)). Two equivalent forms are \( V(G) = D + 1 \), where \( D \) is the number of decision (predicate) nodes, and \( V(G) = R \), the total number of regions into which the planar flow graph divides the plane, i.e. the bounded regions plus the one outer unbounded region.

Ans: White-box testing (glass-box or structural testing) derives test cases from knowledge of the internal logic and source code of the module, so as to exercise statements, branches, conditions, independent paths and loops. Basis-path testing uses \( V(G) = E - N + 2 \) to fix the number of independent paths that must be tested, and it is normally performed by developers at the unit level.

Ans: Black-box testing (functional or behavioural testing) derives test cases only from the specified input–output behaviour in the SRS, with no knowledge of the internal code structure. Its standard techniques are equivalence partitioning, boundary value analysis, decision tables, cause–effect graphing and state-transition testing.

Ans: Unit Testing is the testing of the smallest testable component — a single module, function or class — in isolation from the rest of the system. It is predominantly white-box, is carried out by the developer, and uses stubs and drivers to stand in for the modules that the unit calls and is called by.

Ans: Integration Testing tests the interfaces and interactions between modules that have already passed unit testing, so as to expose defects arising from their combination rather than from within a module. Its strategies are big-bang, top-down (needs stubs), bottom-up (needs drivers) and sandwich/hybrid integration.

Ans: System Testing is black-box testing of the complete, fully integrated software in an environment resembling production, validating it against the SRS as a whole. It covers functional behaviour together with non-functional aspects — performance, load, stress, security, recovery and usability — and is normally carried out by an independent test team.

Ans: Acceptance Testing is formal testing carried out by the customer or end user against pre-agreed acceptance criteria to decide whether the delivered system is acceptable. It follows system testing, is entirely black-box and driven by user requirements rather than the SRS alone, and takes the two forms alpha and beta testing.

Ans: Alpha Testing is acceptance testing performed by the customer or potential users at the developer’s site in a controlled environment, with the developer present and recording errors and usage problems as they occur. It always precedes beta testing.

Ans: Beta Testing is a “live” test performed by real end users at their own sites in an uncontrolled environment, with the developer not present. The users report the problems they encounter at intervals, and the developer makes final modifications before general release.

Ans: Equivalence Partitioning is a black-box technique that divides the input domain into classes (partitions) whose members the program is expected to treat identically, so that testing one representative value from each valid and invalid class is as effective as testing every member. It sharply reduces the number of test cases without losing functional coverage.

Ans: Boundary Value Analysis (BVA) is a black-box technique that complements equivalence partitioning by choosing test values at and just around the edges of each partition, since defects cluster at boundaries rather than in the middle of a range. For an input range \( [a,\,b] \) the test values are \( a-1,\ a,\ a+1,\ b-1,\ b,\ b+1 \).

Ans: Regression Testing is the re-execution of a selected subset of previously passed test cases after a modification (bug fix, enhancement or environment change), to confirm that the change has not introduced new defects in the unchanged parts of the software. It differs from retesting, which re-runs only the specific failed test case to verify that one particular reported defect is now fixed.

Ans: Smoke Testing is a shallow-and-wide “build verification” test that exercises only the critical end-to-end functionality of a newly integrated build, in order to decide whether the build is stable enough to be accepted for detailed testing. If the smoke test fails the build is rejected outright and returned to development.

Ans: Sanity Testing is a narrow-and-deep, usually unscripted check made on a relatively stable build to verify that a particular bug fix or newly added function works and that the surrounding area behaves rationally, before committing to full regression testing. It is thus a subset of regression testing, whereas smoke testing is a check on the acceptability of the build itself.

Ans: A Stub is a dummy called (lower-level) module that simulates a subordinate module by returning a canned result, and is required in top-down integration testing. A Driver is a dummy calling (higher-level) module that invokes the module under test with test inputs and displays the results, and is required in bottom-up integration testing.

Ans: COCOMO (Constructive Cost Model), developed by Barry Boehm, is an algorithmic cost-estimation model that predicts effort and schedule from the estimated size of the product in KLOC (thousands of delivered lines of code). Basic COCOMO gives effort \( E = a\,(KLOC)^{b} \) person-months and development time \( D = c\,(E)^{d} \) months, so average staff size \( = E/D \) persons. The coefficients depend on the project mode, chosen by team and product size and by the rigidity of the constraints:

• Organic — small (< 50 KLOC), familiar in-house project, small experienced team, flexible requirements: \( a = 2.4,\ b = 1.05,\ c = 2.5,\ d = 0.38 \).
• Semi-detached — medium (50–300 KLOC), mixed-experience team, medium constraints: \( a = 3.0,\ b = 1.12,\ c = 2.5,\ d = 0.35 \).
• Embedded — large (> 300 KLOC), tight hardware, software and regulatory constraints (e.g. real-time/avionics): \( a = 3.6,\ b = 1.20,\ c = 2.5,\ d = 0.32 \).

Ans: Function Point (FP) analysis is Albrecht’s size metric that measures the functionality delivered to the user independently of the programming language, by counting five function types — External Inputs, External Outputs, External Inquiries, Internal Logical Files and External Interface Files — each weighted as simple, average or complex to give the Unadjusted Function Points. The final size is \( FP = UFP \times VAF \), where \( VAF = 0.65 + 0.01 \sum_{i=1}^{14} F_i \) and each of the 14 general system characteristics \( F_i \) is rated from 0 to 5.

Ans: Software Reliability is the probability of failure-free operation of a program in a specified environment for a specified period of time. For a constant failure rate \( \lambda \) it is given by \( R(t) = e^{-\lambda t} \), and in practice it is measured through MTBF, failure intensity or defect density \( = \dfrac{\text{Number of defects}}{\text{Size (KLOC or FP)}} \).

Ans: Mean Time Between Failures (MTBF) is the average time elapsing between two consecutive failures of a repairable system, and therefore includes both the operating time and the repair time: \( MTBF = MTTF + MTTR \). System availability follows as \( \text{Availability} = \dfrac{MTTF}{MTTF + MTTR} \times 100\% \).

Ans: Mean Time To Failure (MTTF) is the average time for which the system operates correctly, from the instant it is started or restored until the next failure occurs — i.e. the pure up-time component of MTBF. It excludes repair time and is the measure normally used for non-repairable items.

Ans: Mean Time To Repair (MTTR) is the average time taken to detect, diagnose and correct a failure and restore the system to service — i.e. the down-time component of \( MTBF = MTTF + MTTR \). It is a measure of maintainability rather than of reliability.

Ans: Software Quality Assurance (SQA) is the umbrella set of planned and systematic activities — standards and procedures, reviews and inspections, audits, process definition, measurement and reporting — that give management confidence that the product will conform to its requirements. SQA is process-oriented and preventive, whereas quality control (testing) is product-oriented and detective.

Ans: CMMI (Capability Maturity Model Integration) is the SEI’s process-improvement framework that assesses and rates the maturity of an organisation’s software processes. Its five staged maturity levels are 1 Initial, 2 Managed (Repeatable), 3 Defined, 4 Quantitatively Managed and 5 Optimising.

Ans: Software Maintenance is the modification of a software product after delivery to correct faults, to adapt it to a changed environment, or to improve its performance and other attributes (IEEE 1219). It consumes roughly 60–70% of the total life-cycle cost and is classified as corrective, adaptive, perfective and preventive maintenance.

Ans: Corrective Maintenance is the reactive modification carried out to diagnose and remove residual faults (errors) discovered in the software after delivery. It restores the software to its specified behaviour and accounts for roughly 20% of total maintenance effort.

Ans: Adaptive Maintenance is the modification carried out to keep a working software product usable in a changed or changing environment — a new operating system, hardware platform, DBMS or compiler, or a change in statutory and regulatory rules. It neither fixes reported bugs nor adds user-requested features.

Ans: Perfective Maintenance is the modification carried out to add new functionality requested by the user, or to improve the performance, usability or maintainability of software that is already working correctly. It is the largest category, absorbing about 50% of the total maintenance effort.

Ans: Preventive Maintenance is the proactive modification carried out to detect and correct latent faults before they manifest as failures, and to make the software easier to maintain in future — for example re-documentation, code restructuring, refactoring and optimisation. It is not a response to any reported problem.

Ans: Software Re-engineering is the examination and alteration of an existing legacy system so as to reconstitute it in a new, more maintainable form without changing its external functionality. It typically proceeds as inventory analysis → reverse engineering → restructuring and re-documentation → forward engineering.

Ans: Reverse Engineering is the process of analysing an existing program or executable in order to recover its design, data structures and specification at a higher level of abstraction — that is, a design-recovery process. It only extracts information and produces documentation and does not alter the subject system, unlike re-engineering.

Ans: A CASE (Computer-Aided Software Engineering) Tool is automated software that supports one or more software-engineering activities. Upper CASE tools support planning, analysis and design (diagram editors, data dictionaries), lower CASE tools support coding, testing and maintenance (code generators, debuggers, test harnesses), and I-CASE integrates both across the whole life cycle.

Classical Waterfall Model

The Classical Waterfall Model is the oldest and simplest Software Development Life Cycle (SDLC) model. It is a linear-sequential model where progress flows strictly downwards through distinct phases.

• Advantages: Simple to understand. Easy to manage because each phase has specific deliverables and a review process. Phases are completed one at a time without overlap.
• Limitations: Highly inflexible. Once a phase is finished, you cannot go back (no feedback loops). High risk of failure if initial requirements are misunderstood. No working software is produced until late in the lifecycle.
• Suitability: Best for small projects with crystal clear, frozen requirements (like a simple payroll system).

Spiral Model

The Spiral Model (proposed by Barry Boehm) is a risk-driven iterative software development process. It combines the systematic aspects of the Waterfall model with the iterative nature of the Prototyping model.

The project is developed in continuous loops (spirals). Each loop represents a phase of the process and consists of 4 quadrants:

1. Determine Objectives: Identify specific goals, alternatives, and constraints for the current iteration.
2. Identify & Resolve Risks: Evaluate alternatives relative to objectives and constraints. The core of this quadrant is building prototypes to mitigate technical and market risks.
3. Development & Testing: Develop the next version of the product (similar to the standard waterfall phases for that iteration).
4. Plan Next Phase: Review the iteration's output with the customer and plan the next spiral based on feedback.

Suitability: Ideal for large, expensive, and complex projects (e.g., aerospace software) where risk mitigation is paramount.

Prototyping Model

The Prototyping Model involves building a working, simplified version (a prototype) of the software before developing the actual final product. This prototype is used to understand requirements better.

Workflow

1. Initial Requirements: Gather basic requirements from the client.
2. Quick Design & Build: Rapidly design and develop a prototype focusing on the user interface and core functionality (ignoring performance, security, and maintainability).
3. Customer Evaluation: The client uses the prototype and provides feedback.
4. Refine Prototype: The prototype is modified based on feedback until the client is satisfied.
5. Develop Final Product: Once the prototype is approved, it serves as the definitive specification for building the actual software using a rigorous SDLC (like Waterfall). The initial prototype is usually thrown away (Throwaway Prototyping).

Suitability: Highly suitable when the client is unsure about their exact requirements, or for systems with complex User Interfaces.

Agile Scrum Framework

Scrum is a popular Agile framework that breaks software development into short, time-boxed iterations called Sprints (usually 2-4 weeks long).

1. Roles

• Product Owner: Represents the customer. Owns the Product Backlog and prioritizes features.
• Scrum Master: A servant-leader who ensures the team follows Scrum practices and removes any impediments blocking the team.
• Development Team: A self-organizing, cross-functional team of developers, testers, and designers who build the product.

2. Artifacts

• Product Backlog: A master list of all desired features, bug fixes, and requirements, prioritized by the Product Owner.
• Sprint Backlog: The subset of items from the Product Backlog chosen by the team to be completed in the current Sprint.

3. Events

• Sprint Planning: Meeting to define what will be done in the Sprint.
• Daily Standup: A 15-minute daily meeting where team members answer: What did I do yesterday? What will I do today? Are there any blockers?
• Sprint Review: Meeting at the end of the Sprint to demo the working software to stakeholders.
• Sprint Retrospective: Meeting to reflect on the Sprint process and identify improvements for the next one.

Characteristics of a Good SRS Document

A Software Requirement Specification (SRS) is a formal document detailing what the software must do. To be effective, an SRS must be:

1. Correct: Every requirement stated must accurately reflect what the customer actually wants. There should be no technical errors in the specifications.
2. Complete: It must include all significant requirements (functional, non-functional, constraints, interfaces). No feature expected by the client should be missing.
3. Unambiguous: Every requirement must have one, and only one, interpretation. Language should be precise; vague terms like "fast," "user-friendly," or "good" should be avoided.
4. Verifiable (Testable): A requirement is verifiable if there exists a finite, cost-effective process to check whether the final software meets that requirement. (e.g., Instead of "system should be fast", use "system must respond within 2 seconds").
5. Consistent: No two requirements should contradict each other.
6. Traceable: It should be easy to trace the origin of each requirement and track it through design, code, and testing phases.

Requirement Elicitation Techniques

Requirement Elicitation is the process of gathering requirements directly from stakeholders, users, and customers. It is the most critical step in requirement engineering.

• Interviews: Direct face-to-face (or virtual) conversations with stakeholders.
  • Structured: Following a strict predefined list of questions.
  • Unstructured: Open-ended discussions allowing the stakeholder to express their vision freely.
• Questionnaires / Surveys: Useful when there is a massive user base (e.g., thousands of employees) spread across different locations. It helps gather quantitative data efficiently, though it lacks deep qualitative insights.
• Prototyping: Building a quick, interactive mockup of the proposed system. Users interact with the prototype and provide immediate, concrete feedback on what they like, dislike, or feel is missing. This is highly effective for resolving ambiguous requirements.
• Brainstorming: Group sessions where stakeholders and developers freely generate ideas without immediate criticism.

Data Flow Diagrams (DFD)

A DFD is a graphical representation of the flow of data through an information system. It focuses purely on data movement, ignoring control flow (like loops and if-statements).

Notation Rules

• Circle/Bubble: Represents a Process (a function that transforms data).
• Arrow: Represents Data Flow (movement of data). Must be labeled.
• Parallel Lines: Represents a Data Store (database or file).
• Rectangle/Square: Represents an External Entity (source or sink of data, like a User or an External API).

Leveling

DFDs are constructed hierarchically (Top-Down Approach):

• Level 0 (Context Diagram): Shows the entire system as a single process bubble interacting with external entities. Gives a high-level overview.
• Level 1: Decomposes the Level 0 process into its major sub-processes, showing internal data stores and data flows between these sub-processes.
• Level 2+: Further decomposes complex Level 1 processes into more granular sub-processes.

Use Case Diagrams

In UML, a Use Case Diagram models the dynamic behavior of a system by showing the interactions between external Actors (stick figures) and the system's Use Cases (ovals).

Relationships between Use Cases

• <<include>>: Used when one use case always requires the functionality of another use case to complete its task. It represents mandatory, reusable behavior.
  Example: (Withdraw Money) --<<include>>--> (Verify PIN). You cannot withdraw money without verifying the PIN.
• <<extend>>: Used when a use case optionally adds functionality to a base use case under specific conditions. It represents optional or exceptional behavior. The arrow points from the extending (optional) use case to the base use case.
  Example: (Print Receipt) --<<extend>>--> (Withdraw Money). Printing a receipt only happens if the user specifically requests it during withdrawal.

Cohesion in Software Design

Cohesion measures the degree to which the elements inside a single module belong together. High cohesion is desired.

Types of Cohesion (from Best to Worst):

1. Functional Cohesion (Best): All elements in the module execute a single, well-defined task (e.g., a function calculateTax()).
2. Sequential Cohesion: The output of one element acts as the input for the next element within the same module (like an assembly line).
3. Communicational Cohesion: Elements operate on the same core data structure, but perform different operations.
4. Procedural Cohesion: Elements are grouped because they always execute in a specific sequence, even if they process different data.
5. Temporal Cohesion: Elements are grouped solely because they must execute at the same time (e.g., an initializeAll() function that boots up the database, clears the screen, and loads user config).
6. Logical Cohesion: Elements perform logically similar tasks (like all input routines) but are controlled by a flag passed by the caller.
7. Coincidental Cohesion (Worst): Elements are grouped completely randomly with no meaningful relationship.

Coupling in Software Design

Coupling measures the degree of interdependence between two different modules. Low (Loose) coupling is desired.

Types of Coupling (from Worst to Best):

1. Content Coupling (Worst): One module directly modifies or accesses the internal local data or code of another module. A nightmare for maintainability.
2. Common Coupling: Multiple modules share access to the same Global Data (global variables). Changing the global data structure forces changes in all connected modules.
3. Control Coupling: One module passes a control flag (like a boolean) to another module, dictating its internal execution logic.
4. Stamp Coupling: Modules pass complex composite data structures (like a massive Struct or Object), but the receiving module only actually needs a few specific fields from it.
5. Data Coupling (Best): Modules communicate strictly by passing simple, fundamental data types (like an int or string) via parameters. The receiving module uses all the data it is given.

Cyclomatic Complexity Calculation

Cyclomatic Complexity V(G) is a software metric used to indicate the complexity of a program. It directly measures the number of linearly independent paths through a program's source code.

Calculation Methods

Given a Control Flow Graph (CFG) of the code:

1. Edge/Node Formula: \(V(G) = E - N + 2P\)
   Where \(E\) = Number of edges, \(N\) = Number of nodes, \(P\) = Number of connected components (usually 1 for a single program).
2. Predicate Node Formula: \(V(G) = D + 1\)
   Where \(D\) = Number of predicate (decision) nodes (like if, while, for).
3. Region Formula: \(V(G) = R\)
   Where \(R\) = Number of regions in the planar flow graph (including the 1 infinite outer region).

Example: A simple if-else statement has 1 decision node (the if condition). Therefore, \(V(G) = 1 + 1 = 2\). There are exactly 2 independent paths (the true branch and the false branch).

White-Box Testing Techniques

White-Box testing involves testing the internal structures, logic, and code of the software rather than its external functionality. The tester must know programming.

• Statement Coverage: Designing test cases so that every single line of code (statement) in the program is executed at least once. It is the weakest metric (e.g., it might miss an empty else branch).
• Branch Coverage (Decision Coverage): Designing test cases so that every possible outcome (True and False) of all decision nodes (if, while) is executed at least once. It guarantees statement coverage.
• Path Coverage: Designing test cases to execute every possible independent execution path through the code from start to finish. The number of required test cases is exactly equal to the Cyclomatic Complexity \(V(G)\). This is the strongest metric but often impractical for large programs with loops.

Black-Box Testing Techniques

Black-Box testing focuses entirely on the inputs and outputs of the software without looking at the internal code. The goal is to verify the software meets its requirements.

• Equivalence Partitioning: Divides the input domain into "classes" (partitions) of equivalent data. The assumption is that if one value in a partition works, all values in that partition will work.
  Example: An age field accepting 18 to 60. Partitions: Invalid (< 18), Valid (18-60), Invalid (> 60). Test cases: 15, 30, 75.
• Boundary Value Analysis (BVA): An extension of Equivalence Partitioning. Since bugs frequently occur at the boundaries of input ranges, BVA specifically tests the exact boundary values and the values just inside and just outside the boundaries.
  Example: For age 18 to 60. Test cases: 17, 18, 19, 59, 60, 61.

Integration Testing: Top-Down vs Bottom-Up

Integration testing verifies that individually tested modules work correctly when combined together.

• Top-Down Integration: Testing starts from the main control module and moves downwards to subordinate modules.
  • Stubs: Since lower-level modules might not be developed yet, "Stubs" are used. A stub is a dummy program that simulates the behavior of the missing lower-level module.
  • Pros: Major design flaws at the top are caught early.
• Bottom-Up Integration: Testing starts from the lowest-level atomic modules and moves upwards to the main control module.
  • Drivers: Since the upper-level control modules might not be developed, "Drivers" are used. A driver is a dummy program that passes test cases down to the module being tested.
  • Pros: Easy to test utility modules thoroughly. No need for complex stubs.

Basic COCOMO Model

The Constructive Cost Model (COCOMO), developed by Barry Boehm, is an algorithmic model used to estimate the Effort and Time required to develop a software project based on its estimated size in Kilo Lines of Code (KLOC).

Formulas

1. Effort (E): Measured in Person-Months (PM).
   \(E = a \times (KLOC)^b\)
2. Development Time (Tdev): Measured in Months (M).
   \(T_{dev} = c \times (E)^d\)

Project Modes (Constants a, b, c, d)

• Organic: Small team, familiar environment. (a=2.4, b=1.05, c=2.5, d=0.38)
• Semi-Detached: Medium size, mixed experience. (a=3.0, b=1.12, c=2.5, d=0.35)
• Embedded: Complex, hardware constraints, tight regulations. (a=3.6, b=1.20, c=2.5, d=0.32)

Function Point Analysis (FPA)

FPA is a method to estimate the size of a software project based on the functionality it provides to the user, rather than counting Lines of Code (LOC), which is language-dependent.

Components

The system is evaluated based on 5 functional parameters, each rated as Simple, Average, or Complex:

1. External Inputs (EI): Screens/forms where users input data into the system.
2. External Outputs (EO): Reports/screens where the system outputs data to the user.
3. External Inquiries (EQ): Simple queries that retrieve data without updating files.
4. Internal Logical Files (ILF): Databases/files maintained entirely within the system.
5. External Interface Files (EIF): Files read by the system but maintained by another external system.

Calculation: Calculate the Unadjusted Function Points (UFP) by summing the weighted components. Then multiply UFP by the Value Adjustment Factor (VAF) to get the final FP count.

Project Scheduling: Gantt Chart vs PERT/CPM

Risk Management Process

Risk Management is a proactive approach to dealing with uncertain events that could negatively impact the software project.

1. Risk Identification: Systematically brainstorming potential risks (e.g., technology failures, staff turnover, requirement changes).
2. Risk Analysis (Projection): Assessing each identified risk based on two metrics:
   • Probability: The likelihood of the risk occurring (e.g., 10%).
   • Impact: The severity of the damage if it occurs (e.g., 1 to 5 scale).
   • Risk Exposure = Probability × Impact.
3. Risk Planning (Mitigation): Developing strategies to reduce the probability or impact of the highest-exposure risks (e.g., training staff, buying backup servers).
4. Risk Monitoring: Continuously tracking the identified risks throughout the project lifecycle to see if their probability is increasing, and executing contingency plans if they occur.

Software Quality Assurance (SQA)

SQA encompasses the entire software development process, monitoring and improving the process to ensure that the final product meets specified quality standards.

Key SQA Activities:

• Process Definition & Improvement: Establishing standard SDLC processes, coding standards, and methodologies (like Agile or CMMI) and continuously improving them.
• Formal Technical Reviews (FTR): Conducting structured peer reviews and code walkthroughs to find defects early before formal testing.
• Auditing: Checking if the development team is actually following the defined organizational processes and standards.
• Testing Management: Overseeing the testing strategy (unit, integration, system testing) to ensure adequate test coverage.
• Configuration Management: Ensuring all changes to code and documents are tracked and controlled properly via version control systems.

Capability Maturity Model Integration (CMMI)

CMMI is a framework that assesses the maturity and quality of an organization's software development processes across 5 levels:

1. Level 1 (Initial): Processes are unpredictable, poorly controlled, and reactive. Success depends entirely on individual heroics.
2. Level 2 (Managed): Processes are planned, documented, and monitored at the project level. Basic project management (requirements, scheduling) is in place.
3. Level 3 (Defined): Processes are standardized and documented across the entire organization. Projects tailor these standard processes for their specific needs.
4. Level 4 (Quantitatively Managed): The organization uses statistical and quantitative techniques to measure process performance and control quality precisely.
5. Level 5 (Optimizing): The organization focuses on continuous process improvement through quantitative feedback and adopting innovative new technologies.

Types of Software Maintenance

Software maintenance is the process of modifying software after delivery to correct faults, improve performance, or adapt it to a changing environment. It consumes the majority of the software lifecycle cost.

• Corrective Maintenance: Reactive modification to fix discovered bugs and errors that prevent the software from functioning as specified. (e.g., Fixing a crash when users enter a negative number).
• Adaptive Maintenance: Modifying the software to keep it usable in a changing environment, such as a new OS version, updated hardware, or a new database schema. (e.g., Updating an iOS app to work with iOS 18).
• Perfective Maintenance: Enhancing the software by adding new features, improving the UI, or increasing performance based on user requests. (e.g., Adding a "Dark Mode" feature).
• Preventive Maintenance: Modifying the software to prevent potential future problems. This involves code refactoring, optimizing database queries, and updating deprecated libraries before they break.

Software Re-engineering & Reverse Engineering

Software Re-engineering is the process of examining, altering, and rebuilding an existing legacy system to reconstitute it in a new form without changing its overall functionality.

Re-engineering Pipeline:

1. Inventory Analysis: Sorting through legacy applications to decide which ones need re-engineering based on business value and maintenance cost.
2. Document Restructuring: Updating outdated documentation to match the current state of the system.
3. Reverse Engineering: Analyzing the legacy source code to extract higher-level design documents (like UML class diagrams and DFDs). It moves backwards through the SDLC (Code → Design → Requirements).
4. Code/Data Restructuring: Refactoring spaghetti code into structured programming and normalizing legacy databases, keeping the same architecture.
5. Forward Engineering: Using the recovered design documents to build a completely new, modern system (e.g., rewriting a legacy COBOL mainframe app into a modern Java/React microservice).

Verification vs. Validation

Formal Technical Reviews (FTR)

An FTR is a highly structured group meeting conducted by software engineers to uncover errors in logic, function, or implementation early in the process.

Goals of FTR:

• Uncover errors early (cheaper to fix).
• Ensure the software meets predefined standards.
• Make projects more manageable by creating milestones.

Code Walkthroughs:

A specific type of FTR where the author of the code leads the review team through a manual simulation of the code execution. The review team acts as a "human compiler," feeding test data into the logic to find edge cases, infinite loops, and logic errors. It is a form of static White-Box testing.

Software Architecture Styles

• Layered Architecture: The system is organized into hierarchical layers (e.g., Presentation Layer → Business Logic Layer → Data Access Layer). Each layer only communicates with the layer directly below it. Pros: Excellent separation of concerns.
• Client-Server Architecture: The system is divided into two parts: Clients (which request services) and Servers (which provide services over a network). Pros: Centralized data management and security.
• Microservices Architecture: A large application is broken down into a suite of small, loosely coupled, independently deployable services that communicate via lightweight APIs (REST/gRPC). Pros: Highly scalable and resilient; different teams can use different tech stacks.

SOLID Principles of Object-Oriented Design

SOLID is an acronym for five design principles intended to make software designs more understandable, flexible, and maintainable.

• S - Single Responsibility Principle: A class should have one, and only one, reason to change. (It should only do one specific job).
• O - Open/Closed Principle: Software entities should be open for extension (adding new features), but closed for modification (don't change existing working code).
• L - Liskov Substitution Principle: Subtypes must be completely substitutable for their base types without altering the correctness of the program.
• I - Interface Segregation Principle: Clients should not be forced to depend on interfaces they do not use. (Better to have many small, specific interfaces than one massive, generic one).
• D - Dependency Inversion Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces).

Software Design Patterns

Design patterns are typical, reusable solutions to common problems in software design.

• Creational Patterns: Deal with object creation mechanisms, creating objects in a manner suitable to the situation.
  Example (Singleton): Ensures a class has only one instance and provides a global point of access to it (e.g., a Database Connection pool).
• Structural Patterns: Deal with object composition, helping to ensure that if one part of a system changes, the entire structure does not need to do so.
  Example (Adapter): Allows incompatible interfaces to work together (like a plug adapter).
• Behavioral Patterns: Deal with communication and assignment of responsibilities between objects.
  Example (Observer): A publish-subscribe model where multiple objects listen and react to state changes in a subject.

Golden Rules of UI Design

Theo Mandel proposed three "Golden Rules" for designing effective User Interfaces:

1. Place the User in Control: Do not force users into rigid sequences. Allow users to undo actions easily. Hide technical internals from the casual user. Provide shortcuts for power users.
2. Reduce the User's Memory Load: The system should remember things so the user doesn't have to. Use recognizable visual cues (icons) rather than requiring the user to recall commands. Follow the "Rule of 7" (human short-term memory can hold roughly 7 items).
3. Make the Interface Consistent: Keep layout, colors, typography, and button placements uniform across all screens. Follow established platform standards (e.g., a "Save" icon should always look like a floppy disk; red usually means "Delete" or "Error").

Software Metrics

Software metrics provide a quantitative basis for the development and management of software.

• Size Metrics: Measure the physical size of the product. The most common is LOC (Lines of Code) or KLOC (Thousands of Lines of Code). Alternatively, Function Points (FP) measure the functionality provided to the user.
• Complexity Metrics: Measure the logical complexity of the code. The most famous is McCabe's Cyclomatic Complexity \(V(G)\), which counts the number of independent paths through the code. High complexity correlates with high bug rates.
• Quality (Defect) Metrics:
  • Defect Density: Number of defects found per KLOC (Defects / KLOC). Lower is better.
  • Defect Removal Efficiency (DRE): A measure of how effectively the QA team finds bugs before shipping.

Software Configuration Management (SCM)

SCM is the discipline of managing, organizing, and controlling changes to software assets (code, documents, diagrams) over time.

Key SCM Activities:

• Version Control (VCS): Tracking every single change made to source code. Systems like Git allow developers to branch off, experiment, and merge code back together without destroying the main project.
• Change Control: A formal process to evaluate, approve, and implement change requests from clients.
• Configuration Audit: Verifying that the software product matches its baseline requirements.
• Release Management: Packaging the software, generating version numbers (e.g., v1.4.2), and distributing it to users.

Fault, Error, and Failure

These terms represent the chronological sequence of a software defect:

1. Error (Mistake): A human action that produces an incorrect result. (e.g., A programmer misunderstands a requirement or makes a typo in the code).
2. Fault (Defect/Bug): The manifestation of an error in the software code or documentation. A fault is a static defect in the code (e.g., if (x = 5) instead of if (x == 5)). A fault may remain dormant forever if that specific code block is never executed.
3. Failure: The observable, incorrect behavior of the software when a fault is actually executed by the CPU. The software fails to perform its required function.

Relationship: An Error made by a human causes a Fault in the code, which, when executed under specific conditions, results in a system Failure.

System Testing: Non-Functional Types

System testing validates the fully integrated software product against its requirements. Non-functional testing focuses on how well the system performs.

• Performance Testing: Testing the system's speed, responsiveness, and stability under a normal expected workload. (e.g., Does the page load in under 2 seconds for 100 concurrent users?)
• Load Testing: Testing the system's behavior when subjected to the maximum expected concurrent user load. It checks if the system can handle its peak designed capacity.
• Stress Testing: Pushing the system beyond its maximum designed capacity until it breaks. The goal is to see how the system fails (does it crash gracefully or corrupt data?) and how it recovers.
• Security Testing: Evaluating the system's vulnerability to malicious attacks, unauthorized access, SQL injections, and data breaches.

Cleanroom Software Engineering

Cleanroom software engineering is a formal, mathematically-based approach focused on defect prevention rather than defect removal.

Core Principles:

1. Formal Specification: The software requirements are mathematically modeled using state-box, clear-box, and black-box specifications.
2. Incremental Development: The product is developed in small, verifiable increments.
3. Statistical Testing: Instead of traditional unit testing, the software undergoes statistical use testing based on usage probability distributions.
4. No Execution by Developers: Developers write the code and verify it mathematically (using correctness proofs), but they are not allowed to compile or execute it. An independent certification team tests the final integrated code.

Software Reliability and MTBF

Software Reliability is the probability that a software system will fulfill its intended function without failure for a specified period of time in a specified environment.

Key Metrics:

• MTTF (Mean Time To Failure): Average time the software operates continuously before failing.
• MTTR (Mean Time To Repair): Average time taken to fix the fault after a failure occurs.
• MTBF (Mean Time Between Failures): \(MTBF = MTTF + MTTR\). It represents the average time between two consecutive failures.
• Availability: The probability that the system is operating successfully at any given moment. \(Availability = \frac{MTTF}{MTBF} \times 100\%\).

Reliability Models: Models like the Jelinski-Moranda model or the Goel-Okumoto model use statistical formulas to predict future reliability and failure rates based on historical testing data.

Code Refactoring

Refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.

Common Techniques:

• Extract Method: Taking a long, complex function and breaking it into several smaller, well-named helper functions.
• Rename Variable: Giving variables descriptive names instead of vague ones (e.g., changing x to customerAge).
• Replace Magic Number with Symbolic Constant: Replacing hardcoded numbers with named constants (e.g., replacing 3.14 with PI).

Benefits:

Improves code readability, reduces cyclomatic complexity, makes the code easier to maintain and extend, and helps uncover hidden bugs.

Static Analysis and Code LINTing

Static Analysis is the automated checking of source code without actually compiling or executing it.

Code LINTing: A specific type of static analysis. A "linter" (like ESLint for JavaScript or SonarQube) scans the source code to flag:

• Stylistic Errors: Deviations from team coding standards (e.g., missing semicolons, wrong indentation).
• Programming Errors: Potential bugs like using uninitialized variables, unreachable code, or infinite loops.
• Security Flaws: Hardcoded passwords or vulnerable dependencies.

Benefits: Enforces code quality automatically, catches silly mistakes early before they reach code review, and trains junior developers on best practices.

Component-Based Software Engineering (CBSE)

CBSE is a paradigm that emphasizes the design and construction of software systems using reusable, independent, off-the-shelf software components.

Key Concepts:

• Component: A self-contained, deployable software package that provides a specific functionality through well-defined interfaces (e.g., a pre-built payment processing module).
• Interface: Components interact exclusively through standard interfaces, making their internal implementations completely hidden (black-box).

Benefits: Drastically reduces development time and cost, improves reliability (since components are already heavily tested), and simplifies maintenance (components can be swapped out easily without affecting the rest of the system).

DevOps and CI/CD Pipeline

DevOps is a culture and set of practices that combines Software Development (Dev) and IT Operations (Ops) to shorten the development lifecycle and provide continuous delivery of high-quality software.

CI/CD Pipeline:

• Continuous Integration (CI): Developers frequently merge their code changes into a central repository (like GitHub). Automated builds and unit tests run immediately upon every commit to detect integration errors instantly.
• Continuous Delivery (CD): The automated process of preparing the tested code for release to production. The software is always in a deployable state.
• Continuous Deployment: Taking it one step further, every change that passes the automated tests is automatically deployed directly to the production servers without human intervention.

Software Economics and Cost Estimation

Software Economics deals with making business decisions regarding software development based on cost, schedule, and quality trade-offs.

Trade-offs:

• Brooks's Law: "Adding manpower to a late software project makes it later." You cannot infinitely reduce the schedule by adding more developers due to communication overhead.
• Cost-Quality-Time Triangle: You can only pick two. If you want high quality fast, it will cost a lot. If you want it cheap and fast, quality will suffer.

Cost Estimation Techniques:

Methods to estimate the required budget include Algorithmic Models (COCOMO), Expert Judgment (Delphi technique), and Estimation by Analogy (comparing to similar past projects).

CASE Tools (Computer-Aided Software Engineering)

CASE tools are automated software utilities that assist software engineers throughout the various phases of the SDLC.

Classification:

• Upper CASE Tools: Support the early phases of SDLC (Requirements, Analysis, and Design). Examples: Diagramming tools (Visio) and prototyping software (Figma).
• Lower CASE Tools: Support the later phases of SDLC (Coding, Testing, and Maintenance). Examples: IDEs (VS Code), Compilers, and Testing frameworks (Selenium).
• Integrated CASE (I-CASE) Environments: Comprehensive suites that support the entire SDLC seamlessly from requirements to deployment (e.g., Azure DevOps, Jira).

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