UNIT 3: SOFTWARE ENGINEERING - SHORT NOTES

I. SOFTWARE PROCESS MODELS AND IMPROVEMENT

SDLC and its Phases

Software Development Life Cycle (SDLC) is a structured process for building software. Core phases are:

1. Requirement Analysis: Gather and analyze stakeholder needs.

2. Design: Create architecture and detailed design specifications.

3. Implementation (Coding): Convert design into executable code.

4. Testing: Verify and validate the software against requirements.

5. Deployment: Release the software to the end-users.

6. Maintenance: Fix bugs, adapt to new environments, and enhance features.

[!TIP] Exam Focus: Be prepared to draw and explain any traditional/evolutionary model diagram (Waterfall, Spiral, RAD).

Capability Maturity Model (CMM) / CMMI

A framework for improving software development processes. CMM Levels (Key for 7-mark questions):

Significance: Provides a roadmap for process improvement, leading to predictable schedules, higher quality, and reduced costs.

Traditional Models

• Linear Sequential (Waterfall):

  • Diagram:

    DiagramWATERFALL: linear, phase-gate model

  • Flow: Requirements → Design → Code → Test → Deployment → Maintenance.

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

  • Disadvantages: Inflexible, no working software until late, high risk if requirements change.

• Iterative Waterfall: Waterfall with feedback loops (e.g., from Testing back to Design). Reduces risk compared to pure Waterfall.

Evolutionary Models

• Spiral Model:

  • Diagram:

    DiagramSPIRAL: four quadrants per loop: objectives/alternatives, risk analysis, development/verification, planning next loop

  • Process: Projects progress through repeated cycles (loops). Each loop involves planning, risk analysis, engineering, and evaluation.

  • Advantages: Explicit risk management, suitable for large, mission-critical systems.

  • Disadvantages: Complex, costly, requires significant risk assessment expertise.

• Prototyping Model:

  • Build a quick, incomplete version (prototype) to understand requirements.

  • Types: Throwaway (discarded after learning) & Evolutionary (basis for final system).

  • Use When: Requirements are unclear or user interface is critical.

• RAD Model (Rapid Application Development):

  • Phases: Business Modeling → Data Modeling → Process Modeling → Application Generation → Testing & Turnover.

  • Applications: Projects with clear business rules, need for quick development, and user involvement.

  • Advantages: Very fast development, high user involvement.

  • Disadvantages: Requires highly skilled team, not for complex, large-scale systems.

• Incremental Model:

  • Software delivered in increments (functional slices). Each increment goes through a mini-Waterfall.

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

  • Disadvantages: Requires good planning, system architecture must accommodate increments.

Agile Models

• Agile Process Model vs Traditional:

  • Traditional: Plan-driven, fixed scope, sequential, heavy documentation.

  • Agile: Value-driven, adaptive scope, iterative/incremental, working software over documentation, customer collaboration.

• Extreme Programming (XP):

  • Key Practices: Pair programming, Test-Driven Development (TDD), Continuous integration, Small releases, On-site customer.

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

• Rational Unified Process (RUP):

  • Iterative framework with four phases: Inception, Elaboration, Construction, Transition.

  • Uses UML extensively. More disciplined than XP, less rigid than Waterfall.

Component-Based Software Development Model

• System assembled from pre-existing, reusable components (e.g., libraries, services, COTS).

• Process: Requirements → Component Analysis → Component Adaptation/Development → Composition → Testing.

• Advantages: Reduced time/cost, higher quality (tested components), easier maintenance.

• Disadvantages: Component availability, integration challenges, black-box nature.

Process Customization and Improvement

• Software Process Metrics: Quantitative measures to assess process performance (e.g., defect density, productivity, schedule variance).

• Customization for Quality Improvement: Tailor the standard process model to project needs using metrics.

  • Example: If defect density is high in testing, customize to add more code reviews (FTR) in the implementation phase.

  • Example: If schedule variance is frequent, customize to use iterative models (Agile/Spiral) for better risk control.

Software Crisis and Issues

Software Crisis: The difficulty and cost of developing useful, reliable, and maintainable software in the 1960s-70s. Root Causes:

• Increasing complexity of software.

• Unrealistic schedules/budgets.

• Poor requirements definition.

• Inadequate testing.

• Lack of software engineering discipline.

• Rapid hardware advancement outpacing software methods.

II. REQUIREMENTS ENGINEERING

Types of Requirements

Importance of Non-Functional: Dictates system architecture, technology choices, and user satisfaction. Often more critical for success than functional specs.

Requirements Elicitation Techniques

• Interviews: One-on-one or group.

• Questionnaires/Surveys: For large user bases.

• Workshops/JAD Sessions: Structured group meetings.

• Observation: Study users in their work environment.

• Document Analysis: Study existing systems, procedures.

• Prototyping: Build mock-ups to refine requirements.

System and Software 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)

4. Appendices (Supporting info)

Characteristics of a Good SRS (SMART + more):

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

Validation & Verification Process:

• Validation: "Are we building the right product?" (e.g., Reviews with stakeholders, Prototyping).

• Verification: "Are we building the product right?" (e.g., Formal reviews, Model checking, Testable requirements).

Use Case Modeling

• Use Case Diagram Components:

  • Actor: Role (human or external system).

  • Use Case: Functionality provided (oval).

  • System Boundary: Box containing use cases.

  • Associations: Lines connecting actors to use cases.

  • Relationships: <<include>>, <<extend>>, Generalization.

• Four Basic Parts of a Use Case Model:

  1. Use Case Diagram (Visual overview).

  2. Brief Use Case Description (One-paragraph summary).

  3. Use Case Narrative (Detailed steps: Main Success Scenario, Extensions).

  4. Use Case Templates (Structured format with fields like Preconditions, Postconditions, Basic Flow, Alternative Flows).

• Application in Requirement Analysis: Captures functional requirements from user's perspective, facilitates communication, forms basis for test case design.

Requirement Traceability

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

• Challenges: High maintenance cost, tool support, requirement volatility, large number of links.

• Mitigation Strategies:

  • Use Requirements Management Tools (e.g., Jira, DOORS).

  • Establish a Traceability Matrix early.

  • Assign clear ownership.

  • Integrate traceability into the development process.

Feasibility Studies

• Types & Outcomes:

  • Technical Feasibility: Can it be built with current tech? → Outcome: Tech risk assessment.

  • Economic Feasibility: Is it cost-effective? → Outcome: Cost-Benefit Analysis, ROI.

  • Operational Feasibility: Will it be used? → Outcome: User acceptance assessment.

  • Schedule Feasibility: Can it be built on time? → Outcome: Time estimate.

• Implicit/Explicit Effects on Requirements:

  • Explicit: Directly changes requirements (e.g., budget cut removes a feature).

  • Implicit: Influences non-functional requirements (e.g., technical constraint leads to a performance requirement).

Structured Analysis (SA)

• Goal: Understand and model the what (functional requirements).

• Tools:

  • Data Flow Diagrams (DFDs): Show data movement between processes, data stores, external entities.

    • Levels: Context (Level 0), Level 1, Level 2...

    • Balancing: Inputs/outputs of parent/child DFDs must match.

  • Data Dictionary: Central repository defining all data elements, structures, flows, and stores in the DFDs. Ensures consistency.

• Relationship with Structured Design (SD): SA model (DFDs) is transformed into SD model (Structure Charts) during design phase.

III. SOFTWARE DESIGN

Design Principles and Concepts

• Golden Rules of User-Interface Design:

  1. Place the user in control. (e.g., undo/redo, flexible interaction).

  2. Reduce the user's memory load. (e.g., visible options, defaults).

  3. Make the interface consistent. (e.g., same operation, same gesture).

• Design Metrics (Importance): Quantify design quality, identify complex areas, predict maintainability/cost.

  • Types: Complexity Metrics (e.g., Coupling, Cohesion), Size Metrics (e.g., Number of Classes, Depth of Inheritance Tree).

• Cohesion and Coupling:

  • Cohesion (Within a module): How closely related the responsibilities of a single module are.

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

  • Coupling (Between modules): Degree of interdependence between modules.

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

  • Goal: High Cohesion, Low Coupling.

Design Approaches

UML Modeling

• UML Diagrams (Key ones):

  • Structural: Class, Object, Component, Deployment.

  • Behavioral: Use Case, Sequence, Activity, State Machine.

• Representing Software Architecture: Component diagrams show physical components; Package diagrams show logical grouping; Deployment diagrams show physical nodes.

• Architectural Views (Krutchen's 4+1):

  1. Logical View: Object model (Class Diagrams).

  2. Process View: Concurrency, communication (Sequence/Activity Diagrams).

  3. Physical View: Deployment topology (Deployment Diagrams).

  4. Development View: Organization of modules (Package Diagrams).

  5. Scenarios (+1): Use Cases tying all views together.

Architectural Design

• Architectural Styles: Reusable patterns of system organization.

  • Examples: Layered, Client-Server, Pipe-and-Filter, Microservices, Event-Driven.

• Component Model: Defines standards for component implementation, composition, and interaction (e.g., JavaBeans, .NET assemblies).

• Object Models: Describe system structure via classes, attributes, operations, and relationships (Association, Inheritance).

User Interface Design

• Importance: Directly impacts usability, user satisfaction, and task efficiency. Poor UI can negate good functionality.

• Key Principles:

  • User-Centered: Design for user's tasks and mental model.

  • Consistency: Across screens and with platform conventions.

  • Feedback: Inform user of actions/status.

  • Error Prevention & Handling: Prevent errors, provide clear recovery.

  • Simplicity: Support both novice and expert users.

  • Visibility: Make objects and actions visible.

Design vs Coding

• Justification: "Design is not coding and coding is not design."

  • Design is about what (architecture, interfaces, data structures) and how at a high level (algorithms, patterns). It's abstract, technology-agnostic.

  • Coding is the implementation of the design in a specific programming language. It deals with syntax, low-level data types, and compiler specifics.

  • Good design makes coding straightforward. Poor design leads to complex, unmaintainable code regardless of coding skill.

IV. SOFTWARE TESTING

Test Planning

• Importance: Defines scope, approach, resources, schedule, and deliverables of testing. Prevents ad-hoc testing.

• Role in SQA: Foundation for all test activities. Ensures testing is systematic, measurable, and aligned with quality goals.

Test Levels

Integration Testing Strategies:

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

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

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

• Sandwich/Hybrid: Combination of top-down and bottom-up.

Test Techniques

Black-Box Testing (Based on specs, no code knowledge)

• Boundary Value Analysis (BVA):

  • Rule: Test at boundaries of equivalence partitions (min, max, just inside/outside).

  • Usage: For input validation, range checks.

  • Example: For input 1 <= age <= 60, test: 0, 1, 2, 59, 60, 61.

• Equivalence Partitioning:

  • Divide input domain into valid/invalid partitions. Test one value from each.

  • Example: For age (valid: 1-60, invalid: <1, >60), test: 30 (valid), -5 (invalid), 100 (invalid).

White-Box Testing (Based on code structure)

• Path Testing: Design tests to execute all independent paths in flow graph.

• Statement Coverage: Execute every statement at least once.

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

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

Static vs Dynamic Analysis

• Static Analysis: Analyze code without executing it.

  • Examples: Code reviews, inspections, linting (syntax/format), static analysis tools (SonarQube, FindBugs).

• Dynamic Analysis: Analyze code during execution.

  • Examples: Unit testing, profiling, memory leak detection, coverage tools.

Test Case Design

• Criteria: Clear, repeatable, independent, covers requirements/risks, has expected result.

• Design Example (Login Module):

  • Test ID: TC_LOGIN_01

  • Title: Valid login with correct credentials.

  • Precondition: User account exists.

  • Input: Username: valid_user, Password: valid_pass.

  • Expected Output: Redirect to dashboard, session created.

  • Postcondition: User logged in.

Test Metrics and Oracles

• Purpose of Test Metrics: Measure testing effectiveness, progress, product quality. Predict release readiness.

• Types:

  • Process Metrics: Defects found/fixed per day, test execution progress.

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

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

  • Types: Specified (from requirements), Developed (test harness), Existing (comparable legacy system), Human (tester judgment).

Testing Tools

• Categories: Test management (Jira, TestRail), Functional automation (Selenium, Appium), Performance (JMeter, LoadRunner), Unit testing (JUnit, pytest), Static analysis (SonarQube, Checkstyle).

• Role: Increase efficiency, repeatability, coverage; reduce manual effort.

V. PROJECT MANAGEMENT AND CONFIGURATION MANAGEMENT

Software Configuration Management (SCM)

• Functions: Identification (items to control), Version Control (track changes), Change Control (manage modifications), Configuration Auditing (verify changes), Status Reporting (track versions).

• Role in Handling Changes: Provides controlled, auditable process for modifying software artifacts (code, docs, models). Prevents chaos.

• Version Control (Git Example):

  • git init / git clone: Initialize/copy repository.

  • git add <file>: Stage changes.

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

  • git push origin main: Upload to remote (e.g., GitHub).

  • git branch <name> / git checkout <name>: Create/switch branches for features.

  • Branching Strategy: Git Flow (master, develop, feature, release, hotfix branches).

Project Planning

• Activities: Define scope, estimate effort/cost, identify risks, develop schedule, allocate resources, plan for quality and configuration management.

• Importance: Foundation for tracking and control. Reduces uncertainty, aligns stakeholders.

Project Scheduling and Tracking

• Key Steps:

  1. Define Activities: Break down WBS into tasks.

  2. Sequence Activities: Determine dependencies (PERT/CPM).

  3. Estimate Durations: For each task.

  4. Develop Schedule: Create timeline (Gantt chart).

  5. Track Progress: Compare actual vs. planned (Earned Value Management).

• Essential for Success: Provides visibility, enables early problem detection, facilitates resource management, and ensures on-time delivery.

Cost Estimation

• Methods:

  • LOC-based: Estimate size (Lines of Code) → Apply productivity rate (LOC/person-month) → Calculate effort/cost.

  • COCOMO (Constructive Cost Model): Empirical model using size (KLOC) and project attributes.

• COCOMO Categories:

  • Organic: Relatively small, familiar environment, relaxed schedule.

  • Semi-detached: Mixture of experience levels, medium size.

  • Embedded: Tightly coupled with hardware, stringent requirements.

• COCOMO Formula (Basic):

$$Effort = a \times (KLOC)^b \quad [Person-Months]$$

$$T_{dev} = c \times (Effort)^d \quad [Months]$$

(Coefficients `a,b,c,d` vary by project mode).

• Advantages of LOC-based: Simple, intuitive.

• Disadvantages: Hard to estimate LOC early, language-dependent, doesn't account for complexity/tools.

Risk Management

• Risk Assessment & Mitigation Principles:

  • Identify risks early and continuously.

  • Analyze (probability, impact) to prioritize.

  • Plan mitigation strategies (avoid, transfer, mitigate, accept).

  • Monitor risks throughout project.

• Risk Identification: Brainstorming, checklists, Delphi technique, SWOT analysis.

• Risk Projection Steps:

  1. Establish a scale (e.g., 1-5) for probability & impact.

  2. Assess each risk's probability and impact.

  3. Calculate Risk Exposure (REx): REx = Probability × Impact.

  4. Rank risks by REx.

• Risk Information Sheet Format:

  | Field | Content | | :--- | :--- | | Risk ID | Unique identifier | | Description | Clear statement of risk | | Probability | Likelihood (e.g., High/Med/Low or 0.1) | | Impact | Severity if it occurs (e.g., High/Med/Low or 1000) | | REx | Probability × Impact | | Mitigation Plan | Actions to reduce probability/impact | | Owner | Person responsible |

Software Maintenance

• Need for Maintenance: Fix defects, adapt to new environments (OS, hardware), enhance features, improve performance.

• Types:

  • Corrective: Fix bugs.

  • Adaptive: Adapt to environment changes.

  • Perfective: Enhance performance/maintainability.

  • Preventive: Prevent future problems.

• Maintenance Process: Request → Analysis → Design → Implementation → Review → Release.

• Re-engineering vs Reverse Engineering:

  • Reverse Engineering: Analyze existing system to understand its structure/function (no modification). Output: Models, documentation.

  • Re-engineering: Rebuild existing system using new tech/architecture, often after reverse engineering. Output: New system.

• Program Comprehension Techniques: Reading code, using debuggers, static analysis tools, documentation review, abstraction (e.g., generating UML from code).

VI. QUALITY ASSURANCE AND ADDITIONAL TOPICS

Software Quality Assurance (SQA)

• Definition: A planned, systematic set of activities to ensure software process and product conform to requirements, standards, and procedures.

• Goal: Prevent defects, not just find them. Applies to process and product.

• Activities: Audits, process definition, training, tool evaluation, configuration management oversight.

Software Quality Metrics

• Product Metrics: Measure attributes of the product itself.

  • Examples: Defect density (defects/KLOC), Mean Time To Failure (MTTF), Cyclomatic Complexity.

• Process Metrics: Measure attributes of the development process.

  • Examples: Defect removal efficiency (DRE), Productivity (LOC/person-month), Schedule variance.

• Metrics for Maintenance: Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR), Backlog of pending change requests.

Verification and Validation (V&V)

• Verification (V): "Are we building the product right?" (Conformance to specs). Static (reviews) and Dynamic (testing).

• Validation (V): "Are we building the right product?" (Fulfills user needs). Dynamic (testing in real environment).

• V&V Plan: Document outlining strategies, resources, schedule, and techniques for both.

Formal Technical Review (FTR)

• Definition: A formal meeting where software engineers examine a work product (e.g., design, code) for defects and improvement opportunities.

• Participants: Author, Moderator, Recorder, Reviewer(s).

• Process: Overview → Preparation → Review Meeting → Rework → Follow-up.

• Goal: Find defects early, improve quality, share knowledge, ensure standards.

Software Process vs Software Product

Software Process Metrics (Role in Customization)

• Role: Provide objective data to identify weaknesses in the process (e.g., high defect escape rate from unit to system testing).

• Customization & Improvement: Use metrics to:

  1. Pinpoint problem areas (e.g., design phase has high rework).

  2. Evaluate impact of process changes (e.g., after introducing pair programming, did defect density drop?).

  3. Predict outcomes (e.g., based on past productivity, estimate next project duration).

  4. Justify process investments (e.g., ROI of a new testing tool).