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

UNIT 1: SOFTWARE ENGINEERING - CORE CONCEPTS & PRACTICES

Based on rigorous analysis of 7 past RGPV exam papers (Jun 2025 - May 2023), this unit focuses on foundational process models, requirements engineering, design principles, testing fundamentals, and project management. Questions frequently ask for comparisons, advantages/disadvantages, diagrams, and definitions.

1.0 SOFTWARE PROCESS & PROCESS IMPROVEMENT

1.1 Software Process & Product

[!TIP] Exam Focus: Questions often ask to "distinguish between" or list characteristics. Remember: Process is the means; Product is the end.

1.2 Process Models (Paradigms)

Linear Sequential (Waterfall) Model

• Phases (in sequence): Requirements → Design → Implementation → Testing → Deployment → Maintenance.

• Diagram:

  DiagramCANVAS: Classic downward flowing waterfall with distinct, non-overlapping phases and feedback arrows only to immediate predecessor.

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

• Disadvantages: Inflexible, difficult to change requirements once phase is complete, working software late in cycle, high risk for large/complex projects.

Prototyping Model

• Types:

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

  • Evolutionary Prototyping: Build prototype as core of final system, incrementally adding features.

• Applications: Requirements unclear, user interface intensive, complex user interactions.

• Advantages: Reduces risk of wrong requirements, user involvement early, better user satisfaction.

• Disadvantages: Can lead to "prototype as final product" with poor architecture, scope creep, management difficulty.

Evolutionary Models

• Incremental Model: Product built and delivered in increments (e.g., core functionality first). Each increment goes through design, code, test.

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

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

• Spiral Model

  DiagramCANVAS: Spiral with four quadrants per loop: (1) Objective Setting & Alternatives, (2) Risk Analysis & Resolution, (3) Development & Verification, (4) Planning for Next Iteration.

  • Phases per cycle: 1. Objective Setting, 2. Risk Analysis (identify/resolve risks), 3. Development (design, code, test), 4. Planning (next cycle).

  • Advantages: Explicit risk management, high-risk projects, large mission-critical systems.

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

RAD (Rapid Application Development) Model

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

• Emphasis: Reusable components, time-boxed development (2-3 months), active user involvement, small teams.

• Applications: Well-understood domain, need for rapid development, user interface heavy.

• Advantages: Very fast development, high user involvement, quality focus.

• Disadvantages: Requires committed users, scalable only to a limit, needs experienced team, management complexity.

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.

• Illustration (Scrum): Sprints (2-4 week iterations), Product Backlog, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.

• Comparison with Plan-Driven (Waterfall):

  • Agile: Adaptive, iterative, emergent requirements, customer-centric, working software frequently.

  • Plan-Driven: Predictive, sequential, fixed requirements, contract-centric, documentation heavy.

• Advantages: Faster time-to-market, higher customer satisfaction, embraces change.

• Disadvantages: Less predictability, documentation can be insufficient, requires high customer involvement, challenging for large distributed teams.

Component-Based Development Model

• Concept: Assemble system from pre-built, reusable components (libraries, services, modules).

• Process: Requirements → Component Identification/Procurement → Component Adaptation → Integration → Testing.

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

• Disadvantages: Component availability, integration challenges, performance overhead, black-box nature limits optimization.

RUP (Rational Unified Process)

• Phases: 1. Inception (scope, business case), 2. Elaboration (architecture, risk mitigation), 3. Construction (component development), 4. Transition (deployment, user support).

• Key Characteristics: Use-case driven, architecture-centric, iterative & incremental, controlled by workflows (Business Modeling, Requirements, etc.) and disciplines (Software Engineering, etc.).

1.3 Process Assessment & Improvement

Capability Maturity Model (CMM)

• Significance: Provides roadmap for improvement, predicts process capability, basis for CMMI (Integrated), widely used for vendor assessment and process quality certification.

Software Process Metrics

• Definition: Quantitative indicators to assess process, product, and project.

• Types:

  • Product Metrics: Size (LOC, FP), Complexity (cyclomatic), Quality (defects/KLOC).

  • Process Metrics: Cycle time, defect removal efficiency, productivity (effort/LOC).

  • Project Metrics: Cost, schedule, effort, risk exposure.

• Role in Customization/Improvement: Provide objective data to identify bottlenecks, predict outcomes, evaluate improvement initiatives, and tailor processes to project context.

[!TIP] Common Pitfall: Confusing CMM Levels with their KPAs. Remember Level 2 is Project-focused, Level 3 is Organization-focused, Level 4 is Quantitative, Level 5 is Continuous Improvement.

2.0 SOFTWARE REQUIREMENTS ENGINEERING

2.1 Requirements Fundamentals

• Functional Requirements (FRs): What the system must do. Services, functions, behaviors.

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

• Non-Functional Requirements (NFRs): How the system performs its functions. Constraints on FRs.

  • Types & Examples:

    • Performance: Response time < 2 sec.

    • Security: Data encryption, role-based access.

    • Usability: Intuitive UI, < 2 hours training.

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

    • Maintainability: Modular design, cyclomatic complexity < 10.

• User Requirements vs. System Requirements:

  • User Requirements: High-level, natural language, what user needs (often in Use Cases or User Stories).

  • System Requirements: Detailed, precise, unambiguous specification for developers (in SRS).

2.2 Requirements Elicitation & Analysis

• Elicitation Techniques:

  • Interviews: Structured/unstructured with stakeholders.

  • Surveys/Questionnaires: For large user groups.

  • Observation: Study users in their environment.

  • Workshops/JAD Sessions: Focused group sessions.

  • Prototyping: Build mock-ups to refine requirements.

  • Document Analysis: Study existing systems, procedures.

• Analysis Activities: Requirements negotiation (conflict resolution), prioritization (MoSCoW, Kano), modeling (use cases, data models), consistency checking.

2.3 Requirements Specification

• System Requirements Specification (SRS) Document:

  DiagramCANVAS: SRS Document Structure: Introduction, Overall Description, Specific Requirements (Functional, Non-Functional, Interface), Appendices.

• Characteristics of a Good SRS (IEEE 830):

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

  • Ranked for importance/ stability, Testable (each requirement should have a test).

2.4 Requirements Validation & Verification

• Validation: "Are we building the right system?" (Conformance to user needs).

  • Techniques: Reviews (inspections, walkthroughs), Prototyping, Test-case derivation (from requirements).

• Verification: "Are we building the system right?" (Conformance to specification).

  • Techniques: Reviews, Model checking, Consistency analysis.

2.5 Requirements Traceability & Management

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

• Challenges: Requirements volatility, large number of links, tool support, team coordination.

• Mitigation: Use Requirements Management Tools (e.g., JIRA, DOORS), maintain Traceability Matrix (linking reqs to design/test cases), define clear ownership, version control.

[!TIP] Exam Tip: Validation vs Verification is a classic question. Remember: Validation = User Needs (Are we building the right thing?), Verification = Spec Conformance (Are we building it right?).

3.0 SOFTWARE MODELING & DESIGN

3.1 Modeling with UML

• Role: Standardized graphical language for visualizing, specifying, constructing, documenting artifacts of a software system.

• Use Case Modeling:

  • Purpose: Capture functional requirements from user's perspective.

  • Four Basic Parts:

    1. Actors: Roles interacting with system (User, Admin).

    2. Use Cases: Discrete units of functionality (Login, Search Book).

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

    4. System Boundary: Box defining system scope.

• UML Diagrams for Library Management System (Example):

  • Use Case Diagram: Actors (Member, Librarian, Admin) with associated use cases.

  • Class Diagram: Entities (Book, Member, Loan) with attributes, methods, and relationships (associations, inheritance).

  • Sequence Diagram: Interaction over time for "Borrow Book" (objects: MemberUI, System, Database, messages: request, validate, update).

  • Activity Diagram: Workflow for "Book Return" (actions, decisions, forks/joins).

3.2 Design Concepts & Principles

• Fundamental Concepts: Abstraction, Information Hiding, Modularity, Separation of Concerns, Functional Independence (high cohesion, low coupling).

• Key Software Design Principles (SOLID & others):

  • Single Responsibility Principle (SRP): A class should have one reason to change.

  • Open-Closed Principle (OCP): Open for extension, closed for modification.

  • Liskov Substitution Principle (LSP): Subtypes must be substitutable for base types.

  • Interface Segregation Principle (ISP): Many client-specific interfaces > one general interface.

  • Dependency Inversion Principle (DIP): Depend on abstractions, not concretions.

3.3 Design Approaches & Strategies

• Function-Oriented Design: Decompose system into a hierarchy of functions. Uses Structure Charts to show module calling hierarchy and data passed.

• Pattern-Based Design: Reuse proven solutions to common design problems (e.g., Singleton, Observer, Factory).

• Component-Based Design: System as assembly of components with defined interfaces. Promotes reuse, parallel development.

3.4 Architectural Design

• Architectural Styles:

  • Layered: Presentation → Business Logic → Data Access.

  • Client-Server: Client requests, Server provides services.

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

  • Repository: Shared data store (central database) accessed by independent components.

• Architectural Views (4+1 View Model):

  1. Logical View: Object model (class diagrams).

  2. Process View: Concurrency, synchronization (activity/sequence diagrams).

  3. Physical View: Deployment on hardware (deployment diagrams).

  4. Development View: Organization of modules in code (package diagrams).

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

3.5 User Interface (UI) Design

• Importance: Directly impacts user productivity, satisfaction, error rates, and system adoption. Poor UI can render a functionally excellent system unusable.

• Golden Rules / Key Principles:

  1. Consistency: Same action → same result, uniform layout, terminology.

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

  3. Recognition rather than Recall: Make options visible; user shouldn't memorize commands.

  4. User Control & Freedom: Undo/redo, clear exit, user-initiated actions.

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

  6. Aesthetic & Minimalist Design: No irrelevant information.

  7. Help & Documentation: Easy to access, task-focused.

3.6 Design Metrics

• Definition: Quantitative measures of design quality and complexity.

• Types:

  • Structural Metrics: Coupling (afferent, efferent), Cohesion (functional, sequential), Complexity (cyclomatic complexity M = E - N + 2P).

  • Size Metrics: Number of classes, methods per class, inheritance depth.

• How They Help: Provide objective basis to identify "problem" modules (high coupling, low cohesion, high complexity) that are harder to understand, test, and maintain. Guide refactoring efforts.

[!TIP] Cyclomatic Complexity Formula: V(G) = E - N + 2P (E=edges, N=nodes, P=connected components). Measures number of linearly independent paths → basis for white-box testing.

4.0 SOFTWARE TESTING (QUALITY ASSURANCE)

4.1 Testing Fundamentals

• Strategic Approaches:

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

  • Analytic: Use formal methods, models to derive tests.

  • Destructive: Try to "break" the system (stress, security).

• Test Plan: Document describing scope, approach, resources, schedule, and test items. Components: Test plan identifier, introduction, test items, features to be tested/not tested, approach, pass/fail criteria, test deliverables, tasks, schedule, risks.

• Software Quality Assurance (SQA): A planned, systematic pattern of activities to ensure quality. Activities: Process definition/assessment, audits, reviews, testing, configuration management, documentation standards, training.

4.2 Test Levels / Types

4.3 Test Case Design Techniques

• Black-Box Testing (Behavioral): Based on specifications, ignores internal code.

  • Equivalence Partitioning (EP): Divide input domain into classes (valid/invalid). Select one test per class.

    • Example: Input: 1-100. Valid class: 1-100. Invalid: <1, >100. Test cases: -5, 50, 105.

  • Boundary Value Analysis (BVA): Test at boundaries of EP classes (min, max, just inside/outside).

    • Example: Same input. Test: 0, 1, 100, 101.

• White-Box Testing (Glass-Box): Based on internal logic/structure.

  • Statement Coverage: Execute every statement at least once. (Statements Executed / Total Statements) * 100%.

  • Branch/Decision Coverage: Execute every decision branch (true & false) at least once.

  • Basis Path Testing: Use cyclomatic complexity V(G) to determine number of independent paths. Design test for each path.

• Test Oracle: Mechanism to determine if test passed/failed. Source of expected results (specification, previous version, expert opinion).

4.4 Test Analysis & Metrics

• Static vs. Dynamic Analysis:

  • Static: Examine code/docs without execution (reviews, static analyzers, lint).

  • Dynamic: Execute program with test inputs (unit, integration, system testing).

• Test Metrics:

  • Purpose: Measure progress, effectiveness, quality, predict completion.

  • Types:

    • Test Progress: % test cases executed, defects found/closed.

    • Test Effectiveness: Defects found in testing vs. post-release (escape rate).

    • Test Coverage: Requirements coverage, code coverage (statement, branch).

• Product vs. Process Metrics: Product metrics measure attributes of the product (size, defects). Process metrics measure the development process (effort, cycle time).

• Testing Tools:

  DiagramSEARCH: software testing tools landscape selenium junit testng loadrunner
  • Categories: Unit (JUnit, NUnit), Functional (Selenium, Cypress), Performance (LoadRunner, JMeter), Management (TestRail, Zephyr).

[!TIP] BVA Rule of Thumb: For a range [a, b], test a-1, a, a+1, b-1, b, b+1. For discrete values, test each valid value and one invalid.

5.0 SOFTWARE PROJECT MANAGEMENT & CONFIGURATION MANAGEMENT

5.1 Project Planning & Estimation

• Feasibility Analysis:

  • Technical: Can it be built with available tech?

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

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

  • Legal: Compliance, licenses, regulations.

• Project Plan Components: Scope, schedule, budget, quality plan, staff plan, communication plan, risk plan.

• Project Metrics: Used to track and control (e.g., Schedule Variance SV = EV - PV, Cost Variance CV = EV - AC).

• Schedule & Cost Estimation Techniques:

  • Expert Judgment, Analogous Estimating.

  • COCOMO (Constructive Cost Model): Effort = a * (Size)^b * EAF (Size in KLOC, EAF=Effort Adjustment Factor). Gives person-months.

  • Function Point Analysis: Measure functionality from user view (inputs, outputs, inquiries, files, interfaces). Convert to LOC via language factor.

5.2 Project Scheduling & Tracking

• Key Steps:

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

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

  3. Estimation: Duration, effort for each task.

  4. Scheduling: Gantt charts, PERT/CPM for critical path.

  5. Resource Allocation: Assign people to tasks.

• Tracking Mechanisms:

  • Milestones: Key events/deliverables.

  • Status Meetings: Regular progress reviews.

  • Earned Value Management (EVM): Integrates scope, schedule, cost.

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

    • SV = EV - PV, CV = EV - AC, SPI = EV/PV, CPI = EV/AC.

• Importance: Early problem detection, informed decision-making, stakeholder communication, project control.

5.3 Risk Management

• Risk Assessment & Mitigation Process:

  1. Identification: Brainstorming, checklists, Delphi technique.

  2. Analysis (Qualitative): Probability (1-5), Impact (1-5), Risk Exposure RE = Probability * Impact. Prioritize.

  3. Analysis (Quantitative): Expected Monetary Value (EMV), Monte Carlo simulation.

  4. Mitigation Planning: Strategies: Avoid, Transfer, Mitigate, Accept.

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

• Risk Information Sheet (RIS) Format:

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

5.4 Software Configuration Management (SCM)

• Role: Manage changes to software artifacts (code, docs, models) throughout lifecycle. Ensures integrity and traceability.

• SCM Functions:

  1. Version Control: Track different versions (Git, SVN).

  2. Change Control: Process for requesting, evaluating, approving/rejecting changes (Change Control Board - CCB).

  3. Configuration Status Accounting: Record and report status of changes.

  4. Configuration Audits: Verify that configuration items conform to specifications.

• Version Control (Git Example):

  • Repository: Central storage (GitHub, GitLab).

  • Commit: Snapshot of changes with message.

  • Branch: Independent line of development (main, feature-x).

  • Merge: Integrate changes from one branch to another.

  • Workflow: git clone → git checkout -b feature → git add/commit → git push → git merge main.

5.5 Maintenance & Re-engineering

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

• Types of Maintenance:

  • Corrective: Fix defects.

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

  • Perfective: Enhance performance, features.

  • Preventive: Prevent future problems (refactoring).

• Reverse Engineering vs. Re-engineering:

  | Aspect | Reverse Engineering | Re-engineering | |---------------------|----------------------------------------------------------|-----------------------------------------------------------| | Goal | Understand existing system (recover design, specs). | Restructure/rewrite existing system to improve it. | | Output | Models, documentation, design. | New, improved system (possibly new platform). | | Activities | Analysis, extraction, abstraction. | Reverse engineering + restructuring + forward engineering. |

• Re-engineering Process: Inventory analysis → Documentation reconstruction → Restructuring → Forward engineering.

• Program Comprehension Techniques: Static analysis (code reading, tools), Dynamic analysis (debugging, profiling), Interactive analysis (questioning original developers).

[!TIP] EVM Formulas are Crucial: CV > 0 (under budget), SV > 0 (ahead of schedule), CPI < 1 (over budget), SPI < 1 (behind schedule).