UNIT 2: SOFTWARE ENGINEERING - EXAM-FOCUSED SHORT NOTES

1. SOFTWARE PROCESS AND PROCESS MODELS

Capability Maturity Model (CMM)

A framework for improving software process maturity, developed by SEI/Carnegie Mellon.

• 5 Maturity Levels:

  1. Initial: Ad-hoc, chaotic.

  2. Repeatable: Project management processes established.

  3. Defined: Process is documented and standardized.

  4. Managed: Process is measured and controlled.

  5. Optimizing: Continuous process improvement.

• Key Process Areas (KPAs): Specific goals/practices for each level (e.g., Requirements Management at Level 2, Defect Prevention at Level 5).

• Significance: Provides a roadmap for process improvement, predicts software quality, and is often required for contracts.

[!TIP] CMM is prescriptive (what to do), while CMMI (its successor) is more capability-focused.

Linear Sequential Model (Waterfall)

Classical, phase-by-phase approach.

• Phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance.

• Characteristics: Simple, document-driven, milestones at phase ends.

• Advantages: Easy to understand, manage, suitable for stable requirements.

• Disadvantages: Inflexible, late testing, high risk if requirements error, no working software until late.

Prototyping Model

Build a quick, incomplete version to clarify requirements.

• Types:

  • Throwaway/Rapid Prototyping: Built for understanding, then discarded.

  • Evolutionary Prototyping: Built incrementally, evolves into final system.

• Process: Identify known requirements → Build prototype → User feedback → Refine/negotiate → Develop final system.

• Applications: User interface-heavy systems, unclear requirements.

• Advantages: Reduces risk/misunderstanding, user involvement.

• Disadvantages: Can lead to "prototype becomes final" (poor structure), management complexity.

RAD (Rapid Application Development) Model

Emphasizes rapid development using reusable components and iterative construction.

• Phases: Requirements Planning → User Design → Construction → Cutover.

• Key Activities: Joint Application Development (JAD) workshops, reusable components, automated tools (4GL, CASE).

• When to Use: Well-understood requirements, time-critical, modular systems, user involvement possible.

• Advantages: Very fast development, high user involvement, reduced manual coding.

• Disadvantages: Requires experienced team, scalable only for moderate size, management commitment critical.

Spiral Model

Risk-driven, iterative model combining Waterfall and prototyping.

• Diagram & Explanation:

  • Each loop represents a phase/iteration.

  • Four Quadrants per Loop:

    1. Objectives, Alternatives, Constraints: Identify goals, alternatives, risks.

    2. Risk Analysis: Evaluate alternatives, resolve risks (e.g., prototype, simulate).

    3. Development: Develop next version.

    4. Planning: Plan next iteration.

• Advantages: Explicit risk management, high accuracy, suitable for large/mission-critical systems.

• Disadvantages: Complex, costly, requires significant risk-assessment expertise.

[!TIP] Spiral is risk-driven; each loop starts with risk analysis.

Agile Process Model

Values individuals, working software, collaboration, and responsiveness over processes, documentation, contracts, and plans.

• Agile Manifesto Principles: Early delivery, welcome changing requirements, daily collaboration, sustainable development, technical excellence.

• Comparison with Traditional:

  | Traditional (Plan-Driven) | Agile (Value-Driven) | |---|---| | Fixed scope/requirements | Embrace changing requirements | | Big design up-front | Emergent design | | Documentation heavy | Working software over documentation | | Sequential phases | Iterative/incremental | | Contract negotiation | Customer collaboration |

• Common Frameworks:

  • Scrum: Roles (Product Owner, Scrum Master, Team), Sprints (2-4 weeks), Artifacts (Product Backlog, Sprint Backlog), Ceremonies (Sprint Planning, Daily Stand-up, Review, Retrospective).

  • XP (Extreme Programming): Practices like Pair Programming, Test-Driven Development (TDD), Continuous Integration, Small Releases.

Evolutionary Process Models

• Incremental Model: Deliver system in increments (functional slices). Each increment adds functionality. Reduces early risk, but requires good planning for integration.

• Component-Based Development (CBD): Build from reusable components (libraries, services). Emphasizes component identification, procurement/integration. Advantages: Reduced cost/time, higher quality. Challenges: Component availability, compatibility.

Rational Unified Process (RUP)

A customizable, iterative framework from IBM Rational.

• Phases:

  1. Inception: Define scope, business case.

  2. Elaboration: Plan project, specify architecture, mitigate top risks.

  3. Construction: Build components, iterative development.

  4. Transition: Deploy to users, support.

• Disciplines (formerly workflows): Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, Environment.

• Iterations: Each phase has multiple iterations; focus shifts from architecture (Elaboration) to features (Construction).

Software Process Customization and Improvement

• Customization (Tailoring): Adapting a standard process (like RUP, CMMI) to project/organization needs. Remove non-essential activities, adjust workflows.

• Improvement Strategies: Process assessment (e.g., CMM), goal setting, pilot implementation, institutionalization.

• Role of Metrics: Provide objective data to identify bottlenecks, measure improvement (e.g., defect density, cycle time). Process metrics (time, cost) vs Product metrics (size, complexity).

Comparison of Process Models

[!TIP] Requirements stability is the primary factor: Stable → Waterfall/Incremental; Unstable → Prototyping/Agile; High Risk → Spiral.

2. REQUIREMENTS ENGINEERING

Types of Requirements

• Functional Requirements (FR): What the system should do (services, functions).

  • Examples: "User shall be able to reset password via email link," "System shall calculate total order cost."

• Non-Functional Requirements (NFR): Constraints on how system performs (qualities).

  • Performance: "95% of transactions shall complete in <2 sec."

  • Security: "All passwords must be stored encrypted."

  • Usability: "New user shall complete checkout in <5 minutes."

  • Reliability: "System uptime ≥ 99.9%."

• Importance: FRs define scope; NFRs define quality attributes, often critical for user acceptance and system success.

Requirements Elicitation Techniques

• Interviews: Structured/unstructured with stakeholders.

• Surveys/Questionnaires: For large user groups.

• Workshops/JAD: Facilitated group sessions for consensus.

• Observation: Study users in their environment.

• Document Analysis: Study existing systems, procedures.

• Use Case Modeling: Identify actors, goals, scenarios (primary elicitation tool).

Use Case Modeling

• Components:

  • Actor: External entity interacting with system (user, other system).

  • Use Case: Discrete functional unit delivering value to actor (verb-noun, e.g., "Withdraw Cash").

  • Relationships: Association (actor-use case), <<include>> (mandatory sub-function), <<extend>> (optional/conditional).

• Four Basic Parts:

  1. Use Case Diagram: Visual overview (actors, use cases, relationships).

  2. Brief Use Case Description: One-paragraph summary.

  3. Use Case Narrative/Scenario: Step-by-step main flow, alternate flows, exceptions.

  4. Use Case Specification: Detailed template (preconditions, postconditions, triggers, main/alternative flows).

• Application in Requirement Analysis: Bridges user needs (stories) to system functions; basis for test case design.

System Requirements Specification (SRS)

• Components:

  1. Introduction (Purpose, Scope, Definitions, References).

  2. Overall Description (Product perspective, user characteristics, constraints, assumptions).

  3. Specific Requirements (Functional, Non-Functional, Interface).

  4. Appendices (Use cases, data models, UI mockups).

• Characteristics of a Good SRS:

  • Complete: All requirements specified.

  • Consistent: No contradictions.

  • Verifiable/Testable: Can be checked (avoid "user-friendly").

  • Unambiguous: Single interpretation.

  • Modifiable: Easy to change.

  • Traceable: Each requirement uniquely identifiable.

• Documenting FRs vs NFRs: FRs in numbered list with ID, description, priority. NFRs often in separate section, linked to affected FRs.

Requirements Validation and Verification

• Validation: "Are we building the right system?" (Conformance to user needs).

  • Process: Requirements reviews (inspections), prototyping, test case derivation from SRS.

  • SRS Validation Techniques: Consistency checks, feasibility review, stakeholder walkthrough.

• Verification: "Are we building the system right?" (Conformance to specifications).

  • Done during/after implementation (testing, inspections).

• Key Difference: Validation checks requirements; Verification checks product against requirements.

Requirements Traceability

• Challenges: Volume of requirements, frequent changes, lack of tool support, manual effort.

• Mitigation Strategies:

  • Traceability Matrix: Table linking requirements to design, code, tests (forward/backward traceability).

  • Tools: Requirements management tools (Jama, DOORS, modern ALM tools).

  • Unique IDs: Assign each requirement a stable identifier.

• Importance: Ensures all requirements are implemented, impact analysis for changes, test coverage, compliance (e.g., safety standards).

[!TIP] Forward Traceability: Req → Design/Code/Test. Backward Traceability: Test/Code/Design → Req (ensures no extra features).

3. SOFTWARE DESIGN

Design Principles and Concepts

• Fundamental Principles:

  • Abstraction: Hide complexity (different levels: architectural, component, procedural).

  • Modularity: Divide system into manageable, cohesive modules.

  • Information Hiding: Modules hide internal details, expose only interfaces.

  • Separation of Concerns: Different aspects (UI, business logic, data) handled separately.

  • Least Knowledge: Modules should know as little as possible about others.

• Golden Rules of User Interface Design (from Shneiderman):

  1. Strive for consistency.

  2. Enable frequent users to use shortcuts.

  3. Offer informative feedback.

  4. Design dialogue to yield closure.

  5. Offer simple error handling.

  6. Permit easy reversal of actions.

  7. Support internal locus of control.

  8. Reduce short-term memory load.

UML (Unified Modeling Language)

• Purpose: Standardized visual modeling language for software blueprints (structure, behavior, architecture).

• Common Diagrams:

  • Structural: Class, Object, Component, Deployment.

  • Behavioral: Use Case, Sequence, Activity, State Machine.

• Representing Architecture: Package diagrams for high-level grouping, component diagrams for physical structure, deployment diagrams for infrastructure.

• Example: Library Management System:

  • Use Case Diagram: Actors: Member, Librarian. Use Cases: Borrow Book, Return Book, Add Member, Search Catalog.

  • Class Diagram: Classes: Book, Member, Loan, Librarian. Associations: Member borrows Book (many-to-many via Loan).

  • Sequence Diagram: "Borrow Book" scenario: Member → Librarian → System → Database.

[!TIP] UML is notation, not methodology. It supports both OO and structured approaches.

Design Approaches: Comparison

Component-Based Design

• Concepts: System built from pre-built, replaceable, reusable components (binary units with interfaces).

• Components: Provide services via well-defined interfaces (e.g., JavaBeans, .NET assemblies, web services).

• Advantages over Traditional:

  • Reuse: Reduces development time/cost.

  • Maintainability: Replace components without system-wide change.

  • Quality: Tested, proven components.

  • Parallel Development: Teams work on different components.

• Challenges: Component selection, integration, versioning, interface compatibility.

Architectural Design

• Architectural Styles (Patterns):

  • Layered: Presentation → Business Logic → Data Access. Promotes separation, but can be slow.

  • Client-Server: Clients request services from servers (2-tier, 3-tier).

  • Pipe-and-Filter: Sequential processing stages (e.g., compilers).

  • Model-View-Controller (MVC): Separates data (Model), UI (View), control logic (Controller).

  • Microservices: Independently deployable services (fine-grained).

• Architectural Views (Krutchen's 4+1):

  • Logical View: Object model (class diagrams).

  • Process View: Runtime components/threads (activity/sequence).

  • Physical View: Deployment on hardware (deployment diagram).

  • Development View: Organization of modules/artifacts (package diagram).

  • Scenarios (Use Cases): Tie views together.

User Interface (UI) Design

• Importance: Directly affects user satisfaction, productivity, error rates, and adoption.

• Key Principles:

  • Consistency: Same action → same result.

  • Error Prevention: Validate inputs, confirm destructive actions.

  • User Control: Undo/redo, clear exits.

  • Visibility of System Status: Feedback (loading, success).

  • Match between System & Real World: User's language, familiar metaphors.

  • Flexibility & Efficiency: Shortcuts for experts.

  • Aesthetic & Minimalist: No irrelevant info.

Design Metrics

Quantitative measures to assess design quality.

• Complexity: Measured via Cyclomatic Complexity (for code) or Structural Complexity (for design: number of modules, connections).

• Coupling: Degree of interdependence between modules.

$$C = \text{number of connections to other modules}$$

- Lower coupling (data coupling) is better than higher (content coupling).

• Cohesion: Degree to which elements inside a module belong together.

  • Types: Functional (best), Sequential, Communicational, Procedural, Temporal, Logical, Coincidental (worst).

• How They Help: Identify "problem" modules (high coupling, low cohesion) → refactor → predict maintainability, testability, defect density.

[!TIP] Good design: High cohesion, low coupling.

4. SOFTWARE TESTING

Test Levels and Strategies

• Integration Strategies:

  • Big Bang: Integrate all at once (risky).

  • Top-Down: Start from top (main control), use stubs for lower modules.

  • Bottom-Up: Start from bottom (utility modules), use drivers.

  • Sandwich/Hybrid: Combine top-down and bottom-up.

• System Testing Types: Functional, Performance (load, stress), Security, Usability, Compatibility, Recovery.

• Acceptance Testing Steps: Plan → Prepare environment → Execute with real data → Evaluate → Sign-off.

  • Alpha: In-house (developer site).

  • Beta: At user sites (field testing).

Test Techniques

• Black-Box Testing: Based on specifications, ignores internal code.

  • Equivalence Partitioning (EP): Divide input domain into equivalence classes (valid/invalid). Test one representative per class.

    • Example: Input age (1-120). Classes: valid (1-120), invalid (<1, >120). Test with 25, -5, 130.

  • Boundary Value Analysis (BVA): Test edges of EP classes (min, min-1, max, max+1, typical).

    • Example: Age: 0, 1, 120, 121.

• White-Box Testing: Based on internal structure/code.

  • Statement Coverage: Execute every statement at least once.

  • Branch/Decision Coverage: Execute every true/false branch.

  • Path Coverage: Execute every possible path (often infeasible).

• Static vs Dynamic Analysis:

  • Static: Analyze code without execution (reviews, inspections, static analysis tools for style, security vulnerabilities).

  • Dynamic: Execute program with test inputs (unit, integration tests).

Test Case Design and Test Oracles

• Effective Test Case: Unique ID, Test Objective, Preconditions, Input Data, Expected Output/Result, Postconditions, Pass/Fail Criteria.

• Test Oracle: Source of expected outcome (truth). Can be:

  • Specification document.

  • Existing system (for regression).

  • Human expert/designated person.

  • Derived from model/formal specification.

Test Metrics

• Types:

  • Process Metrics: Monitor testing process (test cases written/executed/day, defect arrival rate).

  • Product Metrics: Measure product under test (defect density = defects/KSLOC, test coverage = % requirements tested).

  • Project Metrics: Track project health (test effort vs plan, defect removal efficiency).

• Purpose: Monitor progress, control quality, predict release readiness, improve process.

• Product vs Process Metrics:

  • Product: What is the quality of the software? (e.g., defects found).

  • Process: How effective is our testing? (e.g., % requirements covered by tests).

Testing Tools

• Categories:

  • Automation Tools: Selenium (web), JUnit (Java unit), TestNG, Cypress.

  • Performance Tools: JMeter, LoadRunner.

  • Defect Tracking: Jira, Bugzilla.

  • Static Analysis: SonarQube, Checkstyle, FindBugs.

• Role: Automate repetitive tasks, increase coverage, simulate load, manage defects, ensure consistency.

Test Plan

• Importance in SQA: Roadmap for testing, ensures systematic coverage, manages resources/schedule, baseline for evaluation.

• Components (IEEE 829 standard):

  1. Test Plan Identifier

  2. Introduction (purpose, scope)

  3. Test Items (software versions)

  4. Features to be Tested / Not Tested

  5. Approach (techniques, tools, pass/fail criteria)

  6. Item Pass/Fail Criteria

  7. Suspension/Resumption Criteria

  8. Test Deliverables (reports, logs)

  9. Testing Tasks (schedule, resources)

  10. Environmental Needs

  11. Responsibilities

  12. Staffing & Training

  13. Schedule

  14. Risks & Contingencies

5. SOFTWARE PROJECT MANAGEMENT

Project Scheduling and Tracking

• Key Steps:

  1. Task Identification: Work Breakdown Structure (WBS).

  2. Sequencing: Define dependencies (FS, SS, FF, SF).

  3. Estimation: Duration/resource effort per task.

  4. Scheduling: Assign dates, create Gantt chart, identify critical path (CPM).

• Tracking Mechanisms:

  • Milestones: Key dates/deliverables.

  • Earned Value Management (EVM):

    • PV (Planned Value): Budgeted cost for planned work.

    • EV (Earned Value): Budgeted cost for actual work done.

    • AC (Actual Cost): Actual cost incurred.

    • Key Indices:

      • CPI (Cost Performance Index) = EV/AC (>1 under budget).

      • SPI (Schedule Performance Index) = EV/PV (>1 ahead).

• Importance: Predict completion, identify deviations early, manage stakeholder expectations, control costs.

Cost Estimation

• Techniques:

  • Expert Judgment: Consult experienced individuals.

  • Analogous Estimating: Use similar past project data.

  • Parametric Models:

    • COCOMO (Constructive Cost Model):

$$E = a \times (KSLOC)^b \times \text{EM}$$

        Where:

        - $E$ = Effort in person-months (PM).

        - $KSLOC$ = Thousands of Source Lines of Code.

        - $a, b$ = Constants (depend on project type: Organic, Semi-detached, Embedded).

        - $EM$ = Effort Multiplier (product of 15 cost drivers like RELY, DATA, CPLX, etc.).

    - **Function Points (FP)**: Measure functionality from user view (inputs, outputs, inquiries, files, interfaces). Convert to LOC via language-dependent factor.

- **Bottom-Up**: Estimate components, roll up.

• Factors Affecting Cost: Size, complexity, team experience, technology, tools, requirements stability, schedule pressure.

Risk Assessment and Mitigation

• Risk Identification: Categorize risks:

  • Technical: Performance, technology, quality.

  • Management: Planning, coordination, staffing.

  • External: Legal, market, environmental.

  • Organizational: Budget, priorities.

• Risk Projection (Estimation):

  1. Establish scale (probability: 0-1; impact: negligible to catastrophic).

  2. Identify risks.

  3. Estimate probability & impact.

  4. Risk Information Sheet (RIS) for each risk: Description, Category, Probability, Impact, Mitigation Plan, Owner.

• Mitigation Strategies:

  • Avoid: Change plan to eliminate risk.

  • Transfer: Shift to third party (insurance, outsourcing).

  • Mitigate: Reduce probability/impact (prototyping, training).

  • Accept: Acknowledge, have contingency plan.

• Principles: Proactive, continuous, prioritized, integrated into project plan.

Software Configuration Management (SCM)

• Role: Manage changes to software artifacts (code, docs, models) throughout lifecycle. Ensures integrity, traceability, reproducibility.

• Key Activities:

  1. Version Control: Track changes (e.g., Git: commit, branch, merge).

  2. Change Control: Process to evaluate, approve, implement changes (Change Request → Review → Approve/Reject → Implement → Verify).

  3. Configuration Auditing: Formal review to ensure compliance with baselines.

  4. Status Reporting: Track configuration items.

• Example (Git):

  • git commit -m "fix login bug": Record change.

  • git branch feature-x: Create branch for new feature.

  • git merge feature-x: Integrate feature into main.

Feasibility Analysis

• Types:

  • Technical: Can we build it with available technology/expertise?

  • Economic: Cost-benefit analysis (ROI, NPV, payback period).

  • Operational: Will it be used? Fit with existing processes?

  • Legal/Contractual: Compliance with laws, regulations, contracts.

  • Schedule: Can we meet deadline?

• Process: Initial investigation → Detailed analysis of each type → Go/No-Go recommendation.

• Importance: Avoid costly mistakes, align with business goals, secure funding.

Project Plan

• Components: Scope statement, Schedule (WBS, Gantt, milestones), Cost estimate/budget, Resource plan (people, equipment), Risk management plan, Quality plan, Communication plan.

• Relationship with Project Metrics: Plan defines what to measure (e.g., "track CPI monthly"). Metrics provide data to compare actual vs plan, enabling control.

6. SOFTWARE QUALITY AND MAINTENANCE

Software Quality Assurance (SQA)

• Definition: A planned, systematic pattern of activities to ensure quality in software processes and products.

• Goals: Ensure processes are followed, products meet specifications, prevent defects.

• Activities:

  • Audits: Independent examination of processes/products.

  • Reviews: Formal/informal (inspections, walkthroughs, peer reviews).

  • Process Standards: Define/ensure adherence to standards (e.g., coding, documentation).

  • Measurement & Analysis: Collect metrics, analyze trends.

  • Training: Ensure team competence.

Quality Metrics

• For Maintenance:

  • Mean Time to Repair (MTTR): Average time to fix a failure.

  • Fault Density: Defects per KLOC or per function point.

  • Mean Time Between Failures (MTBF): Average time between system failures.

  • Backlog of Open Defects: Number of unresolved defects.

• Overall Software Quality Metrics:

  • Customer Satisfaction: Surveys.

  • Defect Removal Efficiency (DRE): (Defects found before release) / (Total defects found) × 100%.

  • Reliability: Probability of failure-free operation over time.

Software Maintenance

• Why Needed: Software is never "finished"; must adapt to changing environment, fix errors, enhance features.

• Types:

  1. Corrective: Fix defects (bugs).

  2. Adaptive: Adapt to environment changes (OS, hardware, regulations).

  3. Perfective: Enhance performance, maintainability, features.

  4. Preventive: Prevent future problems (code refactoring, documentation updates).

• Statistics: Typically 60-80% of total cost is maintenance.

Re-engineering and Reverse Engineering

• Reverse Engineering: Analyze existing system to identify components and interrelationships → create representations (higher-level models). Focus: Understanding.

• Re-engineering: Restructuring or rewriting system to improve quality, often using reverse engineering output. May involve: code refactoring, data migration, architecture update.

• Key Differences:

  | Reverse Engineering | Re-engineering | |---|---| | Analysis only | Analysis + modification | | Output: models, docs | Output: new/improved system | | No change to code | Code is changed |

Program Comprehension Techniques

• Approaches for Understanding Existing Code:

  • Documentation: Read design docs, comments, manuals.

  • Debugging/Tracing: Run with debugger, trace execution.

  • Static Analysis: Use tools to generate call graphs, metrics.

  • Visualization: IDE tools, dependency graphs.

  • Knowledge Acquisition: Talk to original developers/users.

  • Formal Methods: Abstract interpretation, slicing.

• Tools: IDE (VSCode, IntelliJ), Doxygen (documentation), Understand (static analysis), GDB (debugging).

7. SPECIAL TOPICS & COMPARISONS

Structured Analysis and Structured Design (SA/SD)

• SA (Analysis Model): Understand what system must do.

  • Tools: Data Flow Diagrams (DFDs - context, level 0, level 1), Entity-Relationship (ER) Diagrams, Data Dictionaries.

• SD (Design Model): Define how system will be built.

  • Tools: Structure Charts (module decomposition, data passing), Module Specifications (pseudocode).

• Process: DFDs → Transform/Centralized analysis → Structure Chart → Detailed Design.

Object Models

• Concepts: Model system as interacting objects (instances of classes).

• Key Diagrams:

  • Class Diagram: Static structure (classes, attributes, operations, relationships: association, inheritance, dependency).

  • Object Diagram: Snapshot of objects at a point in time.

  • Sequence Diagram: Dynamic interactions over time (messages between objects).

• Comparison with Structured Models:

  | Structured (SA/SD) | Object-Oriented | |---|---| | Data & processes separate | Data + behavior encapsulated | | DFDs, Structure Charts | Class, Sequence Diagrams | | Top-down decomposition | Object identification, collaboration | | Global data stores | Object state |

Validation vs Verification (Broader Context)

• Verification: "Are we building the product right?" (Conformance to specs). Activities: Reviews, inspections, static analysis, testing against requirements.

• Validation: "Are we building the right product?" (Conformance to user needs). Activities: Prototyping, user acceptance testing, beta testing.

• Analogy: Verification = building to code; Validation = building the correct house.

Component Model in Software Engineering

• Definition: A component is a replaceable, reusable unit that encapsulates implementation and exposes a set of interfaces.

• Diagram: Shows component (rectangle with "lollipop" for provided interface, "socket" for required interface), dependencies.

• Key Concepts: Interface contract, component repository, middleware (for communication).

• Example: A PaymentProcessor component with IPayment interface, used by Order component.

Feasibility Analysis (Reiterated from Project Management)

• Types: Technical, Economic, Operational, Legal, Schedule.

• Process: Define scope → Analyze each type → Assess risks → Recommend.

• Importance: Early go/no-go decision, resource justification, risk identification.

Test Oracles (Reiterated from Testing)

• Definition: Mechanism to determine if test output is correct.

• Sources: Specification, existing system, user expectation, derived from model.

• Challenge: Often the oracle itself is unreliable or unavailable ("oracle problem").

• Types: Specified (from doc), Derived (from model), Implicit (human expectation).

END OF UNIT 2 NOTES
Focus on understanding definitions, comparisons, and being able to explain with examples/diagrams as per past papers.