Software Engineering (CY-602) - Unit 4 Short Notes

I. SOFTWARE PROCESS MODELS & IMPROVEMENT

Capability Maturity Model (CMM)

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

• Five Maturity Levels:

  1. Initial: Ad-hoc, chaotic processes.

  2. Repeatable: Project management processes established (track cost, schedule).

  3. Defined: Process is documented, standardized, and integrated.

  4. Managed: Process is measured and controlled using metrics.

  5. Optimizing: Continuous process improvement via innovation.

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

• Significance: Provides a roadmap for organizational improvement, used for vendor assessment and quality certification (CMMI is its successor).

[!TIP] CMM focuses on process maturity, not the people. Higher levels correlate with better predictability and quality.

Traditional/Linear Models

• Waterfall Model:

  • Phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance (strictly sequential).

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

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

  • When to Use: Stable requirements, regulated environments, small projects.

• Prototyping Model:

  • Types:

    • Throwaway/Rapid Prototyping: Build quick prototype to understand requirements, then discard.

    • Evolutionary Prototyping: Build robust prototype, incrementally evolve into final system.

  • Process: Identify known requirements → Build prototype → User feedback → Refine prototype → Final system.

  • Advantages: Reduces risk, improves user involvement, clarifies requirements.

  • Disadvantages: Can lead to scope creep, management complexity, may compromise on quality.

Evolutionary/Iterative Models

• Spiral Model (Risk-Driven):

  DiagramCANVAS: Spiral diagram with four quadrants per loop: 1. Determine objectives/alternatives, 2. Evaluate alternatives/identify risks, 3. Develop & verify (build next version), 4. Plan next phase (commit to next loop)

  • Phases per Loop: 1. Determine objectives, 2. Evaluate alternatives & risks, 3. Develop & test next version, 4. Plan next iteration.

  • Pros: Explicit risk management, suitable for large, critical systems.

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

• Incremental Model:

  • Strategy: Deliver product in increments (functional slices). Each increment goes through a mini-waterfall.

  • Advantages: Early user feedback, lower risk per increment, better resource utilization.

  • Applicable: When core features are needed early, budget/scope phased.

• RAD (Rapid Application Development):

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

  • Importance: Emphasizes reusable components, iterative prototyping, and user involvement for speed.

  • Applications: Data-intensive, business-focused applications with tight deadlines.

  • Advantages: Very fast development, high user satisfaction.

  • Disadvantages: Requires highly skilled teams, scalable design challenges, not for complex algorithms.

Agile & Modern Frameworks

• Agile Process Model:

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

  • Characteristics: Iterative, incremental, adaptive, people-centric, collaborative.

  • vs Traditional: Welcomes changing requirements, delivers working software frequently, face-to-face communication.

• RUP (Rational Unified Process):

  • Phases: Inception → Elaboration → Construction → Transition.

  • Disciplines (Artifacts & Workflows): Business Modelling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, Environment.

  • Iterative Nature: Each phase is a series of timeboxed iterations.

Process Customization & Improvement

• Need for Tailoring: Generic models (like CMM) must be adapted to organization's size, domain, and project type.

• Role of Software Process Metrics:

  • Product Metrics: Size, complexity, defects density.

  • Process Metrics: Effort, cost, time, efficiency.

  • Project Metrics: Milestones, budget variance, team velocity.

  • Used to measure current state, identify bottlenecks, and guide improvement.

• Improvement Methods: Use CMM/KPAs as a guide, analyze metrics to pinpoint weak areas, implement changes, and re-measure.

II. REQUIREMENTS ENGINEERING

Requirements Fundamentals

• Functional Requirements: Describe system's services/functions (what it does).

  • Example: "The system shall allow users to reset their password via email."

• Non-Functional Requirements (NFRs): Describe system's qualities/constraints (how well it does it).

  • Types & Examples:

    • Performance: Response time < 2 sec.

    • Security: Data encrypted at rest.

    • Usability: New user shall complete task in < 5 min.

    • Reliability: 99.9% uptime.

    • Maintainability: Code must follow naming conventions.

• User Requirements (High-level, natural language, for users/clients) vs. System Requirements (Detailed, precise, for developers - part of SRS).

• Characteristics of a Good SRS (SMART+):

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

Requirements Elicitation & Analysis

• Elicitation Techniques:

  • Interviews (structured/unstructured), Surveys/Questionnaires, Observation (shadowing users).

  • Joint Application Design (JAD): Facilitated workshop with stakeholders.

  • Brainstorming, Prototyping (to clarify needs).

• Activities: Gathering (collect raw needs) → Analysis (resolve conflicts, classify) → Negotiation (prioritize, compromise) → Specification (document in SRS).

Requirements Specification (SRS)

• Components:

  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, analysis models).

• Importance: Single source of truth, basis for design/test, contract between client & developer.

Requirements Validation & Verification

• Validation (Are we building the right system?): Ensures requirements reflect user real needs.

  • Techniques: Reviews, Prototyping, Model validation (e.g., use case walkthrough).

• Verification (Are we building the system right?): Ensures requirements are correctly & consistently specified.

  • Techniques: Consistency checks, completeness checks, formal reviews.

Requirements Traceability

• Challenges: Volatility (changing needs), Scope creep, Lack of tooling, Documentation gaps.

• Mitigation:

  • Traceability Matrix (RTM): Table linking requirements ↔ design ↔ test cases ↔ code.

  • Tools: Dedicated RTM tools (e.g., Jama Connect, modern ALM tools).

  • Change Management Process: Formal request, impact analysis, approval.

Use Case Modeling

• What: Technique to capture functional requirements from an actor's (user/external system) perspective.

• Components:

  • Actors (roles), Use Cases (functional units), Relationships:

    • Association (actor-use case link).

    • Include (mandatory sub-function).

    • Extend (optional/conditional extension).

• Use Case Description Structure:

  • Preconditions, Postconditions, Main Flow (basic path), Alternate Flows (exceptions/other paths).

III. SOFTWARE DESIGN

Fundamental Design Concepts & Principles

• Concepts: Abstraction (hide complexity), Information Hiding (protect internals), Modularity (divide & conquer), Software Architecture (high-level structure).

• SOLID Principles:

  1. Single Responsibility: One class → one reason to change.

  2. Open/Closed: Open for extension, closed for modification.

  3. Liskov Substitution: Subtypes must be substitutable for base types.

  4. Interface Segregation: Many client-specific interfaces > one general interface.

  5. Dependency Inversion: Depend on abstractions, not concretions.

Design Strategies & Approaches

• Function-Oriented Design (FOD / Structured Design):

  • Artifacts: Data Flow Diagrams (DFDs) (show data movement), Structured Charts (show module calling hierarchy & data passed).

  • Process: Transformation Analysis (map DFD's input→process→output to modules).

• Object-Oriented Design (OOD):

  • Concepts: Objects (instance), Classes (blueprint), Inheritance, Polymorphism, Encapsulation.

  • Tool: CRC Cards (Class-Responsibility-Collaboration) for early design brainstorming.

• FOD vs OOD Comparison:

  | Aspect | Function-Oriented (FOD) | Object-Oriented (OOD) | |---------------------|--------------------------------------|--------------------------------------| | Primary Unit | Function/Process | Object/Class | | Focus | Data flow & transformations | Data + behavior bundled together | | Coupling | Data coupling between functions | Message passing between objects | | Change Impact | High (data structure changes ripple)| Lower (encapsulation) |

• Pattern-Based Design: Reusable solutions to common problems.

  • Examples: MVC (Model-View-Controller), Singleton (ensure one instance).

• Component-Based Design (CBD):

  • Principles: High cohesion, low coupling, well-defined interfaces.

  • Advantages: Reusability, maintainability, parallel development.

  • Process: Component identification → interface definition → composition → testing.

Architectural Design

• Architectural Styles/Patterns:

  • Layered (e.g., Presentation-Business-Data layers).

  • Client-Server (2-tier, 3-tier).

  • Pipes-and-Filters (e.g., compiler phases).

  • Microservices (loosely-coupled, independently deployable services).

• Architectural Views (4+1 View Model):

  • Logical View (OO classes, relationships).

  • Process View (Runtime processes/threads, concurrency).

  • Physical View (Deployment on hardware).

  • Development View (Module organization in codebase).

  • Scenarios (Use cases) tie them together.

User Interface (UI) Design

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

• Golden Rules:

  1. Consistency: Same action → same result.

  2. User Familiarity: Use real-world metaphors.

  3. Minimal Surprise: Interface behaves as user expects.

  4. Recoverability: Undo, error correction.

  5. User Guidance: Help, feedback, status.

  6. User Diversity: Accommodate different skills/disabilities.

Design Metrics

• Purpose: Quantify design quality, predict maintainability, identify problem areas.

• Key Metrics:

  • Coupling: Degree of interdependence between modules (lower is better).

  • Cohesion: How closely related responsibilities within a module are (higher is better).

  • Cyclomatic Complexity ($V(G)$): Number of linearly independent paths through code.

$$ \boxed{V(G) = E - N + 2P} $$

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

    > *Higher $V(G)$ → more complex, harder to test/maintain.*

IV. SOFTWARE MODELING (UML)

Role of UML

• Purpose: Standardized visual language for specifying, constructing, documenting software artifacts.

• Helps Represent Architecture: Component Diagrams (physical components & dependencies), Deployment Diagrams (physical nodes & runtime execution).

Key UML Diagrams

Application: UML for Library Management System

1. Identify Actors: Member, Librarian, System.

2. Identify Use Cases: Borrow Book, Return Book, Search Catalog, Add Member, etc. Draw Use Case Diagram.

3. Identify Key Classes: Book, Member, Loan, Catalog, Librarian. Draw Class Diagram with attributes/operations and associations.

4. Model Key Interactions: Draw Sequence Diagram for "Borrow Book" (Member → System → Catalog → Loan).

5. Model Workflow: Draw Activity Diagram for "Return Book" (including overdue check).

6. Show Components/Deployment: Component Diagram (UI, Business Logic, Database); Deployment Diagram (Client PC, Application Server, DB Server).

V. SOFTWARE TESTING

Testing Fundamentals & Strategies

• Strategic Approaches (Test Levels):

  1. Unit Testing: Test individual units (functions/methods). Done by developers. Criteria: Statement, Branch/Decision, Path Coverage.

  2. Integration Testing: Test interactions between integrated units. Strategies:

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

     • Top-Down: From top (main control), use stubs.

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

     • Sandwich/Hybrid: Combination.

  3. System Testing: Test complete, integrated system against SRS. Types: Functional, Performance, Stress, Security, Usability, Recovery.

  4. Acceptance Testing: Validate system for user. Types:

     • UAT (User Acceptance Testing): By end-users.

     • Alpha: In-house (developer site).

     • Beta: At user site (field testing).

• Static vs Dynamic Analysis:

  • Static: Examine code/docs without execution (e.g., Code Reviews, Walkthroughs, Static Analysis Tools for style/complexity).

  • Dynamic: Execute program with test cases (all other testing types).

Test Case Design Techniques

• Black-Box Testing (Specification-based, no code knowledge):

  • Boundary Value Analysis (BVA): Test at boundaries of input domains.

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

    • Example: Input 1-100 → test: 0, 1, 2, 99, 100, 101.

  • Equivalence Partitioning: Divide input domain into valid/invalid partitions; test one value per partition.

  • Decision Table Testing: For logic with multiple conditions (rules → actions).

  • State Transition Testing: Test state changes (based on state diagrams).

• White-Box Testing (Structure-based, code knowledge):

  • Statement Coverage: Execute every statement at least once.

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

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

  • Cyclomatic Complexity ($V(G)$): Gives minimum number of paths needed for basis path testing.

  • How Carried Out: Developers use Control Flow Graph (nodes=statements, edges=control flow) to derive test cases.

Test Planning & Management

• Test Plan: Document describing scope, approach, resources, schedule of testing.

• Contents: Test items, features to be tested/not tested, approach (techniques, tools), pass/fail criteria, resources, schedule, risks, approvals.

• Role in SQA: Provides a roadmap for testing activities, ensures alignment with quality goals, facilitates communication & tracking.

Test Oracles & Metrics

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

  • Sources: Specification, previous version, user expectation, design doc.

• Test Metrics:

  • Purpose: Measure effectiveness, progress, product quality.

  • Types:

    • Product Metrics: Defects density, reliability.

    • Process Metrics: Defect detection rate, test coverage.

    • Project Metrics: Test execution progress, budget variance.

• Testing Tools:

  • Categories: Test management (TestRail), Static analysis (SonarQube), Dynamic analysis (Selenium, JMeter), Performance (LoadRunner).

VI. SOFTWARE CONFIGURATION MANAGEMENT (SCM) & VERSION CONTROL

SCM Functions & Importance

• Functions:

  1. Version Control: Track changes to artifacts.

  2. Change Control: Manage/approve modifications.

  3. Configuration Auditing: Verify conformance to specs.

  4. Status Reporting: Track configuration items.

• Importance: Ensures integrity of product, enables reproducibility, manages parallel development, supports rollback.

Version Control (Example: Git)

• How it Helps: Central repository stores all versions. Developers work on branches, merge changes. History is preserved.

• Basic Git Commands:

  • git clone <repo>: Copy repository.

  • git add <file>: Stage changes.

  • git commit -m "msg": Save snapshot locally.

  • git push: Upload commits to remote.

  • git pull: Fetch & integrate remote changes.

  • git branch <name>: Create branch.

  • git merge <branch>: Merge branch into current.

VII. SOFTWARE PROJECT MANAGEMENT & QUALITY

Project Planning & Estimation

• Feasibility Analysis:

  • Technical: Can we build it with available tech?

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

  • Operational: Will it be used/organizationally fit?

  • Legal: Compliance with laws/regulations.

• Project Plan Components: Scope statement, Schedule (WBS, Gantt), Resources, Budget, Risk plan, Quality plan.

• Schedule & Cost Estimation Techniques:

  • Expert Judgment: Consult experienced people.

  • Function Points: Measure functionality (unadjusted FP → adjusted FP → effort).

  • COCOMO (Constructive Cost Model): Effort = $$\displaystyle a \times (\text{KLOC})^b \times \text{EAF} $$.

    • $a, b$ = constants based on project type (Organic, Semi-detached, Embedded).

    • EAF = Effort Adjustment Factor (from cost drivers).

Project Scheduling & Tracking

• Key Steps:

  1. Define Activities (from WBS).

  2. Sequence Activities (dependencies).

  3. Estimate Resources & Durations.

  4. Develop Schedule (Gantt chart, PERT for uncertainty).

  5. Monitor & Control (track progress).

• Tracking Tools: Earned Value Management (EVM):

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

  • Indices: CPI = EV/AC (cost efficiency), SPI = EV/PV (schedule efficiency).

• Why Essential: Ensures on-time/on-budget delivery, early problem detection, resource optimization.

Risk Management

• Steps:

  1. Identify: List potential risks (checklists, SWOT, expert judgment).

  2. Analyze: Assess probability & impact (qualitative/quantitative).

  3. Prioritize: Focus on high-probability/high-impact.

  4. Mitigate: Plan actions (avoid, transfer, mitigate, accept).

  5. Monitor: Track identified risks, watch for new ones.

• Risk Information Sheet (RIS) Format:

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

Software Quality Assurance (SQA)

• Definition: A planned, systematic set of activities to ensure quality is built in (prevention-oriented).

• Activities: Audits, Reviews (design/code), Process definition, Standards enforcement, Training.

• Relationship with Testing: Testing is a subset of SQA (detection-oriented). SQA oversees the entire process, including testing.

Project Metrics vs. Process Metrics

• Product Metrics: Measure product characteristics (size, complexity, defect density).

• Process Metrics: Measure process characteristics (effort, cost, time, efficiency of activities).

• Project Metrics: Measure project health (milestones met, budget variance, team velocity, defect arrival rate).

VIII. SOFTWARE MAINTENANCE & RE-ENGINEERING

Need for Software Maintenance

• Reasons: Fix errors (Corrective), adapt to new environment (Adaptive), enhance features (Perfective), prevent future problems (Preventive).

Types of Maintenance

1. Corrective: Bug fixes.

2. Adaptive: Changes due to OS, hardware, DBMS changes.

3. Perfective: Performance improvements, new features.

4. Preventive: Code refactoring, documentation updates to prevent future issues.

Reverse Engineering vs. Re-engineering

Program Comprehension Techniques

• Static Analysis: Code reading, call graphs, data flow analysis (without execution).

• Dynamic Analysis: Debugging, profiling (with execution).

• Documentation Analysis: Study existing manuals, comments.

• Visualization Tools: IDE navigators, dependency graphs, UML reverse engineering tools.