MODULE 03

SYLLABUS: Coding, Testing and Maintenance: Coding guidelines - Code review, Code walkthrough and Code
inspection, Code debugging and its methods. Testing - Unit testing , Integration testing, System testing and its
types, Black box testing and White box testing, Regression testing Overview of DevOps and Code Management -
Code management, DevOps automation, Continuous Integration, Delivery, and Deployment (CI/CD/CD), Case
study – Netflix. Software maintenance and its types- Adaptive, Preventive, Corrective and Perfective maintenance.
Boehm’s maintenance models (both legacy and nonlegacy)

CODING
Coding (Construction) is the process of transforming software design into executable source code
using a programming language.
→ It is the phase where design decisions are converted into reality.

Coding Guidelines
Coding guidelines are standard rules and conventions followed while writing code to ensure
quality, consistency, readability, and maintainability. They are essential because most software cost
is spent after development, during maintenance.

Need for Coding Guidelines

Without guidelines:
• Code becomes difficult to understand
• Debugging becomes complex
• Maintenance cost increases
• Error probability increases
With guidelines:
• Uniform coding style
• Fewer logical errors
• Easier reviews and inspections
• Faster testing and debugging
Common Coding Guidelines
(a) Naming Guidelines
• Use meaningful variable and function names
• Avoid single-letter variable names (except loop counters)
• Function names should describe actions (e.g., calculateTotal())
(b) Layout and Formatting
• Proper indentation
• Consistent spacing
• Clear block structures
(c) Modularity
• One function should perform one task
• Avoid long functions
• Improve reusability and testability
(d) Commenting
• Use comments to explain logic and purpose
• Avoid obvious comments
• Update comments when code changes
(e) Error Handling
• Handle all possible error conditions
• Avoid ignoring exceptions
• Provide meaningful error messages

Code Review, Walkthrough And Inspection

These are static verification techniques (code is not executed).
1. Code Review
Code review is an informal or semi-formal evaluation of source code by peers to identify defects and
improve quality.
Characteristics
• Conducted by team members
• Focus on logic, standards, and correctness
• Less formal than inspection
Advantages
• Early defect detection
• Improves code quality
• Knowledge sharing

2. Code Walkthrough
A code walkthrough is a developer-led meeting (not formal) where the author explains the code to
reviewers.
Process
1. Developer presents code
2. Logic is explained step-by-step
3. Reviewers ask questions and suggest improvements
Purpose
• Improve understanding
• Identify logical mistakes
• Training and knowledge transfer
3. Code Inspection
Code inspection is a formal, systematic, and structured review process aimed at detecting defects.
Roles in Code Inspection
Role Responsibility
Moderator Controls inspection process
Author Writes the code
Reviewer Detects defects
Recorder Documents defects

Steps in Code Inspection

1. Planning
2. Overview meeting
3. Preparation
4. Inspection meeting
5. Rework
6. Follow-up

Feature Review Walkthrough Inspection

Formality Low Medium High
Defined roles No No Yes
Documentation Minimal Minimal Detailed
Defect detection Moderate Moderate High

Code Debugging And Its Methods

Debugging is the process of locating, analyzing, and correcting errors discovered during testing.
→ Testing identifies errors, while debugging removes them.

Why Debugging is Difficult?

Debugging is challenging because:
1. Error cause may be far from the symptom
2. Fixing one error may temporarily hide another
3. Errors may be caused by unexpected system conditions
4. Human mistakes may be difficult to trace
5. Timing issues may cause unpredictable behavior
6. Input conditions may be hard to reproduce
7. Errors may appear intermittentlys
8. Bugs may be distributed across multiple modules
Debugging Process
1. Execute test cases
2. Compare expected and actual results
3. Identify the error symptoms
4. Locate the root cause of the error
5. Correct the defect
6. Perform regression testing to ensure no new errors
occur

→ Debugging continues until the error is eliminated.

Debugging Strategies
Three major debugging strategies are commonly used.
1. Brute Force Method
The developer examines large amounts of information such as:
• The programmer adds many print statements (trace messages) in the code.
• Observes intermediate outputs to check where the program behaves unexpectedly.
• Sometimes the programmer dumps the entire program memory or variables to analyze.
This method may eventually find the bug but is time-consuming and inefficient.

2. Backtracking Method
Debugging starts at the point where the error appears and traces the program backward to locate the cause.
This approach works well for small programs.

3. Cause Elimination Method

Possible causes of the error are listed and systematically tested.
Two approaches are used:
A. Induction Approach: Start from observed error/output → analyze data → identify possible causes
Steps
• Observe incorrect output
• Collect related data (inputs, logs, variables)
• Form possible causes (hypotheses)
Example: Program prints wrong total price
• Observed: Total = 500 (should be 300)
• Check: Input values, Calculation formula, Loop execution
Possible causes:
• Wrong formula
• Duplicate addition
• Incorrect input
→ These are identified by analyzing data (induction)
B. Deduction Approach: Start from all possible causes → eliminate impossible ones step by step
Steps
• List all possible causes
• Test each condition
• Remove causes that are not valid
Example: Same problem: wrong total price

Possible causes:
• Wrong formula (checked and verified correct)
• Duplicate loop execution (still possible)
• Input error (checked and verified inputs correct)
→ Remaining cause = loop running twice

SOFTWARE TESTING
Software testing is the process of executing a program with the intention of finding errors.

The purpose of testing is to:

• Detect errors in software
• Ensure the software meets user requirements
• Improve reliability and quality
Software Testing Can be Divided into Two Steps:

Verification and Validation (V&V)

Verification: This step involves checking if the software is doing what is supposed to do.
Question: Are we building the product right?
Validation: This step verifies that the software actually meets the customer's needs and requirements.
Question: Are we building the right product?

Levels of Software Testing

Testing is performed in several stages. Testing proceeds from small to large:
1. Unit Testing
2. Integration Testing
3. System Testing
4. Regression Testing
Types of Testing

We’re studying:
1. Black-box Testing
2. White-box Testing
Black Box Testing and White Box Testing are NOT types or levels of testing. They are testing approaches
(techniques/strategies) used to design test cases.
3. Unit Testing
4. Integration Testing
5. System Testing
6. Regression Testing

A. Black Box Testing

Black Box Testing is a functional (behavioral) testing technique where the tester does not know
internal code/logic and tests the system based only on inputs and outputs.
Tester’s View
System is treated as a “black box”
→ Only input → output is visible
→ Internal working is hidden
Objective: To verify whether the software meets functional requirements (SRS).
Example: Login system:
• Input → username, password
• Output → login success / error message
Tester checks:
• Valid input → login success
• Invalid input → error
(No knowledge of how authentication works internally)
Focus Areas
• Input validation
• Output correctness
• Functional behavior
• User interface
• Error handling
Advantages
• No need for programming knowledge
• Test cases based on requirements (unbiased)
• Effective for validation testing
Disadvantages
• Cannot detect internal logic errors
• Limited code coverage
• Not suitable for complex logic testing

B. White Box Testing

White Box Testing is a structural testing technique where the tester has complete knowledge of internal
code and logic.
Tester’s View
System is treated as a “transparent box” → Internal code, paths, and logic are visible
Objective: To verify internal logic, control flow, and code correctness.
Example Login function: Tester checks code:
if(username == correct && password == correct)
login success
else
error

Test cases:
• Correct username + password
• Wrong password
• Empty input
• Edge cases
Focus Areas
• Code structure
• Branch and path coverage
• Conditions and loops
• Internal data flow
Advantages
• Detects hidden logical errors
• Ensures high code coverage
• Helps in optimization
Disadvantages
• Requires programming knowledge
• Time-consuming
• Not suitable for high-level functional testing
Cyclomatic Complexity
Cyclomatic Complexity is a software metric that measures the number of independent paths through a
program’s control flow. It indicates the program’s complexity and helps determine the minimum number
of test cases required for complete testing.

V(G) = E − N + 2P
• E = Number of edges in control flow graph
• N = Number of nodes
• P = Number of connected components (usually 1)

Simplified (for most programs):

Cyclomatic Complexity = Number of decision points + 1
(decision points: if, while, for, case, etc.)

Example
If a program has 3 decision statements,
Cyclomatic Complexity = 3 + 1 = 4
Importance
• Measures code complexity
• Helps in test case design
• Higher value → more complex, harder to maintain

Comparison b/w Black-box & White-box Testing

Aspect Black Box Testing White Box Testing
Knowledge of code Not required Required
Focus Functionality Internal logic
Type Behavioral Structural
Performed by Tester Developer
Coverage Low High
Example Login validation Checking login code logic

1. Unit Testing
Unit Testing is the process of testing individual units (functions/methods) to verify that they work
correctly as per intended logic.
Performed By: Developers during the coding phase

Focus
• Internal logic of functions
• Input–output correctness
• Boundary conditions and exceptions
Example: Function: add(a, b)
• Input: (2, 3) → Output: 5
• Input: (0, 0) → Output: 0
Advantages
• Early detection of defects
• Improves code quality
• Increases developer confidence
• Faster development and debugging
• Reduces later testing cost
Disadvantages
• Time and effort required
• Depends on developer skill
• Difficult for complex units
• Cannot test module interactions
• Not suitable for UI testing

Unit Testing Techniques

1. Functional Techniques

(a) Boundary Value Analysis (BVA)

Concept: Test values at boundaries of input range
Example: Age range = 18–60
Test → 17, 18, 19, 59, 60, 61
Key Point: Errors often occur at boundaries
(b) Equivalence Partitioning (EP)
Concept: Divide inputs into groups; test one value from each
Example: Consider a password validating case:
Partition Example
< 8 (Invalid) 6 characters
8–16 (Valid) 10 characters
> 16 (Invalid) 20 characters
Key Point: Reduces number of test cases

2. Structural Techniques

(a) Statement Coverage

Concept: Execute every statement at least once
Example:
if (x > 0)
y = 4;
z = 5;

If input x = 1 → all lines executed

(b) Branch Coverage
Concept: Test all decision outcomes (true & false)
Example:
if (x > 0)
y = 1;
x = 7 → true branch
else y = -1;
x = -2 → false branch
2. Integration Testing
Integration Testing verifies interaction between modules and ensures correct data flow across interfaces.
When Performed: After unit testing, before system testing

Focus
• Interfaces between modules
• Data exchange
• Control flow
Need (Why Important)
• Modules may work individually but fail when combined
• Interface errors are common
• Data inconsistency may occur
Types of Integration Testing
Type Description Key Feature Example
Simple setup but
All modules are integrated Testing a complete e-commerce app
Big Bang difficult to isolate
and tested at once (UI + payment + database) in one go
errors
Modules are integrated and Easier debugging and First test login module, then
Incremental
tested step-by-step error isolation integrate with dashboard
Testing starts from top- Uses stubs for lower
Test main menu before actual
Top-Down level modules and moves modules not yet
payment module is ready
downward developed
Testing starts from low-
Uses drivers for Test database functions before
Bottom-Up level modules and moves
higher modules integrating with UI
upward
Large system where UI and database
Sandwich Combination of top-down Parallel testing from
are tested simultaneously before full
(Hybrid) and bottom-up approaches top and bottom levels
integration

Unit vs Integration Testing

Aspect Unit Testing Integration Testing
Scope Single module Multiple modules
Focus Internal logic Interaction between modules
Performed by Developer Developer/Tester
Stage During coding After unit testing
Goal Verify unit correctness Verify interface correctness

3. System Testing
System Testing is the testing of a complete and integrated system as a whole to verify that it meets
specified requirements (functional + non-functional).
Key Characteristics
• End-to-end testing of the application
• Performed in production-like environment
• Validates both functional and non-functional requirements
Objectives
• Verify system meets requirements (SRS)
• Validate overall system behavior
• Detect defects missed earlier
• Ensure proper integration of all modules
• Evaluate performance, security, usability
System Testing Process
1. Test Environment Setup: Create environment similar to real system
2. Test Case Design: Prepare test scenarios
3. Test Data Preparation: Create input data
4. Test Execution: Run test cases
5. Defect Reporting: Identify and record defects
6. Regression Testing: Check side effects of fixes
7. Fix & Retest: Fix bugs and test again

Types of System Testing

Type Purpose Key Focus Example
Verify features work as per Login works only for valid
Functional Testing Correct functionality
requirements users
Performance Check system performance Website response with
Speed, response time
Testing under load 1000 users
Ensure system and data are Authentication, Unauthorized access is
Security Testing
protected authorization blocked
Evaluate ease of use and user Easy navigation for a new
Usability Testing User-friendliness
experience user
Compatibility Verify system works across Works on Chrome,
Browsers, OS, devices
Testing environments Firefox, mobile
Check system recovery after Data restored after system
Recovery Testing Backup, restoration
failure crash
Stress / Load Test system under E-commerce site during
Stability under pressure
Testing extreme/heavy load sale peak

4. Regression Testing
Regression Testing is re-running previous test cases to ensure that new changes do not break existing
functionality.
When to Perform
• After adding new features
• After bug fixing
• After code modification/optimization
Regression Testing Process
1. Identify code changes
2. Analyze impact
3. Select affected test cases
4. Define test scenarios
5. Categorize test cases
6. Prioritize (high risk first)
7. Execute tests
Example: Consider an ATM system:
• Original feature: Withdraw cash → working correctly
• Developer fixes a bug in balance calculation
Now perform regression testing:
• Test withdraw again
• Test deposit
• Test balance check
Ensure all old features still work after the fix.

CODE MANAGEMENT
Code management is a set of practices and tools used to manage source code changes in a
collaborative environment, ensuring: Multiple developers can work safely, Versions are controlled,
Code can be built and tested easily

Key Features
1. Check-In / Check-Out
• Developers download (check-out) code, modify, then upload (check-in)
• Prevents overwriting others’ work
2. Version Control
• Each change creates a new version
• Older versions can be restored
3. Branching & Merging
• Work done in separate branches
• Later merged into main code
4. Metadata (Version Info)
Stores:
• Who made change
• When
• What changed
5. Release Identification
• Each version has unique ID (commit/tag)
• Helps track releases
6. Change History
• Maintains record of all updates
• Helps debugging and tracking
7. Parallel Development
• Multiple developers work simultaneously
• System manages conflicts
8. Project Support
• Entire project can be built/tested together
9. Storage Optimization
• Stores only changes (not full copies) → efficient

Tools
• Git (distributed version control)
• GitHub / GitLab / Bitbucket (collaboration + CI/CD)
• SVN (centralized system)

DevOps
DevOps is a software development approach that integrates development (Dev) and operations
(Ops) to enable continuous development, testing, deployment, and maintenance of software.

Traditional Approach
Separate teams:
• Development → builds software
• Release → prepares build
• Support → handles users
• Maintenance → fixes issues
Issues:
• Communication gaps
• Delays in release
• Lack of accountability
• Slow bug fixing
DevOps Approach
• Single cross-functional team
• Continuous collaboration across: Development, Testing, Deployment, Support
• Eliminates delays and improves efficiency

The image illustrates the DevOps lifecycle,

showing the continuous integration of
development (Dev) and operations (Ops) through
an infinity loop. It includes stages like plan, code,
build, test, release, deploy, operate, and
monitor, emphasizing continuous feedback and
improvement. Dev focuses on coding,
automation, and testing, while Ops handles
deployment, configuration, and monitoring using
tools like CI/CD, containerization, and logging.
Overall, DevOps aims to deliver software faster,
improve quality, and ensure reliable system
performance through automation and
collaboration.
Principles of DevOps
1. End-to-End Responsibility
• Entire team is responsible for the system lifecycle
• No separate ownership → better accountability
2. Automation of Processes
• Automate: Build, Testing, Deployment
• Reduces human errors and improves speed
3. Continuous Monitoring & Measurement
• Collect data of Performance metrics, Failure rates
• Use feedback to improve system

Benefits of DevOps
1. Faster Deployment
• Frequent releases (small updates)
• Reduced time-to-market
2. Reduced Risk
• Smaller changes → easier testing
• Continuous testing → early bug detection
3. Faster Recovery
• Issues identified quickly
• Faster debugging and fixing
4. Improved Productivity
• Automation reduces manual work
• Developers focus on innovation

DevOps Automation
Automation in DevOps refers to using tools to automatically perform repetitive tasks in the
software lifecycle.

Activities Automated
• Code building
• Testing
• Deployment
• Monitoring

Ensures: Consistency, Reliability, Speed

Key Components of DevOps Automation

1. Continuous Integration (CI)
Practice of integrating code changes frequently into a shared repository, followed by automatic build and
testing.
2. Continuous Delivery (CD)
• System is always in deployable state
• Tested in staging environment
• Release is manual
3. Continuous Deployment
• Automatic deployment to production
• No human intervention required
4. Infrastructure as Code (IaC)
• Infrastructure managed using code
• Example tools: Ansible, Puppet, Terraform

Continuous Integration (CI)

Continuous Integration (CI) is the process of frequently integrating code changes into a shared
repository, followed by automatic build and testing to detect errors early.
Objective
• Ensure system is always in a working state
• Detect bugs at early stage
• Maintain code quality
Key Characteristics
• Frequent code commits (multiple times/day)
• Automated build process
• Automated testing (unit + integration)
• Immediate feedback to developers

This figure illustrates the Continuous Integration

process where a developer writes code and submits
it to a CI tool. The CI system automatically builds
the application and runs tests on the latest code.
If any problem is detected, feedback is sent back to
the developer for correction. If everything is
successful, the changes are approved and merged
by the maintainer or developer, making the
application ready for deployment. This process
ensures early error detection, improved code
quality, and reliable integration of changes.

Steps in CI

1. Fetch Source Code (GET)

• Trigger: commit / push / merge
• CI server (Jenkins, GitLab CI) detects changes
• Latest code fetched from repository
Inputs:
• Source code files
• Repository trigger
2. Compile and Build
• Source code is compiled
• Dependencies and configurations are applied
Inputs:
• Libraries
• Configuration files
• Database files
Output:
• Executable system (e.g., .exe, .jar)

3. Testing
• Automated tests are executed:
• Unit testing
• Integration testing
Outcome:
• Pass → Deployable system
• Fail → Errors fixed by developer

Developer Local Integration

Steps:
1. Modify code
2. Commit to local repository
3. Pull latest changes from main branch
4. Merge updates locally
5. Build locally
6. Run tests
7. Push to central repository

Integrate Twice Concept

• First integrate & test locally
• Then integrate to shared repository
Prevents breaking the main build

Advantages of CI
• Early bug detection
• Easier debugging (small changes)
• Reduced integration issues
• Improved software quality

2. Continuous Delivery (CD)

Continuous Delivery is a DevOps practice where the system is always kept in a deployable state, but
actual release to users is done manually.
Objective
• Ensure software is always ready for release
• Reduce release risk
• Enable controlled deployment
Key Characteristics
• Automated build and testing
• Deployment to staging (pre-production) environment
• Manual approval before production release
This figure highlights the Continuous Delivery phase, where the application, after successful build and
packaging, moves through the release
pipeline. The packaged software is
deployed to a testing/staging
environment, where further validation
and acceptance testing are performed to
ensure functional correctness,
performance, and stability. Only after all
tests pass, the system becomes ready for
production release, which is done
through a manual decision. Thus,
Continuous Delivery ensures that the
software is always in a deployable state,
enabling reliable and controlled releases
with minimal risk.

Steps in Continuous Delivery

1. Configure Test Server

• Setup environment similar to production
• Configure required software, libraries, settings
Purpose: Safe testing environment

2. Install System on Test Server

• Deploy built application to staging server
Purpose: Validate behavior in real-like environment

3. Run Acceptance Tests

• Test system using predefined test cases
Checks:
• Functional correctness
• Performance
• Stability
• User requirements
If all tests pass → System ready for delivery

Final Step in CD
• Software installed on production servers
• Users switched to new version
Important: Release is manual decision

Advantages of Continuous Delivery

• System always ready for release
• Reduced deployment risk
• Better testing in real-like conditions
• Controlled and reliable releases
3. Continuous Deployment (CDP)
Continuous Deployment is an extension of continuous delivery where every successful change is
automatically deployed to production without manual intervention.
Objective
• Achieve fully automated release process
• Deliver features to users instantly
Key Characteristics
• No manual approval required
• Automatic deployment after tests pass
• Fast release cycles
Process Steps
1. Code is integrated (CI)
2. System passes all tests
3. Automatically deployed to production
4. Users immediately use new version
Advantages of Continuous Deployment
• Faster delivery of features
• Immediate feedback from users
• Reduced manual effort
• Continuous improvement
Risks / Limitations (Important for exams)
• Higher risk if testing is weak
• Requires strong automation and monitoring
• Not suitable for all systems (e.g., critical systems)

Feature Continuous Delivery Continuous Deployment

Release Manual Automatic
Control Human decision Fully automated
State Ready for release Always released
Risk Lower Higher

CASE STUDY: NETFLIX — DevOps & CI/CD

Introduction
Netflix is a global streaming platform that serves millions of users worldwide. To ensure high availability,
scalability, and rapid feature delivery, Netflix adopted DevOps practices with CI/CD and
microservices architecture.

Problem Faced (Before DevOps)

• Monolithic system → difficult to scale
• Manual deployment → slow and error-prone
• Service downtime during updates
• Difficulty handling large-scale traffic
Solution Adopted- Netflix implemented:
• Microservices architecture (independent services)
• Cloud-based infrastructure (AWS)
• DevOps with CI/CD automation

DevOps Implementation at Netflix

1. Continuous Integration (CI)
• Developers frequently commit code
• Automated build and testing
• Early detection of bugs
2. Continuous Delivery (CD)
• Software is always kept in deployable state
• Tested in staging environments
• Ready for release at any time
3. Continuous Deployment
• Automatic deployment to production
• No manual intervention
• Multiple deployments per day
Deployment Pipeline
• Code changes trigger automated pipeline
• If tests pass → deployed directly
• Continuous monitoring ensures stability

Special Practice: Chaos Engineering

Chaos Engineering is the practice of intentionally introducing failures into a system to verify its resilience
and fault tolerance. Netflix pioneered this approach in real-world production systems.

Architecture
At the edge, client devices (mobile, web, smart TVs, gaming consoles) send requests that are first routed
through AWS Elastic Load Balancer (ELB). ELB distributes incoming traffic across multiple backend
instances to prevent overload and ensure horizontal scalability. From there, requests reach the Netty
server, which is a high-performance, non-blocking I/O server used by Netflix to efficiently handle massive
concurrent connections.

The core API gateway layer is implemented using Zuul, which applies three types of filters: Inbound
filters (authentication, routing, request validation), Endpoint filters (actual request processing and routing
to services), and Outbound filters (response transformation, logging, compression). This layer acts as a
centralized control point for cross-cutting concerns, aligning with DevOps practices like observability and
security enforcement.

After routing, requests go through Hystrix, Netflix’s circuit breaker mechanism. Hystrix isolates failures in
microservices and prevents cascading system-wide outages by implementing fallback logic when services
fail or respond slowly. This is critical for resilience engineering.

The Service Client then communicates with various microservices, each responsible for a specific domain
(user profile, recommendations, playback, etc.). These services are loosely coupled and independently
deployable, enabling continuous delivery and rapid iteration—key DevOps principles.

For data storage, Netflix uses a polyglot persistence strategy:

• Cassandra for highly scalable, distributed NoSQL storage (user activity, metadata).
• EVCache (in-memory caching layer) for low-latency reads.
• MySQL for relational data like billing and transactions.
• Critical microservices directly interact with these databases depending on consistency and latency
requirements.

To ensure system reliability, Netflix employs tools like:

• Chaos Monkey, which randomly terminates instances in production to test fault tolerance.
• Titus, Netflix’s container management platform for running microservices at scale.

For content delivery, Netflix uses Open Connect CDN, which caches video content closer to users,
reducing latency and bandwidth costs. This is crucial for streaming performance optimization.
On the media processing side, when new video content is uploaded, it goes through a queue-based
asynchronous pipeline. A transcoder service processes videos into multiple formats/resolutions. These
jobs are handled by concurrent workers and stored in Amazon S3. This decoupled design ensures
scalability and fault isolation.

For event-driven architecture and monitoring:

• Kafka acts as a distributed event streaming platform.
• Apache Samza processes streaming data in real time.
• Processed events are stored or analyzed using Elasticsearch (search/analytics) and Apache Spark
(batch/stream processing).
• Chukwa is used for log collection and monitoring.

Overall, the architecture demonstrates key DevOps patterns:

• Microservices + API Gateway (Zuul)
• Resilience (Hystrix, Chaos Monkey)
• Scalability (ELB, Cassandra, Kafka)
• Asynchronous processing (queues, Kafka, S3 pipelines)
• Observability (Chukwa, Elasticsearch)
• Continuous deployment support (Titus, containerization)

The system is designed to tolerate failures, scale elastically, and deliver low-latency streaming globally
while enabling rapid, independent deployments of services.
 From the above description of the architecture a basic idea only need for the exam.

Benefits Achieved
• High availability (minimal downtime)
• Faster and frequent releases
• Improved scalability
• Quick bug detection and recovery

Conclusion
Netflix’s use of DevOps, CI/CD, and microservices enables continuous delivery of features with high
reliability, scalability, and performance, making it a successful real-world implementation of modern
software engineering practices.

SOFTWARE MAINTENANCE
Software maintenance is the post-delivery phase of the software life cycle in which the system is
modified, updated, and improved to ensure continued effective operation.
• Performed after deployment
• Ensures software remains: Correct, Efficient, Secure, Relevant
Purpose of Software Maintenance
• Correct errors and defects
• Maintain system performance
• Adapt to environmental changes
• Enhance functionality
• Improve security
• Extend software lifespan

Key Aspects of Software Maintenance

1. Bug Fixing
• Identifying and correcting defects
• Restores correct system behavior
Example: Fixing login authentication error

2. Enhancements
• Adding new features or modifying existing ones
• Based on user needs or business requirements
Example: Adding report generation feature
3. Performance Optimization
• Improves speed and resource utilization
• Includes code optimization and database tuning
Example: Reducing response time of application

4. Porting and Migration

• Adapting software to new environments
• Ensures compatibility with new platforms
Example: Moving application to cloud

5. Re-engineering
• Improving internal structure without changing functionality
• Enhances maintainability and scalability
Example: Converting monolithic system to microservices

6. Documentation
• Updating technical and user documents
• Supports future maintenance
Includes: design documents, test cases, manuals

Types of Software Maintenance

Software maintenance is classified into four types:
1. Corrective Maintenance
Fixing errors or bugs discovered after software delivery.
Purpose
• Ensure correct functioning
• Resolve user-reported issues
Process
1. Identify problem
2. Analyze root cause
3. Modify code
4. Re-test and update
Example
• Fixing login failure
• Correcting billing calculation error
Benefits
• Improves reliability
• Increases user satisfaction
Challenges
• Risk of introducing new bugs
• Debugging complexity
2. Adaptive Maintenance
Modifying software to adapt to changes in environment.
Purpose
• Maintain compatibility with: Hardware, OS, APIs, Regulations
Process
1. Identify changes
2. Analyze impact
3. Modify system
4. Re-test
Example
• Updating system for new OS
• Integrating new API
Benefits
• Prevents system obsolescence
• Extends system life
Challenges
• Complex dependency handling
• Requires deep system understanding

3. Perfective Maintenance
Enhancing performance, usability, or functionality of software.
Purpose
• Improve efficiency
• Add new features
• Enhance user experience
Process
1. Collect feedback
2. Identify improvements
3. Implement changes
4. Perform regression testing
Example
• Improving UI design
• Adding new features
• Optimizing algorithms
Benefits
• Better user satisfaction
• Improved performance
• Reduced future maintenance cost
Challenges
• Risk of introducing new defects
• May require redesign
4. Preventive Maintenance
Proactive maintenance to prevent future problems.
Purpose
• Improve reliability
• Reduce future failures
• Minimize risks
Process
1. Code review
2. Performance monitoring
3. System updates
4. Refactoring
Example
• Updating security patches
• Removing unused code
• Upgrading libraries
Benefits
• Reduces system failures
• Improves stability - Lowers long-term cost
Challenges
• Requires time and resources
• Benefits not immediately visible

Boehm’s Software Maintenance Model

Boehm’s Software Maintenance Model (1983) applies economic decision-making to maintenance. Every
change has a cost, so decisions balance:
• Objectives: performance, reliability, functionality
• Constraints: time, cost, resources
Goal: Improve productivity and support better maintenance decisions.

Nature of the Model

• Closed-loop model (continuous cycle)

• Cycle: Change Request → Evaluation → Implementation → Feedback → New Changes
Stages in Boehm’s Maintenance Model
1. Change Identification & Classification
• Changes proposed by users/stakeholders
• Types: Corrective, Adaptive, Perfective, Preventive
• Helps in prioritization
2. Cost–Benefit Evaluation
• Analyze cost vs expected benefit
• Determines feasibility
3. Management Decision
• Select changes based on budget, time, resources
• Planning & scheduling
4. Implementation of Changes
• Coding, testing, documentation update, release
5. Verification & Validation
• Ensure requirements are met
• No new errors introduced
6. Release & Feedback
• Deliver updated system
• Feedback generates new change requests
Conclusion: Continuous improvement cycle

Metrics in Boehm’s Model

1. Annual Change Traffic (ACT)
KLOC added +KLOC deleted
ACT=
KLOC total
• Measures proportion of code changed per year
• Indicates maintenance activity level
Example:
Added = 10 KLOC, Deleted = 5 KLOC, Total = 100 KLOC
ACT = 0.15 (15%)

2. Annual Maintenance Effort (AME)

AME=ACT×SDE
• Estimates yearly maintenance effort
• SDE = Software Development Effort (person-months)
Example:
ACT = 0.15, SDE = 600 PM
AME = 90 PM/year

Boehm’s model is available for both

different systems:
1. Legacy Systems
Old systems with outdated technology but still in use
Characteristics:
• Outdated languages/platforms
• Poor documentation
• Hardware dependency
• Difficult to modify
Maintenance Strategy:
• Prefer re-engineering or replacement
• Use cost–benefit analysis carefully
• Techniques: reverse engineering, restructuring
Issues:
• High cost
• Complex debugging
• Small changes → major impact
Objective: Maintain operation while planning modernization

2. Non-Legacy (Modern) Systems

Well-designed systems with modern architecture
Characteristics:
• Modular design
• Good documentation
• Easy testing & updates
• Supports CI/CD
Maintenance Strategy:
• Focus on: Adaptive, Perfective, Preventive maintenance
• Easier and cost-effective
Objective: Enhance functionality with low cost and risk

© NOTES BY CLEARITT LEARNING

SUBSCRIBE ON YOUTUBE
POSSIBLE QUESTIONS
Short Answer Questions
1. Define Code Review, Walkthrough, and Inspection.
2. Explain Debugging and its methods (Backtracking, Brute Force, Cause Elimination).
3. Define Unit Testing, Integration Testing, and System Testing.
4. Differentiate Black-box and White-box Testing.
5. What is Regression Testing? Why is it important?
6. Define DevOps and CI/CD.
7. List and explain types of Software Maintenance (Corrective, Adaptive, Perfective, Preventive).
Essay Questions
1. Explain Code Review, Walkthrough, and Inspection with differences.
2. Explain levels of testing: Unit, Integration, and System testing.
3. Explain types of Integration Testing (Big Bang, Top-down, Bottom-up, Incremental, Sandwich).
4. Explain types of System Testing with examples.
5. Explain DevOps lifecycle and CI/CD pipeline.
6. Explain Netflix case study in point of DevOps.
7. Explain Boehm’s Software Maintenance Model including ACT and AME, and Legacy vs Non-
Legacy systems.
Model Questions – KTU
1. Compare white box and black box testing. (3 Marks)
2. What is the cyclomatic complexity of a software program? (3 Marks)
3. Differentiate between code inspection, code walk through and code review in detail. (5 Marks)
4. Illustrate the concept of DevOps with an example. (4 Marks)
5. What is software maintenance? What are its different types? (5 Marks)
6. What is the need of regression testing in software testing process? (4 Marks)