UNIT 5: Software Engineering - Comprehensive Short Notes

Based on RGPV exam pattern analysis (2022-2025). Focus on definitions, diagrams, comparisons, and examples.

1. SOFTWARE PROCESS MODELS & IMPROVEMENT

Traditional Models

Linear Sequential (Waterfall) Model

• Definition: A linear, phase-to-phase progression where each phase must be completed before the next begins.

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

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

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

[!TIP] Exam often asks for advantages/disadvantages and when to use.

Iterative Waterfall Model

• Adds feedback loops from later phases to earlier ones (e.g., testing → design).

• Allows limited revisions but still largely sequential.

Evolutionary Models

Prototyping Model

• Types:

  • Throwaway/Rapid Prototyping: Build quick prototype, discard after requirement validation.

  • Evolutionary Prototyping: Continuously refine prototype into final system.

• Applications: UI-heavy systems, unclear requirements, user training.

• Advantages: Early user feedback, reduces risk of wrong requirements.

• Disadvantages: May lead to "prototype as final product" with poor architecture.

Spiral Model

• Diagram:

  DiagramCANVAS: Spiral Model showing loops for planning, risk analysis, engineering, evaluation

• Phases (per loop):

  1. Planning: Determine objectives, alternatives, constraints.

  2. Risk Analysis: Identify/resolve risks (e.g., prototype, simulate).

  3. Engineering: Develop next version of product.

  4. Evaluation: Customer reviews, plan next loop.

• Advantages: Explicit risk management, high flexibility, suitable for large critical systems.

• Disadvantages: Complex, costly, requires risk expertise.

[!TIP] Risk analysis is the key differentiator from other models.

RAD (Rapid Application Development)

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

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

• Applications: Data-centric business applications (e.g., inventory, payroll).

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

• Disadvantages: Requires modularized system, skilled developers, management commitment.

[!TIP] Contrast with Waterfall: RAD uses reusable components and parallel development.

Component-Based Model

• Builds systems from pre-built, tested components (e.g., libraries, APIs).

• Advantages: Reduced development time, higher reliability, easier maintenance.

• Disadvantages: Component selection critical, integration challenges, licensing issues.

Agile & Iterative Models

Agile Process Model

• Agile Manifesto Principles: Individuals/interactions > processes/tools; Working software > documentation; Customer collaboration > contract negotiation; Responding to change > following plan.

• Characteristics vs Traditional: Iterative, incremental, adaptive, people-centric, minimal documentation.

• Methods: XP, Scrum, Crystal, FDD.

Extreme Programming (XP)

• Key Practices: Pair programming, TDD (Test-Driven Development), continuous integration, refactoring, small releases, on-site customer.

• Advantages: High quality, rapid feedback, adapts to changing requirements.

• Disadvantages: Requires high customer involvement, scope creep risk, less documentation.

RUP (Rational Unified Process)

• Phases: Inception → Elaboration → Construction → Transition.

• Disciplines (across phases): Business modeling, requirements, analysis/design, implementation, test, deployment, configuration management, project management, environment.

• Iterative: Each phase has multiple iterations.

Process Improvement Frameworks

Capability Maturity Model (CMM)

• 5 Levels:

  | Level | Name | Key Characteristics | |-------|------|---------------------| | 1 | Initial | Ad hoc, chaotic, success depends on individuals | | 2 | Repeatable | Project management processes established (track cost/schedule) | | 3 | Defined | Process standardized, documented, and integrated | | 4 | Managed | Process measured and controlled using metrics | | 5 | Optimizing | Continuous process improvement via innovation |

• Significance: Provides roadmap for process improvement, links to software quality (higher maturity → more predictable, quality outcomes).

[!TIP] CMM vs CMMI: CMMI is an integrated, superset model (CMMI for Development, Services, Acquisition).

Software Process Metrics

• Types:

  • Product Metrics: Size (LOC, FP), complexity (cyclomatic), quality (defects/KLOC).

  • Process Metrics: Efficiency (time/phase), effectiveness (defect removal rate).

  • Project Metrics: Effort (person-months), cost, schedule adherence.

• Role in Customization: Metrics identify bottlenecks, measure improvement impact, guide process tailoring.

2. REQUIREMENTS ENGINEERING

Requirements Fundamentals

Software Product vs Software Process

Functional Requirements (FRs)

• Definition: Specific services/functions the system must provide (what it does).

• Examples: "User shall be able to reset password via email." "System shall calculate total cart value."

• Importance: Directly map to user needs, form basis for test cases.

Non-Functional Requirements (NFRs)

• Types & Examples:

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

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

  • Usability: Learning curve < 2 hours, error rate < 1%.

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

  • Maintainability: Mean time to repair (MTTR) < 1 hour.

• Importance: Define system qualities, often critical for acceptance, harder to test than FRs.

Requirements Elicitation & Analysis

• Activities: Elicitation → Analysis → Specification → Validation.

• Techniques:

  • Interviews/Surveys: Direct user input.

  • Observation: Study user workflow.

  • Prototyping: Validate unclear requirements.

  • Use Cases: Scenario-based functional requirements.

  • Document Analysis: Existing systems, policies.

[!TIP] Elicitation vs Analysis: Elicitation = gathering raw needs; Analysis = refining, resolving conflicts, prioritizing.

Requirements Specification

SRS (System/Software Requirements Specification) Document

• Typical Structure:

  1. Introduction (purpose, scope, definitions)

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

  3. Specific Requirements (FRs, NFRs, interfaces)

  4. Appendices (use cases, data dictionary)

• Characteristics of Good SRS (IEEE 830):

  • Complete: All requirements specified.

  • Consistent: No contradictory statements.

  • Unambiguous: Single interpretation.

  • Verifiable: Can be tested.

  • Modifiable: Easy to change.

  • Traceable: Links to design/test artifacts.

[!TIP] SRS vs Use Cases: SRS is comprehensive document; use cases are a technique within it for functional requirements.

Use Case Modeling

• Four Basic Parts:

  1. Actors: Users or external systems interacting (e.g., Customer, Payment Gateway).

  2. Use Cases: Functional sequences (e.g., "Place Order").

  3. Relationships: Association, <<include>>, <<extend>>, generalization.

  4. System Boundary: Box defining system scope.

• Application: Captures functional requirements from user perspective, basis for test cases.

• Example (ATM): Actors: Customer, Bank, Technician. Use Cases: Withdraw Cash, Check Balance, Maintain ATM.

[!TIP] <<include>> vs <<extend>>: Include = mandatory sub-function; Extend = optional/conditional behavior.

Requirements Validation & Traceability

Validation vs Verification

Requirement Traceability

• Challenges: Volatility (changing requirements), Complexity (many linked artifacts), Tool support (manual matrices error-prone).

• Mitigation Strategies:

  • Traceability Matrix: Rows = requirements, Columns = design/test artifacts.

  • Tools: Requirements management tools (Jama, DOORS), version control integration.

  • Unique IDs: Assign stable IDs to each requirement.

• Importance: Impact analysis for changes, coverage verification, compliance.

Feasibility Study

• Types:

  • Technical: Can it be built with current tech?

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

  • Operational: Will it be used? Fit in organization?

  • Legal: Compliance with laws/regulations (GDPR, HIPAA).

• Outcomes: Go/no-go decision, refined requirements, risk identification.

• Effect on Requirements: Explicit feasibility constraints become NFRs; implicit constraints shape FRs.

3. SOFTWARE DESIGN

Design Fundamentals

• Design vs Coding: Design = what and how (architecture, interfaces, data structures). Coding = implementation in programming language.

[!TIP] Exam question: "Justify: Design is not coding and coding is not design." Emphasize abstraction levels, design patterns, architecture vs syntax.

Basic Design Principles

• Modularity: Divide system into manageable modules.

• Abstraction: Hide complexity, show essential features.

• Information Hiding: Modules hide internal details behind interfaces.

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

• Golden Rules of UI Design:

  1. Consistency: Same operation → same gesture.

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

  3. Error Handling: Clear, constructive messages.

  4. User Control: Undo, redo, exit.

  5. Recognition over Recall: Make options visible.

Design Approaches

Function-Oriented Design (Structured)

• SA (Structured Analysis): Decompose functions using DFDs (Data Flow Diagrams).

• SD (Structured Design): Transform analysis model into design via transformation analysis (input → transform → output).

• Output: Structure charts, module specifications.

Object-Oriented Design (OOD)

• Object Model: Classes, objects, attributes, methods, relationships (association, inheritance).

• Comparison with Function-Oriented:

  | Aspect | Function-Oriented | Object-Oriented | |--------|-------------------|-----------------| | Primary Abstraction | Function/Process | Object/Class | | Data | Passed as parameters | Encapsulated with methods | | Change Impact | High (data flow changes) | Lower (encapsulation) | | Reuse | Function libraries | Class inheritance/composition |

UML Modeling (Very High Frequency)

• Purpose: Standardized visual modeling language for software architecture.

• Common Diagrams:

  | Diagram | Purpose | Elements | |---------|---------|----------| | Use Case | Functional requirements | Actors, use cases, relationships | | Class | Static structure | Classes, attributes, methods, associations | | Sequence | Object interactions over time | Lifelines, messages, activation bars | | Component | Physical components/modules | Components, interfaces, dependencies | | Deployment | Physical deployment | Nodes, artifacts, connections |

• Example: Library Management System

  • Use Case: Borrower, Librarian actors; Check Out, Return, Search use cases.

  • Class: Book (ISBN, title), Member (ID, name), Loan (date, due).

  • Sequence: Member → System → Database for search.

[!TIP] Sequence vs Collaboration: Sequence emphasizes time order; collaboration (communication) emphasizes structural links.

Design Metrics

• Definition: Quantitative measures of design quality.

• Key Metrics:

  • Cohesion: How closely related responsibilities of a module are.

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

  • Coupling: Degree of interdependence between modules.

    • Types: Data (best), Stamp, Control, External, Common, Content (worst).

  • Complexity: Cyclomatic Complexity \( V(G) = E - N + 2P \) (E=edges, N=nodes, P=components).

• How Metrics Improve Design: Identify high coupling/low cohesion → refactor; complexity → more testing; track improvement over time.

4. SOFTWARE TESTING

Testing Fundamentals

Strategic Approaches

• Strategic: Planned, systematic (test plan, levels, techniques).

• Tactical: Specific test execution.

Testing Levels

• Integration Strategies:

  • Big Bang: 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 (leaf modules), use drivers.

  • Sandwich/Hybrid: Combination (top-down + bottom-up).

• System Testing Types: Functional, Performance, Security, Usability, Compatibility, Recovery.

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

  • Alpha: In-house, controlled environment.

  • Beta: Real users, live environment (pilot).

Static vs Dynamic Analysis

Test Case Design Techniques

Black-Box Testing (ignores internal structure)

• Equivalence Partitioning:

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

  • Rule: One test per class.

  • Example: Input field accepts 1-100.

    • Valid class: 1-100 → test 50.

    • Invalid class: <1 → test 0.

    • Invalid class: >100 → test 101.

• Boundary Value Analysis (BVA):

  • Test at boundaries of equivalence classes.

  • Rule: min, min-1, max, max+1, typical.

  • Example: Same 1-100 → test 0, 1, 100, 101.

  • Why? Errors often occur at boundaries.

• Decision Tables: For logic with multiple conditions (e.g., login: username valid? password valid?).

• State Transition Testing: Test state changes (e.g., ATM: card inserted → PIN entered → cash dispensed).

White-Box Testing (uses internal structure)

• Statement Coverage: Execute every statement at least once.

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

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

• Mutation Testing: Introduce faults (mutants) → check if tests detect them.

• Example: if (x>0 && y<10) → need tests for (T,T), (T,F), (F,T), (F,F) for branch coverage.

Test Oracles

• Definition: Mechanism to determine expected output for a given input.

• Role: Compare actual vs expected → pass/fail.

• Types: Human (tester), documented (spec), previous version, derived (model-based).

[!TIP] Test Oracle Problem: Hard to automate for complex systems; oracle itself may be incorrect.

Test Management & Metrics

Test Plan

• Importance in SQA: Blueprint for testing, ensures coverage, manages resources/risks.

• Components (IEEE 829):

  1. Test Plan Identifier

  2. Introduction (purpose, scope)

  3. Test Items (software features)

  4. Features to be Tested / Not Tested

  5. Approach (techniques, tools)

  6. Pass/Fail Criteria

  7. Suspension/Resumption Criteria

  8. Test Deliverables

  9. Responsibilities

  10. Risks & Contingencies

  11. Schedule

Test Metrics

• Types:

  • Process Metrics: Defect detection rate, test execution progress.

  • Product Metrics: Defect density (defects/KLOC), test coverage (% requirements tested).

  • Project Metrics: Effort, cost, schedule variance.

• Purpose: Monitor testing progress, predict quality, improve process.

• Product vs Process Metrics Difference:

  • Product: Measures output (e.g., number of defects in code).

  • Process: Measures activity (e.g., time to fix a defect).

Regression Testing

• Relation: Re-run tests after changes (bug fix, enhancement) to ensure existing functionality unaffected.

• When: Unit (after code change), System (after build), Acceptance (after release).

• Automation: Crucial for efficiency (tools: Selenium, JUnit).

5. SOFTWARE PROJECT MANAGEMENT

Project Planning & Estimation

Project Plan Components

• Scope, Schedule, Resources (human, hardware, software), Risks, Quality, Communication, Procurement.

Project Metrics

• Size: LOC (Lines of Code), FP (Function Points) → \( \text{FP} = \text{UFP} \times \text{VAF} \).

• Effort: Person-months (PM).

• Cost: Effort × cost/PM + other costs.

Cost Estimation Methods

1. Expert Judgment: Based on expert opinion.

2. Analogy: Compare with similar past projects.

3. COCOMO (Constructive Cost Model):

   • Formula: \( \text{Effort} = a \times (\text{KLOC})^b \times \text{EAF} \) (PM)

     • \( a, b \): Constants based on project type.

     • EAF: Effort Adjustment Factor (from 15 cost drivers).

   • Categories:

     | Mode | Project Type | \( a \) | \( b \) | |------|--------------|---------|---------| | Organic | Small, familiar team | 2.4 | 1.05 | | Semi-detached | Mixed experience | 3.0 | 1.12 | | Embedded | Tightly coupled hardware/software | 3.6 | 1.20 |

   • LOC-based Estimation Advantages: Simple, historical data available.

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

[!TIP] COCOMO vs FP: FP is language-independent, better early estimation; LOC is easier later.

Feasibility Analysis

• Types: Technical, Economic (cost-benefit, ROI), Operational, Legal, Schedule.

• Outcomes: Feasibility report → decision (proceed/modify/stop).

Project Scheduling & Tracking

• Steps:

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

  2. Dependency Identification: PERT/CPM (Critical Path Method).

  3. Duration Estimation: Expert judgment, three-point (PERT: \( \text{TE} = (O + 4M + P)/6 \)).

  4. Critical Path: Longest path → determines project duration.

• Tools:

  • Gantt Chart: Bar chart showing tasks vs time.

  • PERT Chart: Network diagram showing dependencies.

• Why Essential: Identifies critical tasks, resource needs, schedule risks, progress tracking.

Risk Management

Risk Identification

• Techniques: Checklists, assumption analysis, SWOT, brainstorming, Delphi technique.

• Common Risks: Technology, requirements, staff, schedule, external factors.

Risk Assessment & Mitigation

• Principles (RMMM - Risk Mitigation, Monitoring, Management):

  • Avoid: Change plan to eliminate risk.

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

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

  • Accept: Acknowledge, have contingency plan.

• Risk Projection Steps:

  1. Establish scale (probability 0-1, impact 1-5).

  2. Assess impact.

  3. Prioritize (risk exposure = probability × impact).

• Risk Information Sheet Format:

  • Risk ID, Description, Probability, Impact, Priority, Mitigation Strategy, Owner, Status.

Software Configuration Management (SCM)

• Role: Manage changes to software artifacts (code, docs, requirements) systematically.

• Functions:

  • Version Control: Track changes (Git, SVN).

  • Change Control: Process to approve/modify baselines.

  • Configuration Auditing: Verify compliance with specifications.

  • Status Reporting: Who changed what, when.

• Git Example:

  | Command | Purpose | |---------|---------| | git commit | Save changes to local repo | | git push | Upload to remote repo | | git pull | Download + merge from remote | | git branch <name> | Create new branch | | git checkout <branch> | Switch branch |

• How it Helps: Collaboration, rollback capability, traceability, parallel development.

Formal Technical Reviews (FTR)

• Purpose: Detect defects early, ensure quality, knowledge sharing.

• Participants: Author, moderator, reviewer(s), recorder.

• Outcomes: Defect list, action items, decision (accept/modify/reject).

6. SOFTWARE QUALITY & MAINTENANCE

Software Quality Assurance (SQA)

• Definition: Set of activities ensuring software processes/standards are followed to produce quality product.

• Activities: Audits, process reviews, testing, standards enforcement, training.

• Quality Attributes (ISO 9126): Functionality, Reliability, Usability, Efficiency, Maintainability, Portability.

Software Maintenance

• Why Needed: Corrections (bugs), Adaptations (environment changes), Enhancements (new features), Preventive (future-proofing).

• Types:

  | Type | Purpose | Example | |------|---------|---------| | Corrective | Fix defects | Patch security hole | | Adaptive | Adapt to environment | Update for new OS | | Perfective | Enhance performance/usability | Add search feature | | Preventive | Prevent future issues | Refactor legacy code |

• Maintenance Process: Request → Evaluate → Plan → Implement → Test → Release → Update docs.

Re-engineering & Reverse Engineering

Program Comprehension Techniques

• Static: Code reading, slicing, visualization tools.

• Dynamic: Debugging, profiling, execution tracing.

• Documentation-based: Design docs, comments, data dictionaries.

7. SPECIAL TOPICS & SHORT NOTE POTENTIAL

CMM vs CMMI

• CMM: Original model for software process improvement (5 levels).

• CMMI: Integrated model (Development, Services, Acquisition). More detailed practices, broader scope, constellations for different domains. CMMI ≥ CMM 2.0.

Test Oracles

• Definition: Source of expected results.

• Challenges: Automating oracles, oracle correctness, complex outputs.

• Types: Specified (from requirements), derived (from model), human, previous version.

Data Dictionary

• Definition: Central repository of metadata about data elements (name, type, format, range, source, relationships).

• Role in Requirements: Defines precise meaning of terms, ensures consistency in SRS.

Coupling & Cohesion

• Coupling (Inter-module): Prefer Data Coupling (simple data passed) over Stamp/Control/Common/Content.

• Cohesion (Intra-module): Prefer Functional Cohesion (single function) over Sequential/Communicational/Logical/Coincidental.

• Design Goal: High cohesion, low coupling.

Validation vs Verification

Software Crisis

• Historical Context: 1960s-70s: projects often over budget, late, unreliable.

• Reasons:

  • Increasing complexity.

  • Poor project management.

  • Inadequate requirements.

  • Lack of standards/tools.

  • "Software engineering" term coined to apply engineering discipline.

Object Models vs Structured Methods

Final Exam Tips:

• For 7-mark questions: Define → Explain with diagram (if applicable) → Advantages/Disadvantages → Example.

• For 5-mark short notes: Concise definition + 3-4 key points + example.

• Always draw labeled diagrams for Spiral, RAD, UML (Use Case, Class, Sequence), DFDs.

• Distinguish pairs clearly: Validation/Verification, Coupling/Cohesion, Black/White Box, Functional/NFRs, Static/Dynamic.

• COCOMO: Memorize modes (Organic, Semi-detached, Embedded) and their \( a, b \) values.

• CMM Levels: Know order and key characteristic of each level.