UNIT 3: Software Engineering - Short Notes

I. SOFTWARE PROCESS MODELS & IMPROVEMENT

Capability Maturity Model (CMM)

A framework for improving software development processes, defining five maturity levels:

Significance: Provides a roadmap for organizational process improvement, enhances product quality, predictability, and reduces risk. Higher maturity correlates with better software quality and lower defect rates.

[!TIP]

Common Pitfall: Confusing CMM levels. Remember: Level 2 is project-focused, Level 3 is organization-focused, Level 4 uses quantitative data, Level 5 is proactive improvement.

Evolutionary & Iterative Models

Spiral Model

Combines waterfall and iterative approaches with risk analysis. Each loop is a phase.

Phases:

1. Determine objectives: Identify alternatives, constraints.

2. Evaluate alternatives: Assess risks, select best approach.

3. Develop & verify: Build next version, test.

4. Plan next iteration: Review results, plan next loop.

Diagram:

Advantages: High risk management, flexible, suitable for large critical systems.
Disadvantages: Complex, costly, requires risk assessment expertise, may not suit small projects.

RAD Model

Focuses on rapid development through reusable components and user involvement.

Phases:

1. Requirements Planning: Identify scope, constraints.

2. User Design: Interactive design with users (JAD sessions).

3. Construction: Component assembly, coding.

4. Cutover: Testing, deployment, user training.

Applications: Time-sensitive projects, user-intensive systems, business applications with clear requirements. Requires skilled users and reusable components.

Incremental Model

Delivers system in increments, each adding functional capability.

Strategy: Divide requirements into prioritized increments. Each increment goes through design, code, test. Early increments provide core functionality; later add features.

Prototyping Model

Builds a prototype to understand requirements, then refines or discards.

Types:

• Throwaway Prototype: Built for understanding, then discarded. Used for unclear requirements.

• Evolutionary Prototype: Continuously refined into final system. Used for complex, evolving requirements.

Advantages: Reduces risk of misalignment, user involvement, early feedback.
Disadvantages: May lead to unrealistic expectations, scope creep, technical debt if not managed.

Agile & Traditional Models

Agile Process Model

Based on Agile Manifesto values: individuals & interactions, working software, customer collaboration, responding to change.

Core Principles: Iterative development, continuous feedback, adaptive planning, self-organizing teams.
Comparison with Traditional (Plan-Driven):

Linear Sequential Model (Waterfall)

Phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Each phase completes before next begins.

Advantages: Simple, easy to manage, good for well-understood projects.
Disadvantages: Inflexible, late testing, difficult to change requirements.

Rational Unified Process (RUP)

Iterative framework with four phases and multiple disciplines.

Phases:

1. Inception: Define scope, business case.

2. Elaboration: Plan project, specify architecture.

3. Construction: Build components, iterative development.

4. Transition: Deploy, user training, support.

Disciplines: Business modeling, requirements, analysis & design, implementation, test, deployment, configuration management, project management, environment, etc.

Software Process Management

Software Process Customization

Tailoring a standard process model to project needs (e.g., adjusting phase length, adding reviews).

How it's done: Analyze project characteristics (size, criticality, team experience), select base model, modify workflows, add/remove artifacts, define entry/exit criteria.

Impact on Quality: Better fit reduces waste, improves adherence, increases defect prevention. Mis-customization can lead to chaos or bureaucracy.

Software Process Metrics

Quantitative indicators to assess and improve processes.

Types:

• Product Metrics: Size, complexity, defects (e.g., defect density).

• Process Metrics: Effort, cost, schedule, review effectiveness.

• Project Metrics: Earned value, team productivity.

Collection & Use: Collected during/after phases, analyzed to identify bottlenecks, predict outcomes, drive improvements (e.g., if review defect detection rate low, improve review process).

Software Product vs. Software Process

II. REQUIREMENTS ENGINEERING

Fundamentals of Requirements

Functional Requirements

Describe what the system must do. Typically phrased as "System shall..."
Examples: "System shall allow user to login with username/password.", "System shall calculate total order amount."

Non-Functional Requirements (NFRs)

Describe how well the system performs. Often quality attributes.

Types & Examples:

• Performance: Response time < 2 sec, throughput 100 TPS.

• Security: Authentication, encryption, role-based access.

• Usability: Intuitive UI, training < 1 hour.

• Reliability: 99.9% uptime, MTBF > 1000 hours.

• Maintainability: Mean time to repair (MTTR) < 4 hours.

• Portability: Support Windows, Linux, macOS.

Importance: Clear, complete, consistent requirements prevent rework, ensure stakeholder alignment, form basis for design and testing.

[!TIP]

Common Pitfall: Mixing functional and non-functional. Ask: "Is this a behavior (functional) or a quality constraint (non-functional)?"

Requirements Specification

System Requirements Specification (SRS) Document

Formal document describing system requirements.

Components:

• Functional Requirements: Detailed behaviors.

• Non-Functional Requirements: Quality attributes, constraints.

• Constraints: Regulatory, technological, organizational.

Characteristics of a Good SRS:

Software Requirements Specification (SwRS)

Focuses on software-specific requirements derived from system requirements. Details software functions, interfaces, data requirements, often used in agile as product backlog.

Requirements Elicitation & Analysis

Elicitation Techniques

• Interviews: One-on-one, structured/unstructured.

• Surveys/Questionnaires: Broad collection, quantitative.

• Observation: Watch users in actual environment.

• Prototyping: Build mockups to refine needs.

• Use Cases: Scenario-based, describe interactions.

• Brainstorming: Group idea generation.

• Document Analysis: Study existing systems, policies.

Activities:

1. Stakeholder Identification: Who is affected/involved?

2. Requirement Gathering: Apply techniques to collect raw needs.

3. Conflict Resolution: Negotiate trade-offs between stakeholders.

4. Prioritization: MoSCoW (Must, Should, Could, Won't), ranking.

Requirements Validation & Verification

Validation Process

Ensures requirements reflect real user needs.

• Reviews: Formal inspections, walkthroughs.

• Prototyping: User feedback on models.

• Test-Case Generation: Deriving tests from reqs to check testability.

Verification vs. Validation (V&V)

Requirements Traceability & Management

Traceability

Ability to trace requirements through development artifacts.

• Forward Traceability: From requirements to design/code/tests. Ensures all reqs implemented.

• Backward Traceability: From code/tests to requirements. Ensures no extraneous features.

Challenges

• Volatility: Requirements change frequently.

• Scale: Large systems have thousands of reqs.

• Tooling: Manual tracking error-prone, need dedicated tools.

Mitigation Strategies

• Traceability Matrix: Table linking reqs to design, code, tests.

• Tool Support: Requirements management tools (e.g., Jama, DOORS).

• Baseline Management: Freeze versions at milestones, control changes.

• Unique Identifiers: Tag each req with ID for tracking.

III. SOFTWARE MODELING & DESIGN

Modeling with UML

Role of UML

Standard graphical notation for visualizing, specifying, constructing, documenting software artifacts. Supports multiple views (structural, behavioral).

Use Case Modeling

Captures functional requirements from user perspective.

Four Basic Parts:

1. Actors: External entities (users, systems) interacting with system.

2. Use Cases: Discrete functional units (e.g., "Place Order").

3. Relationships:

   • Association: actor-use case link.

   • Include: mandatory sub-function.

   • Extend: optional/conditional behavior.

   • Generalization: actor or use case inheritance.

4. System Boundary: Box defining system scope; actors outside, use cases inside.

Creation Process:

1. Identify actors (who uses system?).

2. Identify scenarios (what do they do?).

3. Define use cases (coherent set of scenarios).

4. Describe use cases (steps, pre/post conditions).

5. Model relationships.

Application in Requirement Analysis: Bridges user needs to system functions, facilitates communication, basis for test design.

Common UML Diagrams

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

• Sequence Diagram: Object interactions over time (lifelines, messages).

• Activity Diagram: Workflow, business processes (actions, flows, forks).

• Deployment Diagram: Physical architecture (nodes, connections).

UML for Library Management System (Example)

• Actors: Member, Librarian, System.

• Use Cases: Borrow Book, Return Book, Search Catalog, Manage Inventory.

• Class Diagram: Classes: Book, Member, Loan, Librarian; associations: Member borrows Book.

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

Software Design Concepts & Principles

Fundamental Design Principles

• Abstraction: Hide complexity, expose essentials.

• Modularity: Divide into manageable, cohesive modules.

• Information Hiding: Conceal implementation details behind interfaces.

• Separation of Concerns: Address different aspects independently.

• Least Knowledge (Law of Demeter): Object interacts only with immediate friends.

• Open/Closed Principle: Open for extension, closed for modification.

• Single Responsibility: One reason to change.

• Liskov Substitution: Subtypes replaceable for supertypes.

• Interface Segregation: Many client-specific interfaces vs. one general.

• Dependency Inversion: Depend on abstractions, not concretions.

"Golden Rules" of User Interface Design

1. Consistency: Uniform look, feel, behavior.

2. Error Prevention: Design to avoid errors (constraints, defaults).

3. Recognition rather than Recall: Make options visible, reduce memory load.

4. Flexibility & Efficiency: Accelerators for experts, customizable.

5. Help & Documentation: Accessible, task-focused.

6. User Control & Freedom: Undo, redo, exit easily.

7. Aesthetic & Minimalist Design: No irrelevant information.

8. Visibility of System Status: Keep user informed.

9. Match between system and real world: User's language, familiar concepts.

10. Help users recognize, diagnose, recover from errors: Clear messages.

Importance: Directly impacts usability, user satisfaction, adoption, and productivity.

Design Approaches & Strategies

Comparison: Object-Oriented (OO) vs. Structured (Function-Oriented) Analysis & Design (SA/SD)

Function-Oriented Design

• Decomposition: Break system into functions (top-down).

• Structure Chart: Hierarchical representation of functions, data passed as parameters.

• Data Flow Design: Map DFDs to structure charts; transform or transaction analysis.

Pattern-Based Design

Use of design patterns (reusable solutions to common problems).
Benefits: Proven designs, shared vocabulary, faster development, improved maintainability.
Examples: Singleton, Observer, Factory, Strategy.

Component-Based Design

Build system from pre-built, interoperable components (e.g., libraries, services).
Concept: Components have well-defined interfaces, are replaceable.
Advantages: High reusability, easier maintenance, parallel development, technology independence.

Architectural Design

Architectural Styles

• Layered: Presentation → Business → Data layers. Promotes separation, but may have performance overhead.

• Client-Server: Clients request services from servers. Scalable, but server is bottleneck.

• Pipe-and-Filter: Sequential processing stages (filters) connected by pipes (data streams). Good for batch processing.

• Microservices: Independently deployable services, each with own database. Highly scalable, resilient, but complex communication.

Architectural Views (4+1 View Model)

• Logical View: Object model, key abstractions.

• Development View: Module organization, dependencies.

• Physical View: Deployment on hardware.

• Process View: Concurrency, synchronization.

• Scenarios (+1): Use cases to validate other views.

User Interface (UI) Design

Critical Importance: UI is user's primary interaction point; poor UI leads to rejection even if functional.

Key Principles:

• User-Centered: Design for user tasks, not technology.

• Consistency: Across screens, with platform conventions.

• Feedback: Inform user of actions, status, errors.

• Simplicity: Minimize cognitive load, avoid clutter.

• Error Handling: Prevent errors, provide clear recovery.

• Flexibility: Support different user expertise levels.

• Aesthetic: Professional, pleasing design.

Design Metrics

Definition: Quantitative measures to assess design quality, predict system attributes.

Common Metrics:

• Cohesion: Degree elements of a module belong together. High cohesion desirable.

• Coupling: Degree modules depend on each other. Low coupling desirable.

• Complexity:

  • Cyclomatic Complexity: $$\displaystyle M = E - N + 2P $$

    Where $E$ = edges, $N$ = nodes, $P$ = connected components (usually 1).

    \boxed{M = E - N + 2}

    Measures number of independent paths; higher → more tests needed, harder to understand.

• Size Metrics: Lines of Code (LOC), number of classes, methods.

How Metrics Drive Improvement: Identify high-coupling modules for refactoring, monitor complexity to avoid "spaghetti code", track cohesion to ensure single responsibility.

IV. SOFTWARE TESTING

Testing Fundamentals & Strategy

Strategic Approaches

• V-Model: Testing phases aligned with development phases (unit ↔ detailed design, integration ↔ architecture, system ↔ requirements, acceptance ↔ user needs).

• Test Planning: Define objectives, scope, approach, resources, schedule.

• Defensive Testing: Assume defects exist, design tests to expose them.

Test Levels/Stages

Integration Testing Strategies:

• Big Bang: All units integrated at once. Simple but hard to debug.

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

• Bottom-Up: Start from bottom (utilities), use drivers. Good for data flow.

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

Regression Testing: Re-testing after changes to ensure existing functionality unaffected. Automated tools often used.

Test Design Techniques

Black Box Testing

Tests based on specifications, ignoring internal code.

Techniques:

1. Equivalence Partitioning (EP): Divide input domain into valid/invalid partitions.

   • Rule: Test one value from each partition.

   • Example: Input age (1-120). Partitions: invalid (<1), valid (1-120), invalid (>120). Test: 0, 50, 121.

2. Boundary Value Analysis (BVA): Test edges of partitions.

   • Rule: Test min, max, just below/above, and nominal.

   • Example: Age 1-120 → test 0,1,2,119,120,121.

3. Decision Table Testing: For logic with multiple conditions.

4. State Transition Testing: For systems with states (e.g., ATM).

White Box Testing

Tests based on internal code structure.

Techniques:

1. Statement Coverage: Execute every statement at least once.

   • Metric: $$\displaystyle \frac{\text{Executed statements}}{\text{Total statements}} \times 100\% $$

2. Branch/Decision Coverage: Execute every decision outcome (true/false).

   • Metric: $$\displaystyle \frac{\text{Executed branches}}{\text{Total branches}} \times 100\% $$

3. Path Coverage: Execute every independent path through code.

   • Metric: $$\displaystyle \frac{\text{Executed paths}}{\text{Total paths}} \times 100\% $$ (often impractical due to loops).

Example:

if (x > 0) {

    y = 1;

} else {

    y = 0;

}

• Statement Coverage: Need 2 tests: x=1 (true), x=-1 (false) → both statements executed.

• Branch Coverage: Same as statement here (two branches).

• Path Coverage: Two paths (true, false) → covered by same tests.

Test Oracles

Definition: Mechanism to determine if test output is correct.

Types:

• Specified: From requirements/specs (most reliable).

• Derived: From similar systems, models.

• Heuristic: Based on experience, rules of thumb.

• Concrete: Known correct output from legacy system.

Role: Essential for automated testing; defines expected results.

Designing Test Cases

Each test case: Input, Output, Test Conditions (pre-state, post-condition).

Example for Login Module:

• Test ID: TC_LOGIN_01

• Input: Valid username/password.

• Output: Redirect to dashboard, success message.

• Conditions: User account exists, active.

• Oracle: Specified (from SRS: "Upon valid credentials, system grants access").

Testing Analysis & Metrics

Static vs. Dynamic Analysis

Test Metrics

Purpose: Measure testing effectiveness, progress, product quality.

Types:

• Product Metrics: Defect density (defects/KLOC), failure rate.

• Process Metrics: Test coverage (% requirements tested), defect detection rate (defects found/hour), test case effectiveness (defects found/total defects).

• Project Metrics: Test effort (person-days), schedule variance.

Product vs. Process Metrics:

Testing Tools & Environments

Categories:

• Test Management: Planning, tracking (TestRail, Zephyr).

• Automation: Selenium (web), JUnit (unit), Appium (mobile).

• Performance: JMeter, LoadRunner.

• Security: OWASP ZAP, Burp Suite.

• Defect Tracking: JIRA, Bugzilla.

Role: Increase coverage, repeatability, speed; reduce manual effort; enable continuous testing.

V. PROJECT MANAGEMENT & QUALITY ASSURANCE

Project Planning & Tracking

Project Plan Components

• Scope: What is in/out.

• Schedule: Timeline, milestones.

• Resources: People, hardware, software.

• Risks: Identified risks, mitigation.

• Communication: Stakeholder updates, meetings.

• Quality: Standards, reviews.

• Configuration Management: Version control, change control.

Project Scheduling

Steps:

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

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

3. Estimation: Effort/duration per task (using COCOMO, function points, expert judgment).

4. Network Diagrams: PERT/CPM, identify critical path.

5. Resource Allocation: Assign people, balance load.

6. Schedule Optimization: Crashing, fast-tracking.

Critical Path: Longest path through network; determines project duration. Delays on critical path delay project.

Project Tracking

• Monitoring Progress: Regular status meetings, earned value.

• Earned Value Management (EVM):

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

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

  • AC (Actual Cost): Actual cost incurred.

  • CV = EV - AC (cost variance).

  • SV = EV - PV (schedule variance).

  • CPI = EV / AC (cost performance index).

  • SPI = EV / PV (schedule performance index).

• Variance Analysis: Compare actual vs. plan, identify deviations, corrective actions.

Schedule and Cost Estimation

Techniques:

• COCOMO (Constructive Cost Model):

  $$\displaystyle Effort = a \times (Size)^b \times EAF $$

  Where $Size$ = KLOC, $EAF$ = effort adjustment factor, $a,b$ = constants by project type (organic, semi-detached, embedded).

• Function Points: Measure functionality based on inputs, outputs, inquiries, files, interfaces. Convert to LOC via language-dependent factor.

• Expert Judgment: Delphi technique, analogy.

Risk Management

Risk Identification

Techniques:

• Checklist: Historical risk lists.

• Assumption Analysis: Challenge project assumptions.

• SWOT: Strengths, Weaknesses, Opportunities, Threats.

• Brainstorming: Team workshops.

Risk Assessment

• Probability: Likelihood (0-1 or 1-5 scale).

• Impact: Effect on objectives (cost, schedule, quality) (1-5 scale).

• Risk Exposure (RE): $$\displaystyle RE = Probability \times Impact $$

  \boxed{RE = P \times I}

  Prioritize by RE.

Risk Mitigation Strategies

• Avoid: Change plan to eliminate risk.

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

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

• Accept: Acknowledge, contingency plan or passive acceptance.

Risk Projection Steps & Risk Information Sheet

1. Identify: List risks.

2. Assess: Estimate P, I, RE.

3. Plan: Choose mitigation strategy, assign owner.

4. Monitor: Track, update.

Risk Information Sheet Format:

Software Configuration Management (SCM)

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

Key Functions:

1. Version Control: Track revisions, support parallel development.

   • Example using Git:

     • git init: Create repository.

     • git add file: Stage changes.

     • git commit -m "msg": Save version.

     • git branch feature: Create branch.

     • git merge feature: Merge branch.

2. Change Control: Process to modify baselines (request, review, approve, implement).

3. Configuration Auditing: Verify compliance with specs, standards.

4. Status Reporting: Track configuration items, changes.

Software Quality

Software Quality Assurance (SQA)

Definition: Independent process to ensure software meets quality standards.

Activities:

• Audits: Independent reviews of processes/products.

• Reviews: Inspections, walkthroughs.

• Standards Enforcement: Coding standards, documentation.

• Tool Support: Static analyzers, test tools.

• Metrics Collection: Defect density, test coverage.

Independence: SQA team reports separately from development, avoids conflict of interest.

Quality Concepts

• Fitness for Use: Meets user needs.

• Customer Satisfaction: Exceeds expectations.

• Defect Prevention vs. Detection: Prevention (training, reviews) cheaper than detection (testing).

Quality Metrics for Maintenance

• Maintainability Index: Composite metric (cyclomatic complexity, LOC, comment density).

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

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

• Defect Density: Defects per KLOC during maintenance.

Feasibility Analysis

Assess project viability before commitment.

Types:

• Technical: Can we build it with available technology?

• Economic: Cost-benefit analysis, ROI, NPV.

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

• Legal: Compliance with laws, regulations, contracts.

• Schedule: Can we meet deadline?

Process: Identify alternatives, evaluate each type, recommend feasible option.

Software Maintenance & Evolution

Need for Maintenance

• Corrective: Fix defects.

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

• Perfective: Enhance performance, usability.

• Preventive: Prevent future problems (refactoring, documentation).

Re-engineering vs. Reverse Engineering

Re-engineering Activities:

1. Inventory: Assess existing systems.

2. Restructuring: Refactor code, improve design.

3. Re-documentation: Update docs.

4. Re-engineering: Rewrite using modern tech.

5. Revalidation: Test new system.

VI. SPECIALIZED TOPICS

Object Models

Concept: Represent system as collection of interacting objects.

Elements:

• Classes: Blueprints (attributes, operations).

• Objects: Instances of classes.

• Relationships: Association, aggregation, composition, inheritance, dependency.

Role in OO Analysis: Capture static structure, identify responsibilities, support design.

Program Comprehension Techniques

Approaches to understand existing code:

• Top-Down: Start with high-level architecture, drill down.

• Bottom-Up: Start with code details, build abstract view.

• Slicing: Focus on variables of interest, extract relevant code.

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

• Dynamic Analysis: Execute with probes, trace execution.

Component Model

Definition: Specification for building reusable components (e.g., COM, EJB, .NET assemblies). Defines interfaces, lifecycle, services.

Significance in CBSE (Component-Based Software Engineering):

• Reusability: Components used across applications.

• Interoperability: Standard interfaces allow composition.

• Maintainability: Replace components independently.

• Parallel Development: Teams work on separate components.

Software Performance/Efficiency Metrics

• Response Time: Time to complete a request.

• Throughput: Number of transactions per unit time.

• Resource Utilization: CPU, memory, I/O usage.

• Scalability: Performance under increased load.

• Latency: Delay before transfer starts.

Measurement: Load testing, profiling tools, monitoring.