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

UNIT 5: SOFTWARE PROCESS, REQUIREMENTS, DESIGN, TESTING & PROJECT MANAGEMENT

1. SOFTWARE PROCESS MODELS & IMPROVEMENT

1.1 Capability Maturity Model (CMM) / CMMI

• Definition: A framework for improving software process maturity, developed by SEI/Carnegie Mellon. CMMI (Capability Maturity Model Integration) is its evolved, integrated version.

• Purpose: To provide a roadmap for organizations to evolve from ad-hoc processes to disciplined, high-quality, and predictable processes.

• 5 Maturity Levels (CMM):

  1. Initial: Processes are chaotic, success depends on individual effort.

  2. Managed: Project management processes are established (requirements, schedule, cost, quality).

  3. Defined: Processes are documented, standardized, and integrated into an organization-wide process.

  4. Quantitatively Managed: Processes are measured and controlled using quantitative data.

  5. Optimizing: Continuous process improvement is enabled by quantitative feedback and innovative ideas.

• Key Process Areas (KPAs): Specific goals and practices associated with each maturity level (e.g., Requirements Management at Level 2, Technical Solution at Level 3).

• Significance: Higher maturity correlates with better predictability, quality, and productivity. Used for process assessment and benchmarking.

[!TIP] Exam Focus: Be prepared to list all 5 levels with 1-2 key characteristics. CMMI replaces CMM but the 5-level concept is foundational.

1.2 Process Models: Comparison & Application

[!TIP] Exam Focus: Know the core difference between predictive (Waterfall) and adaptive (Agile) models. Be ready to draw and explain the Spiral Model diagram.

1.3 Software Process Customization & Improvement

• Customization (Tailoring): Adapting a standard process model (like RUP or CMMI) to fit a specific project's size, domain, risk, and team structure.

• Need: No single process fits all projects. Tailoring avoids overhead and increases relevance.

• Improvement Methods:

  • Using CMMI: Identify current maturity level, target KPAs, implement practices.

  • Metrics: Collect data (e.g., defect density, cycle time) → Analyze → Identify bottlenecks → Implement changes → Re-measure.

  • Process Assessment: Formal (e.g., SCAMPI) or informal reviews to find gaps.

• Example Tailoring: A small startup might use a lightweight Agile process (e.g., Kanban), while a bank might use a heavily documented, phase-gated variant of Waterfall for compliance.

2. REQUIREMENTS ENGINEERING

2.1 Requirements Fundamentals

• Functional Requirements: What the system must do (services, functions). Examples: "User shall be able to reset password," "System shall calculate total bill."

• Non-Functional Requirements (NFRs): Constraints on how the system should be (quality attributes). Categories:

  • Performance: Response time, throughput.

  • Security: Authentication, authorization, encryption.

  • Usability: Ease of learning, error prevention.

  • Reliability: Mean time between failures (MTBF), availability.

  • Maintainability: Modifiability, modularity.

  • Portability: Ability to run on different environments.

• User Requirements: High-level, natural language statements of what users need. System Requirements: Detailed, structured, often technical specifications for developers.

• Good SRS Characteristics: Correct, Unambiguous, Complete, Consistent, Rankable (priority), Verifiable, Modifiable, Traceable.

2.2 Requirements Elicitation & Analysis Techniques

• Elicitation (Gathering): Interviews, Questionnaires/Surveys, Observation, Document Analysis, Prototyping, Joint Application Development (JAD - facilitated workshop), Use Case Modeling.

• Analysis: Refining raw requirements, resolving conflicts, modeling (e.g., creating DFDs, use cases), prioritizing, negotiating trade-offs.

2.3 Requirements Specification (SRS)

• Structure (IEEE 830 standard):

  1. Introduction (Purpose, Scope, Definitions)

  2. Overall Description (Product perspective, User characteristics, Constraints)

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

• Importance: Single source of truth for stakeholders and developers. Foundation for design, testing, and contract.

2.4 Requirements Validation & Verification

• Validation (Are we building the right system?): Ensuring requirements match user needs. Techniques: Reviews, Prototyping, Test case generation from requirements.

• Verification (Are we building the system right?): Ensuring software meets specified requirements. Techniques: Reviews, inspections, testing.

• Key Difference: Validation checks relevance to problem; Verification checks conformance to specification.

2.5 Requirements Traceability

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

• Importance: Impact analysis for changes, coverage analysis (all requirements tested), compliance, understanding dependencies.

• Challenges: Tool overhead, maintaining links as artifacts evolve, scalability for large projects.

• Mitigation: Use Requirements Traceability Matrix (RTM) or dedicated tools (e.g., Jira, DOORS). Define a clear, lightweight traceability policy early.

[!TIP] Exam Focus: Functional vs. Non-Functional is a very high frequency question. Have 2-3 clear examples for each NFR category. Know the difference between Validation and Verification.

3. SOFTWARE DESIGN

3.1 Design Fundamentals & Principles

• Key Concepts:

  • Abstraction: Hiding complexity, showing essential features.

  • Information Hiding: Concealing implementation details behind interfaces.

  • Modularity: Dividing system into manageable, cohesive modules.

  • Functional Independence: Measured by Cohesion (internal strength of a module) & Coupling (interdependence between modules). Aim for high cohesion, low coupling.

• SOLID Principles (OOD):

  • Single Responsibility

  • Open/Closed

  • Liskov Substitution

  • Interface Segregation

  • Dependency Inversion

3.2 Design Approaches & Modeling

• Architectural Styles:

  • Layered: Presentation → Business Logic → Data Access.

  • Client-Server: Separates UI (client) from processing/data (server).

  • Pipe-and-Filter: Sequential processing stages (e.g., compilers).

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

3.3 UML Diagrams (Application Focus)

• Use Case Diagram: Captures functional requirements. Components: Actors (external entities), Use Cases (system functions), Relationships (association, <<include>>, <<extend>>).

  • Example (Library): Actors: Member, Librarian. Use Cases: Borrow Book, Return Book, Add Member.

• Class Diagram: Static structure. Shows classes, attributes, operations, and relationships (association, inheritance, aggregation).

• Sequence Diagram: Dynamic interaction. Shows objects/actors and messages exchanged over time for a specific scenario.

• Activity Diagram: Workflow of business/operational processes. Similar to flowchart with swimlanes.

3.4 Design Metrics & Quality

• Purpose: Quantify design complexity, predict quality/maintenance effort, identify problem areas.

• Examples:

  • Design Complexity: Based on Structure Chart (fan-in, fan-out, module depth).

  • Coupling Metrics: Measure strength of connections between modules (e.g., data coupling, control coupling).

  • Cohesion Metrics: Measure how closely related responsibilities within a module are.

• How they help: High coupling/low cohesion indicates fragile design, harder to change/test, higher defect density.

3.5 User Interface (UI) Design

• Golden Rules / Key Principles:

  1. User Familiarity: Use terms/concepts from user's world.

  2. Consistency: Commands, menus, input/output formats should be uniform.

  3. Minimal Surprise: Users' expectations should be met; similar actions yield similar results.

  4. Recoverability: Users should be able to undo mistakes (e.g., confirmation dialogs, undo).

  5. User Guidance: Help, error messages, status indicators.

  6. User Diversity: Support different skill levels, disabilities (accessibility).

• Process: User analysis → Prototyping (low/high fidelity) → Usability testing → Iteration.

[!TIP] Exam Focus: Cohesion & Coupling are fundamental. Be ready to give examples of high vs. low cohesion and different coupling types. For UML, practice drawing a simple Use Case Diagram for a given problem (e.g., Online Shopping).

4. SOFTWARE TESTING

4.1 Testing Fundamentals & Strategies

• Test Levels:

  • Unit Testing: Test individual functions/methods (by developers). White-box.

  • Integration Testing: Test interaction between integrated units/modules. Strategies: Big Bang, Top-Down, Bottom-Up, Sandwich (Hybrid).

  • System Testing: Test complete, integrated system against requirements. Types: Functional, Performance, Security, Stress, Usability.

  • Acceptance Testing: Validate system with end-users/customer. Alpha (in-house), Beta (at user site).

• Test Criteria: Correctness (no defects), Completeness (all requirements tested), Reliability (consistent performance).

4.2 Test Techniques

4.3 Test Design & Execution

• Test Plan: Document describing scope, approach, resources, schedule. Components: Test items, features to test, approach, pass/fail criteria, deliverables, risks.

• Test Case Design: [Test ID, Description, Precondition, Input, Expected Output, Postcondition]. Criteria: Valid/invalid inputs, clear expected results, independent, traceable to requirement.

• Test Oracle: Mechanism to determine if test passed/failed (e.g., specification, previous version, expert).

• Example (Login Module):

  • Input: Valid username/password → Expected: Redirect to dashboard.

  • Input: Invalid password → Expected: Show error message "Invalid credentials."

4.4 Specific Testing Types

• Integration Strategies:

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

  • Top-Down: Start from top (main control). Needs stubs.

  • Bottom-Up: Start from bottom (utility functions). Needs drivers.

  • Sandwich: Combines Top-Down & Bottom-Up. Most practical.

• System Testing Types: Functional (features), Performance (load, stress), Security (vulnerabilities), Usability (user-friendliness).

• Regression Testing: Re-testing after changes to ensure existing functionality still works. Often automated.

• Acceptance Testing Steps: 1. Plan acceptance, 2. Select test cases, 3. Run tests with user data, 4. Record results, 5. Negotiate fixes/release.

[!TIP] Exam Focus: BVA & EP are very high frequency. Know the rules (e.g., for BVA: min-1, min, min+1, max-1, max, max+1). Integration strategies comparison is common.

5. SOFTWARE PROJECT MANAGEMENT & QUALITY

5.1 Project Planning & Tracking

• Scheduling Steps: 1. Task Identification (WBS - Work Breakdown Structure), 2. Sequencing (dependencies), 3. Estimation (time, cost), 4. Allocation, 5. Gantt Chart visualization.

• Tracking Mechanisms: Milestones (key dates), Progress Reports, Earned Value Management (EVM) (integrates scope, schedule, cost: PV, EV, AC → CPI, SPI).

• Estimation Techniques:

  • COCOMO (Constructive Cost Model): Effort = a * (KLOC)^b * EAF (where EAF is Effort Adjustment Factor). Has 3 modes (Organic, Semi-detached, Embedded).

  • Function Points (FP): Measure functionality from user view. FP = Count_total * (0.65 + 0.01 * Σ(Value Adjustment Factors)). Convert to LOC using language-dependent factor.

  • Expert Judgment, Analogous Estimating.

5.2 Risk Management

• Steps (Risk Management Process):

  1. Identification: List potential risks (brainstorming, checklists).

  2. Analysis: Estimate Probability (P) and Impact (I). Often use Risk Exposure = P * I.

  3. Prioritization: Rank risks (e.g., using Risk Matrix).

  4. Mitigation Planning: Strategies: Avoid, Transfer, Mitigate (reduce P/I), Accept.

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

• Risk Information Sheet (RIS): Document for each major risk: ID, Description, Probability, Impact, Priority, Mitigation Plan, Owner, Status.

5.3 Software Configuration Management (SCM)

• Definition: The management of changes to software artifacts (code, docs, requirements) throughout the lifecycle.

• Core Functions:

  1. Version Control: Track changes (e.g., Git).

  2. Change Control: Process for requesting, evaluating, approving/rejecting changes.

  3. Configuration Auditing: Formal reviews to ensure compliance with baselines.

  4. Status Reporting: Reports on changes, versions, build status.

• Git Example Workflow:

  
  git clone <repo>       # Get repository
  
  git checkout -b feature-x  # Create & switch branch
  
  # ... make changes ...
  
  git add .              # Stage changes
  
  git commit -m "msg"    # Commit to local branch
  
  git push origin feature-x # Push to remote
  
  git checkout main      # Switch back
  
  git merge feature-x    # Merge changes
  
  

5.4 Software Quality Assurance (SQA) & Metrics

• Software Quality: Conformance to explicitly stated requirements and implicit customer expectations (fitness for use).

• SQA Activities: Audits, Reviews (informal, technical, inspection), Standards compliance, Testing, Process definition.

• Product vs. Process Metrics:

  | Product Metrics | Process Metrics | | :--- | :--- | | Measure attributes of the software product. | Measure attributes of the development process. | | Examples: Defect density, Complexity (cyclomatic), Lines of Code (LOC), Function Points. | Examples: Effort (person-months), Schedule variance, Cost variance, Review efficiency. |

• Test Metrics: Defect density (defects/KLOC), Test coverage (% requirements tested), Test case effectiveness (defects found/total defects).

5.5 Software Maintenance & Evolution

• Need: Software is never perfect; environment changes; new user needs arise.

• Maintenance Types:

  • Corrective: Fix defects.

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

  • Perfective: Enhance performance, maintainability, features.

  • Preventive: Prevent future problems (e.g., code refactoring).

• Reverse Engineering vs. Re-engineering:

  • Reverse Engineering: Analyzing existing system to identify its components and interrelationships. Goal: Understanding.

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

  • Key Difference: Reverse Eng. is analysis; Re-eng. is reconstruction (often includes reverse + forward engineering).

• Program Comprehension Techniques: Debugging, reading code, using visualization tools, documentation analysis.

[!TIP] Exam Focus: Product vs. Process Metrics is a classic 5-mark question. Know COCOMO formula and basic modes. Risk Management steps are frequently asked.

6. SPECIAL TOPICS & TOOLS

6.1 Testing Tools

• Categories & Examples:

  • Test Management: Jira, TestRail (plan, track, manage test cases).

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

  • Performance: JMeter, LoadRunner (load, stress testing).

  • Security: OWASP ZAP, Burp Suite (vulnerability scanning).

6.2 Feasibility Analysis

• Assesses practical benefits of a project. Types:

  • Technical: Can we build it with available tech/expertise?

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

  • Operational: Will it be used? Does it fit organizational culture?

  • Legal: Compliance with laws, regulations, contracts.

6.3 Validation and Verification (V&V)

• In-depth: See 2.4. V&V is a continuous process throughout SDLC, not just testing. Includes requirements reviews (verification), prototype validation, design inspections, code reviews, and all levels of testing.

6.4 Object Models (OOAD)

• Concepts: Objects (instance of class), Classes (blueprint), Inheritance (generalization), Polymorphism (multiple forms), Encapsulation (data hiding), Association/Aggregation/Composition (relationships).

6.5 Structured Methods

• Structured Analysis (SA): Uses DFDs to model system functions and data flows. Focuses on "what."

• Structured Design (SD): Transforms DFDs into Structure Charts showing module calls and data passed. Focuses on "how."

[!TIP] Exam Focus: Feasibility types are often asked as a short note. Structured Analysis & Design is a recurring 4-7 mark question—be ready to draw and explain a simple DFD Level 0 and corresponding Structure Chart.