UNIT 2: SOFTWARE ENGINEERING - COMPREHENSIVE NOTES

I. SOFTWARE PROCESS FUNDAMENTALS

Software Product vs. Software Process

Software Crisis & Need for Software Engineering

• Software Crisis: Period (1960s-70s) where projects frequently failed—exceeded budget/schedule, low quality, unmaintainable.

• Root Causes: Increasing complexity, lack of disciplined approach, poor management, unrealistic estimates.

• Need for SE: Applies engineering principles (systematic, disciplined, quantifiable) to develop reliable, efficient, maintainable software cost-effectively.

SDLC Phases (Waterfall View)

1. Requirements Analysis: What the system must do.

2. System Design: How the system will be structured (architecture, components).

3. Implementation (Coding): Translating design into source code.

4. Testing: Verifying product against requirements.

5. Deployment: Releasing to the user.

6. Maintenance: Modifying post-deployment (corrective, adaptive, perfective, preventive).

Software Process Characteristics

• Understandable & Communicable: Clear to all stakeholders.

• Predictable: Allows estimation of cost, schedule.

• Repeatable: Consistent outcomes across projects.

• Measurable: Progress and quality can be quantified.

• Adaptable: Can be tailored for project needs.

• Efficient: Minimizes waste of resources.

[!TIP] Exam Focus: Be ready to define each phase's objective and key deliverable (e.g., SRS from Requirements, Design Doc from Design).

II. SOFTWARE PROCESS MODELS

A. Traditional Models

Linear Sequential (Waterfall) Model

• Diagram:

  DiagramCANVAS: Classic downward-flowing cascade with 6 distinct, non-overlapping phases: Requirements -> Design -> Implementation -> Testing -> Deployment -> Maintenance. Arrows flow strictly downward.

• Phases: Rigid, phase-gate model. Each phase must be 100% complete before next begins.

• Advantages:

  • Simple, easy to understand.

  • Well-defined milestones & documentation.

  • Works for well-understood, stable requirements (e.g., government systems).

• Disadvantages:

  • No working software until late.

  • Inflexible; difficult to change requirements.

  • High risk if requirements are wrong.

  • Customer sees product very late.

Iterative Waterfall Model

• Modification: Feedback loops added from later phases to earlier ones (e.g., Testing -> Design).

• Purpose: Addresses Waterfall's inflexibility by allowing limited rework.

B. Evolutionary Models

Prototyping Model

• Core Idea: Build a quick, throwaway or evolutionary prototype to understand requirements.

• Types:

  • Throwaway/Rapid Prototype: Built for feedback, then discarded. Final system built from scratch.

  • Evolutionary Prototype: Prototype is continuously refined into the final system.

• When Useful:

  • Unclear, complex, or volatile user requirements.

  • User interface design.

  • High-risk areas needing early validation.

• Risk: "Prototype becomes the final product" leading to poor architecture if not managed.

Spiral Model (Risk-Driven)

• Diagram:

  DiagramCANVAS: Spiral with 4 quadrants per loop: (1) Objectives/Alternatives, (2) Risk Analysis, (3) Development & Verification, (4) Planning. Each loop is a development cycle.

• Key Driver: Risk Management. Each cycle (loop) addresses the highest-priority risk.

• Phases per Cycle:

  1. Determine objectives, alternatives, constraints.

  2. Evaluate alternatives; identify & resolve risks (e.g., prototyping, simulation).

  3. Develop & verify next version (could be prototype, model, or actual code).

  4. Plan next phase.

• Advantages:

  • Explicit risk management.

  • High customer involvement.

  • Supports large, mission-critical systems.

• Disadvantages:

  • Complex, costly.

  • Requires significant risk-assessment expertise.

  • Can be indefinite without clear exit criteria.

RAD (Rapid Application Development) Model

• Core Idea: Time-boxed, iterative development using reusable components and intensive user involvement.

• Phases:

  1. Requirements Planning: Identify scope, key requirements.

  2. User Design: Interactive sessions (JAD) to build UI/process models.

  3. Construction: Rapid build using 4GL, tools, reuse. Parallel development.

  4. Cutover: Data conversion, testing, training, turnover.

• Components: JAD workshops, Reusable components, 4GL tools, Prototyping.

• Advantages: Very fast development, high user satisfaction, reduced code.

• Disadvantages: Requires highly skilled teams, suitable only for modular, UI-intensive systems, management complexity.

• Applications: Data-driven, transaction processing systems (e.g., inventory, payroll).

Incremental Model

• Core Idea: Product built and delivered in increments (functional slices). Each increment adds capability.

• Process: Plan whole architecture, then develop/ deliver increments one by one.

• Advantages:

  • Early user feedback on working increments.

  • Lower risk per increment.

  • Easier to manage.

• Disadvantages:

  • Requires good architectural foresight upfront.

  • System may be "patched" if increments not well-integrated.

  • Total cost often higher than waterfall.

C. Agile Models

Agile Process Model

• Manifesto Values: Individuals & interactions > processes & tools; Working software > comprehensive documentation; Customer collaboration > contract negotiation; Responding to change > following a plan.

• Principles: Satisfy customer via early/continuous delivery; welcome changing requirements; frequent delivery (weeks); daily collaboration; sustainable development; technical excellence; simplicity; self-organizing teams.

• Comparison with Traditional:

  | Traditional (Plan-Driven) | Agile (Value-Driven) | |-------------------------------|--------------------------| | Fixed scope, schedule, cost | Fixed time, cost; variable scope | | Big design upfront | Emergent design | | Comprehensive docs | Working software as primary measure | | Sequential phases | Iterative & incremental | | Formal communication | Informal, face-to-face |

Extreme Programming (XP)

• Key Practices:

  • Pair Programming: Two programmers, one workstation. Improves code quality, knowledge sharing.

  • Test-Driven Development (TDD): Write test before code. Reded: Red-Green-Refactor cycle.

  • Continuous Integration: Integrate & test code multiple times/day.

  • Small Releases: Frequent, small releases (1-3 weeks).

  • On-site Customer: Customer part of the team.

  • Refactoring: Continuous code improvement.

  • Simple Design: "Just enough" design.

• Advantages: High quality, rapid feedback, adaptability, strong team morale.

• Disadvantages: Requires high customer commitment, can be difficult for large/distributed teams, less documentation.

D. Process Improvement Frameworks

Capability Maturity Model (CMM)

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

• 5 Levels:

  1. Initial: Chaotic, ad-hoc. Success depends on individuals.

  2. Repeatable: Basic project management (tracking cost/schedule). Success from similar past projects.

  3. Defined: Process is documented, standardized, integrated. Organization-wide.

  4. Managed: Process is measured & controlled quantitatively. Quality goals set.

  5. Optimizing: Continuous process improvement via innovation & defect prevention.

• Significance: Higher maturity → more predictable, higher quality, lower cost. CMMI is its successor.

Rational Unified Process (RUP)

• Nature: Iterative, use-case driven, architecture-centric framework (not a rigid model).

• Phases:

  1. Inception: Define scope, vision, business case.

  2. Elaboration: Analyze problem domain, establish architecture, mitigate key risks.

  3. Construction: Build product incrementally.

  4. Transition: Deploy to users (beta, training, support).

• Disciplines (Artifacts/Activities): Business Modelling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration Mgmt, Project Mgmt, Environment.

• Comparison with Agile:

  • RUP: More prescriptive, heavier documentation, suitable for large/regulated projects.

  • Agile (e.g., XP): Lighter, more adaptive, values individuals over process.

E. Process Customization & Improvement

• Role of Metrics: Provide objective data to identify bottlenecks, measure improvement impact, predict outcomes.

• Customization: Tailor a generic process model (e.g., add prototyping phase, adjust iteration length) based on:

  • Project size, criticality, volatility.

  • Team experience.

  • Organizational culture.

• Improvement Goal: Increase productivity, quality, predictability, customer satisfaction.

III. REQUIREMENTS ENGINEERING

A. Types of Requirements

B. Requirements Elicitation Techniques

• Interviews: One-on-one/group. Deep dive, but time-consuming.

• Surveys/Questionnaires: Reach many users quickly. Limited depth.

• Workshops/JAD (Joint Application Development): Structured group sessions with users/developers. High collaboration, fast conflict resolution.

• Use Case Identification: Identify actors & goals to derive functional requirements.

• Prototyping: Build mock-ups to elicit feedback on UI/functionality.

• Observation: Watch users in their environment. Reveals implicit needs.

• Document Analysis: Study existing systems, manuals, procedures.

• Brainstorming: Generate ideas freely in a group.

• Delphi Technique: Anonymous, iterative expert consensus (for forecasting/prioritization).

C. Requirements Analysis & Specification

System Requirements Specification (SRS)

• Purpose: Contract between client & developer. Defines what to build.

• Structure/Components:

  1. Introduction (Purpose, Scope, Definitions).

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

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

  4. Other Requirements (e.g., legal, regulatory).

• Characteristics of Good SRS (SMART+):

  • Complete: All requirements specified.

  • Consistent: No conflicting requirements.

  • Unambiguous: Single interpretation.

  • Verifiable: Can be tested/proven.

  • Traceable: Source of each requirement known.

  • Modifiable: Easy to change.

  • Correct: Matches actual user needs.

Use Case Modeling

• Four Basic Parts:

  1. Actors: Users or external systems interacting with the system (Primary, Secondary).

  2. Use Cases: Discrete functional units delivering value to an actor (e.g., "Withdraw Cash").

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

  4. System Boundary: Rectangle defining scope of the system.

• Application: Captures functional requirements from user's perspective. Drives design, testing, documentation.

• Use Case Diagram: Visual representation of actors, use cases, relationships.

• Use Case Specification (Text): Detailed description: Name, Actors, Pre/Post-conditions, Main Flow (steps), Alternate Flows, Exceptions.

Data Dictionary (Structured Analysis)

• Purpose: Central repository of all data elements in the system. Defines names, aliases, descriptions, data types, formats, ranges, structures, relationships.

• Contents: Data Flows, Data Stores, Data Items, Structures, External Entities.

• Role: Ensures consistency, eliminates ambiguity, supports code generation.

D. Requirements Validation & Verification

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

  • Techniques: Reviews (inspections, walkthroughs), Prototyping, Develop test cases from requirements.

• Verification: "Are we building the product right?" (Conformance to specs).

  • Checks: Consistency (no contradictions), Completeness (all needs covered), Feasibility (technical, cost, schedule).

E. Requirements Traceability

• Challenges:

  • Requirements change frequently.

  • Large number of requirements.

  • Links between requirements, design, code, tests are lost.

  • Tool support & discipline needed.

• Mitigation Strategies:

  • Requirements Traceability Matrix (RTM): Table linking Req ID -> Design -> Code -> Test Case. Tracks forward & backward.

  • Unique Requirement IDs: In all artifacts.

  • Dedicated Tools: e.g., JIRA, DOORS, specialized traceability tools.

  • Change Management Process: Enforce traceability updates with every change.

IV. SOFTWARE DESIGN

A. Design Fundamentals

Design Principles (Golden Rules of UI Design)

1. Place the User in Control: Provide undo, flexible exits, user-driven navigation.

2. Reduce the User's Memory Load: Make objects, actions, options visible. Minimize recall.

3. Make the Interface Consistent: Same gestures, terms, commands for same actions.

4. Provide Feedback: For every user action, indicate system status (e.g., progress bar).

5. Offer Simple Error Handling: Prevent errors; if occur, constructively explain & recover.

6. Enable Easy Reversal of Actions (Undo).

7. Support Internal Locus of Control: Users feel in charge, not the system.

Basic Design Principles

• Abstraction: Hide implementation details, show essential features.

• Modularity: Divide system into manageable, named, independent modules.

• Information Hiding: Modules hide internal data/implementation; expose only necessary interfaces.

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

• Least Knowledge Principle (Law of Demeter): Module should not know internal details of others it uses.

Design Concepts

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

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

• Coupling: Degree of interdependence between modules.

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

• Design Patterns: Reusable solutions to common design problems (e.g., Singleton, Observer, Factory). Promote reuse, flexibility.

"Design is not Coding and Coding is not Design"

• Design: Abstract, high-level, platform-independent. Focuses on structure, components, interfaces, algorithms. Uses UML, diagrams.

• Coding: Concrete, platform-specific implementation in a programming language. Focuses on syntax, data structures, algorithms in code.

• Good Design enables clean, maintainable code. Coding without design leads to "spaghetti code".

B. Design Metrics

• Importance: Objective assessment of design quality, complexity, maintainability. Predicts testing effort, defect density.

• Common Metrics:

  • Complexity: Cyclomatic Complexity (V(G)), Design Complexity.

  • Cohesion: Measured by strength of functional relatedness.

  • Coupling: Number & type of connections between modules.

  • Size: Number of modules, classes, lines of design code.

C. Design Approaches

Function-Oriented Design (Structured Design - SD)

• Basis: Structured Analysis (SA) DFDs & data dictionaries.

• Strategy: Top-down decomposition. System seen as a set of functions processing data flows.

• Output: Structure Chart (hierarchy of modules, data flow, control flow).

• Example:

  DiagramCANVAS: Simple Structure Chart: Main -> (Process Order, Validate Payment, Update Inventory). Arrows show data/control passed.

Object-Oriented Design (OOD)

• Basis: Object-Oriented Analysis (OOA) use cases, object models.

• Key Concepts: Objects (instances), Classes (blueprints), Inheritance, Polymorphism, Encapsulation.

• Output: Class Diagrams, Sequence Diagrams.

• Comparison with FOD:

  | Aspect | Function-Oriented | Object-Oriented | |------------|-----------------------|---------------------| | Primary Element | Function/Process | Object/Class | | Basis of Decomposition | Functions & data flow | Objects & responsibilities | | Data Passing | Explicit parameters | Messages between objects | | Change Impact | High (data structures change ripples) | Lower (encapsulation localizes change) | | Reuse | Function libraries | Class inheritance/composition |

Component-Based Design

• Idea: System built from pre-built, standardized, reusable components (e.g., DLLs, web services, microservices).

• Advantages: Faster development, higher quality (tested components), easier maintenance, technology independence.

• Challenges: Component selection, integration complexity, versioning, interface stability.

D. Architectural Design

• Architectural Styles:

  • Layered: Presentation -> Business Logic -> Data Access. Promotes separation.

  • Client-Server: Clients request services from servers.

  • Pipe-and-Filter: Data flows through sequential processing elements (filters) connected by pipes (e.g., compilers).

  • Microservices: Independently deployable services, fine-grained, decentralized.

• Architectural Views (4+1 Model):

  • Logical View: Object model (classes, relationships).

  • Process View: Concurrency, synchronization, runtime components (threads, processes).

  • Physical View: Deployment on hardware (nodes, networks).

  • Development View: Organization of modules in code (packages, layers).

  • Scenarios (Use Cases): Tie views together.

• UML in Architecture: Component Diagrams (physical components, interfaces), Deployment Diagrams (nodes, connections).

E. User Interface Design

• Importance: Primary point of user interaction. Affects usability, user satisfaction, adoption, productivity. Poor UI leads to errors, frustration, abandonment.

• Key Principles:

  • Consistency: Same operation, same result.

  • Error Prevention: Disable invalid actions, confirm destructive actions.

  • Feedback: Immediate, clear response to user action.

  • Simple, Natural Dialogue: Speak user's language, minimize steps.

  • Good Information Display: Clear, appropriate detail, good visual hierarchy.

  • Forgiveness: Allow undo, easy recovery from errors.

  • User Control: User initiates actions, feels in charge.

F. UML in Design (Key Diagrams)

• Class Diagram: Static structure. Classes, attributes, operations, relationships (association, inheritance, dependency). Most important for OOD.

• Sequence Diagram: Dynamic behavior over time. Shows objects/classes (lifelines) and messages exchanged for a specific scenario/use case.

• Component Diagram: Physical, replaceable parts (components), interfaces, dependencies.

• Deployment Diagram: Physical architecture. Nodes (hardware/software), connections, artifacts deployed.

Example: Library Management System (Class Diagram Snippet)

V. SOFTWARE TESTING

A. Testing Fundamentals

• Verification vs Validation:

  • Verification: "Are we building the product right?" (Conformance to specs). Static & Dynamic.

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

• Static vs Dynamic Analysis:

  • Static: Examine code/docs without execution. (Code reviews, walkthroughs, static analysis tools).

  • Dynamic: Execute program with test inputs. (Unit, integration, system testing).

• Test Oracle: Mechanism to determine if test passed/failed.

  • Types: Specified (from requirements/specs), Implicit (common knowledge), Heuristic (experience-based).

B. Test Levels

1. Unit Testing: Test individual units (functions, classes, methods) in isolation.

   • Criteria: Path coverage, branch coverage. Usually by developers.

   • Example (Login): Test validateCredentials(username, password) with valid/invalid combos, empty inputs, SQL injection strings.

2. Integration Testing: Test interaction between integrated units/modules.

   • Strategies:

     • Big Bang: Integrate all at once. High risk, hard to debug.

     • Top-down: Start from top (main control). Use stubs for lower modules.

     • Bottom-up: Start from bottom (utility modules). Use drivers.

     • Sandwich/Hybrid: Combines top-down & bottom-up.

   • Outcome: Interface defects, data flow issues.

3. System Testing: Test complete, integrated system against system requirements.

   • Types: Functionality, Performance (load, stress), Security, Usability, Compatibility, Recovery.

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

4. Acceptance Testing: Validate system for user/customer.

   • Alpha: In-house, by users at developer's site.

   • Beta: By users at their own site ("field test").

   • User Acceptance Testing (UAT): Formal sign-off by customer.

5. Regression Testing: After changes (bug fix, enhancement), re-run subset of previous tests to ensure no new defects introduced.

C. Test Design Techniques

Black-Box Testing (Behavioral)

• Ignores internal code structure. Based on specs/requirements.

• Equivalence Partitioning (EP):

  • Divide input domain into equivalence classes (valid/invalid).

  • Rule: Test one value from each class.

  • Example: Input: age 1-120. Classes: Valid (1-120), Invalid (<1, >120). Test cases: age=50 (valid), age=-5 (invalid), age=150 (invalid).

• Boundary Value Analysis (BVA):

  • Rule: Test values at, just below, just above boundaries. EP is often combined with BVA.

  • Example: For age 1-120: Test 0, 1, 2, 119, 120, 121.

  • For multiple variables: Single Fault Assumption (test one boundary at a time) or Worst-Case (all combinations).

White-Box Testing (Structural)

• Uses knowledge of internal code structure.

• Coverage Criteria:

  • Statement Coverage: Execute every statement at least once. \boxed{\text{Minimal coverage}}

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

  • Path Coverage: Execute every independent path through control flow graph (CFG). Often impractical (exponential paths).

• Example with CFG:

  DiagramCANVAS: Simple CFG: Start -> A (decision x>0?) -> B (if true) -> C -> End; A -> D (if false) -> C -> End. Paths: 1. Start-A-B-C-End. 2. Start-A-D-C-End.
  Path coverage requires both paths.

D. Test Management

Test Plan

• Purpose: Master document for planning, organizing, controlling testing. Communicates strategy to stakeholders.

• Contents (IEEE 829 Standard):

  • Test Plan Identifier, Introduction, Test Items, Features to be Tested/Not Tested, Approach, Pass/Fail Criteria, Suspension/Resumption Criteria, Test Deliverables, Responsibilities, Schedule, Risks & Contingencies, Approvals.

• How it helps QA: Provides baseline, defines scope/resources, manages expectations, tracks progress, ensures completeness.

Test Metrics

• Purpose: Measure effectiveness, efficiency, progress of testing. Predict product quality.

• Types:

  • Base Metrics: Raw data (e.g., # test cases designed, # executed, # passed/failed).

  • Derived Metrics: Calculated from base (e.g., % test completion, defect density, test effectiveness = defects found / total defects).

• Use: Monitor project health, identify high-risk areas, improve test process.

Testing Tools (Categories)

• Static Analysis Tools: Check code without execution (e.g., SonarQube, Checkstyle).

• Dynamic Analysis Tools: Execute code (e.g., Selenium, JUnit, LoadRunner).

• Test Management Tools: Manage test cases, execution, defects (e.g., JIRA, TestRail).

• Performance/Monitoring Tools: Measure system behavior under load.

VI. SOFTWARE PROJECT MANAGEMENT

A. Project Planning

• Activities: Define scope, objectives; identify tasks, dependencies; estimate resources/cost/schedule; identify risks; plan communications; establish baselines.

• Feasibility Analysis:

  • Technical: Can it be built with available tech/expertise?

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

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

  • Outcomes: Go/No-Go decision. Impacts requirement scope (e.g., technical constraints become requirements).

B. Effort & Cost Estimation

COCOMO (Constructive Cost Model)

• Equation:

$$E = a \times (KSLOC)^b \times \prod_{i=1}^{n} EM_i$$

*   `E` = Effort in **Person-Months (PM)**.

*   `KSLOC` = Estimated **thousands of source lines of code**.

*   `a, b` = Constants based on project **mode**.

*   `EM_i` = **Effort Multipliers** (e.g., RCPX, RUSE, SCED) for cost drivers.

• Modes:

  • Organic: Small, familiar, relaxed (a=2.4, b=1.05).

  • Semi-detached: Mixed environment, medium size (a=3.0, b=1.12).

  • Embedded: Tightly coupled with hardware, strict regulations (a=3.6, b=1.20).

• Versions:

  • Basic: Uses only KSLOC & mode.

  • Intermediate: Adds cost drivers (15 EM_i).

  • Detailed: Adds phase distributions, personnel attributes.

• Schedule:

$$D = c \times (E)^d$$

(D = development time in months).

LOC-based Estimation

• Method: Estimate size (LOC) first, then apply productivity rates (LOC/PM) or models like COCOMO.

• Advantages: Simple, historical data available.

• Disadvantages: LOC depends on language, style; hard to estimate early; doesn't capture functionality well.

Other Methods

• Use Case Points (UCP): Based on number/ complexity of use cases & technical/environmental factors.

• Expert Judgment: Delphi technique, planning poker.

• Analogous Estimating: Use similar past project data.

C. Project Scheduling & Tracking

• Steps:

  1. Task Breakdown (WBS): Decompose project into work packages.

  2. Estimate Duration/Effort per task.

  3. Determine Dependencies (FS, SS, FF, SF).

  4. Create Network Diagram (PERT/CPM).

  5. Identify Critical Path (longest path, zero slack).

  6. Allocate Resources.

  7. Create Gantt Chart (timeline view).

• Tracking:

  • Milestones: Key events (requirements sign-off, design complete).

  • Earned Value Management (EVM):

    • PV (Planned Value), EV (Earned Value), AC (Actual Cost).

    • CV = EV - AC (Cost Variance), SV = EV - PV (Schedule Variance).

    • CPI = EV / AC (Cost Performance Index), SPI = EV / PV (Schedule Performance Index).

  • Regular status meetings, burn-down charts (Agile).

D. Risk Management

• Risk Assessment Process:

  1. Identification: Brainstorming, checklists, historical data, SWOT.

  2. Analysis:

     • Qualitative: Assess probability (H/M/L) & impact (H/M/L). Plot on Probability-Impact matrix. Prioritize.

     • Quantitative: Monte Carlo simulation, decision trees, sensitivity analysis.

  3. Prioritization: Risk Exposure (RE) = Probability × Impact. Rank by RE.

  4. Risk Projection: Use Risk Information Sheet (RIS) for each major risk:

     • Risk Description, Category, Probability, Impact, Mitigation Plan, Contingency Plan, Owner.

• Mitigation Strategies:

  • Avoid: Change plan to eliminate risk.

  • Transfer: Outsource or insure (e.g., cloud provider).

  • Mitigate: Reduce probability or impact (e.g., prototyping, training).

  • Accept: Acknowledge, have contingency plan (for low-impact/high-cost-to-avoid).

E. Software Configuration Management (SCM)

• Purpose: Manage changes to software artifacts (code, docs, models) throughout lifecycle.

• Key Activities:

  • Version Control: Track changes. Git Example:

    • git commit: Save changes to local repo.

    • git branch: Create independent line of development.

    • git merge: Integrate branches.

    • git repository: Central/remote storage (GitHub, GitLab).

  • Change Management: Formal process for requesting, evaluating, approving, implementing changes. Change Request (CR) -> Change Control Board (CCB) review -> Approval/Rejection -> Implementation & Verification.

  • Baselines: Formal, agreed-upon snapshots of artifacts at specific times (e.g., requirements baseline, design baseline). Used as basis for further work.

  • Audits: Formal reviews to ensure conformance to baselines, standards, procedures.

VII. SOFTWARE MAINTENANCE & EVOLUTION

A. Types of Maintenance

1. Corrective: Fix defects found post-release.

2. Adaptive: Modify system to cope with environmental changes (new OS, hardware, regulations).

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

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

B. Re-engineering vs Reverse Engineering

C. Maintenance Process

1. Request: User submits modification request (problem report, enhancement request).

2. Analysis: Evaluate impact, feasibility, cost. Prioritize.

3. Design: Design changes, update affected docs (SRS, design).

4. Implementation: Code changes, unit test.

5. Testing: Integration, regression, system testing of change.

6. Delivery: Deploy to user, update docs, train if needed.

• Metrics: Mean Time to Repair (MTTR), number of change requests, backlog size, maintenance cost as % of total cost.

• Program Comprehension Techniques: Debugging, tracing, static analysis, documentation reading, tool support (call graphs, dependency browsers).

VIII. SOFTWARE QUALITY ASSURANCE (SQA)

A. SQA Activities & Goals

• Goal: Ensure software processes and products conform to standards, procedures, and requirements.

• Activities:

  • Process Definition & Improvement: Define, audit, improve SE processes.

  • Product Evaluation: Reviews, audits, testing oversight.

  • Quality Measurement: Collect/analyze metrics.

  • Configuration Management Oversight: Ensure SCM compliance.

  • Training & Support: For SE practices.

  • SQA Plan: Document outlining SQA activities, standards, tools, responsibilities.

B. Formal Technical Reviews (FTR)

• Purpose: Detect defects early, improve product quality, share knowledge, ensure standards compliance.

• Process:

  1. Planning: Identify artifact, participants (moderator, recorder, author, reviewers).

  2. Overview: Author presents material.

  3. Preparation: Reviewers examine artifact against checklist.

  4. Review Meeting: Focus on defects, not solutions. Record issues.

  5. Rework & Follow-up: Author fixes defects. Verifier checks.

• Types: Inspection (most formal, defect-focused), Walkthrough (less formal, author-led, for understanding), Technical Review (peer review, balanced).

C. Quality Standards

• ISO 9001: Generic quality management system standard. Focuses on process.

• ISO/IEC 25010 (SQuaRE): Software product quality model (characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability).

• CMMI (Capability Maturity Model Integration): Extension of CMM. Provides best practices for process improvement. Maturity Levels (1-5) same as CMM. Also has Capability Levels for specific process areas.

IX. SOFTWARE PROCESS METRICS

A. Types of Metrics

B. Collection & Analysis

• Collection: Automated tools (static analyzers, CI/CD pipelines), manual forms, defect tracking systems.

• Analysis: Statistical techniques (control charts, trend analysis), root cause analysis. Focus on trends, not single points.

C. Use in Process Improvement & Customization

• Baseline Establishment: Measure current state.

• Identify Weaknesses: High defect injection phase? Long cycle time?

• Set Improvement Goals: "Reduce defect density by 20%."

• Evaluate Changes: Did new process (e.g., TDD) improve quality metrics?

• Customization: Metrics show which process model elements work for your context (e.g., if requirements volatility is high, favor iterative models).

\boxed{\text{End of Unit 2 Notes}}