Software Engineering Study Notes

Software Engineering is the systematic application of engineering principles to the design, development, testing, and maintenance of software.

Software Crisis refers to the situation where the rate of development of software cannot keep pace with the demand, resulting in over-budget, late, low-quality, or unreliable software.

(a) Complexity: Large number of interacting components.
(b) Intangibility: Cannot be seen or touched.
(c) Evolvability: Software can be updated and modified.
(d) No wear-out: Software does not degrade with time like hardware.

A Software Process is a framework for the activities, actions, and tasks that must be performed to transform the user's requirements into software.

Umbrella Activities are activities that span the entire software process. Examples: SCM, project tracking, risk management, quality assurance, reviews, measurement.

CMMI (Capability Maturity Model Integration) is a process improvement model. 5 levels: (1) Initial, (2) Managed, (3) Defined, (4) Quantitatively Managed, (5) Optimizing.

Process Maturity indicates the extent to which a software process is defined, managed, measured, controlled, and effective. Higher maturity leads to higher software quality.

Waterfall, Incremental, Spiral, V-Model, RAD, Agile (Scrum, Kanban, XP).

DevOps is a set of practices combining Software Development (Dev) and IT Operations (Ops) to shorten the development lifecycle and provide continuous delivery with high software quality.

Verification: "Are we building the product right?" — checks conformance to requirements.
Validation: "Are we building the right product?" — checks the product meets user needs.

Software has unique characteristics that differentiate it from hardware:
(a) Complexity: Large programs may have millions of lines of code with intricate interdependencies.
(b) Intangibility: Cannot be physically touched; exists as logical entities.
(c) Conformance: Must conform precisely to user requirements — even small errors can cause major failures.
(d) No physical wear-out: Does not degrade with use; defects are caused by design errors, not aging.
(e) Ease of change: Can be easily modified to adapt to new requirements or environments.
(f) Reusability: Components can be reused across different systems.
(g) Continuous development: Software evolves throughout its lifetime.

A Software Process Framework defines the set of activities that must occur to produce high-quality software. It includes:
(a) Communication: Understanding requirements from stakeholders.
(b) Planning: Estimating cost, schedule, and resources.
(c) Modeling: Creating representations of the system (requirements, design models).
(d) Construction: Coding, testing, and integration.
(e) Deployment: Delivering the software to users.

Umbrella Activities support the framework throughout the process:
(a) Software Configuration Management (SCM)
(b) Project Tracking & Management
(c) Risk Management
(d) Formal Technical Reviews
(e) Software Quality Assurance
(f) Measurement

CMMI is a process improvement framework with 5 maturity levels:

Level 1 — Initial: Process is unpredictable, poorly controlled, reactive. Success depends on individual effort.

Level 2 — Managed: Projects are planned, performed, measured, and controlled. Requirements are managed, and processes are institutionalized.

Level 3 — Defined: Processes are well-characterized and understood, described in standards and procedures. Organization has a set of standard processes.

Level 4 — Quantitatively Managed: The organization and projects establish quantitative objectives for quality and process performance. Processes are measured and controlled using statistical techniques.

Level 5 — Optimizing: Continuous process improvement is enabled by quantitative feedback and from piloting innovative ideas and technologies.

The Spiral Model, proposed by Barry Boehm, is a risk-driven process model. Each loop (spiral) represents a phase of the software process:

(1) Determine Objectives: Identify objectives and alternatives for the current phase.
(2) Identify & Resolve Risks: Identify risks and strategies to resolve them.
(3) Develop & Test: Develop and test the deliverables (prototype, design, code).
(4) Review & Plan: Review results with customer, plan next phase.

Advantages: Risk handling, flexibility, suitability for large projects.
Disadvantages: Complex, requires risk expertise, can be expensive.

Agile emphasizes iterative development, customer collaboration, and responsiveness to change.

Scrum: Work is divided into 2-4 week Sprints. Roles: Product Owner, Scrum Master, Development Team. Ceremonies: Sprint Planning, Daily Stand-up, Sprint Review, Retrospective.

Kanban: Visual workflow management using a Kanban board with columns (To Do, In Progress, Done). Focus on continuous delivery without fixed iterations. Limits Work In Progress (WIP).

XP (Extreme Programming): Engineering-focused agile. Practices include: Test-Driven Development (TDD), Pair Programming, Continuous Integration, Refactoring, Simple Design, On-site Customer, Small Releases.

DevOps bridges development and operations through automation and collaboration. Key practices:
(a) CI/CD: Continuous Integration and Continuous Deployment pipelines.
(b) Infrastructure as Code (IaC): Managing infrastructure through code (Terraform, Ansible).
(c) Monitoring & Logging: Real-time monitoring (Prometheus, ELK stack).
(d) Microservices: Decentralized architecture enabling independent deployments.
(e) Containerization: Using Docker and Kubernetes for consistent environments.

The V-Model (Verification & Validation model) is an extension of the Waterfall model where each development phase has a corresponding testing phase:

Left side (Development): Requirements → System Design → Architecture Design → Module Design
Right side (Testing): Acceptance Testing → System Testing → Integration Testing → Unit Testing

For each level: Unit Test ↔ Module Design, Integration Test ↔ Architecture Design, System Test ↔ System Design, Acceptance Test ↔ Requirements.

Advantages: Early test planning, high success rate, clear deliverables.
Disadvantages: Still rigid, no early prototype, not suitable for changing requirements.

Waterfall Model: A sequential model with phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Each phase must be completed before the next begins. Best for projects with well-understood, stable requirements.

Incremental Model: Software is designed, implemented, and tested incrementally. The product is delivered in increments, each adding functionality. Reduces early project risk and allows partial utilization.

Spiral Model: Risk-driven iterative model. Each loop goes through: Objective setting → Risk analysis → Development & testing → Planning next loop. Best for large, complex, high-risk projects.

Comparison:

Feature	Waterfall	Incremental	Spiral
Approach	Sequential	Incremental	Iterative + Risk-driven
Flexibility	Low	Medium	High
Risk Management	Late	Partial	Continuous
Customer Feedback	End only	After each increment	Each iteration
Cost	Lower initially	Distributed	Higher (risk analysis)
Best For	Stable requirements	Evolving requirements	High-risk projects

Agile Manifesto principles: Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan.

Scrum Framework:
• Roles: Product Owner (defines backlog), Scrum Master (facilitates), Team (developers).
• Sprint: 2-4 week time-boxed iteration.
• Ceremonies: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
• Artifacts: Product Backlog, Sprint Backlog, Increment.

Extreme Programming (XP):
Values: Communication, Simplicity, Feedback, Courage, Respect.
Practices: TDD, Pair Programming, Continuous Integration, Refactoring, Small Releases, On-site Customer, Collective Ownership.

Kanban:
Visualize workflow, limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively. Uses Kanban board with columns.

DevOps:
A cultural and technical movement that unifies software development (Dev) and software operation (Ops). Key aspects: CI/CD pipelines, Infrastructure as Code, Automated testing, Monitoring, Cloud-native deployment, Microservices architecture.

Software Process Framework has five generic activities:
(1) Communication: Requirements gathering and stakeholder communication.
(2) Planning: Estimation, scheduling, risk management.
(3) Modeling: Requirements and design modeling.
(4) Construction: Coding, testing, integration.
(5) Deployment: Delivery and feedback.

Umbrella Activities:
(1) Software Configuration Management (SCM): Manages changes, versions, baselines.
(2) Project Tracking & Management: Monitors progress against plan.
(3) Risk Management: Identifies, analyzes, mitigates risks.
(4) Formal Technical Reviews: Peer reviews of work products.
(5) Software Quality Assurance (SQA): Audits and ensures quality standards.
(6) Measurement: Collects metrics for process improvement.
(7) Reuse: Identifies reusable components.
(8) Tool Support: Uses CASE tools for automation.

CMMI 5 Levels: (1) Initial (unpredictable) → (2) Managed (planned) → (3) Defined (standardized) → (4) Quantitatively Managed (measured) → (5) Optimizing (continuously improving).

A condition or capability that must be met by a system to satisfy a contract, standard, or specification.

Functional: Describe what the system should do (e.g., login, search, calculate).
Non-functional: Describe how the system should be (e.g., performance, security, reliability).

Software Requirements Specification — a comprehensive description of the software system to be developed, serving as a contract between customer and developer.

The process of gathering requirements from stakeholders through techniques like interviews, surveys, observation, prototyping, and workshops.

A document that traces requirements from their origin through design, coding, and testing, ensuring each requirement is addressed.

A description of a system's behavior as it responds to a request from an external entity (actor), showing the interaction between actor and system to achieve a goal.

An actor is an external entity (human user, hardware, or another system) that interacts with the system.

Interviews, Questionnaires, Observation (Job Shadowing), Prototyping, Workshops (JAD), Brainstorming.

The process of checking that the specified requirements are correct, complete, consistent, and feasible.

The process of managing changing requirements throughout the project lifecycle — tracking, controlling, and communicating changes.

(1) Elicitation: Gathering requirements from stakeholders through interviews, surveys, observation, prototyping, and workshops.
(2) Analysis: Refining, resolving conflicts, prioritizing, and modeling requirements. Checks for consistency, completeness, and correctness.
(3) Specification: Documenting requirements in the SRS document. Can be formal or informal.
(4) Validation: Ensuring the requirements are valid, complete, consistent, and testable. Uses reviews, prototyping, and test case generation.
(5) Management: Tracking and controlling changes to requirements throughout the project. Uses RTM and change control processes.

Functional Requirements: Define what the system should do. Examples: "The system shall allow users to log in with username and password", "The system shall calculate total bill", "The system shall send confirmation email".

Non-functional Requirements: Define how the system should behave. Examples:
• Performance: Response time < 2 seconds
• Security: Passwords must be encrypted
• Reliability: 99.9% uptime
• Usability: System shall be learnable in 2 hours
• Portability: System shall run on Windows and Linux

(1) Interviews: One-on-one or group discussions with stakeholders. Advantage: detailed information. Disadvantage: time-consuming.
(2) Questionnaires/Surveys: Structured questions sent to many stakeholders. Advantage: wide coverage. Disadvantage: limited depth.
(3) Observation (Job Shadowing): Watching users perform their tasks. Advantage: reveals unstated needs. Disadvantage: may affect behavior.
(4) Prototyping: Building a working model to clarify requirements. Advantage: users see concrete output. Disadvantage: may create unrealistic expectations.
(5) Workshops (JAD): Structured group meetings with all stakeholders. Advantage: rapid consensus. Disadvantage: requires skilled facilitator.

(1) Introduction: Purpose, scope, definitions, references, overview.
(2) Overall Description: Product perspective, functions, user characteristics, constraints, assumptions.
(3) Specific Requirements: Functional requirements, interface requirements (user, hardware, software, communication), performance requirements, design constraints, software system attributes.
(4) Appendix: Analysis models, issue lists, requirements cross-reference.

A good SRS is Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable, Traceable.

A Use Case Diagram shows the interaction between actors and use cases (functionalities).

Elements:
• Actor: External entity (stick figure icon).
• Use Case: Oval shape representing a function.
• System Boundary: Rectangle enclosing use cases.
• Associations: Lines connecting actors to use cases.
• Include/Extend: Relationships between use cases.

Example (Online Library):
Actors: Student, Librarian
Use Cases: Search Books, Borrow Books, Return Books, Add Books (Librarian only), View History

RTM is a document that ensures every requirement is traced through design, coding, and testing. Types:
(1) Forward Traceability: Requirements → Design → Code → Test Cases.
(2) Backward Traceability: Code → Design → Requirements.
(3) Bidirectional: Both directions.

RTM columns typically include: Req ID, Req Description, Design Element, Code Module, Test Case ID, Test Status. RTM helps identify missing test cases, measure project progress, and ensure compliance.

Requirements Engineering Process (5 phases):

(1) Elicitation: Collecting requirements from stakeholders using interviews, questionnaires, observation, prototyping, workshops, and brainstorming. Focus on understanding the problem domain and stakeholder needs.

(2) Analysis: Classifying requirements, resolving conflicts, prioritizing (MoSCoW method: Must, Should, Could, Won't), and modeling. Produces use case models, data flow diagrams.

(3) Specification: Writing the formal SRS document. SRS must be: Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable, Traceable.

(4) Validation: Reviewing SRS for correctness through reviews, prototyping, and test case derivation. Ensures the SRS is what the customer wants.

(5) Management: Managing requirement changes using RTM, change control boards, and version control.

SRS Structure (IEEE 830-1998):
(1) Introduction: Purpose, Scope, Definitions, References, Overview
(2) Overall Description: Product Perspective, Functions, User Characteristics, Constraints, Assumptions
(3) Specific Requirements: Functional, Interface, Performance, Design Constraints, Attributes
(4) Appendices: Analysis models, Issue list

Use Case Diagram: A behavioral diagram that describes the functional requirements of the system from the user's perspective.

Components:
• Actors: People, hardware, or other systems that interact with the system.
• Use Cases: Specific functionality the system provides.
• System Boundary: Rectangle separating the system from external actors.
• Relationships: Association, Include, Extend, Generalization.

Example — ATM System:
Actors: Customer, Bank
Use Cases: Authenticate User, Withdraw Cash, Deposit Cash, Check Balance, Change PIN, Print Receipt

RTM (Requirement Traceability Matrix):
A matrix that maps each requirement to its corresponding design, code, and test elements.

Req ID	Requirement	Design Element	Code Module	Test Case	Status
REQ-01	User login	Login screen	auth.js	TC-01	Pass
REQ-02	Password reset	Reset form	reset.js	TC-02	Pass
REQ-03	Profile update	Profile page	profile.js	TC-03	Pending

The process of defining the architecture, components, interfaces, and other characteristics of a system to satisfy specified requirements.

Abstraction is the process of focusing on essential features while hiding unnecessary details. It provides a simplified view of a complex system.

Refinement is the process of elaborating a high-level abstraction step by step to reveal more detail. Top-down design approach.

Dividing a software system into separate, independent modules, each performing a specific function.

Cohesion is the degree to which the elements of a module belong together. High cohesion is desirable.

Coupling is the degree of interdependence between modules. Low coupling is desirable.

Coincidental, Logical, Temporal, Procedural, Communicational, Sequential, Functional (highest).

Data, Stamp, Control, External, Common, Content (highest/tightest).

A reusable solution to a commonly occurring problem in software design. Describes the problem, solution, when to apply, and trade-offs.

Client-Server, 3-Tier, n-Tier, Pipe and Filter, Repository, Layered.

Abstraction: Focusing on essential features and hiding unnecessary details. At different levels: data abstraction (data types), procedural abstraction (operations), control abstraction (control flow).

Refinement: A top-down approach where a high-level abstraction is progressively elaborated into more detailed specifications. Each refinement step adds detail while preserving the overall structure.

Modularity: The software is decomposed into manageable modules, each with a single responsibility. Benefits: easier development, testing, maintenance, and understanding.

Cohesion (intramodule): How closely related the elements within a module are.

Type	Description	Example
Functional	All elements contribute to one task	CalculateSalary module
Sequential	Output of one feeds input of next	ReadFile → ProcessData
Communicational	Elements operate on same data	ReadEmployee, UpdateEmployee
Procedural	Elements called in sequence	Initialize → Process → Cleanup
Temporal	Elements activated at same time	openFile, closeFile, errorHandler
Logical	Related logically but not functionally	All input functions grouped
Coincidental	No meaningful relationship	Unrelated functions in one module

Coupling (intermodule): Degree of interdependence between modules.

Type	Description	Example
Data	Modules share data via parameters	Passing a data structure
Stamp	Share data structure (only parts used)	Passing a record, using only some fields
Control	One module controls flow of another	Passing a control flag
External	Share external data format/device	Shared global variable
Common	Share global data area	Global variables
Content	One module modifies internal data of another	Branching into another module

Client-Server: Two components — Client (requests service) and Server (provides service). Server manages shared resources. Example: Web browser (client) + Web server.

3-Tier Architecture: Three layers:
(1) Presentation Layer: UI, user interaction.
(2) Business Logic Layer: Application logic, validation.
(3) Data Layer: Database management.

Advantages: Scalability, maintainability, security, reusability.

n-Tier Architecture: Extension of 3-tier with more layers. Distributes processing across multiple tiers for scalability and maintainability. Used in enterprise applications.

Singleton Pattern: Ensures a class has only ONE instance and provides a global point of access to it. Use: Database connections, Logging, Configuration management.

Implementation: Private constructor, static instance variable, public getInstance() method.

Factory Pattern: Creates objects without specifying the exact class. A factory method returns an object of one of several possible classes based on input parameters. Use: When the exact type of object to create is determined at runtime. Promotes loose coupling between creator and products.

Observer Pattern: Defines a one-to-many dependency. When the subject changes state, all its observers are notified and updated automatically. Use: Event handling systems, MVC pattern, publish-subscribe systems.

Strategy Pattern: Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from the clients that use it. Use: Different sorting algorithms, payment methods, compression algorithms.

(1) User Documentation: Manuals, help guides for end users (installation, usage, troubleshooting).
(2) System Documentation: Technical documents for developers/maintainers (architecture, design, code, algorithms, data structures).
(3) Technical Documentation: API documentation, database schema, system requirements, network diagrams.
(4) Marketing Documentation: Product descriptions, market analysis, product positioning.

Software Design is the process of defining the architecture, components, interfaces, and data for a system to satisfy specified requirements. It bridges the gap between requirements and implementation.

Design Process: Architectural design → Database design → Interface design → Component-level design.

Cohesion (within modules) — types from lowest to highest:
1. Coincidental (no relation) → 2. Logical → 3. Temporal → 4. Procedural → 5. Communicational → 6. Sequential → 7. Functional (all elements contribute to single well-defined task).

Coupling (between modules) — types from lowest to highest:
1. Data (independent, share data) → 2. Stamp → 3. Control → 4. External → 5. Common → 6. Content (one module directly references content of another).

Design Principle: Aim for high cohesion and low coupling.

Factory Pattern:
Problem: Need to create objects but want to decouple creation from usage.
Solution: A Factory class has a method that creates and returns objects based on input.
Example: A NotificationFactory that creates Email, SMS, or Push notification objects based on user preference.

Singleton Pattern:
Problem: Need exactly one instance of a class.
Solution: Restrict instantiation, provide global access point.
Example: Database connection pool — only one pool needed, shared by entire application.

Observer Pattern:
Problem: Need to notify multiple objects when one object changes.
Solution: Subject maintains list of observers; notifies on state change.
Example: YouTube channel (subject) + Subscribers (observers). When a video is uploaded, all subscribers are notified.

Strategy Pattern:
Problem: Need to select an algorithm at runtime.
Solution: Define interface, implement algorithms as separate classes, choose at runtime.
Example: E-commerce payment — CreditCard, PayPal, UPI strategies. Customer selects payment method at checkout.

The process of executing a program with the intent of finding errors.

(1) Find defects. (2) Establish confidence in software quality. (3) Prevent defects.

(1) All tests should be traceable to customer requirements. (2) Testing should begin "in small" and progress toward testing "in large". (3) Exhaustive testing is not possible.

Unit Testing, Integration Testing, System Testing, Acceptance Testing.

Testing of individual software components or modules in isolation. Usually done by the developer.

Testing the interfaces between integrated components/modules. Approaches: Top-down, Bottom-up, Big-bang.

Testing the complete, integrated system to verify it meets specified requirements. Performed by an independent testing team.

Formal testing conducted to determine whether the system satisfies acceptance criteria, enabling the user to determine whether to accept the system. Types: Alpha, Beta.

White Box: Tests internal structure/code. Tester knows the code. (Glass box testing).
Black Box: Tests functionality without knowing internal code. Tests inputs and outputs. (Functional testing).

Re-running previously completed tests after changes to ensure that modifications have not introduced new defects in existing functionality.

A software metric measuring the number of linearly independent paths through a program's source code. V(G) = E − N + 2P, where E = edges, N = nodes, P = connected components.

A testing technique where small changes (mutations) are introduced into the program code to check if the test suite can detect them. If a test fails on a mutant, the mutant is "killed".

Testing Objectives:
(1) Finding defects: Primary objective — discover errors, bugs, and flaws.
(2) Establishing confidence: Show that software meets requirements and is reliable.
(3) Preventing defects: Early testing reveals design issues before they become expensive.
(4) Providing information: Status reports, quality metrics.

Testing Principles:
(1) All tests should be traceable to customer requirements.
(2) Tests should be planned before testing begins.
(3) The Pareto principle applies — 80% of errors come from 20% of modules.
(4) Start testing "in small" and progress toward "in large".
(5) Exhaustive testing is impossible — use intelligent testing.
(6) Testing should be conducted by an independent third party for effectiveness.

(1) Unit Testing: Tests individual modules/functions in isolation. Developer uses white box techniques. Tools: JUnit, pytest.
(2) Integration Testing: Tests interfaces between modules. Approaches: Big Bang, Top-down (stubs), Bottom-up (drivers), Sandwich (combination).
(3) System Testing: Tests the complete system against requirements. Includes functional, performance, security, usability testing.
(4) Acceptance Testing: Final testing to confirm system is ready for deployment.
    • Alpha Testing: Done at developer's site by internal users.
    • Beta Testing: Done at customer's site by external users.

Boundary Value Analysis is a black box test design technique that focuses on testing at the boundaries of input domains rather than the center. Errors tend to occur at boundaries.

If valid range is [1, 100], test values: 1, 2 (min boundary), 50 (nominal), 99, 100 (max boundary), 0 and 101 (out of range).

Steps: (1) Identify input boundaries from specification. (2) Create test cases for each boundary (just below, on, just above). (3) Apply to output boundaries too.

Equivalence Class Partitioning (ECP) divides input domain into equivalence classes (valid and invalid). One test from each class is sufficient.

Example: Field accepts age 18–60.
Valid class: 18–60 → test with 30
Invalid class 1: < 18 → test with 15
Invalid class 2: > 60 → test with 65

Steps: (1) Identify input conditions. (2) Partition into valid/invalid equivalence classes. (3) Select one representative from each class.

Decision Table Testing is used when combinations of input conditions produce different actions. It lists conditions, rules, and actions in a tabular format.

Example — Login System:
Conditions: C1 = Valid Username, C2 = Valid Password
Actions: A1 = Show Home, A2 = Show Error, A3 = Lock Account

Rules	R1	R2	R3	R4
C1 (Valid User)	T	T	F	F
C2 (Valid Pass)	T	F	T	F
A1 (Home)	X
A2 (Error)		X	X
A3 (Lock)				X

State Transition Testing tests the different states of a system and the transitions between them based on events/conditions.

Example — ATM PIN Verification:
States: Idle → Entering PIN → Authenticated → Blocked
Transitions:
• Entering PIN + Correct → Authenticated
• Entering PIN + Wrong → Idle (retry count −)
• 3 Wrong attempts → Blocked
• Blocked + Admin Reset → Idle

Test cases: Correct PIN on 1st try, Wrong PIN then Correct, 3 consecutive wrong PINs, etc.

White Box Testing (Structural/Glass Box):
Tests the internal structure and code. Requires knowledge of the code. Techniques:
• Statement Coverage: Every statement executed at least once.
• Branch Coverage: Every branch (if/else) taken both ways.
• Path Coverage: Every possible path through the code tested.
• Condition Coverage: Every boolean condition tested for true and false.

Black Box Testing (Functional/Specification-based):
Tests functionality without knowledge of internal code. Based on requirements/specifications. Techniques:

1. Boundary Value Analysis (BVA): Tests at boundary values. If range is [a, b], test: a, a+1, b-1, b, a-1, b+1.

2. Equivalence Partitioning (ECP): Divide input into valid/invalid classes. One test from each class.

3. Decision Table Testing: Table format for combinations of conditions → actions. Useful for business rules with many condition combinations.

4. State Transition Testing: Tests state changes triggered by events. Useful for systems with well-defined states (ATM, vending machine).

Aspect	White Box	Black Box
Focus	Internal code structure	External functionality
Knowledge	Requires code knowledge	No code knowledge needed
Tester perspective	Developer / Tester	End user / Tester
Techniques	Path, branch, statement coverage	BVA, ECP, Decision table, STT
When performed	Unit, Integration level	System, Acceptance level
Testing basis	Program logic, code	Requirements specification

McCabe's Cyclomatic Complexity V(G):
Measures the number of linearly independent paths through a program. Used to determine the minimum number of test cases needed for complete branch coverage.

Formula: V(G) = E − N + 2P
where E = number of edges, N = number of nodes, P = number of connected components.

Alternative formulas:
V(G) = Number of regions (closed areas) in the flow graph
V(G) = Number of predicate nodes + 1

Example — Flow Graph:
Consider a program with:
Nodes N = 5 (Start, Condition1, Condition2, Action1, End)
Edges E = 6
Components P = 1

V(G) = E − N + 2P = 6 − 5 + 2(1) = 3

Meaning: The program has 3 independent paths. We need at least 3 test cases for complete path coverage.

Significance: V(G) > 10 indicates high complexity and risk. Good modules have V(G) between 3–10.

Example Code:

int max(int a, int b) {
    if (a > b) {
        return a;
    } else {
        return b;
    }
}

Flow Graph:
Nodes (N): Start, Condition, Return a, Return b, End = 5 nodes
Edges (E): Start→Condition, Condition→Return a, Condition→Return b, Return a→End, Return b→End = 5 edges
P = 1

V(G) = E − N + 2P = 5 − 5 + 2(1) = 2

Test Cases (Path Coverage):
Path 1: Start → Condition(a>b=T) → Return a → End [test: a=5, b=3]
Path 2: Start → Condition(a>b=F) → Return b → End [test: a=2, b=4]

Also: Mutation testing creates mutants (e.g., change > to <, change a to b). Good test suite kills all mutants. Regression testing ensures new code doesn't break existing tests.

The degree to which software meets its specified requirements and satisfies user needs.

Product Operation, Product Revision, Product Transition.

Software Quality Assurance — a planned and systematic set of actions to ensure a software process or product conforms to its established technical requirements.

The probability of failure-free operation of software for a specified time in a specified environment.

Mean Time Between Failures = 1 / λ, where λ is the failure rate.

Corrective, Adaptive, Perfective, Preventive.

Analyzing an existing system to identify its components and interrelationships and create representations at a higher level of abstraction.

Computer-Aided Software Engineering — tools that automate software development activities.

The discipline of identifying, controlling, and managing changes to software artifacts throughout the lifecycle.

Constructive Cost Model — a method for estimating effort (person-months) and development time based on software size in KLOC.

McCall's model defines quality through three perspectives:

Category	Quality Factors	Metrics
Product Operation (How well it works)	Correctness, Reliability, Efficiency, Integrity, Usability	MTBF, Response time, Storage, Security violations
Product Revision (How well it changes)	Maintainability, Flexibility, Testability	Time to fix, Modules affected, Test coverage
Product Transition (How well it adapts)	Portability, Reusability, Interoperability	Platforms supported, Code reuse ratio, Interface compatibility

SQA: A planned set of actions ensuring software processes and products conform to requirements. Activities: SQA plan, quality audits, work product reviews, deviation correction, management reporting.

FTR (Formal Technical Reviews): Peer review where engineers examine work products to uncover errors. Types: Walkthroughs, Inspections, Code Reviews, Technical Reviews. Benefits: Improved quality, reduced testing cost, better team communication.

Software Reliability = probability of failure-free operation for a specified time in a specified environment.

Formulas:
R(t) = e^−λt
MTBF = 1 / λ
where λ = failure rate (failures per unit time)

Improving reliability: Fault tolerance, defensive programming, thorough testing, code reviews, automated regression testing.

Type	Purpose	Example
Corrective	Fix bugs after delivery	Patching a login vulnerability
Adaptive	Adapt to environment changes	Updating app for new OS
Perfective	Add features / improve performance	Adding dark mode, optimizing queries
Preventive	Prevent future problems	Refactoring code, updating docs

Maintenance accounts for 40–80% of total software cost.

CASE (Computer-Aided Software Engineering): Tools that automate SDLC activities.

(1) Upper-CASE: Analysis & design support (requirements tools, diagramming, prototyping).
(2) Lower-CASE: Coding, testing, maintenance support (debuggers, test generators).
(3) Integrated-CASE: Combine both, maintaining consistency across phases (e.g., IBM Rational Rose).

Benefits: Improved quality, reduced development time, better documentation, standardization.

SCM manages changes to software artifacts throughout the lifecycle. Key activities:
(1) Configuration Identification: Naming and numbering items (baselines, versions).
(2) Version Control: Tracking changes (Git, SVN).
(3) Change Control: Evaluating, approving, tracking changes.
(4) Configuration Auditing: Verifying conformity to requirements.
(5) Status Accounting: Recording and reporting change status.

COCOMO (Constructive Cost Model) estimates effort (person-months) and schedule based on software size (KLOC).

Basic COCOMO:
Effort (PM) = a × (KLOC)^b
Tdev (months) = c × (Effort)^d

Mode	a	b	c	d	Typical Project
Organic	2.4	1.05	2.5	0.38	Small, familiar (20 KLOC)
Semi-detached	3.0	1.12	2.5	0.35	Medium, mixed (50 KLOC)
Embedded	3.6	1.20	2.5	0.32	Large, complex (300 KLOC)

Numerical Example — Organic Mode:
Project size: 50 KLOC, Organic mode

Step 1 — Effort:
Effort = 2.4 × (50)^1.05
= 2.4 × 54.8 ≈ 131.5 PM

Step 2 — Development Time:
Tdev = 2.5 × (131.5)^0.38 ≈ 2.5 × 7.9 ≈ 19.75 months

Step 3 — Average Staff:
Staff = 131.5 / 19.75 ≈ 7 persons

Intermediate (Detailed) COCOMO:
Effort = Basic COCOMO × EAF
EAF = product of 15 cost driver ratings (Required Reliability, DB Size, Complexity, Time Constraint, Memory, VM Volatility, etc.)

Cost driver ratings: Very Low (0.75), Low (0.88), Nominal (1.00), High (1.15), Very High (1.40), Extra High (1.60–1.65).

Reverse Engineering: Analyzing existing system to understand its components and interrelationships. Creates representations at higher abstraction. Used to recover lost documentation and understand legacy systems.

Forward Engineering: Traditional approach from high-level abstraction to implementation.

Re-engineering: Combines reverse and forward engineering. System is examined, redesigned, and re-implemented. Activities: inventory analysis, document restructuring, reverse engineering, forward engineering.

Software Migration: Moving from one platform to another (COBOL → Java, on-premises → cloud).

Maintenance types and costs: Corrective (fixing bugs), Adaptive (environment changes), Perfective (new features), Preventive (prevent future issues). Maintenance = 40–80% of total software cost.

CASE tools: Upper-CASE (analysis/design), Lower-CASE (coding/testing), Integrated-CASE (both). Examples: Rational Rose, Enterprise Architect, Eclipse IDE, JIRA.

McCall's Quality Factors (detailed):
(1) Correctness: Does exactly what it is specified to do.
(2) Reliability: Performs as required over time.
(3) Efficiency: Minimal resource usage for functionality.
(4) Integrity: Controls access to data, security.
(5) Usability: Easy to learn and operate.
(6) Maintainability: Easy to identify and fix errors.
(7) Flexibility: Easy to adapt to new requirements.
(8) Testability: Easy to test and validate.
(9) Portability: Easy to transfer to different environments.
(10) Reusability: Modules usable in other systems.
(11) Interoperability: Ability to interface with other systems.

SQA Activities: SQA plan → Quality audits → Work product reviews → Deviation management → Management reporting.

SCM: Configuration Identification → Version Control → Change Control → Auditing → Status Accounting.