Software development life cycle (SDLC) is a structured process that is used to design, develop, and

test good-quality software. SDLC, or software development life cycle, is a methodology that defines
the entire procedure of software development step-by-step. The goal of the SDLC life cycle model is
to deliver high-quality, maintainable software that meets the user's requirements.

Stages of the Software Development Life Cycle

1)Planning and Requirement Analysis

2: Defining Requirements

3: Designing Architecture

4: Developing Product

5: Product Testing and Integration

6: Deployment and Maintenance of Products

Descriptive Breakdown of SDLC Components

The Software Development Life Cycle (SDLC) is a structured approach to developing software,
ensuring quality, efficiency, and alignment with business goals. Below is a detailed description of
each component:

1. Planning & Requirement Analysis

Description:
This is the foundational phase where the project's scope, objectives, and feasibility are determined.
It involves gathering input from stakeholders (clients, users, business analysts) to define what the
software should accomplish.
Key Activities:

• Requirement Gathering: Collecting functional (features) and non-functional (performance,

security) requirements.

• Feasibility Study: Evaluating technical, economic, legal, and operational feasibility.

• Risk Assessment: Identifying potential risks and mitigation strategies.

• Resource Planning: Estimating budget, timeline, and team allocation.

• Documentation: Creating a Software Requirement Specification (SRS) document.

Outcome:
A clear project roadmap with defined goals, constraints, and success criteria.

2. System Design

Description:
In this phase, the system architecture is designed based on the SRS. It defines how the software will
be structured, including data flow, modules, and technologies.

Key Activities:

• High-Level Design (HLD): Overall system architecture, database design, and technology stack
selection.

• Low-Level Design (LLD): Detailed module design, algorithms, and data structures.

• UI/UX Design: Wireframes, prototypes, and user interface mockups.

• Security & Compliance: Defining encryption, authentication, and regulatory requirements.

Outcome:

• Design Document (HLD & LLD)

• Prototypes/Wireframes

3. Implementation (Coding)

Description:
Developers write the actual code based on the design documents. This phase transforms
requirements into a functional product.

Key Activities:

• Coding: Following best practices (clean code, version control).

• Unit Testing: Testing individual components for bugs.

• Code Reviews: Ensuring quality and consistency.

• Integration: Combining different modules.

Outcome:

• Functional software (but not yet fully tested)

• Source code in repositories (Git, SVN, etc.)

4. Testing

Description:
The software is rigorously tested to identify and fix defects before deployment.

Key Activities:

• Functional Testing: Ensures features work as per requirements.

• Performance Testing: Checks speed, scalability, and stability.

• Security Testing: Identifies vulnerabilities (penetration testing).

• User Acceptance Testing (UAT): Final validation by end-users.

• Bug Fixing & Regression Testing: Ensures fixes don’t break existing features.

Outcome:

• Test reports (bug logs, performance metrics)

• Stable, production-ready software

5. Deployment

Description:
The software is released to the production environment for end-users.

Key Activities:

• Release Planning: Phased rollout or full deployment.

• Installation & Configuration: Setting up servers, databases, and networks.

• User Training: Educating users on how to use the software.

• Monitoring: Initial performance tracking post-launch.

Outcome:

• Live software accessible to users

• Deployment logs & post-release reports

6. Maintenance

Description:
After deployment, the software is continuously monitored, updated, and improved.
Key Activities:

• Bug Fixes: Addressing issues reported by users.

• Updates & Patches: Security patches, feature enhancements.

• Performance Optimization: Improving speed and efficiency.

• End-of-Life (EOL) Planning: Deciding when to retire or upgrade the software.

Outcome:

• Improved software stability & performance

• Version updates (e.g., v1.0 → v2.0)

2) Umbrella Activities in Software Engineering (8 Marks)

Definition:

1)Umbrella activities are a series of steps or procedures followed by a software development

team to maintain the progress, quality, changes, and risks of complete development tasks.

2)Umbrella activities are the supporting tasks that are carried out throughout the entire
software development life cycle (SDLC). They ensure quality, efficiency, and manageability of
the project.

Key Umbrella Activities:

Tasks of Umbrella Activities

Umbrella activities consist of different tasks:

• Software Project Tracking and Control

• Formal Technical Reviews

• Software Quality Assurance

• SCM or Software configuration management

• Document Preparation and Production

• Re-usability Management

• Measurement and Metrics

• Risk Management
 Definition:

In software engineering, umbrella activities are the supportive, cross-cutting tasks that span across
all stages of the Software Development Life Cycle (SDLC). These activities ensure that the
development process is managed, controlled, and optimized to deliver a high-quality, cost-
effective, and reliable software product.

Detailed Explanation of Umbrella Activities

1. Software Project Tracking an0d Control

Purpose:
To continuously monitor the progress of the project and ensure that it aligns with the planned
schedule, budget, and resources.

Key Tasks:

• Progress Tracking: Comparing actual progress with the project plan using tools like Gantt
charts or burndown charts.

• Milestone Reviews: Checking project outcomes at major development stages.

• Corrective Actions: Adjusting timelines, team allocations, or budgets in case of deviations.

 • Status Reporting: Regular updates through weekly reports, Agile stand-up meetings, or
stakeholder meetings.

Tools:
Jira, Trello, Microsoft Project, Asana.

2. Formal Technical Reviews (FTR)

Purpose:
To identify and eliminate defects early in the development cycle through structured peer
evaluations.

Key Tasks:

• Inspections: Formal reviews with predefined checklists, mainly for critical documents like
SRS or design specs.

• Walkthroughs: Informal reviews led by the document or code author.

• Peer Reviews: Code reviews, using platforms like GitHub or GitLab.

Focus Areas:

• Accuracy, completeness, maintainability, performance, and compliance with standards.

Outcome:
Review reports, defect logs, and recommended improvements.

3. Software Quality Assurance (SQA)

Purpose:
To ensure that the software and its development process meet predefined quality standards.

Key Tasks:

• Process Audits: Ensuring adherence to development methodologies like Agile, CMMI, or

ISO standards.

• Test Planning and Execution: Managing unit, integration, system, and acceptance testing.

• Metrics Monitoring: Analyzing defect density, code coverage, and other KPIs.

Standards:
ISO 9001, IEEE 730, CMMI Levels.

Tools:
Selenium, SonarQube, TestRail, JUnit.

4. Software Configuration Management (SCM)

Purpose:
To handle the organization and control of software changes across the project lifecycle.
Key Tasks:

• Version Control: Tracking changes to code using tools like Git, SVN.

• Baseline Management: Maintaining stable snapshots of the project for releases.

• Change Control: Handling and documenting change requests.

• Build & Release Management: Automating the deployment process with CI/CD tools.

Tools:
GitHub, GitLab, Jenkins, Docker, Ansible.

5. Document Preparation and Production

Purpose:
To ensure accurate and updated documentation is available for all stakeholders throughout the
project.

Types of Documents:

• Technical Documents: Software Requirement Specification (SRS), High/Low-Level Design

(HLD/LLD), API documentation.

• User Manuals: Installation guides, help documents, FAQs.

• Project Process Documents: Test cases, meeting minutes, audit reports.

Best Practices:

• Collaborative editing (Google Docs, Confluence).

• Version-controlled documentation.

6. Reusability Management

Purpose:
To identify and reuse existing components, designs, or modules to save time, reduce effort, and
ensure reliability.

Key Tasks:

• Code Reuse: Utilizing libraries (React, jQuery), frameworks (Spring Boot), or APIs.

• Design Patterns: Implementing common reusable solutions like Singleton, Factory, and
MVC.

• Component Repositories: Maintaining shared modules and assets.

Benefits:

• Accelerated development

• Reduced bugs
 • Consistency across projects

7. Measurement and Metrics

Purpose:
To quantitatively assess the performance, quality, and efficiency of the software and the
development process.

Types of Metrics:

• Product Metrics:

o Defect Density (defects per KLOC)

o Cyclomatic Complexity (to assess code maintainability)

• Process Metrics:

o Sprint Velocity (in Agile)

o Lead Time and Mean Time to Repair (DevOps)

Tools:
SonarQube, Prometheus, Excel, Tableau (for dashboards).

8. Risk Management

Purpose:
To proactively identify, analyze, and mitigate risks that may affect the success of the project.

Key Steps:

1. Risk Identification: Using brainstorming, historical data, or SWOT analysis.

2. Risk Assessment: Analyzing likelihood vs. impact using a Risk Matrix.

3. Risk Mitigation Strategies:

o Avoidance (change project plan)

o Transfer (use insurance or third-party vendors)

o Acceptance (develop contingency plans)

Tools:
Risk Registers, Monte Carlo Simulation, Risk Matrix templates.

Conclusion:

Umbrella activities are critical to the success of a software project. They provide a support
framework that spans across the SDLC to ensure:

• Consistency and control

 • Defect prevention rather than correction

• High product and process quality

• Proactive risk and change management

These activities are vital for managing complex projects, especially in modern development
environments like Agile, DevOps, and Hybrid models.

Agile Methodologies and Principles

Definition:

Agile methodology is a modern software development approach that emphasizes incremental

delivery, customer collaboration, adaptability to change, and continuous improvement. It is based
on the Agile Manifesto introduced in 2001 by a group of software engineers.

Agile breaks down large projects into smaller, manageable units called iterations or sprints, usually
lasting 1–4 weeks.

Key Characteristics of Agile:

• Iterative and incremental development

• Continuous feedback and improvement

• Cross-functional, self-organizing teams

• Prioritization of working software over documentation

• Quick response to changing requirements

12 Agile Principles (from the Agile Manifesto):

1. Customer satisfaction through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development.

3. Deliver working software frequently, from a few weeks to a few months.

4. Business people and developers must work together daily.

5. Build projects around motivated individuals, trust them to get the job done.

6. Use face-to-face communication as the most efficient method.

7. Working software is the primary measure of progress.

 8. Agile processes promote sustainable development.

9. Continuous attention to technical excellence and good design.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects and tunes its behavior for effectiveness.

Popular Agile Methodologies:

Methodology Key Features

Sprint-based planning, roles (Scrum Master, Product Owner),

Scrum
Daily Stand-ups, Sprint Review & Retrospective

Kanban Visualize workflow with boards, WIP limits, continuous delivery

Extreme Programming (XP) Test-driven development (TDD), pair programming, refactoring

Lean Software Development Eliminate waste, amplify learning, fast delivery

Crystal Lightweight, focuses on team communication and safety

DSDM (Dynamic Systems

Time-boxing, active user involvement
Development Method)

Roles in Agile (Scrum Model Example):

• Product Owner: Defines the product backlog, prioritizes features.

• Scrum Master: Facilitates the process, removes obstacles.

• Development Team: Cross-functional team that builds the product.

Events/Meetings in Scrum:

• Sprint Planning – Decide what will be done in the upcoming sprint

• Daily Stand-up (Scrum) – Short daily progress meetings

• Sprint Review – Review completed work with stakeholders

• Sprint Retrospective – Analyze what went well or needs improvement

Advantages of Agile:

• Faster delivery of working software

 • High customer involvement and satisfaction

• Early detection of defects

• Better adaptability to changing requirements

• Continuous feedback improves product quality

• Promotes team collaboration and transparency

🛠 Popular Agile Tools:

• Jira – Sprint and backlog management

• Trello – Visual Kanban boards

• Asana, ClickUp – Task tracking and collaboration

• VersionOne, Azure DevOps – Enterprise-level Agile project tracking

Conclusion:

Agile is a customer-centric, change-tolerant software development approach. It encourages

frequent delivery, team collaboration, and adaptability, making it ideal for dynamic and fast-
changing projects. Agile principles ensure that software is developed efficiently, collaboratively, and
with continuous feedback, resulting in higher-quality software and improved stakeholder
satisfaction.

Software Development Process Models

Definition:

A Software Development Process Model is a structured framework that describes the sequence of
activities and tasks involved in developing a software product. It provides a systematic way to plan,
develop, test, and deploy software.

Different models suit different project types depending on factors like project size, complexity,
requirements clarity, and timeline.
WATER FALL MODEL:

Definition:

The Waterfall Model is a linear and sequential software development model where each phase
must be completed before moving to the next. It flows downward like a waterfall, hence the name.
It is one of the earliest models used in software development.

It is a Oldest model and is known as linear sequential model or

classic life cycle model;

The waterfall model is a breakdown of project activities into

linear sequential phases, where each phase depends on the

deliverables of the previous one and corresponds to a

specialization of tasks

🪜 Steps in Waterfall Model:

1. Requirement Gathering and Analysis

2. System Design

3. Implementation (Coding)

4. Testing

5. Deployment
 6. Maintenance

Sure! Below is the exact content from the PDF regarding the Waterfall Model, V-Model, Incremental
Model, and Iterative Model (as it appears in your Unit-1 PPT):

Waterfall Model

➢ It is the Oldest model and is known as linear sequential model or classic life cycle model;
➢ The waterfall model is a breakdown of project activities into linear sequential phases, where each
phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.

Phases:

• Communication
✓ All the possible requirements of the system to be developed are captured in this phase.
✓ Communication between customer and developer.

• Planning
✓ It consists of complete estimation, scheduling for project development.

• Modelling
✓ Defines overall system architecture.
✓ Helps in specifying hardware and software.
✓ Architecture creates low level and high level design.

• Construction
✓ Consists of code generation and testing.
✓ Coding implements the design details using an appropriate programming language.
✓ Testing the flow of coding and checking the functionality.
✓ Testing is done by unit testing, integration testing, and system testing.
✓ Unit testing – testing individual component.
✓ Integration testing – individual units are combined and tested.
✓ System testing – testing that validates the complete and fully integrated software product.

• Deployment
✓ Delivering the product to the customer and taking feedback from them.
✓ Software must be maintained.

Advantages:

• Simple and easy to understand and use.

• Easy to manage due to the rigidity of the model.

• Clearly defined stages and milestones.

 • Works well for smaller projects where requirements are well understood.

Disadvantages:

• High amounts of risk and uncertainty.

• Not suitable for long, complex, or object-oriented projects.

• Poor adaptability to changing requirements.

When to Use:

• Requirements are very well documented, clear, and fixed.

• Product definition is stable.

• Technology is well understood.

V-Model

➢ A variation of waterfall model that depicts the relationship of quality assurance actions to the
actions associated with communication, modeling, and early code construction activities.

➢ The V-Model demonstrates the relationships between each phase of the development life cycle
and its associated phase of testing.
➢ It is also known as verification and validation model.

• Verification: Process of evaluating development phases to check if requirements are met.

“Am I building the product right?”

• Validation: Process of testing whether the software meets user expectations.

“Am I building the right product?”

Advantages:

• Simple and easy to use.

• Each phase has clear deliverables and reviews.

Disadvantages:

• High risk and uncertainty.

• Not suitable for complex or long-term projects.

Incremental Model

➢ The incremental model combines elements of linear and parallel process flows.
➢ It combines elements of the Waterfall model, applied in an iterative manner.

➢ The first increment is often a core product with many supplementary features.
➢ Users use and evaluate it, and modifications are made to better meet needs.

Example – Word Processing Software:

 • 1st Increment: Document processing.

• 2nd Increment: File management.

• 3rd Increment: Spell check and grammar.

Advantages:

• Working software is produced early.

• Flexible and less costly to change.

• Easier to test and debug.

• Better risk management.

Disadvantages:

• Not suitable for small projects.

• Needs good planning and design.

• Total cost may be higher than Waterfall.

When to Use:

• Requirements are clear.

• Need to release software early.

• High-risk features exist.

Iterative Model

➢ In iterative method, the concept of incremental development is used frequently, with changes
made during design and implementation of each new iteration.
➢ Begins by specifying and implementing part of the software, which is reviewed to identify further
requirements.
➢ The process is repeated with new versions created in each iteration.

When to Use:

• Requirements are mostly known.

• Project is large.

• Some details can evolve over time.

Advantages:

• Operational product delivered in every iteration.

• Supports changing requirements.

• Easier testing and debugging.

• Identified risks from one iteration can help in the next.

Disadvantages:

• Requires more management attention.

• Architecture issues may arise.

• Not suitable for smaller projects.

Let me know if you want the RAD model, Spiral model, Prototype model, or the Agile
methodologies content as well in the same format.
 UNIT-II
Definition of SRS:

Software Requirements Specification (SRS) is a structured document that describes what the
software will do and how it is expected to perform. It acts as an agreement between the client and
development team and includes functional, non-functional, and interface requirements.

🗂 SRS Document Structure and Definitions:

1. Introduction

Describes the overall purpose and structure of the SRS document. It helps the reader understand
the background, scope, and intent of the software project.

1.1 Purpose

• Describes why the SRS is being written.

• Specifies the intended audience (developers, testers, customers).

1.2 Scope

• Describes what the software will do and what it will not do.

• Includes product benefits, objectives, and goals.

1.3 Definitions, Acronyms, and Abbreviations

• Explains technical terms, abbreviations, and acronyms used in the SRS.

• Example: UI – User Interface, API – Application Programming Interface

1.4 References

• Lists external documents used for reference while preparing the SRS.

• Example: IEEE standards, system manuals.

1.5 Overview

• Briefly explains the contents of the entire SRS document.

• Acts as a roadmap for readers.

2. System Description

Gives a high-level overview of the software system, its environment, and its key users.
2.1 Product Perspective

• Explains how the software fits into a larger system, or whether it is standalone.

• May include system block diagrams.

2.2 Product Functions

• Lists the main functions or features the software will perform.

• Can be shown using data flow diagrams or use case diagrams.

2.3 User Characteristics

• Describes the intended users, their technical skills, and experience.

• Example: Admins, Customers, Technicians.

2.4 System Constraints

• Lists limitations imposed on the system.

• Examples: Programming language used, platform (Windows only), memory usage.

2.5 System Dependencies

• Lists hardware, software, or network requirements needed for the system to function.

• Example: Requires Oracle DB, needs Chrome browser.

2.6 Requirements Sub-Domain

• Breaks down requirements by module or feature group.

• Helps in better classification and tracking.

3. Specific System Requirements

Provides detailed requirements that the system must fulfill.

3.1 Functional Requirements

• Define what the system must do.

• Describe interactions between the system and its environment.

• Types of Functional Requirements:

o User Authentication

o Data Entry and Validation

o Processing Logic

o Report Generation

3.2 Non-Functional Requirements

• Define how the system should behave.

 • Types of Non-Functional Requirements:

o Performance – response time, throughput.

o Security – access control, encryption.

o Usability – user-friendly interfaces.

o Reliability – uptime, fault tolerance.

o Maintainability – ease of updates or bug fixes.

3.3 External Interface Requirements

• Define how the system interacts with hardware, other software, or users.

• Types of External Interfaces:

o User Interfaces – GUI designs, screen layouts.

o Hardware Interfaces – sensors, printers.

o Software Interfaces – APIs, OS interactions.

o Communication Interfaces – protocols, data formats.

3.4 Design Constraints

• Implementation language requirements

• Operating environment specifications

• Database integrity policies

• Resource limitations and standards compliance

Let me know if you'd like a filled example SRS using this structure for a specific project (e.g., Library
System, Online Store, etc.).
Solution:

Here is the COCOMO Theory explained clearly in exam-ready format, suitable for an 8-mark answer:

COCOMO (Constructive Cost Model) – Theory

Definition:

COCOMO is a software cost estimation model developed by Barry W. Boehm in 1981. It helps
estimate the effort, time, and cost required to develop software projects based on the size of the
project (in KLOC).

Types of COCOMO Models:

COCOMO has three levels:

1. Basic COCOMO:
Estimates effort and development time using a simple equation based on the size (KLOC).

2. Intermediate COCOMO:
Considers additional cost drivers like product reliability, database size, developer capability,
etc.

3. Detailed COCOMO:
More accurate; applies cost drivers to each phase of the software lifecycle.

Basic COCOMO Model – Effort Estimation Formula:

For Basic COCOMO, the following formulas are used:

1. Effort (E) = a × (KLOC)^b

2. Development Time (D) = c × (Effort)^d

3. Average Staff Size (N) = Effort / Development Time

4. Productivity (P) = KLOC / Effort

Modes in COCOMO:

COCOMO provides different constant values (a, b, c, d) based on the project mode:

Mode Description a b c d

Organic Small, simple projects with experienced teams 2.4 1.05 2.5 0.38
Mode Description a b c d

Semi-Detached Medium-sized projects with average experience 3.0 1.12 2.5 0.35

Embedded Complex systems with strict hardware/software requirements 3.6 1.20 2.5 0.32

Inputs Required:

• Size of the project in KLOC (Kilo Lines of Code)

• Project mode (Organic, Semi-Detached, Embedded)

Advantages:

• Simple and easy to understand

• Provides quick estimates

• Useful for project planning and budgeting

Limitations:

• Assumes all code is written manually (no reuse or automation)

• Accuracy decreases for new technologies

• Based only on KLOC, which is hard to estimate early in the project

Given:
• Project Size = 200 KLOC
• Mode = Semi-Detached (Average experience, schedule not
tight)
• Constants for Semi-Detached mode:
o a = 3.0, b = 1.12, c = 2.5, d = 0.35

Formulas Used (COCOMO Basic Model):

1. Effort (E) = a × (KLOC)^b
2. Development Time (D) = c × (E)^d
 3. Average Staff Size (N) = E / D
4. Productivity (P) = KLOC / E

1. Effort Calculation
E = a × (KLOC)^b = 3.0 × (200)^1.12 = 3.0 × 427.04 = 1281.12 person-
months

2. Development Time Calculation

D = c × (E)^d = 2.5 × (1281.12)^0.35 = 2.5 × 11.06 = 27.65 months

3. Average Staff Size

N = E / D = 1281.12 / 27.65 = 46.34 persons

4. Productivity
P = KLOC / E = 200 / 1281.12 = 0.156 KLOC/person-month

Final Answer:

Parameter Result

Effort (E) 1281.12 person-months

Development Time (D) 27.65 months

Average Staff Size (N) 46.34 persons

Parameter Result

Productivity (P) 0.156 KLOC/person-month

 UNIT-IV

Definition: Cohesion

Cohesion refers to how closely related the tasks performed by a single module are.
High Cohesion means a module does one specific task well.
Low Cohesion means the module performs unrelated tasks.

Types of Cohesion with Definitions:

1. Functional Cohesion

All parts of the module work to achieve one single function.

Best type of cohesion
Example: A method that computes the area of a circle.

2. Sequential Cohesion

The output of one task is used as input for the next task in the module.
Example: A module that reads data → processes it → stores it.

3. Communicational Cohesion

Tasks operate on the same data but perform different functions.

Example: A module that reads a file and prints its content.

4. Procedural Cohesion

Tasks are executed in a specific order (sequence of steps).

Example: A module that opens a file, reads it, and then closes it.

5. Temporal Cohesion

Tasks grouped because they are executed at the same time (e.g., at system startup).
Example: Initialization module that loads settings and starts logging.

6. Logical Cohesion

Multiple similar functions in one module, selected by a control variable.

Example: A function that prints, saves, or deletes data based on user choice.
7. Coincidental Cohesion

Tasks are grouped randomly with no logical relationship.

Worst type of cohesion
Example: A module with unrelated tasks like sending mail, calculating age, and resizing image.

Definition: Coupling

Coupling is the degree of interdependence between modules.

Low Coupling means modules are independent.
High Coupling means modules are tightly connected (hard to maintain).

Types of Coupling with Definitions:

1. Content Coupling

One module directly modifies or relies on the internal content of another.

Worst type of coupling
Example: Module A changes a variable inside Module B directly.

2. Common Coupling

Multiple modules share global data.

Example: Modules accessing the same global variable.

3. External Coupling

Modules share information through an external device or interface.

Example: Two modules using the same printer interface.

4. Control Coupling

One module controls the logic of another by passing control flags.

Example: Module A sends a flag to Module B to select which operation to perform.

5. Stamp Coupling

Modules share a composite data structure (like a record or object), but use only parts of it.
Example: Passing a full student object, but only accessing the name.
 6. Data Coupling

Modules share only necessary data, nothing extra.

Best type of coupling
Example: Module A sends only ID and name to Module B.

7. No Coupling

Modules are completely independent, with no interaction.

Ideal in some cases
Example: Two modules that never call or affect each other.

Want a table comparing both? Let me know!

Or I can give you this in a handwritten-style format for exams too.

 UNIT-V

Control Flow Graph and Cyclomatic Complexity Analysis

Pseudocode Analysis

begin int x, y, power;

float z;

input(x, y);

if(y<0)

power = -y;

else power = y;
 z=1;

while(power!=0)

{ z=z*x;

power=power-1;

} if(y<0)

z=1/z;

output(z);

end

Control Flow Graph

The control flow graph has the following nodes:

Node 1 (Start):

• Declaration and input statements

• begin int x, y, power; float z; input(x, y);

Node 2 (First Decision):

• if(y<0)

Node 3 (True Branch):

• power = -y;

Node 4 (False Branch):

• power = y;

Node 5 (Merge Point):

• z=1;

Node 6 (Loop Decision):

• while(power!=0)

Node 7 (Loop Body):

• z=z*x; power=power-1;

Node 8 (Second Decision):

• if(y<0)

Node 9 (True Branch):

• z=1/z;

Node 10 (End):

• output(z); end
Control Flow Connections

1. Node 1 → Node 2

2. Node 2 → Node 3 (if y<0)

3. Node 2 → Node 4 (if y≥0)

4. Node 3 → Node 5

5. Node 4 → Node 5

6. Node 5 → Node 6

7. Node 6 → Node 7 (if power≠0)

8. Node 6 → Node 8 (if power=0)

9. Node 7 → Node 6 (loop back)

10. Node 8 → Node 9 (if y<0)

11. Node 8 → Node 10 (if y≥0)

12. Node 9 → Node 10

Cyclomatic Complexity Calculation

Method 1: Using the Formula V(G) = E - N + 2P

Where:

• E = Number of edges = 12

• N = Number of nodes = 10

• P = Number of connected components = 1

V(G) = 12 - 10 + 2(1) = 4

Method 2: Counting Decision Points

Decision points in the code:

1. if(y<0) (first occurrence)

2. while(power!=0)

3. if(y<0) (second occurrence)

V(G) = Number of decision points + 1 = 3 + 1 = 4

Method 3: Counting Independent Paths

The independent paths through the program are:

1. y≥0, power=0 initially, y≥0 at end

2. y≥0, power>0 (loop executes), y≥0 at end

3. y<0, power>0 (loop executes), y<0 at end

 4. y<0, power=0 initially, y<0 at end

Number of independent paths = 4

Result

The Cyclomatic Complexity of this pseudocode is 4.

This indicates moderate complexity with 4 independent execution paths through the program. The complexity arises from
two conditional statements and one loop structure.

Complete Guide to Black Box and White Box Testing Techniques

Black Box Testing

Black Box Testing is a software testing method where the internal structure, design, and
implementation of the item being tested are not known to the tester. The tester focuses only on
inputs and outputs without any knowledge of the internal code structure.

Characteristics of Black Box Testing

• No knowledge of internal code structure

• Focus on functionality and behavior

• Input-output based testing

• User perspective testing

• Requirements-based testing

Black Box Testing Techniques

1. Equivalence Partitioning (Equivalence Class Testing)

Definition: Dividing input data into equivalent partitions where all values in a partition should
behave similarly.

Process:

• Identify valid and invalid equivalence classes

• Select one representative value from each class

• Test with these representative values

Example: For age input (18-60 valid range):

• Valid class: 18-60

• Invalid classes: <18, >60

• Test cases: 25 (valid), 10 (invalid), 70 (invalid)

2. Boundary Value Analysis (BVA)

Definition: Testing at the boundaries of equivalence classes, as errors often occur at boundary
conditions.

Types:

• Normal BVA: Test at boundaries

• Robust BVA: Include invalid boundary values

• Worst-case BVA: Test all combinations of boundary values

Example: For range 1-100:

• Test values: 0, 1, 2, 99, 100, 101

3. Decision Table Testing

Definition: Systematic approach for complex business logic with multiple input combinations.

Components:

• Conditions: Input variables

• Actions: Expected outcomes

• Rules: Combination of conditions and actions

Example: Login System Decision Table:

• Conditions: Valid Username (Y/N), Valid Password (Y/N)

• Actions: Grant Access, Deny Access, Lock Account

• Rules cover all combinations

4. State Transition Testing

Definition: Testing based on system states and transitions between states.

Components:

• States: Different conditions of the system

• Transitions: Changes from one state to another

• Events: Triggers that cause transitions

• Actions: Activities performed during transitions

Example: ATM Machine States:

• Idle → Card Inserted → PIN Entry → Transaction → Card Ejected

5. Use Case Testing

Definition: Testing based on user scenarios and use cases.

Process:

• Identify use cases from requirements

• Create test scenarios for each use case

• Include normal, alternative, and exception flows

• Test end-to-end user workflows

6. Error Guessing

Definition: Informal technique based on tester's experience and intuition.

Approach:

• Guess potential error-prone areas

• Use experience from similar applications

• Focus on common failure points

• Test unusual or unexpected inputs

7. Cause-Effect Graphing

Definition: Graphical technique to identify combinations of input conditions.

Process:

• Identify causes (inputs) and effects (outputs)

• Create cause-effect graph

• Convert graph to decision table

• Generate test cases from decision table

8. Pair-wise Testing (All-Pairs Testing)

Definition: Testing all possible pairs of input parameters.

Benefits:
 • Reduces number of test cases

• Covers most defects with minimal tests

• Effective for systems with many parameters

9. Classification Tree Method

Definition: Hierarchical decomposition of input domain.

Process:

• Create classification tree

• Define classes and partitions

• Generate test cases from tree paths

Black Box Testing Levels

1. Functional Testing

• Unit Testing: Individual components

• Integration Testing: Component interactions

• System Testing: Complete system

• Acceptance Testing: User requirements

2. Non-Functional Testing

• Performance Testing: Speed, scalability

• Usability Testing: User experience

• Security Testing: Vulnerability assessment

• Compatibility Testing: Different environments

Advantages of Black Box Testing

• User perspective: Tests from end-user viewpoint

• Unbiased testing: No code influence on test design

• Requirements validation: Ensures requirements are met

• Independence: Can be done by non-programmers

• Large input coverage: Tests various input combinations

Disadvantages of Black Box Testing

• Limited coverage: Cannot test all code paths

• Inefficient: May miss logical errors in code

• Redundant testing: May test same logic multiple times

• No insight: Cannot identify unused code or dead code

White Box Testing

White Box Testing is a software testing method where the tester has complete knowledge of the
internal structure, design, and implementation of the software being tested.

Characteristics of White Box Testing

• Complete code knowledge

• Structure-based testing

• Logic coverage focus

• Developer perspective

• Code path analysis

White Box Testing Techniques

1. Control Flow Testing

Statement Coverage (C0):

• Definition: Every statement in code executed at least once

• Formula: (Statements Executed / Total Statements) × 100

• Goal: Achieve 100% statement coverage

Branch Coverage (C1):

• Definition: Every branch (decision outcome) executed at least once

• Formula: (Branches Executed / Total Branches) × 100

• Stronger than statement coverage

Path Coverage:

• Definition: Every possible path through code executed

• Most comprehensive but often impractical

• Exponential growth with loops and conditions

2. Data Flow Testing

Definition: Testing based on variable definitions and uses.

Key Concepts:

• Definition (def): Variable assignment

• Use (use): Variable usage

• Kill: Variable redefinition

Coverage Criteria:
 • All-defs: Every definition reaches at least one use

• All-uses: Every definition-use pair covered

• All-du-paths: All definition-use paths covered

3. Loop Testing

Simple Loops:

• Skip loop entirely

• Single pass through loop

• Two passes through loop

• m passes (m < n, where n is maximum)

• Maximum passes (n)

• n+1 passes (exceed maximum)

Nested Loops:

• Start with innermost loop

• Test simple loop cases for inner loop

• Work outward to outer loops

• Continue until all loops tested

Concatenated Loops:

• Use approach for simple loops

• If loops are independent, test separately

• If dependent, use nested loop approach

Unstructured Loops:

• Redesign code to use structured loops

• Test using appropriate structured loop strategy

4. Condition Testing

Simple Condition Testing:

• Test each boolean condition

• Use true and false values

• Ensure branch coverage

Multiple Condition Testing:

• Test all combinations of conditions

• Use truth tables for complex conditions

 • Consider short-circuit evaluation

Modified Condition/Decision Coverage (MC/DC):

• Each condition independently affects decision outcome

• NASA and aviation industry standard

• Provides thorough condition testing

5. Basis Path Testing

Definition: Systematic method derived from cyclomatic complexity.

Process:

1. Draw control flow graph

2. Calculate cyclomatic complexity V(G)

3. Determine basis set of independent paths

4. Create test cases for each path

Cyclomatic Complexity Calculation:

• V(G) = E - N + 2P

• V(G) = P + 1 (where P is number of predicates)

6. Graph-Based Testing Methods

Control Flow Graphs:

• Nodes represent statements/blocks

• Edges represent control flow

• Used for path analysis

Data Flow Graphs:

• Track variable definitions and uses

• Identify data flow anomalies

• Support data flow testing

7. Mutation Testing

Definition: Introducing small changes (mutants) to code and checking if tests detect them.

Process:

• Create mutants by modifying original code

• Run test suite against mutants

• Calculate mutation score

• Improve tests to kill more mutants

Mutation Operators:

• Replace operators (+, -, *, /)

• Change constants

• Modify variable references

• Alter conditional statements

White Box Testing Levels

1. Unit Testing

• Individual functions/methods

• Code coverage analysis

• Logic verification

• Data flow testing

2. Integration Testing

• Interface testing

• Call sequence verification

• Data passing validation

• Module interaction testing

3. System Testing

• End-to-end flow testing

• Performance bottleneck identification

• Resource usage analysis

• Security vulnerability testing

Coverage Metrics and Tools

Coverage Types

1. Function Coverage: Functions called

2. Statement Coverage: Statements executed

3. Branch Coverage: Branches taken

4. Condition Coverage: Conditions evaluated

5. Path Coverage: Paths executed

Popular Tools

• Java: JaCoCo, Cobertura, Emma

• C/C++: gcov, Bullseye, Testwell CTC++

 • C#/.NET: NCover, dotCover, OpenCover

• Python: Coverage.py, pytest-cov

• JavaScript: Istanbul, Blanket.js

Static vs Dynamic White Box Testing

Static Testing

• Code reviews

• Static analysis tools

• Code walkthrough

• Code inspection

• No code execution

Dynamic Testing

• Code execution required

• Runtime behavior analysis

• Coverage measurement

• Performance profiling

Advantages of White Box Testing

• Thorough testing: Tests all code paths

• Early detection: Finds errors early in development

• Optimization: Identifies dead code and inefficiencies

• Security: Reveals security vulnerabilities

• Complete coverage: Can achieve 100% code coverage

Disadvantages of White Box Testing

• Expensive: Requires skilled testers with code knowledge

• Time-consuming: Detailed analysis takes time

• Maintenance: Tests need updates with code changes

• Limited scope: May miss missing functionality

• Tool dependency: Requires specialized tools

Best Practices

For Black Box Testing

1. Understand requirements thoroughly

2. Use multiple techniques in combination

 3. Focus on user scenarios

4. Test both positive and negative cases

5. Document test cases clearly

6. Automate repetitive tests

For White Box Testing

1. Start with high-risk modules

2. Aim for adequate coverage, not 100%

3. Combine with black box testing

4. Use appropriate tools

5. Regular code reviews

6. Maintain test cases with code changes

Integration of Both Approaches

Gray Box Testing: Combines both black box and white box approaches

• Limited code knowledge

• Integration testing focus

• Web application testing

• Penetration testing

The most effective testing strategy uses both black box and white box techniques complementarily,
ensuring comprehensive coverage from both user and developer perspectives.