How the Spiral Model Works Develop a working version (prototype or

Development proceeds in a series of increment)

loops (spirals). Testing
Each loop represents a phase of the Test the current version for correctness
project, and every loop focuses heavily and usability
on risk analysis. User Evaluation & Feedback
Each spiral has four main activities: Users review the system
Planning New requirements or changes are
Define objectives for the phase suggested
Identify alternatives and constraints Refinement / Evolution
Decide features to implement in this System is improved and expanded
iteration Next version is developed
Risk Analysis ( Core of the model) This cycle repeats until the system meets
Identify technical, cost, schedule, or all requirements.
usability risks Iterative Enhancement Model
Evaluate and reduce risks (often using The Iterative Enhancement Model is a
prototypes, simulations, or PoCs) software development model in which
Engineering the system is built step by step through
Design, code, and test the selected repeated iterations, and each iteration
features enhances the system by adding new
Build working increments of the system features or improving existing ones.
Evaluation Phases in Each Iteration
Customer/user evaluates the output Every iteration typically goes through
Feedback is collected these activities:
Decision made: continue, modify, or stop Requirement Analysis
the project Select a subset of requirements for this
iteration
Design
Design only the selected features
Implementation
Code the selected functionality
Testing
Test the new features + regression test
old ones
Review / Feedback
User evaluates the system
Evolutionary Model (Software
Feedback guides the next iteration
Engineering)
Requirement Engineering Process
Phases of the Evolutionary Model
Each cycle typically includes: The Requirement Engineering (RE)
Initial Requirement Analysis Process is a systematic approach to
Identify core requirements identify, analyze, document, validate,
Understand user needs (often and manage the requirements of a
incomplete at start) software system throughout its life cycle.
Design & Implementation In short:
Right requirements → Right system → Walkthroughs
Fewer failures Prototyping
Phases of Requirement Engineering Test-case generation
Process Requirement Management
Feasibility Study Handle requirement changes during
Check whether the project is technically, development
economically, and operationally feasible Includes:
Answers: Version control
Is the project worth doing? Change impact analysis
Can it be completed with available Traceability
resources? Ensures requirements stay updated over
time
Requirement Elicitation Difference: Requirement Analysis vs
Gather requirements from stakeholders Requirement Engineering
Techniques:
Interviews Requirement Requirement
Basis
Questionnaires Analysis Engineering
Brainstorming
Observation Complete
Process of
Workshops process of
understanding
Focus: What the user really needs handling
Meaning and analyzing
Requirement Analysis & Negotiation requirements
user
Analyze requirements for: from start to
requirements
Completeness finish
Consistency
Feasibility Broad (covers
Narrow
Resolve conflicts between stakeholders entire
Scope (focused on
Prioritize requirements requirement
analysis)
Requirement Specification lifecycle)
Document requirements clearly in SRS
(Software Requirement Specification) Feasibility,
Includes: Elicitation, elicitation,
Functional requirements analysis, analysis,
Activities
Non-functional requirements modeling, specification,
Constraints validation validation,
Written in clear, unambiguous language management
Requirement Validation
Ensure requirements are: Lifecycle Mainly early Throughout
Correct Coverage SDLC phase the SDLC
Complete
Consistent SRS +
Analyzed and
Verifiable managed &
Output validated
Traceable traceable
requirements
Methods: requirements
Reviews
SRS Documentation Performance
Security
SRS (Software Requirement
Reliability
Specification) is a formal written
Usability
document that clearly describes what a Scalability
software system should do, how it c) Interface Requirements
should perform, and the constraints User interfaces
under which it must operate. Hardware interfaces
It serves as a contract between the Software interfaces
customer and the development team. Communication interfaces
Purpose of SRS
System Models (Optional)
• Clearly define functional & non- Use case diagrams
functional requirements Data Flow Diagrams (DFD)
UML diagrams
• Act as a reference for developers, Appendices
testers, and stakeholders Additional information
• Reduce ambiguity and Supporting material
misunderstandings
DFD (Data Flow Diagram)
• Basis for design, coding, testing, A Data Flow Diagram (DFD) is a
and maintenance graphical representation that shows
how data flows through a system, how
Standard Structure of an SRS (IEEE- it is processed, and where it is stored.
style) It focuses on what happens to data, not
how the system is implemented.
Introduction
Purpose of DFD
Purpose of the document.
• Understand system functionality
Scope of the system.
• Visualize data movement
Definitions, acronyms, abbreviations
• Improve communication between
References.
users & developers
Overview of the document.
• Help in requirement analysis and
Overall Description
system design
Product perspective.
Basic Components (Symbols)
Product functions (high-level).
User characteristics. Process (○ / Rounded rectangle)
• Transforms input data into output
Operating environment.
• Example: Process Order
Design & implementation constraints.
Assumptions and dependencies. Data Flow (→ Arrow)
• Shows movement of data
Specific Requirements
• Example: Order Details
a) Functional Requirements
Detailed system functions Data Store (║ ║ or Open rectangle)
Inputs, processing, outputs • Stores data temporarily or
Use cases / scenarios permanently
b) Non-Functional Requirements • Example: Customer Database
 External Entity (▭ Rectangle) Data Flow – Movement of data between
• Source or destination of data components
• Example: Customer, Bank Types of Architectural Design
Levels of DFD Layered Architecture
Level 0 – Context Diagram System is divided into layers.
• Highest-level view Example:
• Entire system shown as one Presentation Layer
process Business Logic Layer
• Shows interaction with external Data Layer
entities Easy to maintain
Very common exam question Widely used in web applications
Level 1 DFD Client–Server Architecture
• Breaks Level 0 process into sub- Client requests services and server
processes responds.
• Shows data stores and detailed Example:
flows Web browser → Web server → Database
Level 2 (and beyond) Centralized control
• Further decomposition of Level 1 Easy data management
processes MVC Architecture (Model–View–
• Used for complex systems Controller)
Model – Data
Architectural Design View – User Interface
Definition Controller – Logic
Architectural Design is the process of Used in web applications
defining the overall structure of a Improves code reusability
software system, including its Microservices Architecture
components, their relationships, and System is divided into small independent
how they interact with each other. services.
It acts as a blueprint for software High scalability
development. Easy deployment
Objectives of Architectural Design Complex management
Define system structure clearly Example: Architectural Design of Library
Improve system performance Management System
Ensure scalability and reliability User Interface
Reduce development complexity ↓
Support future modifications Application Logic
Components of Architectural Design ↓
Components – Individual modules of the Database
system Explanation:
Connectors – Communication between UI handles user interaction
components Application logic processes requests
Interfaces – Interaction between system Database stores books, users, and
and users records
Component Level Design Step-by-step logic used inside a
component.
Definition Example:
Component Level Design is the phase of Validation logic
software design where the internal Calculation logic
structure of each module (component) is
defined in detail.
It explains: USER INTERFACE (UI) DESIGN
How a component works
What functions it performs Definition
How it interacts with other components User Interface Design refers to designing
It is done after architectural design and the screens, layouts, buttons, and
before coding. interactions through which users interact
with a software system.
It focuses on usability, simplicity, and
Objectives of Component Level
user experience.
Design
Convert design into implementable form
Define classes, methods, and data Objectives of UI Design
structures Make system easy to use
Improve code reusability Improve user satisfaction
Reduce coding errors Reduce user errors
Make testing easier Provide smooth interaction
Elements of User Interface Design
Elements of Component Level Input Controls – Text box, button,
Design dropdown
Navigation Components – Menus, links
Components
Information Components – Messages,
Independent modules performing
alerts
specific tasks.
Layout Design – Proper alignment and
Example: Login Module, Payment
spacing
Module
Principles of Good UI Design
Simplicity
Interfaces
Consistency
Define how components communicate
Clarity
with each other.
Fast response
Example:
User-friendly design
login(username, password)
Example
In a Library Management System UI:
Data Structures
Login page
Defines how data is stored and accessed.
Book search page
Example:
Issue/Return page
Arrays
Fine details page
Classes
Databases WEB APPLICATION DESIGN
Web Application Design refers to the
Algorithms process of designing web-based
software systems that work through a Reduce cost of fixing errors later
browser using the internet. Types of Review Techniques
It includes: Informal Review
Frontend design Casual peer checking
Backend logic No defined process or documentation
Database connectivity Quick feedback
Components of Web Application Used for: Notes, small documents,
Design early drafts
Client Side (Frontend) Walkthrough
HTML – structure Author explains the document/code
CSS – styling step by step
JavaScript – interaction Participants ask questions and give
Server Side (Backend) suggestions
Handles logic and processing Moderately structured
Languages: PHP, Java, Python, [Link] Used for: Requirements, design
Database documents
Stores data Common exam question
Examples: MySQL, MongoDB Technical Review (Formal Technical
Web Application Architecture Review – FTR)
User Conducted by a team of technical
↓ experts
Web Browser (UI) Uses a defined agenda and checklist
↓ Focuses on technical correctness
Web Server Used for: Design, architecture,
↓ complex logic
Database
Inspection (Most Formal)
Most rigorous review technique
Review Techniques (Software Roles defined: Moderator, Author,
Engineering) Reader, Recorder
Uses checklists, metrics, and defect logs
Review techniques are systematic No problem-solving—only defect
methods used to evaluate software detection
work products (requirements, SRS, Used for: SRS, critical design, safety
design documents, code, test cases) to systems
detect errors early, improve quality, and Highest defect detection rate
reduce rework.
Management Review
They are a key part of quality assurance
Conducted by project managers
(QA).
Focus on:
Objectives of Reviews Schedule
Detect defects early Cost
Ensure compliance with standards (IEEE, Progress
company rules) Resource usage
Improve clarity, correctness, and
Used for: Project control, milestones
completeness
SQA (Software Quality Assurance) Verification and Validation (V & V)

Software Quality Assurance (SQA) is a

planned and systematic set of activities
that ensures the software development
process and the final product meet
specified requirements, standards, and
procedures.
Focuses on preventing defects, not
just finding them.

Objectives of SQA
Ensure high-quality software
Improve development processes Verification
Ensure compliance with standards (IEEE, Question it answers:
ISO, etc.) Are we building the product right?
Detect errors early in SDLC Meaning:
Increase customer satisfaction Verification checks whether work
products (SRS, design, code) conform to
SQA Activities specifications and standards.
Quality Planning Nature:
Define quality goals Static process (no execution of code)
Select standards, methods, tools Done during development
Prepare SQA plan Techniques:
Reviews
Process Definition & Implementation Walkthroughs
Define software processes Inspections
Ensure teams follow standard procedures Static analysis
Example:
Reviews & Audits Checking whether the SRS follows IEEE
Review SRS, design, code, test cases standards.
Conduct formal technical reviews
Perform process audits Validation
Question it answers:
Testing Support Are we building the right product?
Ensure proper testing strategies Meaning:
Verify test plans and test cases Validation checks whether the final
Support validation & verification
software meets user needs and
expectations.
Configuration Management Nature:
Control changes in software artifacts
Dynamic process (requires execution)
Version control and baselines
Done after or near completion
Techniques:
Defect Tracking & Reporting
System testing
Log defects
Acceptance testing
Analyze root causes
User testing
Suggest corrective actions
Alpha & beta testing Objectives of a Software Quality
Example: Framework
Testing whether the software performs Deliver reliable, secure, and
tasks the user actually wants. maintainable software
Prevent defects rather than only
detecting them
Verification vs Validation (Very Standardize development and QA
Important ) processes
Ensure continuous quality improvement
Basis Verification Validation

Correctness Correctness Core Components of Software

Focus Quality Framework
of process of product
Quality Model
Are we Are we Defines quality attributes of software.
Question building it building the Common attributes:
right? right thing? Functionality
Reliability
Type Static Dynamic Usability
Efficiency
Documents, Executing the Maintainability
Involves
code reviews software Portability
(These attributes act as quality goals.)
Performed Developers / Testers /
by QA team Users Quality Processes
Processes followed to achieve quality:
User
SRS Requirement engineering
Example acceptance
inspection Design reviews
testing Coding standards
Software Quality Framework Testing
Maintenance
A Software Quality Framework is a Quality Assurance (SQA)
structured approach that defines quality Process-oriented activities
goals, processes, standards, activities, Reviews, audits, standards compliance
and metrics to ensure that a software Ensures correct processes are followed
product meets user requirements and Quality Control (QC)
quality expectations throughout the Product-oriented activities
SDLC. Testing, inspections, defect detection
Ensures correct product is delivered
In simple words:
It answers what quality means, how to Standards & Procedures
achieve it, and how to measure it. IEEE standards
ISO standards
Organizational guidelines
Documentation and coding standards
Framing an SQA Plan
Framing an SQA Plan means Define Review & Audit Procedures
systematically preparing a document that Type of reviews (walkthrough, inspection)
defines how quality will be assured Frequency of audits
during software development—who does Checklists and reporting format
what, when, how, and using which
standards/tools. ISO 9000 medels
The ISO 9000 models are part of the ISO
Step-by-Step Procedure to Frame an 9000 family of standards, which provide
SQA Plan guidelines and requirements for Quality
Understand the Project & Scope Management Systems (QMS) to ensure
Study project objectives, size, and consistent quality in products and
complexity services.
Identify deliverables and constraints These standards are published by
Decide the scope of quality assurance International Organization for
Standardization (ISO).
Define Quality Objectives
Set measurable quality goals Purpose of ISO 9000 Models
Reliability Ensure consistent quality
Performance Improve customer satisfaction
Security Standardize organizational processes
Maintainability Support continuous improvement
Align goals with customer expectations
Major ISO 9000 Models (Exam-
Identify Applicable Standards Oriented)
Select standards to be followed: ISO 9000 – Fundamentals &
Documentation standards Vocabulary
Coding standards Describes basic concepts and terminology
Testing standards Acts as a reference guide
Ensure compliance with No certification (informational standard)
organizational/industry norms Used to understand quality terms

Define Organization & Responsibilities ISO 9001 – Quality Management

Assign roles: System (MOST IMPORTANT )
SQA Manager Specifies requirements for a QMS
Developers Applicable to software, manufacturing,
Testers services
Reviewers Only ISO 9000 model used for certification
Clearly define authority and responsibility Key focus areas:
Customer focus
Plan SQA Activities Leadership
Specify what quality activities will be Process approach
performed: Continuous improvement
Reviews & inspections (SRS, design, code) Very frequently asked in exams
Audits Main Components of ISO 9000
Testing support Quality Management System (QMS)
Process monitoring
Establish, document, implement, and SEI CMM (Capability Maturity Model) is a
maintain a QMS process improvement framework
Includes quality manual, procedures, and developed by the Software Engineering
records Institute (SEI) to assess and improve the
Focus on process-based approach software development maturity of an
organization.
Management Responsibility It focuses on how well software
Top management commitment processes are defined, managed,
Quality policy & quality objectives measured, and optimized.
Responsibility, authority, and Objectives of SEI CMM
communication Improve software process quality
Management review of QMS Reduce project risks
Leadership is mandatory Increase predictability of cost & schedule
Deliver consistent and reliable software
Resource Management Five Maturity Levels of SEI CMM (VERY
Human resources (skills, training, IMPORTANT )
competence) Level 1 – Initial
Infrastructure (hardware, software, tools) Processes are ad hoc and chaotic
Work environment Success depends on individual effort
Ensures resources needed for quality No defined standards
High risk, unpredictable outcomes
Product / Service Realization
Planning of product realization Level 2 – Repeatable
Customer-related processes Basic project management practices
Design & development established
Purchasing Past successes can be repeated
Production & service delivery Focus on cost, schedule, and requirements
Core operational activities management
Projects are planned and tracked
Measurement, Analysis, and Level 3 – Defined
Improvement Processes are documented, standardized,
Monitoring & measurement and integrated
Internal quality audits Organization-wide software processes
Control of non-conforming products Training programs exist
Corrective and preventive actions Proactive and consistent approach
Continuous improvement
Level 4 – Managed
Heart of quality improvement Processes are quantitatively measured
Quality and performance metrics used
Documentation & Records Predictable outcomes
Quality manual Data-driven management
Procedures and work instructions
Level 5 – Optimizing
Records for traceability and accountability
Focus on continuous process
“Say what you do, do what you say” improvement
Defect prevention and innovation
SEI CMM (Capability Maturity Model) Uses feedback and advanced techniques
Best-in-class maturity
Unit Testing combined and tested as a group to verify
Unit Testing is a software testing that they interact correctly with each
technique in which individual units or other.
components of a program (such as Focus: Interfaces, data flow, and
functions, methods, or classes) are tested interaction between modules
independently to verify that they work
correctly. Objectives of Integration Testing
A unit is the smallest testable part of Detect interface defects
software. Verify data flow between modules
Ensure combined modules work as
Objectives of Unit Testing expected
Verify correctness of individual modules Identify issues missed during unit testing
Detect bugs early
Simplify debugging When Is Integration Testing Done?
Ensure each unit works as expected before After unit testing
integration Before system testing

Who Performs Unit Testing? Types of Integration Testing (Very

Usually done by developers Important )
Performed during the coding phase Top-Down Integration Testing
Testing starts from top-level modules
Unit Testing Process Lower-level modules are replaced by stubs
Identify the unit (function/module) Advantages:
Design test cases Early testing of main control logic
Prepare test data No need for drivers
Execute the unit Disadvantages:
Compare actual output with expected Lower modules tested late
output
Fix defects and re-test Bottom-Up Integration Testing
Testing starts from low-level modules
Upper-level modules are replaced by
Types of Unit Testing
drivers
White-Box Unit Testing
Advantages:
Tests internal logic and code structure
Core functionality tested early
Techniques:
No need for stubs
Statement coverage
Disadvantages:
Branch coverage
System behavior seen late
Path coverage
Sandwich (Hybrid) Integration Testing
Black-Box Unit Testing
Combination of Top-Down and Bottom-Up
Tests functionality without looking at
Middle layer tested first
internal code
Advantages:
Based on inputs and outputs only
Balanced approach
Faster fault isolation
Integration Testing
Integration Testing is a software testing
Big Bang Integration Testing
technique in which individual modules are
All modules integrated at once Contract Acceptance Testing
Tested as a whole Verifies system meets contractual
Advantages: requirements
Simple to implement Regulatory Acceptance Testing
Disadvantages: Ensures compliance with legal and
Very difficult debugging regulatory standards
High risk
Acceptance Testing
Acceptance Testing is a formal testing Regression Testing
process performed to determine whether Regression Testing is a software testing
a software system meets user technique performed to ensure that
requirements and business needs, and recent code changes (bug fixes,
whether it is ready for delivery or enhancements, new features) have not
deployment. negatively affected existing functionality.
It answers the key question: In simple terms:
“Is the software acceptable to the user?” “Did the change break something that was
Objectives of Acceptance Testing already working?”
Verify software against user requirements
Ensure system is fit for real-world use Objectives of Regression Testing
Build customer confidence Verify existing features still work correctly
Decide go / no-go for release Detect side effects of code changes
Maintain software stability
Who Performs Acceptance Testing? Ensure quality after updates
End users
Customers When Is Regression Testing Needed?
Business representatives After bug fixes
(with support from testers or developers) After adding new features
After code refactoring
When Is Acceptance Testing Done? After environment or configuration
After system testing changes
Before final deployment
Types of Regression Testing
Types of Acceptance Testing (Very Corrective Regression Testing
Important ) When no major changes in code
User Acceptance Testing (UAT) Existing test cases are reused
Performed by end users Selective Regression Testing
Confirms system meets business Only a subset of test cases is executed
requirements Saves time and effort
Progressive Regression Testing
Alpha Testing When new features are added
Conducted at developer’s site New test cases are designed along with
Users test the system in a controlled old ones
environment Complete Regression Testing
Beta Testing Entire test suite is executed
Conducted at customer’s site Used before major releases
Real users test in a real environment
Top-Down Integration Testing Top-Down Bottom-Up
Concept: Basis
Testing Testing
Testing starts from the top-level (main Starting Top-level Lowest-level
control) module and progresses point module module
downward to lower-level modules.
Test aids Stubs Drivers
How it works
Top module is tested first Control
Tested early Tested late
Lower modules are replaced with stubs logic
(temporary dummy modules) System
Visible early Visible late
Gradually, stubs are replaced with real behavior
modules Fault
Moderate Easy
Advantages isolation
Early testing of main control logic Strong core
No need for drivers Use case Early demo
testing
Early system behavior visible
Disadvantages Text Drivers
Lower-level modules tested late A Test Driver is a temporary piece of code
Writing stubs can be complex used in software testing to call and test a
Suitable when lower-level module when the higher-level
High-level logic is critical modules are not yet developed.
Early demonstration is needed Think of a test driver as a fake calling
program.
Bottom-Up Integration Testing
Concept: Why Test Drivers Are Needed
Testing starts from the lowest-level During Bottom-Up Integration Testing,
modules and moves upward to higher- low-level modules are ready first, but:
level modules. The higher-level modules that should call
How it works them don’t exist yet
Low-level modules are tested first So, test drivers are written to:
Higher-level modules are replaced with Invoke the lower-level module
drivers Pass test data
Drivers are removed as real modules are Collect and display output
integrated
Advantages What a Test Driver Does
Core functionality tested early A test driver typically:
No need for stubs Calls the module under test
Easier fault isolation Supplies input values
Disadvantages Receives output results
System behavior visible late Displays or logs the results
Writing drivers is required Where Test Drivers Are Used
Suitable when Bottom-Up Integration Testing
Low-level utility modules are critical Unit testing (sometimes)
Stable foundation is required Early testing of utility or core modules

Top-Down vs Bottom-Up (Exam- Test Stubs

Friendly Table )
A Test Stub is a temporary, dummy LOC (Lines of Code)
module used in integration testing to Number of classes
replace a lower-level module that is not Number of functions/modules
yet developed. Used for effort and cost estimation
It responds to calls from the module
under test with predefined (fake) data. Function-Oriented Metrics
Measure functionality delivered to the
Why Test Stubs Are Used user.
When using Top-Down Integration Testing: Examples:
Higher-level modules are ready Function Points (FP)
Lower-level modules are not implemented Feature count
yet Use-case points
So, test stubs are created to: Language-independent
Simulate the behavior of lower modules
Allow testing of upper modules early Quality Metrics
Measure product quality and reliability.
What a Test Stub Does Examples:
A test stub: Defect density = defects / KLOC
Is called by the module under test Mean Time Between Failures (MTBF)
Accepts parameters Failure rate
Returns hard-coded or simple outputs Indicates reliability
Does not contain full logic
Performance Metrics
Where Test Stubs Are Used Measure execution efficiency.
Top-Down Integration Testing Examples:
Early system-level testing Response time
Interface testing Throughput
Memory usage
CPU utilization
Product Metrics
Product Metrics are quantitative measures
used to evaluate the quality, size, Maintainability Metrics
performance, and characteristics of a Measure ease of maintenance and
software product. modification.
They focus on the software itself, not the Examples:
process or people. Cyclomatic complexity
Code churn
Change request frequency
Objectives of Product Metrics
Measure software quality
Estimate effort, cost, and maintenance Usability Metrics
Identify defects and improvement areas Measure user experience.
Compare products or versions objectively Examples:
Error rate
Task completion time
Types of Product Metrics
User satisfaction score
Size-Oriented Metrics
Measure software size.
Examples:
Risk Management (Software Engineering) Transfer – Shift risk (outsourcing,
Risk Management is the systematic insurance)
process of identifying, analyzing, Accept – Acknowledge and monitor
prioritizing, and controlling risks that may
negatively affect a software project’s cost, Risk Monitoring & Control
schedule, quality, or scope. Continuously track identified risks
Simple idea: Identify problems before Identify new risks
they become disasters. Execute mitigation plans
Update risk status
Objectives of Risk Management Risk management is a continuous
Minimize project failures activity
Reduce uncertainty
Improve planning and decision-making Types of Risks (Exam-Focused)
Ensure timely and quality delivery Project Risks
Schedule slippage
Steps in Risk Management (Very Budget overrun
Important ) Resource issues
Risk Identification Technical Risks
Identify possible risks that may occur. New or unproven technology
Common software risks: Integration problems
Requirement changes Performance issues
Schedule delays Business Risks
Cost overrun Market changes
Technical complexity Customer dissatisfaction
Lack of skilled resources Product cancellation
Output: List of potential risks
Project Scheduling.
Risk Analysis Project Scheduling is the process of
Evaluate each risk based on: planning, organizing, and controlling
Probability (likelihood of occurrence) project tasks by deciding what work will
Impact (severity of damage) be done, when it will be done, and in what
Often represented using a Risk order, so the project finishes on time and
Exposure formula: within budget.
Risk Exposure = Probability × Impact In short: Right task → Right time →
Right order
Risk Prioritization
Rank risks as High, Medium, or Low Objectives of Project Scheduling
Focus first on high-probability, high-impact Complete the project within deadline
risks Optimize use of resources
Helps in effective resource allocation Identify critical activities
Track and control project progress
Risk Planning (Risk Mitigation) Reduce delays and risks
Decide actions to handle risks.
Risk strategies: Steps in Project Scheduling (Very
Avoid – Change plan to remove risk Important )
Mitigate – Reduce probability or impact Identify Project Tasks
Break the project into small activities Example: updating app for new Android
Use Work Breakdown Structure (WBS) version
Perfective Maintenance
Determine Task Dependencies Improves performance or usability
Identify which tasks depend on others Example: faster search, better UI
Decide precedence relationships Preventive Maintenance
Improves maintainability
Estimate Time for Each Task Example: code refactoring, documentation
Estimate duration using: updates
Expert judgment
Past project data Advantages
PERT estimation Extends software life
Keeps users satisfied
Allocate Resources Improves reliability
Assign developers, testers, tools, etc. Problems
Avoid over-allocation Poor documentation
High cost over time
Create the Schedule Complexity of old code
Prepare schedule using charts and
networks Software Re-engineering
Identify start and finish dates Software Re-engineering is the process of
analyzing and modifying existing software
Monitor & Update Schedule to improve its structure, maintainability,
Track progress or performance, without changing its core
Update schedule for delays or changes functionality.
Software Maintenance Goal: Improve the internal quality of
Software Maintenance is the process of old software
modifying and updating software after
delivery to keep it useful, correct, and Re-engineering Activities
efficient. Inventory Analysis
Typically consumes 60–80% of total Decide which systems need re-engineering
software cost. Reverse Engineering
Objectives Understand existing code & design
Fix defects Extract higher-level abstractions
Improve performance Code Restructuring
Adapt to new environments Improve code readability and structure
Enhance features
Data Restructuring
Improve database schema
Types of Software Maintenance (VERY
Forward Engineering
IMPORTANT ) Rebuild system using improved design
Corrective Maintenance
Fixes bugs and errors
Example: fixing login failure
Adaptive Maintenance
Adapts software to new OS, hardware,
laws
Structural Testing (White-Box Testing) Ensures all possible execution paths are
Structural Testing is a software testing tested
technique that focuses on the internal Most thorough but complex
structure of the code—its statements, Goal: Execute every unique path
branches, paths, and logic.
It is commonly known as White-Box Loop Coverage
Testing. Tests loops for:
Core idea: Test the code from the Zero iteration
inside. One iteration
Multiple iterations
Objectives of Structural Testing Goal: Validate loop behavior
Verify internal logic of the program
Ensure all code paths are executed Functional Testing (Black-Box Testing)
Detect hidden errors in logic and control Functional Testing is a software testing
flow technique that verifies whether the
Improve code coverage functions of a software system work
according to specified requirements.
What Is Tested? It focuses on what the system does, not
Statements how it is implemented.
Decision points (if/else, switch) Also called Black-Box Testing.
Loops
Conditions Objectives of Functional Testing
Paths in the program Validate software behavior against SRS /
requirements
Types of Structural Testing (Very Ensure correct input–output behavior
Important ) Detect missing or incorrect functionality
Statement Coverage Confirm user-visible features work
Ensures every statement is executed at properly
least once
Weak coverage (may miss logic errors) What Is Tested?
Goal: Execute all lines of code User actions (login, search, submit)
Business rules
Branch (Decision) Coverage Input validations
Ensures each decision outcome Error messages
(true/false) is tested Output results
Better than statement coverage
Goal: Test all branches Types of Functional Testing (Very
Important )
Condition Coverage Unit Functional Testing
Tests individual boolean conditions in Tests individual functions or methods
decisions Focus on functional correctness
Useful when conditions are complex
Goal: Each condition is true and false Integration Functional Testing
at least once Tests interaction between modules from a
functional perspective
Path Coverage
 System Testing Identify features and constraints
Tests the complete integrated system
Verifies end-to-end functionality Estimate Software Size
Common measures:
Acceptance Testing LOC (Lines of Code)
Validates software against user requirements
Function Points (FP)
Includes UAT, Alpha, Beta testing
Use Case Points
Functional Structural
Basis Estimate Effort
Testing Testing
Effort = Size × Productivity
What system How system Measured in person-months
Focus
does works Estimate Cost
Cost = Effort × Cost per person-month
Code Estimate Schedule
Not required Required
knowledge Decide project duration
Allocate tasks over time
Testing type Black-box White-box
Estimation Techniques (VERY
Requirements Program IMPORTANT )
Based on
(SRS) logic Expert Judgment
Based on experience of experts
Simple but subjective
Estimation for Software Project
Estimation by Analogy
Software Project Estimation is the process
Compare with similar past projects
of predicting the effort, cost, time, and
More accurate if history exists
resources required to develop a software
system before development starts. LOC-Based Estimation
Based on estimated Lines of Code
In simple words:
Language dependent
How much? How long? How many
people? Function Point (FP) Estimation
Based on system functionality
Objectives of Software Project
Language independent
Estimation
Considers:
Plan project schedule
Inputs
Estimate cost and effort
Outputs
Allocate resources effectively
Files
Reduce risk of overrun and failure
Interfaces
Support management decisions
Queries
What Is Estimated?
Widely used in industry
Size of the software
COCOMO Model (Constructive Cost
Effort (person-months)
Model)
Cost (money) Algorithmic estimation model.
Time / Schedule Basic COCOMO:
Resources (people, tools) Organic
Semi-detached
Steps in Software Project Estimation Embedded
(Exam-Oriented ) Effort = a × (KLOC)^b
Understand Project Scope
Analyze requirements (SRS)