Unit 1: Introduction to Software Engineering

1. Software Engineering - A Layered Approach

● Definition: Software Engineering is a systematic, disciplined, and quantifiable approach

to the development, operation, and maintenance of software. The focus is on delivering
high-quality software efficiently.
● Layered Approach: Software engineering is structured into four layers:
1. Tools: Automated tools to support the software development process (e.g., IDEs,
version control).
2. Methods: Technical approaches and methodologies used in design and testing
(e.g., design patterns, testing strategies).
3. Process: A framework that defines the tasks and activities involved in producing
software.
4. Quality Focus: Ensures that each layer aligns with quality goals like reliability,
maintainability, etc.

Example: Consider building a Gym Fitness Tracking App. The layered approach ensures the
app is developed using appropriate tools (e.g., Android Studio for mobile app development),
methods (e.g., agile), processes (defining sprints), and a focus on delivering a bug-free app that
meets user requirements.

2. Software Process – Process Framework, Umbrella Activities

● Software Process: A set of related activities that lead to the production of a software
product. Commonly includes:
○ Specification: What the system should do (requirements).
○ Design and Implementation: How the system will be built.
○ Validation: Ensuring the system works as intended.
○ Evolution: Adapting the system over time.
● Process Framework:
○ Process Framework refers to the general organization of activities required for
software development (e.g., initiation, planning, execution, closure).
● Umbrella Activities:
○ Activities that support the entire software process, such as:
1. Project Tracking and Control: Monitoring progress.
2. Risk Management: Identifying and mitigating risks.
3. Quality Assurance: Ensuring software quality through reviews, audits.
4. Configuration Management: Keeping track of different versions of
software.
Example: For the Gym Fitness Tracking App, the process framework would include defining
the app’s core features (calorie tracking, workout logging), developing the design, testing, and
tracking the app's evolution over time. Umbrella activities like configuration management would
ensure that updates are correctly applied.

3. Process Models

a. Waterfall Model:

● Linear Sequential Flow: One phase must be completed before the next begins.
● Phases:
1. Requirements.
2. Design.
3. Implementation.
4. Verification.
5. Maintenance.
● Drawback: Limited flexibility; no feedback allowed once a stage is completed.

Example: Developing the Gym Fitness Tracking App using the waterfall model means clearly
defining features, designing UI, implementing code, testing, and then deploying without
returning to previous stages.

b. Incremental Model:

● Iterative: Breaks the project into smaller parts; each part is developed separately and
incrementally adds to the system.
● Advantage: Allows feedback and evolution over iterations.

Example: In the Gym Fitness Tracking App, you first develop basic features like tracking
workouts, then incrementally add features like calorie tracking, graphs, etc.

c. Evolutionary Process Model:

● Prototyping Model: Develop an initial version, take feedback, and refine.

○ Suitable for projects where requirements are unclear.
○ Users provide feedback to refine the system iteratively.
● Spiral Model: Combines iterative development with risk management.
○ Each iteration involves planning, risk analysis, engineering, and evaluation.
○ Focuses on risk minimization through feedback loops.

Example: A prototype of the Gym Fitness Tracking App might initially support basic workout
logging. Feedback would help iterate on UI improvements and performance monitoring. The
spiral model would include risk analysis, such as potential user privacy concerns for workout
data, with solutions integrated in each cycle.
4. Introduction to Agile, Agile Model – Scrum

● Agile Methodology:
○ Focuses on flexibility, customer collaboration, and adaptive planning.
○ Principles:
1. Customer satisfaction through early and continuous delivery.
2. Embrace changing requirements.
3. Frequent delivery of working software.
4. Simplicity in design and implementation.
● Scrum: A popular agile framework.
○ Roles:
1. Product Owner: Defines features of the product.
2. Scrum Master: Facilitates the Scrum process.
3. Development Team: Develops the software.
○ Artifacts:
1. Product Backlog: List of features or tasks.
2. Sprint Backlog: Subset of tasks to be done in the next sprint.
3. Increment: Working software delivered at the end of each sprint.
○ Sprints: Short development cycles (2–4 weeks) that produce a working product
increment.
○ Meetings:
1. Sprint Planning: Decide what to achieve in a sprint.
2. Daily Stand-up: 15-minute meeting to review progress.
3. Sprint Review: Demonstrating the completed work.
4. Sprint Retrospective: Reflect on improvements.

Example: The Gym Fitness Tracking App can be developed using Scrum. The product
backlog could include tasks like creating an admin login, workout templates, and calorie
trackers. Sprints might focus on completing one feature at a time (e.g., the workout logger),
followed by user feedback and refinement.

Unit 1: Introduction to Software Engineering

Software Engineering - A Layered Approach

Definition and Basic Concepts:

● Software Engineering: It is the application of a systematic, disciplined, and quantifiable

approach to the development, operation, and maintenance of software.
● Layered Approach:
1. Tools: Support for automation.
 2. Methods: Best practices and structured techniques.
3. Process: Framework for systematic software development.
4. Quality Focus: Ensuring the final product meets user expectations.

Advantages/Benefits:

● Systematic approach reduces errors.

● Improves software quality and maintainability.

Detailed Explanation:

1. Quality Focus: Ensures compliance with requirements through reviews and testing.
2. Process: Provides consistency across teams and projects, making the development
predictable.

Use Cases/Applications:

● Building enterprise applications, safety-critical systems, and scalable web applications.

Software Process – Process Framework and Umbrella Activities

Definition and Basic Concepts:

● Process Framework: Provides structure for planning, controlling, and monitoring

software development. Includes specific stages like requirement analysis, design,
coding, and testing.
● Umbrella Activities: Cross-cutting activities such as project management, risk
management, quality assurance, and configuration management.

Detailed Explanation:

1. Framework Activities:
○ Requirement gathering.
○ Design.
○ Implementation.
○ Testing.
○ Maintenance.
2. Umbrella Activities:
○ Risk Management: Identifying, assessing, and mitigating risks.
○ Configuration Management: Tracking and managing changes in software.

Use Cases/Applications:

● All modern software projects rely on this structure for success.

Process Models
 1. Waterfall Model:

○ Linear and sequential.

○ Stages: Requirement, Design, Implementation, Verification, Maintenance.
○ Advantages:
■ Simple and easy to understand.
○ Disadvantages:
■ Inflexible; poor for iterative changes.
■ Real requirements may not emerge until testing.
2. Incremental Model:

○ Development is divided into small increments.

○ Each increment delivers a part of functionality.
○ Advantages:
■ Early product delivery.
■ Flexible to changes.
○ Example: Banking software where features like login, fund transfer, and
statements are developed incrementally.
3. Evolutionary Process Models:

○ Prototyping:
■ Early development of a working model for feedback.
■ Advantages: Captures unclear requirements.
■ Disadvantages: Can lead to scope creep.
○ Spiral Model:
■ Combines iterative development with risk analysis.
■ Four phases: Planning, Risk Analysis, Engineering, and Evaluation.
■ Advantages: Effective for large and high-risk projects.
■ Disadvantages: Expensive and complex.

Agile and Scrum

1. Agile:

○ Flexible approach emphasizing collaboration, customer feedback, and iterative

development.
○ Manifesto Principles:
■ Customer satisfaction.
■ Welcome changing requirements.
■ Deliver working software frequently.
2. Scrum:

○ Agile framework focused on managing iterative and incremental work.

○ Key Roles:
■ Product Owner: Defines requirements.
 ■ Scrum Master: Facilitates the process.
■ Development Team: Builds the product.
○ Artifacts:
■ Product Backlog: List of tasks/features.
■ Sprint Backlog: Tasks for a specific sprint.
■ Increment: The completed work after a sprint.
○ Events:
■ Sprint Planning, Daily Standups, Sprint Review, Retrospective.

Example Questions for Viva:

1. Define Software Engineering and explain its layered approach.

2. What are umbrella activities? Give examples.
3. Compare Waterfall and Incremental models.
4. Explain the working of the Spiral Model.
5. What is Agile? State its key principles.
6. Describe the roles in Scrum.

Let me know if you need notes for more units!

Unit 2: Software Requirements Analysis and Specification

1. Use Case Approach

● Definition: A Use Case defines a specific interaction between a user (actor) and the
system to achieve a goal. It describes the system’s behavior in response to a request
from the user.
● Components of a Use Case:
1. Actor: The user or system that interacts with the system.
2. Precondition: Conditions that must be true before the use case can start.
3. Main Flow: Step-by-step description of how the interaction unfolds.
4. Alternate Flow: What happens if the interaction doesn't follow the main flow.
5. Postcondition: The state of the system after the use case is completed.

Example: In the Gym Fitness Tracking App, one use case could be "Log Workout Session":

● Actor: User
 ● Precondition: User is logged in.
● Main Flow:
1. User selects a workout from the list.
2. User enters the number of sets and reps.
3. System stores the workout data.
● Postcondition: Workout is logged, and the system updates user progress.

2. Software Requirement Specification (SRS) Document

● Definition: The SRS document provides a detailed description of a software system to

be developed, serving as a contract between the developer and the customer.
● Key Components:
1. Introduction: Project purpose, scope, and objectives.
2. System Features: Detailed descriptions of the system’s features.
3. Functional Requirements: Specific requirements that describe the system’s
behavior.
4. Non-Functional Requirements: Constraints like performance, security, usability.
5. External Interfaces: Descriptions of how the system will interact with external
systems.
6. Assumptions and Dependencies: Any assumptions or conditions affecting the
requirements.

Example: For the Gym Fitness Tracking App, the SRS would describe:

● Functional Requirements: The app should allow users to log workouts, track calories,
and view progress reports.
● Non-Functional Requirements: The app must respond to user inputs within 2 seconds
and ensure data privacy.
● External Interfaces: Integration with a calorie-tracking API or fitness wearables.

3. Flow-Oriented Model

● Definition: The flow-oriented model represents the flow of data through a system using
diagrams. It focuses on how inputs are transformed into outputs through a series of
processes.
● Types of Flow Models:
1. Data Flow Diagrams (DFD): Show how data moves between processes, data
stores, and external entities.
2. Control Flow Diagrams: Show how control signals and events flow through the
system.
Example: In the Gym Fitness Tracking App, a simple Data Flow Diagram (DFD) might
include:

● Input: User inputs workout details (sets, reps).

● Process: The system processes and stores workout data.
● Output: Updated progress report generated for the user.

4. Data Flow Model

● Definition: A Data Flow Model depicts the flow of information through a system,
focusing on data processing steps rather than control flow.
● Elements:
1. Processes: Represented by circles, these are the functions where data is
processed.
2. Data Stores: Represented by open-ended rectangles, these are repositories
where data is stored.
3. Data Flows: Represented by arrows, these show the movement of data between
processes and stores.
4. External Entities: Represented by rectangles, these are entities outside the
system that interact with it.

Example: For the Gym Fitness Tracking App, a Data Flow Model could include:

● External Entity: User

● Process: Log Workout Data
● Data Store: User Workout History
● Data Flow: From user to workout history, storing information like exercise type, sets, and
reps.

Unit 2: Software Requirements Analysis and Specification

Software Requirements Analysis and Specification

Definition and Basic Concepts:

● Software Requirements Analysis: A process of understanding the user needs and

documenting them systematically.
● Software Requirement Specification (SRS): A document that outlines functional and
non-functional requirements, serving as a bridge between the user and the development
team.

Advantages/Benefits:
 ● Avoids misunderstandings between stakeholders.
● Provides a clear reference for design and development.
● Reduces the risk of project failure by addressing requirements early.

Use Case Approach

Definition and Basic Concepts:

● Use Case: A description of system interactions with users or other systems to achieve
specific goals.
● Actors: Entities interacting with the system (e.g., user, external system).
● Components:
○ Primary Actor: Initiates the interaction.
○ Scenario: Sequence of steps for achieving the goal.
○ Preconditions/Postconditions: System state before and after the interaction.

Advantages/Benefits:

● Enhances clarity of functional requirements.

● Helps identify user needs and system boundaries.

Detailed Explanation:

1. Creating Use Cases:

○ Identify actors (e.g., customer, admin).
○ Define the system goal for each actor.
○ Write scenarios with steps (e.g., "Customer places an order").
2. Example:
○ Actor: Online Shopper.
○ Use Case: Place an Order.
○ Scenario:
1. Log in to the system.
2. Add items to the cart.
3. Proceed to checkout.
4. Enter payment details and confirm.

Use Cases/Applications:

● Common in e-commerce systems, booking platforms, and enterprise software.

Software Requirement Specification (SRS) Document

Definition and Basic Concepts:

● A formal document that specifies:

○ Functional Requirements: What the system should do.
○ Non-Functional Requirements: System qualities like performance, security.
○ Constraints: Limitations or conditions (e.g., platform-specific requirements).

Structure of an SRS:

1. Introduction:
○ Purpose, scope, definitions.
2. Overall Description:
○ System environment, assumptions, and dependencies.
3. Specific Requirements:
○ Functional and non-functional details.
4. Appendices:
○ Glossary, references.

Advantages/Benefits:

● Acts as a contract between stakeholders.

● Reduces ambiguity in development.
● Serves as a reference during testing.

Use Cases/Applications:

● Any software project requiring clear communication of requirements.

Flow-Oriented Model

Definition and Basic Concepts:

● Represents how data flows through the system, showing the processes and
transformations applied to it.
● Components:
○ Processes: Functions that transform data.
○ Data Stores: Storage of data within the system.
○ Data Flows: Movement of data between entities.

Advantages/Benefits:

● Useful for visualizing and analyzing data dependencies.

● Helps in identifying redundancies or inefficiencies.

Detailed Explanation:
 1. Data Flow Diagram (DFD):
○ Levels:
■ Context Diagram: High-level view showing system boundaries.
■ Level-1 DFD: Detailed decomposition of processes.
○ Symbols:
■ Oval: Process.
■ Arrow: Data flow.
■ Rectangle: External entity.
■ Open Rectangle: Data store.

Example:

● Context Diagram for Online Shopping System:

○ Entities: Customer, Payment Gateway.
○ Processes: Order Processing, Payment Verification.

Use Cases/Applications:

● Designing systems with significant data flow, such as banking systems or inventory
management.

Data Flow Model

Definition and Basic Concepts:

● A subset of the flow-oriented model focusing specifically on the movement of data.

● Represents:
○ Input data.
○ Processes transforming data.
○ Output data.

Advantages/Benefits:

● Helps in functional decomposition.

● Highlights bottlenecks in data processing.

Example:

● Online Banking System:

○ Input: User credentials.
○ Process: Authentication.
○ Output: Access to account details.
Sample Viva Questions:

1. What is the purpose of requirements analysis?

2. Define a use case and explain its components.
3. What are functional and non-functional requirements? Provide examples.
4. How does an SRS benefit the software development process?
5. Explain the flow-oriented model and its components.
6. Differentiate between the context diagram and Level-1 DFD.
7. How are data flows represented in a Data Flow Model? Provide an example.

Let me know if you need notes for additional units or any topic explained further!

Unit 3: Design Modeling

1. Translating the Requirements Model into the Design Model

● Definition: After gathering and analyzing requirements, the next step is to convert those
requirements into a detailed design that can be implemented in code. This process
ensures that functional and non-functional requirements are translated into architectural
components.
● Steps in Translation:
1. Identify Major System Components: Identify key modules or components.
2. Define Interfaces: Determine how the components will interact.
3. Design Data Structures: Define the organization of the data used by the
system.
4. Create Functional Flow: Map out how data flows between components.

Example: For the Gym Fitness Tracking App, requirements such as workout logging and
calorie tracking are transformed into design components like the workout module, calorie
tracking module, and user authentication module. The interaction between these modules is
defined using interfaces.

2. The Design Process and Design Concepts

● Design Process: The design process is a series of steps that engineers follow to arrive
at the final design of a system. It involves:
1. Architectural Design: Defining the overall structure of the system.
2. Detailed Design: Specifying the system components and their interactions.
3. Design Review: Ensuring the design meets the requirements.

Key Design Concepts:

a. Abstraction: - Definition: The process of simplifying complex reality by modeling classes
appropriate to the problem. - Types: 1. Data Abstraction: Abstracting the details of how data is
stored. 2. Control Abstraction: Abstracting the control mechanisms of the system. - Example:
In the Gym Fitness Tracking App, the user workout details are stored in an abstract form like
WorkoutData rather than the full complexity of each workout entry.

b. Modularity: - Definition: Dividing the system into smaller, manageable parts (modules) that
can be developed and tested independently. - Goal: High cohesion within modules and low
coupling between modules. - Example: The app’s features could be divided into separate
modules: a workout module, a diet module, and a progress tracker, each developed
independently but interacting with the others.

c. Functional Independence: - Definition: Achieving independence of modules such that each

performs a single function. - Advantage: Enhances maintainability and scalability. - Example: In
the Gym Fitness Tracking App, the workout logging module should function independently of
the calorie tracking module, allowing independent updates.

3. Structure Charts

● Definition: A structure chart is a hierarchical diagram that shows the breakdown of a

system into its major components or modules.
● Elements:
1. Modules: Represented as rectangles.
2. Control: Lines connecting modules showing data flow.
3. Condition and Looping: Conditional elements are represented to show
alternative or looping paths.
● Types:
1. Transform-Centered Structure Chart: Based on input and output
transformations.
2. Transaction-Centered Structure Chart: Based on user actions triggering
different paths.

Example: For the Gym Fitness Tracking App, a structure chart might have modules for:

● User Authentication
● Workout Logging
● Calorie Tracking
● Progress Reporting

The chart will show how data flows between these modules, ensuring logical organization and
separation of concerns.
Unit 3: Design Modeling

Translating the Requirements Model into the Design Model

Definition and Basic Concepts:

● Requirements Model: Captures what the system should do (functional and

non-functional requirements).
● Design Model: Specifies how the system will achieve the requirements.
○ Converts requirements into architecture, data structures, and interfaces.

Steps in Translation:

1. Analyze Requirements: Review SRS and use cases for clarity.

2. Define Architecture: Establish a high-level structure of the system.
3. Design Components: Break down the architecture into smaller modules.
4. Detail Interface Design: Define how modules will interact.
5. Document Data Structures: Specify formats for data storage and transfer.

Advantages/Benefits:

● Bridges the gap between analysis and implementation.

● Ensures alignment between requirements and the final product.

Example:

● In an e-commerce system:
○ Requirement: Users should search for products.
○ Design: A search engine module with components for query input, result retrieval,
and display.

The Design Process

Definition and Basic Concepts:

● Design Process: A structured approach to create a design model for the system.
● Stages:
1. Data Design: Representation of data structures and databases.
2. Architectural Design: High-level structure of the system.
3. Interface Design: Interaction between system components and users.
 4. Component Design: Detailed specification of each module.

Advantages/Benefits:

● Ensures clarity in system construction.

● Facilitates maintenance and scalability.

Detailed Explanation:

1. Data Design:
○ Focus on defining how data will be organized, stored, and accessed.
○ Example: Database schema for user accounts.
2. Architectural Design:
○ Establishes overall system structure (e.g., layered architecture).
○ Example: MVC (Model-View-Controller) pattern.
3. Interface Design:
○ Specifies user interfaces and APIs.
○ Example: Login form for users.
4. Component Design:
○ Details each module’s internal logic and interactions.
○ Example: A payment gateway module.

Use Cases/Applications:

● Used in any project transitioning from requirements to implementation.

Design Concepts

1. Abstraction:

○ Simplifying complex systems by focusing on relevant details.

○ Types:
■ Data Abstraction: Hiding details of data representation.
■ Procedural Abstraction: Hiding the implementation details of functions.
○ Example: Defining a "User" class without exposing internal attributes.
2. Modularity:

○ Dividing a system into smaller, manageable modules.

○ Modules should have high cohesion (perform related tasks) and low coupling
(minimal dependency).
○ Advantages:
■ Easier debugging and testing.
■ Promotes reusability.
 ○Example: Separate modules for authentication, order management, and
payment in an e-commerce system.
3. Functional Independence:

○ Modules operate independently with well-defined interfaces.

○ Advantages:
■ Reduces complexity.
■ Facilitates parallel development.
○ Example: Payment processing independent of product catalog management.

Structure Charts

Definition and Basic Concepts:

● A Structure Chart is a hierarchical diagram representing the organization of modules in

a system.
● Depicts:
○ Modules: Functional components.
○ Control Flow: Interaction between modules.
○ Data Flow: Data passed between modules.

Components:

● Rectangle: Represents a module.

● Arrow: Indicates control or data flow.
● Horizontal Line: Represents subordination (parent-child relationship).

Advantages/Benefits:

● Simplifies understanding of module relationships.

● Helps identify redundant modules or dependencies.

Example:

● Online Shopping System:

○ Parent Module: Order Management.
○ Child Modules: Payment Processing, Inventory Update.

Use Cases/Applications:

● Used in structured programming and software engineering for visualizing system design.
Sample Viva Questions:

1. What is the purpose of translating the requirements model into the design model?
2. List the stages in the design process and explain their significance.
3. Define abstraction. How is it applied in software design?
4. What are the characteristics of modularity in software design?
5. Explain functional independence with an example.
6. What is a structure chart? How does it help in software design?
7. Differentiate between data flow and control flow in structure charts.

Let me know if you need additional clarifications or more units!

Unit 4: Software Metrics and Project Estimation

1. Function-Based Metrics

● Definition: Function-based metrics measure the functionality of the software system

from the user’s perspective, focusing on what the software does rather than how it does
it.
● Common Function-Based Metrics:
1. Function Points (FP): Used to estimate the complexity and size of a software
project based on the number of functional components like inputs, outputs, user
interactions, and data files.
2. Lines of Code (LOC): Measures the size of software by counting the number of
lines in the source code.
3. Weighted Micro Function Points (WMFP): Enhances the traditional FP
approach by factoring in the complexity of micro functions.

Example: For the Gym Fitness Tracking App, function points would be calculated based on:

● Number of user inputs (e.g., logging a workout, entering calorie data).

● Number of outputs (e.g., progress reports).
● Interactions with data files (e.g., user workout history). This allows developers to
estimate the effort and time needed to develop the system.

2. Software Measurement

● Definition: Software measurement involves collecting, analyzing, and using metrics to

evaluate the software development process and its products.
● Metrics for Software Quality:
1. Product Metrics: Measure the characteristics of the final software product, such
as size, reliability, and maintainability.
 2. Process Metrics: Evaluate the effectiveness of the software development
process, like defect detection efficiency or cost of rework.
3. Project Metrics: Track the progress and quality of the software project, such as
cost, schedule, productivity, and risk.

Common Metrics:

● Defect Density: Number of defects per size of the software (e.g., per KLOC).
● Cyclomatic Complexity: Measures the complexity of the code based on the number of
independent paths.

Example: For the Gym Fitness Tracking App, you could track:

● Defect Density: After each development sprint, calculate how many bugs are found per
1,000 lines of code.
● Cyclomatic Complexity: Measure the complexity of functions like the workout logger to
ensure the code remains maintainable.

3. Software Project Estimation (FP-Based Estimations)

● Definition: Software project estimation involves predicting the effort, time, and cost
required to develop a software system.
● FP-Based Estimation Process:
1. Calculate Unadjusted Function Points (UFP): Based on inputs, outputs, user
interactions, files, and external interfaces.
2. Determine Value Adjustment Factor (VAF): Adjusts the UFP by considering
factors like performance, usability, security.
3. Calculate Adjusted Function Points (AFP): Adjust UFP using VAF to get the
final estimate.

Example: For the Gym Fitness Tracking App, the team estimates:

● UFP: 20 (based on inputs like workouts, outputs like progress reports, etc.).
● VAF: 1.1 (accounting for performance requirements, data privacy, etc.).
● AFP: 22 FP. Using the FP estimate, the team calculates the effort in person-months and
cost based on their productivity rate.

4. Project Scheduling

● Definition: Project scheduling involves planning the sequence and timing of tasks
needed to complete a software project. It ensures that the project stays on track in terms
of time and resources.
 ● Components of Project Scheduling:
1. Timeline Charts (Gantt Charts): A graphical representation of tasks scheduled
over time. It helps visualize the start and end dates of tasks and track progress.
2. Tracking the Schedule: Monitoring the project’s progress against the schedule
and identifying variances to take corrective actions.

Example: For the Gym Fitness Tracking App, the project manager would create a Gantt
Chart to visualize the following tasks:

● User interface design

● Database development
● Integration of calorie-tracking API
● Testing and deployment Each task is given a start and end date, and the chart helps the
team track progress and stay on schedule.

Unit 4: Software Metrics and Project Estimation

Function-based Metrics

Definition and Basic Concepts:

● Function-based Metrics: Measure software size and complexity based on its functional
components.
● They are typically derived using Function Points (FP), which quantify the functionality
delivered to the user.

Key Components:

● Inputs: User input to the system.

● Outputs: Outputs produced by the system.
● Inquiries: User requests that require system response.
● Internal Logical Files (ILF): Data maintained within the system.
● External Interface Files (EIF): Data used by the system but maintained externally.

Formula:

● FP = (Inputs × Weight1) + (Outputs × Weight2) + (Inquiries × Weight3) + (ILFs ×

Weight4) + (EIFs × Weight5), where weights are based on complexity.

Advantages/Benefits:

● Objective measure of system functionality.

● Facilitates comparison across projects.
Example:

● A banking application:
○ Inputs: 5, Outputs: 3, Inquiries: 2, ILFs: 4, EIFs: 1.
○ Assign appropriate weights and calculate FP.

Software Measurement

Definition and Basic Concepts:

● Software Measurement: The process of quantifying characteristics of software or its

development process.
● Types:
○ Direct Measures: Size (lines of code), execution speed.
○ Indirect Measures: Reliability, maintainability.

Advantages/Benefits:

● Provides insights for project planning and quality control.

● Helps track progress and identify risks.

Key Metrics:

1. Size Metrics: LOC (Lines of Code), FP.

2. Effort Metrics: Person-months required for development.
3. Quality Metrics: Number of defects per 1,000 LOC.

Example:

● A project with 20,000 LOC and 100 defects gives a defect density of 5 defects per 1,000
LOC.

Metrics for Software Quality

Definition and Basic Concepts:

● Measure the performance, maintainability, and usability of software.

● Categories:
○ Product Metrics: Measures the software itself (e.g., defect density, code
complexity).
○ Process Metrics: Measures the process used to develop software (e.g., time to
fix bugs).
○ Project Metrics: Measures project execution (e.g., cost variance).
Key Quality Metrics:

1. Reliability: Mean Time to Failure (MTTF).

2. Maintainability: Effort required to make changes.
3. Usability: User satisfaction scores.

Advantages/Benefits:

● Ensures alignment with user expectations.

● Helps identify areas for improvement.

Software Project Estimation

Definition and Basic Concepts:

● Project Estimation: Predicting the resources, time, and cost needed for software
development.
● Function Point (FP) Based Estimation:
○ Steps:
1. Calculate Function Points.
2. Estimate productivity (FP/person-month).
3. Estimate effort, time, and cost.

Advantages/Benefits:

● Provides realistic timelines and budgets.

● Improves resource allocation.

Example:

● If a project has 100 FP and a team’s productivity is 10 FP per person-month:

○ Effort = 100 / 10 = 10 person-months.

Project Scheduling

Definition and Basic Concepts:

● Project Scheduling: Planning and managing the timeline of tasks to complete the
project on time.
● Tools:
○ Timeline Charts: Visualize task durations and dependencies (e.g., Gantt
Charts).
○ Tracking Tools: Monitor progress against planned milestones.
Key Techniques:

1. Work Breakdown Structure (WBS):

○ Decomposes the project into smaller tasks.
2. Critical Path Method (CPM):
○ Identifies tasks that directly affect project completion time.
3. PERT (Program Evaluation and Review Technique):
○ Uses optimistic, pessimistic, and most likely time estimates.

Advantages/Benefits:

● Identifies critical tasks and potential delays.

● Improves resource allocation.

Example:

● A project with tasks A, B, and C:

○ A: 2 weeks, B: 3 weeks (depends on A), C: 1 week (depends on B).
○ Total duration: 6 weeks.

Sample Viva Questions

1. What are function-based metrics, and how are they calculated?

2. Explain the significance of software measurement in project management.
3. What are the key metrics for measuring software quality?
4. Define Function Point-based estimation and describe its steps.
5. What are timeline charts, and how do they assist in project scheduling?
6. Describe the Critical Path Method (CPM) and its importance.
7. How do you calculate defect density in a software project?

Let me know if you need notes for additional units or concepts!

Quality Control and Quality Assurance

1. Quality Control (QC)

● Definition: QC involves the operational techniques and activities used to fulfill quality
requirements. It focuses on identifying defects in the final product.
● Key Activities:
○ Testing (unit, integration, system testing).
 ○ Inspections and reviews (code reviews, design reviews).
○ Defect tracking and reporting.
● Purpose: To ensure the product meets the desired quality standards before release.

Example: In the Gym Fitness Tracking App, QC ensures that the calorie tracker accurately
calculates values by conducting rigorous system testing.

2. Quality Assurance (QA)

● Definition: QA involves planned and systematic activities implemented in a quality

system to provide confidence that the product meets the quality standards.
● Key Components:
1. Process Definition and Implementation: Establish processes for consistent
product development.
2. Audits and Reviews: Periodic evaluations to ensure processes are followed.
3. Standards Compliance: Ensuring compliance with industry standards (e.g., ISO
9001).
● Purpose: To prevent defects by improving the development process.

Example: For the Gym Fitness Tracking App, QA ensures that the development team follows
coding standards and conducts peer reviews to prevent defects during development.

Software Process Assessment and Improvement

1. Process Assessment

● Definition: A systematic evaluation of an organization's software processes to identify

strengths, weaknesses, and areas for improvement.
● Common Models:
1. CMMI (Capability Maturity Model Integration):
■ Levels: Initial, Managed, Defined, Quantitatively Managed, Optimizing.
2. ISO/IEC 15504 (SPICE): International standard for process assessment.
● Outcome: A roadmap for process improvement.

Example: If the development team for the Gym Fitness Tracking App finds that testing is
delayed, they may assess and improve their process to integrate automated testing early in the
development cycle.

2. Process Improvement

● Definition: Enhancing existing processes to increase efficiency, quality, and adaptability.

● Steps:
 1. Identify bottlenecks or inefficiencies.
2. Implement changes (e.g., adopting Agile for faster iterations).
3. Monitor the results to ensure improvements are effective.

Example: After an assessment, the team decides to adopt a CI/CD pipeline for faster
deployments.

Software Risks

1. Definition: Risks are potential problems that may affect the success of a project.

2. Types of Risks:

● Project Risks: Impact the project schedule, budget, or resources.

● Technical Risks: Issues with technology, such as integration failures or performance
problems.
● Business Risks: Affect the business goals, such as changing market demands.

Risk Management Process

1. Risk Identification

● Definition: Identifying potential risks that could affect the project.

● Techniques:
○ Brainstorming.
○ Checklist analysis.
○ Historical data review.
● Examples:
○ Incomplete requirements for the Gym Fitness Tracking App.
○ Delays in API integration.

2. Risk Projection (Analysis)

● Definition: Evaluating the likelihood and impact of identified risks.

● Risk Analysis Components:
1. Probability: Likelihood of the risk occurring.
2. Impact: Severity of the effect on the project.
● Example: The risk of delayed API integration might have a high probability and high
impact on project deadlines.

3. Risk Mitigation
 ● Definition: Developing strategies to reduce the likelihood or impact of risks.
● Mitigation Strategies:
1. Avoidance: Eliminate the risk (e.g., choosing a simpler API).
2. Reduction: Minimize the impact (e.g., allocate additional resources).
3. Acceptance: Acknowledge and plan for the risk.
● Example: To mitigate the risk of incomplete requirements, the team conducts detailed
requirement analysis with stakeholders.

4. Risk Monitoring and Management

● Definition: Continuously tracking identified risks and identifying new ones during the
project lifecycle.
● Activities:
1. Regular status meetings to review risks.
2. Updating the risk management plan as necessary.
● Example: The team monitors the progress of the API integration and has a contingency
plan ready for delays.

Unit 5: Quality Control and Risk Management

Quality Control and Quality Assurance

Definition and Basic Concepts:

● Quality Control (QC):

○ Focuses on detecting defects in the software product.
○ Uses techniques like testing, code reviews, and inspections.
○ Reactive process that ensures the product meets quality standards.
● Quality Assurance (QA):
○ Ensures processes used to manage and create deliverables are effective.
○ Proactive process focusing on improving the development process.
○ Includes adherence to standards (e.g., ISO 9001).

Differences:

Aspect Quality Quality Control

Assurance
Focus Process-oriented Product-oriented

Objective Prevent defects Identify and fix defects

Technique Audits, training Testing, inspections

s

Advantages/Benefits:

● QA ensures reliability and standardization.

● QC directly improves the end-user experience.

Example:

● QA: Implementing coding standards.

● QC: Running unit tests to find bugs.

Software Process Assessment and Improvement

Definition and Basic Concepts:

● Process Assessment:
○ Evaluating the effectiveness of current software development processes.
○ Models like CMMI (Capability Maturity Model Integration) provide a structured
approach.
● Process Improvement:
○ Making changes to address weaknesses identified during assessments.
○ Common frameworks: Six Sigma, Total Quality Management (TQM).

Advantages/Benefits:

● Reduces defect rates and rework.

● Improves team productivity and delivery timelines.

Example:

● Assessment identifies delays in testing due to unclear requirements; improvement might

include better requirement documentation.
Software Risks

Definition and Basic Concepts:

● Software Risk: Potential events that can negatively affect the project timeline, cost, or
quality.
● Types:
1. Project Risks: Budget overruns, resource unavailability.
2. Technical Risks: Unproven technology, performance issues.
3. Business Risks: Market changes, client withdrawal.

Advantages/Benefits:

● Risk management ensures project stability and helps meet deadlines.

Risk Identification, Projection, and Mitigation

1. Risk Identification:

○ Process of listing potential risks.

○ Tools:
■ Brainstorming sessions.
■ Checklists.
■ SWOT Analysis.
○ Example: Identifying the risk of server crashes during peak usage.
2. Risk Projection:

○ Analyzing the likelihood and impact of risks.

○ Tools:
■ Probability-Impact Matrix.
○ Example:
■ Risk: Team member leaves mid-project.
■ Likelihood: High, Impact: Critical.
3. Risk Mitigation:

○ Creating a plan to reduce the likelihood or impact of risks.

○ Techniques:
■ Backup plans.
■ Training sessions.
■ Resource allocation.
○ Example: Using cloud backup systems to mitigate data loss risks.
 4. Risk Monitoring and Management:

○ Continuously tracking risks throughout the project lifecycle.

○ Tools: Risk registers, periodic reviews.
○ Example: Regularly monitoring performance metrics for delays.

Cyclomatic Complexity

Definition and Basic Concepts:

● Cyclomatic Complexity:
○ A software metric used to measure the complexity of a program’s control flow.
○ Indicates the number of independent paths through a program.

Formula:

● CC=E−N+2PCC = E - N + 2P
○ EE: Number of edges in the control flow graph.
○ NN: Number of nodes in the control flow graph.
○ PP: Number of connected components.

Interpretation:

● Complexity values:
○ 1−101-10: Simple, low-risk programs.
○ 11−2011-20: Moderate complexity.
○ >20>20: High complexity, error-prone.

Advantages/Benefits:

● Helps determine test cases for code coverage.

● Identifies potential maintenance challenges.

Example:

● A function with:
○ 6 edges, 5 nodes, and 1 connected component:
■ CC=6−5+2=3CC = 6 - 5 + 2 = 3.

Sample Viva Questions

1. Differentiate between quality assurance and quality control.

2. What are the key steps in software process improvement?
 3. Define software risk. What are its types?
4. Explain risk mitigation with an example.
5. How do you calculate cyclomatic complexity? Provide the formula.
6. What does a high cyclomatic complexity indicate about a program?
7. What tools are used for risk monitoring and management?

Let me know if you need further clarification or additional notes!

Software Testing Overview

● Definition: Software testing is a process to identify defects or bugs in software to ensure

it meets the specified requirements and quality standards.
● Purpose: To validate and verify that the software behaves as expected and to find and
fix any defects before release.
● Goals:
○ Ensure software functionality.
○ Improve the reliability and performance of the software.
○ Confirm compliance with user requirements.

Strategic Approach to Software Testing

1. Planning and Design:

○ Identify test objectives.
○ Select appropriate testing strategies.
○ Develop a comprehensive test plan outlining resources, schedules, and test
cases.
2. Execution:
○ Run test cases and compare actual outcomes against expected results.
3. Evaluation:
○ Track defects and analyze test results.
○ Perform defect reporting and track resolution.
4. Closure:
○ Final review and documentation.
○ Report on overall testing quality and project readiness.

Types of Software Testing

1. Unit Testing

● Definition: The process of testing individual units or components of the software in

isolation.
● Objective: To ensure that each unit performs as expected.
● Tools: JUnit, NUnit, pytest.
● Example: Testing a function in the Gym Fitness Tracking App that calculates the total
calories burned during a workout.

2. Integration Testing

● Definition: Testing the interaction between integrated units or components.

● Objective: To ensure that combined parts of the application work together as intended.
● Approaches:
○ Top-Down: Start with higher-level modules and integrate lower-level ones.
○ Bottom-Up: Start with lower-level modules and work upward.
● Example: Testing the integration of the workout tracker module with the database that
stores user workout data.

3. Validation Testing

● Definition: The process of ensuring that the software meets user expectations and
requirements.
● Objective: To check if the software meets business needs and requirements.
● Method:
○ Verify that the software behaves as intended in real-world scenarios.
● Example: Confirming that the Gym Fitness Tracking App correctly logs workouts and
calculates calories for different user profiles.

4. System Testing

● Definition: Testing the complete and fully integrated software product.

● Objective: To validate that the entire system meets the specified requirements.
● Types:
○ Functional Testing: Ensures that the software performs its functions as
expected.
○ Non-functional Testing: Evaluates performance, usability, security, etc.
● Example: Performing end-to-end testing on the Gym Fitness Tracking App to check
user registration, login, tracking workouts, and viewing statistics.

Types of Testing Techniques

1. Black-Box Testing
 ● Definition: Testing without knowledge of the internal workings of the application.
● Focus: Input-output behavior, not the code itself.
● Advantages:
○ Tests are based on specifications.
○ No need for code knowledge.
● Example: Testing the calorie calculation feature in the Gym Fitness Tracking App by
feeding inputs (e.g., user weight, duration of workout) and checking outputs.

2. White-Box Testing

● Definition: Testing with knowledge of the internal logic of the application.

● Focus: Code paths, branches, and logic.
● Techniques:
○ Statement Coverage: Ensures each line of code is executed at least once.
○ Path Coverage: Ensures all possible paths through the code are tested.
● Example: Testing the code for the workout tracking algorithm in the Gym Fitness
Tracking App to verify that all decision points are evaluated.

Basis Path Testing and Cyclomatic Complexity

1. Basis Path Testing

● Definition: A white-box testing technique that uses control flow graphs to identify
independent paths in the code.
● Objective: To ensure that all paths in the program are tested.
● Steps:
1. Create a control flow graph of the code.
2. Identify independent paths.
3. Design test cases that execute these paths.
● Benefit: Helps achieve maximum code coverage with minimal test cases.

Example: In the Gym Fitness Tracking App, basis path testing would include testing all
different routes through the code for calculating calories burned, considering different user
inputs.

2. Cyclomatic Complexity

● Definition: A software metric used to measure the complexity of a program based on its
control flow graph.
● Formula: V(G)=E−N+2PV(G) = E - N + 2P
○ V(G)V(G): Cyclomatic complexity.
○ EE: Number of edges in the control flow graph.
○ NN: Number of nodes in the control flow graph.
 ○ PP: Number of connected components (typically 1 for a single program).
● Interpretation:
○ A higher cyclomatic complexity indicates more complex code, potentially harder
to test and maintain.
● Example: A function in the Gym Fitness Tracking App that handles user input with
many conditional branches (e.g., different types of workouts) will have higher cyclomatic
complexity and require more test cases.

Unit 6: Software Testing

Strategic Approach to Software Testing

Definition and Basic Concepts:

● Software Testing: A process to evaluate the functionality of a software application and

ensure it meets the specified requirements.
● Strategic Approach:
○ Involves planning the testing activities to ensure comprehensive coverage and
effective resource usage.
○ Follows a structured approach starting from unit testing up to system testing.

Key Aspects:

● Test Plan: A document that outlines the scope, objectives, resources, schedule, and
activities of the testing process.
● Test Strategy: High-level description of the testing approach and the methods to be
used.
● Test Case Design: Creation of test cases based on requirements, specifications, and
design documents.

Advantages/Benefits:

● Helps identify defects early in the development lifecycle.

● Reduces overall cost and effort by detecting issues early.

Types of Software Testing

1. Unit Testing:

○ Definition: Testing individual units or components of a software to ensure they

function correctly in isolation.
 ○ Tools: JUnit (Java), NUnit (.NET), PyTest (Python).
○ Example: Testing a function that calculates the sum of two numbers to verify
correct output.
○ Advantages: Identifies issues in the code early; facilitates code refactoring.
2. Integration Testing:

○ Definition: Testing the interaction between integrated units or modules to ensure

they work together as expected.
○ Approaches:
■ Top-Down: Tests from the top module down to the lower levels.
■ Bottom-Up: Tests from lower-level modules up to the top.
○ Example: Verifying that data passed between the user interface and the
database is correct.
○ Advantages: Detects interface defects between modules.
3. Validation Testing:

○ Definition: Checks if the software meets the business requirements and is fit for
its intended purpose.
○ Key Activities: Reviews, walkthroughs, and user acceptance testing.
○ Example: Verifying if the features of an e-commerce application match user
specifications (e.g., payment process works as described).
○ Advantages: Ensures the software fulfills the requirements from a user's
perspective.
4. System Testing:

○ Definition: Testing the complete and integrated software to verify that it meets
the specified requirements.
○ Approach: End-to-end testing covering all functional and non-functional aspects.
○ Example: Testing the entire e-commerce platform with real user transactions.
○ Advantages: Ensures the system behaves as expected in a real-world
environment.

Black-Box and White-Box Testing

1. Black-Box Testing:

○ Definition: A testing technique where the tester does not have knowledge of the
internal code or logic of the application.
○ Focus: Functional behavior, input-output validation.
○ Techniques:
■ Equivalence Partitioning: Divides input data into valid and invalid
partitions.
■ Boundary Value Analysis: Tests the boundaries of input ranges.
 ○Example: Testing an input form by entering valid and invalid data to check the
response.
○ Advantages: Allows testing from a user perspective; effective for validating
functionality.
2. White-Box Testing:

○ Definition: A testing method where the tester has complete knowledge of the
internal logic, code, and structure of the application.
○ Focus: Code structure, logic flow, path coverage.
○ Techniques:
■ Statement Coverage: Ensures every statement is executed at least
once.
■ Path Coverage: Ensures every possible path in the code is tested.
○ Example: Testing a function by covering all possible conditional branches (e.g.,
if-else statements).
○ Advantages: Identifies hidden errors and ensures code quality.

Basis Path Testing

Definition and Basic Concepts:

● Basis Path Testing: A white-box testing technique aimed at ensuring all independent
paths in a program are tested.
● Cyclomatic Complexity: Used to determine the number of paths in the control flow
graph.
● Process:
1. Create a control flow graph for the program.
2. Identify independent paths.
3. Create test cases that cover each independent path.

Advantages/Benefits:

● Ensures comprehensive code coverage.

● Identifies potential logical errors and dead code.

Example:

● For a simple function with decision points:

○ Paths: A → B, A → C, A → B → D, A → C → D.
○ Create test cases to cover each path.

Sample Viva Questions

 1. What is a strategic approach to software testing?
2. Describe unit testing and its importance.
3. How does integration testing differ from system testing?
4. What is the purpose of validation testing?
5. Explain black-box testing and provide an example.
6. What is white-box testing, and what are its advantages?
7. What is basis path testing, and why is it important in software testing?

Let me know if you need further elaboration on any section or more sample questions!