UNIT 4: SOFTWARE ENGINEERING - EXAM-FOCUSED SHORT NOTES

1. SOFTWARE PROCESS MODELS

Traditional/Linear Models

• Waterfall Model (Linear Sequential)

  • Definition: A sequential, phase-gated model where each phase must be completed before the next begins.

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

  • Iterative Waterfall: Feedback loops exist between adjacent phases (e.g., design to requirements).

  • Advantages: Simple, easy to understand, good for well-understood projects.

  • Disadvantages: Inflexible, late testing, difficult to change requirements.

  • [!TIP] Exam Focus: Often contrasted with evolutionary models. Key drawback: "You don't test until the end."

Evolutionary Models

• Prototyping Model

  • Definition: Build a quick, rough version (prototype) of the system to understand requirements, then refine/rebuild.

  • Types: Throwaway Prototyping (discarded after learning), Evolutionary Prototyping (continuously refined).

  • When to use: Unclear or complex user requirements, high user interaction needed.

  • Advantage: Reduces risk of wrong requirements.

  • Disadvantage: Can lead to "prototype becomes the final product" with poor architecture.

• Spiral Model

  • Definition: Risk-driven iterative model combining waterfall and prototyping. Each loop is a development phase.

  • Four Quadrants per Loop:

    1. Objective Setting & Alternatives: Define goals, constraints, alternatives.

    2. Risk Analysis: Identify/resolve risks (e.g., via prototyping, simulation).

    3. Development & Validation: Build next version.

    4. Planning: Plan next loop.

  • Advantage: Explicit risk management, suitable for large, mission-critical systems.

  • Disadvantage: Complex, costly, requires significant risk assessment expertise.

  • Diagram:

    DiagramSEARCH: "spiral model diagram software engineering"

• RAD (Rapid Application Development) Model

  • Definition: Emphasizes rapid development using component-based construction and iterative development with minimal planning.

  • Phases: Business Modeling → Data Modeling → Process Modeling → Application Generation → Testing & Turnover.

  • Key Enabler: Reusable components and tools (e.g., CASE, 4GLs).

  • When to use: Well-understood, modular business applications with tight deadlines.

  • Advantages: Very fast development, high user involvement.

  • Disadvantages: Requires skilled team, suitable only for certain project types, scalability issues.

Agile Models

• Agile Manifesto Values:

  • Individuals & interactions over processes & tools.

  • Working software over comprehensive documentation.

  • Customer collaboration over contract negotiation.

  • Responding to change over following a plan.

• Extreme Programming (XP)

  • Core Practices: Pair Programming, Test-Driven Development (TDD), Continuous Integration, Small Releases, Simple Design, Refactoring, On-site Customer.

  • Goal: High-quality code, rapid feedback, adaptability.

Unified Process

• RUP (Rational Unified Process)

  • Definition: A customizable, iterative framework for developing software.

  • Four Phases: Inception → Elaboration → Construction → Transition.

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

  • Key: Iterative, use-case driven, architecture-centric.

Process Improvement & Customization

• Capability Maturity Model (CMM) / CMMI

  • Purpose: Framework for assessing and improving software process maturity.

  • 5 Maturity Levels:

    1. Initial: Ad-hoc, chaotic.

    2. Managed: Project management processes are defined.

    3. Defined: Process is standardized across organization.

    4. Quantitatively Managed: Process measured & controlled quantitatively.

    5. Optimizing: Continuous process optimization.

  • Significance: Higher maturity → Predictable, high-quality, efficient software production.

• Software Process Metrics

  • Product Metrics: Measure attributes of the product (e.g., size, complexity, defects).

  • Process Metrics: Measure attributes of the process (e.g., effort, cost, time, defect arrival rate).

  • Use: Provide objective data for process customization and improvement. Example: High defect density in testing → Improve design/code reviews.

2. REQUIREMENTS ENGINEERING

Requirements Fundamentals

• Software Product vs. Software Process:

  • Product: The what – deliverables, features, functions (e.g., "The system shall allow users to reset passwords").

  • Process: The how – activities to build the product (e.g., requirements elicitation, coding, testing).

• Functional vs. Non-Functional Requirements

  | Functional Requirements | Non-Functional Requirements (NFRs) | | :--- | :--- | | Describe what the system must do. | Describe how well the system performs its functions. | | Directly traceable to a user task. | Often called constraints or quality attributes. | | Examples: "User can log in", "System calculates tax". | Examples: "Response time < 2 sec" (Performance), "99.9% uptime" (Reliability), "Use AES-256" (Security), "GUI must be intuitive" (Usability). |

• User Requirements vs. System Requirements:

  • User Requirements: High-level, natural language statements of what users need. (e.g., "The system should help me track my expenses.")

  • System Requirements: Detailed, precise, unambiguous specification of system behavior. (e.g., "The system shall store transaction records with date, category, amount, and description fields.")

Requirements Elicitation & Analysis

• Elicitation Techniques: Interviews, Surveys/Questionnaires, Workshops (JAD), Observation, Document Analysis, Prototyping, Use Case Analysis.

• Activities: Elicitation → Documentation → Validation → Negotiation → Management.

Requirements Specification (SRS)

• System/Software Requirements Specification (SRS)

  • Purpose: Formal, agreed-upon contract between client and developer.

  • Structure (IEEE 830 Standard):

    1. Introduction (Purpose, Scope, Definitions)

    2. Overall Description (Product Perspective, User Characteristics, Constraints, Assumptions)

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

    4. Appendices (Supporting info)

  • Characteristics of a Good SRS:

    • Correct, Unambiguous, Complete, Consistent, Verifiable, Modifiable, Traceable.

  • Completeness: All necessary requirements are included.

  • Consistency: No contradictory requirements.

Requirements Validation & Verification

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

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

• SRS Validation Process: Reviews (informal/formal), Prototyping, Model Checking, Acceptance Criteria definition.

• Example Validation: For requirement "The system shall allow users to reset passwords," validate by asking users: "Is this the correct way you want to recover account access?"

Requirements Management

• Requirement Traceability

  • Definition: Ability to describe and follow the life of a requirement in both forward (to design, code, tests) and backward (to source, stakeholder) directions.

  • Traceability Matrix: Table linking requirements to their origin (e.g., stakeholder), design elements, code modules, and test cases.

  • Challenges: High maintenance cost, tool support, keeping links updated with changes.

  • Mitigation: Use automated tools (e.g., JIRA, DOORS), establish clear ownership, integrate into change management process.

• Feasibility Study

  • Purpose: Determine if the project is viable (technical, economic, operational, legal, schedule).

  • Outcomes: Go/No-Go decision, refined project scope, initial risk list, rough cost/time estimates.

  • Effect on Requirements: Defines high-level constraints and boundaries that shape the requirements. Explicit/implicit constraints from feasibility (e.g., "Must use existing Oracle DB") directly become part of requirements.

3. SOFTWARE MODELING (UML)

UML Overview

• Role: Standardized graphical language for visualizing, specifying, constructing, and documenting software-intensive systems.

• Purpose: Represent architecture, design, processes, and data structures; bridge analysis and design; facilitate communication.

Use Case Modeling

• Use Case Model Definition: A model that describes the system's functional requirements from an actor's perspective.

• Four Basic Parts:

  1. Actors: Roles interacting with the system (Human: User, Admin; External: Payment Gateway).

  2. Use Cases: Discrete units of functionality (e.g., "Place Order", "Generate Report").

  3. System Boundary: Box defining the system scope.

  4. Associations: Lines connecting actors to use cases they participate in.

• Application in Requirement Analysis: Primary tool for requirements elicitation and specification. Captures functional requirements in user-centric, scenario-based form.

• Example - Library Management System:

  • Actors: Member, Librarian, System.

  • Use Cases: Search Catalog, Check Out Book, Return Book, Add Member, Generate Fine.

  • Diagram:

    DiagramSEARCH: "library management system use case diagram"

Structural & Behavioral Diagrams

• Class Diagram (Structural): Shows system's classes, their attributes, operations, and relationships (association, inheritance, dependency). Static structure.

• Sequence Diagram (Behavioral): Shows interactions between objects over time for a specific use case/scenario. Emphasizes time ordering of messages.

• Component Diagram (Structural): Shows physical components (files, libraries, executables) and their dependencies.

Architectural Views (4+1 View Model)

• Multiple Concurrent Views for complex systems:

  1. Logical View: Object model (Class Diagrams) – functionality.

  2. Process View: Runtime behavior, concurrency (Sequence, Activity Diagrams).

  3. Physical View: Deployment, hardware topology (Deployment Diagrams).

  4. Development View: File organization, modules (Component Diagrams).

  5. Scenarios (+1): Use Cases – tying all views together.

4. SOFTWARE DESIGN

Design Fundamentals

• Importance: Transforms requirements into a blueprint for construction. Determines quality attributes (performance, security, modifiability).

• "Design is not Coding and Coding is not Design": Design is about high-level structure, decomposition, and relationships (abstraction). Coding is about syntax and low-level implementation details. Good design precedes coding.

• Basic Principles:

  • Abstraction: Hide complexity (Procedural, Data).

  • Modularity: Divide system into manageable, cohesive modules.

  • Information Hiding: Hide internal details behind interfaces.

  • Separation of Concerns: Break system into distinct features.

Design Strategies & Paradigms

• Function-Oriented Design (Structured Design / SA/SD)

  • Approach: Decompose system into functions (processes) that transform inputs to outputs. Data flows between functions.

  • Tools: Data Flow Diagrams (DFDs), Structure Charts.

  • Focus: "What does the system do?"

• Object-Oriented Design (OOD)

  • Approach: Decompose system into objects (instances of classes) that combine data and behavior. Objects interact via messages.

  • Tools: Class Diagrams, Sequence Diagrams.

  • Focus: "What are the entities and how do they collaborate?"

• Comparison: FOD vs. OOD

  | Aspect | Function-Oriented (SA/SD) | Object-Oriented (OOA/OOD) | | :--- | :--- | :--- | | Basic Element | Function/Process | Object/Class | | Decomposition | Top-down, functional hierarchy | Bottom-up or spiral, object collaboration | | Data & Behavior | Separated (data passed as params) | Encapsulated together | | Change Impact | High (data structure changes ripple) | Lower (changes often localized) | | Primary View | Data Flow Diagram (DFD) | Use Case & Class Diagrams |

• Pattern-Based Design: Reuse proven solutions to recurring design problems (e.g., Singleton, Observer, Factory).

• Component-Based Design: Assemble system from pre-built, standardized, replaceable components.

  • Advantages: Reuse, reduced development time, easier maintenance/upgrades, better quality (tested components).

Design Quality & Metrics

• Design Metrics: Quantitative measures to assess design quality (e.g., complexity, coupling, cohesion).

• Coupling (Inter-module Dependency): Degree of interdependence between modules.

  • Types (Low to High): Data → Stamp → Control → Common → Content.

  • Goal: Minimize coupling (especially content/control).

• Cohesion (Intra-module Strength): Degree to which elements within a module are related.

  • Types (High to Low): Functional → Sequential → Communicational → Procedural → Temporal → Logical → Coincidental.

  • Goal: Maximize cohesion (functional is best).

• Function Technical Review (FTR): Formal peer review of a design/function to find defects, ensure standards, and share knowledge.

Architectural Design

• Architectural Styles (Patterns):

  • Pipe-and-Filter: Components (filters) process data streams connected by pipes (e.g., compilers).

  • Client-Server: Clients request services from servers (e.g., web apps).

  • Layered (n-Tier): Hierarchical layers (Presentation, Business Logic, Data Access). Each layer uses services of layer below.

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

• Component Model: Specification of component properties (provided/required interfaces), dependencies, and composition.

• Object Model: Describes system in terms of objects, classes, inheritance, and associations.

User Interface (UI) Design

• Importance: Directly impacts user satisfaction, productivity, error rates, and learnability. Poor UI can ruin a functionally excellent system.

• Golden Rules / Key Principles:

  1. Place User in Control: Provide undo/redo, visible navigation, clear exits.

  2. Reduce User Memory Load: Minimize remembering information (use recognition over recall), provide visible options.

  3. Make Interface Consistent: Maintain consistent layout, terminology, and behavior across screens.

  • Other: Strive for simplicity, provide feedback, use familiar metaphors, prevent errors.

5. SOFTWARE TESTING

Testing Fundamentals

• Software Testing vs. System Testing:

  • Software Testing: Process of executing a program to find defects. Focus on the software product.

  • System Testing: Testing the complete, integrated system in its operational environment to verify it meets specified requirements. Includes hardware, software, people, procedures.

• Strategic Approaches:

  • Preventive: Tests designed early (before coding) – test-first.

  • Reactive: Tests designed after software is produced – test-last.

• Static vs. Dynamic Analysis:

  • Static: Examine code/documentation without executing (e.g., code reviews, static analysis tools like SonarQube, linting).

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

Testing Levels

• Unit Testing: Test individual units (modules, functions, classes) in isolation.

  • Process: Usually by developers, uses stubs/drivers, white-box techniques.

  • Example: Test a calculateTax(income) function with various incomes.

• Integration Testing: Test interaction/integration between integrated units/modules.

  • Strategies:

    • Big Bang: All at once (risky, hard to debug).

    • Top-Down: Start from top-level modules, use stubs.

    • Bottom-Up: Start from low-level modules, use drivers.

    • Sandwich (Hybrid): Combines top-down and bottom-up.

  • Outcome: Find interface defects, data flow issues.

  • Example: Test interaction between Order and Inventory modules.

• System Testing: Test complete, integrated system against functional and non-functional requirements.

  • Types: Functional, Performance, Load, Stress, Security, Usability, Recovery, Compatibility.

  • Case Study (OS): Test boot process, process scheduling, memory management, file system operations, driver compatibility, security (user permissions).

• Acceptance Testing: Formal testing to determine if system satisfies acceptance criteria, typically by end-users/customers.

  • Steps: Plan → Prepare test data/environment → Execute → Verify results → Negotiate fixes → Sign-off.

  • Types: User Acceptance Testing (UAT), Contract Acceptance Testing, Regulatory Acceptance Testing.

• Regression Testing: Re-run previously executed tests after changes to ensure existing functionality is not broken.

Testing Techniques

• Black-Box Testing (Behavioral): Tests based on specifications, ignoring internal code structure.

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

    • Rule: For range a-b, create 3 classes: x < a (invalid), a ≤ x ≤ b (valid), x > b (invalid).

  • Boundary Value Analysis (BVA): Test values at boundaries of equivalence classes and just inside/outside.

    • Rule: For range a-b, test: a-1, a, a+1, b-1, b, b+1.

    • Example: For "age 18-60", test: 17, 18, 19, 59, 60, 61.

• White-Box Testing (Structural): Tests based on internal code structure (control flow, paths).

  • Path Testing: Design tests to execute all possible paths through the code.

    • Example: For a simple if-else statement, need 2 test cases to cover both true and false paths. Cyclomatic Complexity = number of independent paths.

Test Design & Execution

• Test Case Design Criteria:

  • Input: Test data, preconditions.

  • Output: Expected result, postconditions.

  • Test Conditions: Specific scenarios to be tested.

  • Example (Login Module):

    | Test ID | Input | Expected Output | Test Condition | | :--- | :--- | :--- | :--- | | TC_LOGIN_01 | Valid user/pass | Successful login, redirect to dashboard | Happy path | | TC_LOGIN_02 | Invalid password | Error message "Invalid credentials" | Invalid password | | TC_LOGIN_03 | Empty user field | Error "Username required" | Boundary/validation |

• Test Oracle: Mechanism to determine if test output is correct (e.g., specification, previous version, expert knowledge).

• Test Metrics & Types:

  • Purpose: Measure effectiveness, progress, quality of testing.

  • Types: Product metrics (defect density), Process metrics (test execution rate), Project metrics (test coverage %).

• Testing Tools: Automate repetitive tasks (Selenium, JUnit, TestNG, Postman, LoadRunner).

6. SOFTWARE QUALITY ASSURANCE (SQA)

• Software Quality Definition: Conformance to explicitly stated functional and performance requirements, implicitly developed standards, and inherent characteristics (reliability, maintainability).

• SQA Importance & Activities:

  • Importance: Independent oversight to ensure processes and standards are followed, leading to higher quality products.

  • Activities: Process definition/audit, Standards review, Technical reviews (FTR), Testing oversight, Configuration management audits, Documentation review, Training.

Quality Metrics

• Product Metrics vs. Process Metrics:

  | Product Metrics | Process Metrics | | :--- | :--- | | Measure attributes of the product (size, complexity, defects, reliability). | Measure attributes of the process (effort, cost, time, defect arrival rate). | | Example: Defect density = defects/KLOC. | Example: Average time to fix a defect. |

• Metrics for Maintenance: Mean Time To Repair (MTTR), Mean Time Between Failures (MTBF), number of change requests, backlog size.

• Testing Metrics: Test coverage (requirements, code), defect detection percentage, test execution rate, pass/fail ratio.

7. SOFTWARE CONFIGURATION MANAGEMENT (SCM)

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

• SCM Functions:

  1. Configuration Identification: Define baselines and items (CI).

  2. Configuration Control: Approve/reject change requests (via Change Control Board - CCB).

  3. Configuration Status Accounting: Record and report status of changes.

  4. Configuration Audits: Verify conformance to specifications (functional, physical).

  • Example: A bug fix request → submitted as change request → CCB reviews/approves → developer modifies code → new version created → updated baseline.

Version Control

• How it Helps: Tracks all versions of files, enables rollback, supports parallel development (branching/merging), maintains history.

• Basic Git Operations (Context):

  • git clone: Copy repository.

  • git add: Stage changes.

  • git commit: Save changes to local repo.

  • git push: Upload commits to remote.

  • git pull: Fetch & merge from remote.

  • git branch: Create/switch branches.

8. PROJECT MANAGEMENT

Project Planning

• Steps/Activities:

  1. Define project scope (from SRS).

  2. Break down work (Work Breakdown Structure - WBS).

  3. Estimate effort/cost/schedule (using models like COCOMO).

  4. Identify risks & plan mitigation.

  5. Develop schedule (Gantt, PERT).

  6. Define resources & team structure.

  7. Establish quality/process plans.

• Project Plan: Comprehensive document outlining above.

• Project Metrics: Used to monitor and control (e.g., Earned Value Management: CPI, SPI).

Project Scheduling & Tracking

• Key Steps:

  1. Define activities (from WBS).

  2. Sequence activities.

  3. Estimate resources & durations.

  4. Develop schedule (critical path via PERT/CPM).

  5. Track: Monitor progress vs. plan (milestones, % complete, effort spent).

• Importance: Early detection of delays/cost overruns, resource management, stakeholder communication, project success predictor.

Cost Estimation

• Methods:

  • LOC-based: Estimate size in Lines of Code, then apply productivity/cost per LOC.

  • COCOMO (Constructive Cost Model): Formula-based using size (KLOC) and project attributes.

• COCOMO Categories (Modes):

  1. Organic: Relatively small, familiar, relaxed environment.

  2. Semi-Detached: Mixed of organic and embedded characteristics.

  3. Embedded: Tightly coupled with hardware, stringent requirements.

  • Formula: Effort = a * (KLOC)^b * EAF (Person-Months), where EAF = Effort Adjustment Factor from cost drivers.

• Advantages/Disadvantages of LOC-based:

  • Adv: Simple, intuitive, good for early rough estimates.

  • Dis: Hard to estimate LOC early, language-dependent, doesn't capture complexity well.

Risk Management

• Risk Identification: Brainstorming, checklists, Delphi technique, assumptions analysis.

• Risk Assessment: Probability (likelihood) & Impact (damage). Prioritize using Risk Exposure = Probability × Impact.

• Risk Mitigation Principles:

  • Avoid: Change plan to eliminate risk.

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

  • Minimize: Reduce probability or impact.

  • Accept: Acknowledge and have contingency plan.

• Risk Projection Steps:

  1. Establish scale for probability & impact.

  2. Identify risks.

  3. Assess probability & impact.

  4. Estimate risk exposure.

  5. Categorize/prioritize.

• Risk Information Sheet (RIS): Document for each risk containing: ID, description, probability, impact, exposure, mitigation plan, owner, status.

Feasibility Analysis

• Feasibility Studies (Types):

  • Technical: Can it be built with available tech?

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

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

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

  • Schedule: Can it be built in time?

• Outcomes: Go/No-Go decision, refined scope, identified constraints, initial risk assessment.

9. SOFTWARE MAINTENANCE

Maintenance Fundamentals

• Need for Maintenance: Software is never perfect; environment changes (OS, hardware, laws); new requirements emerge; defects found post-deployment.

• Types of Maintenance:

  1. Corrective: Fix defects.

  2. Adaptive: Modify for environment changes (e.g., new OS).

  3. Perfective: Enhance performance, maintainability, features (non-defect).

  4. Preventive: Prevent future problems (e.g., code refactoring, updating docs).

Maintenance Process

• Activities:

  1. Request & Analysis: Receive change request, analyze impact, feasibility.

  2. Planning: Estimate cost/time, allocate resources.

  3. Implementation: Design, code, unit test changes.

  4. Testing: Regression, integration, system testing of changes.

  5. Delivery & Deployment: Release patch/update, update docs.

  6. Support: Monitor post-deployment.

Re-engineering

• Re-engineering vs. Reverse Engineering:

  • Reverse Engineering: Analyze existing system to identify its components and interrelationships (create representations). Understanding.

  • Re-engineering: Restructuring and/or rewriting the existing system to improve it. Transformation.

  • Forward Engineering: Traditional development from scratch.

• Re-engineering Process:

  1. Inventory & Analysis (Reverse Eng.)

  2. Restructure (e.g., refactor code, update data model)

  3. Re-code (if needed, using modern tech)

  4. Validate (test thoroughly)

• Program Comprehension Techniques (Context of Maintenance): Debugging, static analysis, visualization tools, documentation reading, expert consultation – used to understand legacy code before modification.