BCSES1-601 | Software Engineering

UNIT IV – Detailed Notes

Software Reliability & Quality Management

10 Hours | Easy-to-Understand Student Notes

Reference: GeeksForGeeks | TutorialsPoint | JavaTPoint

# Topic Key Concepts

1 Software Reliability Definition, Importance, Failure vs Fault

2 Software Reliability Metrics ROCOF, MTTF, MTTR, MTBF, POFOD, Availability

3 Reliability Growth Modelling Jelinski-Moranda, NHPP, Duane, Coutinho

4 Software Quality Management Quality concepts, SQA, Quality plans

5 Risk Management Risk identification, assessment, mitigation

6 ISO & SEI CMMI ISO 9000/9001, CMM levels, CMMI

7 Six Sigma DMAIC, DMADV, Roles, Benefits

8 Computer Aided Software Engineering CASE tools, Upper/Lower CASE

9 Software Maintenance Types, IEEE model, challenges

10 Software Configuration Management Version control, Change control, Audit

11 Component-Based Software Development

CBSE, CBD cycle, benefits
 1. Software Reliability

1.1 What is Software Reliability?

Software reliability is defined as the probability that a software system will operate without failure under
specified conditions for a specified period of time. In simpler terms, it measures how well a software
product does its job consistently without crashing, giving wrong results, or behaving unexpectedly.

■ NOTE
Think of software reliability like a light bulb. If you switch on a bulb 1000 times and it works 999
times, its reliability = 999/1000 = 0.999 or 99.9%. Software reliability works the same way – it is
the fraction of time the software works correctly.

1.2 Key Terminology – Fault, Error & Failure

These three terms are often confused. Understanding them is critical:

Term Definition Example

Fault
A static defect in the code – a wrong instruction orAmissing
missinglogic.
null-check in code.
(Bug/Defect)

Error The incorrect internal state reached because of a fault

Variable
during
holds
execution.
garbage value.

Failure The observable, externally visible wrong behaviourApp

of the
crashes
system.
or gives wrong output.

Chain Reaction
Fault (in code) → triggers an → Error (bad internal state) → leads to a → Failure (visible
crash/wrong output). Removing faults reduces errors and therefore failures.

1.3 Importance of Software Reliability

Software reliability is important because:

• Safety-critical systems (aircraft, medical devices, nuclear plants) absolutely need reliable software.
• Unreliable software leads to financial losses, data corruption, and legal liability.
• High reliability = high user trust and customer satisfaction.
• Reliability planning helps teams decide when software is ready for release.

1.4 Factors Affecting Software Reliability

Factor Impact on Reliability

Complexity More complex code has more potential fault hiding places.

Development process Rigorous processes (reviews, testing) reduce faults.

Programmer skill Experienced developers write fewer faults.

Quality of requirements Ambiguous requirements lead to faults.

Testing thoroughness More testing reveals and removes more faults.

 2. Software Reliability Metrics
Reliability metrics are quantitative measures that allow engineers to assess and compare the reliability of a
software system. The Software Requirements Specification (SRS) should clearly specify reliability goals
using these metrics.

Software Reliability Metrics

ROCOF MTTF MTTR

Rate of Occurrence Mean Time Mean Time
of Failure To Failure To Repair

MTBF POFOD AVAIL

Mean Time Probability of Availability
Between Failures Failure on Demand of System

2.1 Rate of Occurrence of Failure (ROCOF)

ROCOF measures how often a software system fails in a given time period. It is calculated as:

ROCOF = (Total number of failures observed) / (Total observation time)

A lower ROCOF means the software fails less frequently – which is desirable. ROCOF is useful for systems
where continuous availability matters, such as web servers.

■ NOTE
Example: If a banking application crashes 3 times during 300 hours of operation, ROCOF =
3/300 = 0.01 failures per hour.

2.2 Mean Time to Failure (MTTF)

MTTF is the average time between successive failures. Only the actual running (execution) time is counted –
not the time spent fixing errors.

MTTF = Total execution time / Number of failures

A higher MTTF means software runs longer before each failure. MTTF is related to ROCOF:

MTTF = 1 / ROCOF

■ NOTE
Example: A system runs for 1000 hours and fails 5 times → MTTF = 1000/5 = 200 hours.

2.3 Mean Time to Repair (MTTR)

MTTR is the average time it takes to fix a failure once it has occurred. This includes the time to diagnose the
problem, fix the fault, and restart the system.
 MTTR = Total repair time / Number of repairs

■ NOTE
A system with low MTTF (fails often) is still tolerable if MTTR is very low (fixed very quickly).

2.4 Mean Time Between Failures (MTBF)

MTBF is the total average time from the start of one failure to the start of the next failure. It includes both the
running time AND the repair time:

MTBF = MTTF + MTTR

Memory Trick
MTTF = time from start to failure. MTTR = time to fix. MTBF = MTTF + MTTR. So MTBF is the
total cycle time for one fail-fix-run sequence.

2.5 Probability of Failure on Demand (POFOD)

POFOD measures the probability that the system will fail when a service request is made. It is particularly
useful for protection systems (e.g., safety shutdown systems) that are used rarely but must work when
needed.

POFOD = Number of failed requests / Total number of requests

■ NOTE
Example: If a fire suppression software system fails 2 times out of every 1000 activations,
POFOD = 2/1000 = 0.002. This means a 0.2% chance of failure on demand.

2.6 Availability
Availability measures the proportion of time the system is actually operational and available for use. It
combines both MTTF and MTTR:

Availability = MTTF / (MTTF + MTTR) = MTTF / MTBF

■ NOTE
Example: MTTF = 200 hrs, MTTR = 5 hrs → Availability = 200/205 ≈ 0.976 = 97.6% uptime.

High availability systems target 99.9% ("three nines") or even 99.999% ("five nines") availability.
 3. Reliability Growth Modelling
Reliability growth modelling uses mathematical/statistical models to track how a software system's reliability
improves over time as testing progresses and faults are found and fixed. As more faults are removed, the
software becomes more reliable – this improvement is called reliability growth.

Reliability Growth Curve

Goal
Reliability

0
Growth Growth Time / Effort
Testing Phase
Slow Rapid Mature

The diagram shows: At the start of testing, reliability grows slowly (few bugs found & fixed). In the middle
phase, it grows rapidly. Towards the end, growth slows as the remaining faults are harder to find. The goal is
to reach the reliability target before release.

3.1 Why Reliability Growth Modelling Matters

• Helps decide WHEN to release software (when does reliability meet the target?).
• Guides resource allocation – where should testing effort be focused?
• Provides confidence to stakeholders that quality is improving.
• Helps predict how many faults remain in the software.

3.2 Jelinski-Moranda (JM) Model – 1972

The Jelinski-Moranda model is one of the earliest and most foundational software reliability growth models. It
was proposed by Jelinski and Moranda in 1972.
 Jelinski-Moranda Model – Failure Rate vs Faults Fixed

High initial failure rate

Failure Rate λ(t)

Approaches 0

Number of Faults Fixed

Key Assumptions:
• The software contains a fixed total number of faults N at the start of testing.
• Each fault contributes equally to the overall failure rate.
• When a fault is found and fixed, it is perfectly repaired (no new faults introduced).
• The failure rate decreases by a constant amount each time a fault is removed.

The failure rate after the (i-1)th fault has been found and fixed is:

λ(i) = Φ × (N − (i−1))
Where: Φ = proportionality constant (detection rate per fault), N = initial total number of faults, i = the index of
the current failure being analysed.

■ NOTE
Limitation: The assumption that all faults contribute equally is unrealistic. In practice, some
faults are more likely to be triggered than others. Also, fixes are not always perfect.

3.3 Non-Homogeneous Poisson Process (NHPP) Model

The NHPP model is a probabilistic model that assumes the number of failures in any time interval follows a
Poisson distribution. The key idea is that the failure rate changes over time (it is non-homogeneous =
non-uniform).

Mean Value Function:

The expected cumulative number of failures by time t is given by a mean value function m(t). A common form
is the Goel-Okumoto (GO) NHPP model:

m(t) = a (1 − e−bt)
Where: a = expected total number of faults to be eventually detected, b = fault detection rate per unit time.
Parameters a and b are estimated from failure data using Maximum Likelihood Estimation (MLE) or least
squares methods.

Advantage
NHPP models are very flexible and can be fitted to many types of failure data. The GO model
specifically captures the S-shape reliability growth curve well.
3.4 Duane Model
The Duane model is an empirical model based on the observation that, when reliability growth testing is
plotted on log-log paper, the cumulative failure rate often follows a straight line.

Cumulative Failure Rate:

λ_c(t) = K × t−α
Where K is a constant, t is cumulative test time, and α is the growth parameter (0 < α < 1). A higher α means
faster reliability growth. The Duane model is easy to apply graphically and is widely used in hardware as well
as software reliability testing.

3.5 Coutinho Model

Coutinho adapted the Duane model specifically for the software testing process. He plotted the cumulative
number of defects discovered and correction actions against cumulative testing weeks on log-log paper.

ln(N(t)) = β■ + β■ × ln(t)
Where N(t) is the cumulative number of failures, and β■, β■ are model parameters estimated using the
least-squares method. The Coutinho model is simple to apply and useful for project managers tracking defect
counts over testing weeks.

3.6 Comparison of Reliability Growth Models

Model Type Key Assumption Best Used When

Jelinski-Moranda Deterministic Equal fault contribution; perfect repair Simple early estimation

NHPP (GO) Probabilistic Failures follow Poisson; non-uniform rate General purpose; flexible

Duane Empirical Log-log linear plot of failure rate Hardware + software testing

Coutinho Empirical Adapted Duane for software defect countsTracking weekly defect counts
 4. Software Quality Management

4.1 What is Software Quality?

Software quality can be defined from two perspectives:

• Product quality: The degree to which a software product meets its specified requirements (correctness,
reliability, efficiency, usability, maintainability, portability).
• Process quality: The quality of the software development and maintenance processes that create the
product.

Quality cannot be tested in at the end – it must be built in throughout the development process.

4.2 Software Quality Attributes (ISO 9126 / McCall's Model)

Attribute Description

Correctness Does the software do exactly what the requirements specify?

Reliability How often does it fail? (as studied in earlier sections)

Efficiency Does it use hardware resources (CPU, memory) wisely?

Usability Is it easy to learn and use? Good UI/UX?

Maintainability How easy is it to fix bugs and add new features?

Portability Can it run on different platforms/OS without changes?

Testability How easy is it to write tests for this software?

Reusability Can its components be reused in other systems?

4.3 Software Quality Assurance (SQA)

Software Quality Assurance (SQA) is a set of activities that ensures the software development process and
the resulting product meet defined quality standards. SQA is proactive – it prevents defects from occurring,
unlike testing which finds defects that already exist.

Key SQA Activities:

• Process Reviews: Reviewing development processes to ensure they follow standards.
• Product Inspections/Walkthroughs: Reviewing documents and code before testing.
• Standards Definition: Defining coding standards, design standards, and documentation standards.
• Audits: Independent checks to verify compliance with plans and standards.
• Metrics Collection: Collecting data to track quality improvements over time.

4.4 Software Quality Plan

A Software Quality Plan (SQP) is a document that outlines what quality standards will be used, what activities
will verify those standards are met, and who is responsible for quality. A typical quality plan contains:

Product introduction: Description of product and intended market.

Product plans: Critical release dates and responsibilities.

Process descriptions: Development and testing processes to be followed.

Quality goals: Specific quality targets (e.g., defect density < 1/KLOC).

Risks and mitigation: Quality risks and how they will be managed.
 5. Risk Management

5.1 What is a Risk?

In software engineering, a risk is an uncertain event or condition that, if it occurs, has a negative effect on
project objectives (scope, schedule, cost, quality). Risk management is the process of identifying, assessing,
and controlling risks before they become problems.

A risk has two key properties:

• Probability (Likelihood): How likely is it that this risk will actually occur? (e.g., 30%)
• Impact (Consequence): If it does occur, how bad will the damage be? (Low / Medium / High / Critical)

Risk Exposure = Probability × Impact

5.2 Types of Risks

Risk Category Description Example

Project Risks Affect schedule or resources. Key developer leaves the team.

Product Risks Affect product quality or performance. New algorithm performs poorly.

Business Risks Affect organisation or product [Link] releases similar product.

Technical Risks Affect implementation or design. Chosen technology proves inadequate.

5.3 Risk Management Process

Step 1 – Risk Identification

Create a list of all potential risks. Use brainstorming, checklists from past projects, and expert judgment.
Categorise risks into project, product, business, and technical types.

Step 2 – Risk Analysis & Assessment

Estimate the probability of each risk occurring (low/medium/high) and the severity of its impact. Prioritise
risks by their risk exposure = probability × impact. Focus on high-exposure risks.

Step 3 – Risk Planning (Mitigation Strategies)

For each high-priority risk, decide a strategy: • Avoidance: Change the plan to eliminate the risk. • Reduction:
Take actions to reduce probability or impact. • Transfer: Shift the risk to a third party (e.g., insurance,
outsource). • Acceptance: Accept the risk and plan a contingency response.

Step 4 – Risk Monitoring

Regularly review the risk list throughout the project. Check if probabilities have changed. Watch for risk
indicators (early warning signs). Update mitigation plans as needed.
5.4 Risk Matrix (Heat Map)
A Risk Matrix maps risks by probability vs impact to help prioritise them:

Impact → Low Medium High Critical

High Prob Medium High Critical Critical

Med Prob Low Medium High Critical

Low Prob Low Low Medium High

 6. ISO Standards & SEI CMMI

6.1 ISO 9000 Series

ISO 9000 is a family of international standards published by the International Organisation for
Standardisation (ISO) for quality management systems. In software engineering, ISO 9001 is the most
relevant standard.

ISO 9001 specifies requirements for a Quality Management System (QMS). An organisation can be
certified to ISO 9001 by a third-party auditor, which signals to customers that the organisation follows a
documented, repeatable quality process.

Key Principles of ISO 9000:

Customer Focus: Understand and meet customer requirements; strive to exceed expectations.

Leadership: Leaders establish unity of purpose and create conditions for people to achieve quality goals.

People Involvement: Competent, empowered people at all levels are essential.

Process Approach: Consistent, predictable results are achieved more effectively by managing activities as
interrelated processes.

Continual Improvement: Ongoing improvement is a permanent objective.

Evidence-based Decision Making: Decisions based on analysis and evaluation of data are more likely to
produce desired results.

Relationship Management: Managing relationships with suppliers and interested parties for sustained
success.

ISO vs CMMI
ISO 9001 is a general quality standard applicable to any industry. CMMI is specific to software
and systems engineering. ISO focuses on "what" to do; CMMI focuses on "how" to mature
processes. Both are complementary.

6.2 SEI CMM (Capability Maturity Model)

The Capability Maturity Model (CMM) was developed by the Software Engineering Institute (SEI) at
Carnegie Mellon University for the US Department of Defence. It describes the key elements of an effective
software development process and arranges them in 5 maturity levels.
 CMMI Maturity Levels

Level 1 – Initial

Level 2 – Managed

Level 3 – Defined

Level 4 – Quantitatively Managed

Level 5 – Optimising

Level 1 – Initial
No defined processes. Development is ad hoc and chaotic. Success depends on individual heroics.
Processes are unpredictable, poorly controlled. Results are unpredictable.

Level 2 – Managed (Repeatable)

Basic project management processes established. Projects can repeat earlier successes with similar
applications. Requirements management, project planning, tracking, and configuration management are in
place. Each project is managed as an entity.

Level 3 – Defined
All processes across the organisation are documented and standardised. Development uses a tailored
version of the organisation's standard process. Processes for both management and engineering are
documented, standardised, and integrated. Organisation-wide training programmes exist.

Level 4 – Quantitatively Managed

Quantitative objectives for product quality and process performance are established. Software processes are
controlled using statistical and quantitative techniques. Measurement data is collected and analysed
systematically. Process capability is well understood.

Level 5 – Optimising
Focus on continuous improvement through incremental and innovative improvements. Process performance
is monitored and analysed. Root cause analysis of defects is performed. Pilot testing of new technologies is
systematically performed.

6.3 CMMI (Capability Maturity Model Integration)

CMMI is the successor to CMM, developed by SEI. It integrates multiple CMM models (SW-CMM for
software, SE-CMM for systems engineering, IPD-CMM for integrated product development) into a single
unified framework.

CMMI benefits organisations by:

• Providing a clear roadmap for process improvement.

• Reducing development costs – higher CMMI levels correlate with 30-60% cost reductions.
• Improving on-time delivery and defect rates significantly.
• Enabling better project estimation accuracy and risk management.
• Helping win government/defence contracts which often require CMMI certification.
 7. Six Sigma in Software Engineering

7.1 What is Six Sigma?

Six Sigma is a data-driven quality management methodology introduced in 1986 by Bill Smith at Motorola.
The name comes from the Greek letter σ (sigma), which represents standard deviation in statistics.
Achieving "Six Sigma" means having a process with a defect rate of only 3.4 defects per million
opportunities (DPMO) – i.e., 99.99966% defect-free.

Six Sigma Goal

Reduce process variation so that 6 standard deviations fit between the process mean and the
nearest specification limit. Result: only 3.4 defects per million opportunities. Five Sigma = 233
DPMO; Four Sigma = 6,210 DPMO; Three Sigma = 66,807 DPMO.

7.2 DMAIC Methodology (for improving existing processes)

Six Sigma – DMAIC Cycle

D
Define

M C
Measure Control
DMAIC

A I
Analyse Improve

D – Define
Define the problem, goals, customer requirements, and project scope. Create a Project Charter. Identify
Critical-to-Quality (CTQ) factors. Understand Voice of the Customer (VoC).

M – Measure
Measure current process performance. Collect data on defects, cycle times, process outputs. Establish a
performance baseline. Validate measurement systems.

A – Analyse
Analyse data to identify root causes of defects and problems. Use statistical tools like cause-and-effect
diagrams, Pareto charts, regression analysis. Identify the vital few factors causing most of the variation.
 I – Improve
Develop, test, and implement solutions that eliminate root causes. Use Design of Experiments (DoE) to find
optimal settings. Pilot the solution before full rollout.

C – Control
Sustain the improvements. Create control plans, monitoring systems, and standard operating procedures.
Use Statistical Process Control (SPC) charts. Hand off to process owners.

7.3 DMADV Methodology (for designing new processes)

DMADV (also called DFSS – Design for Six Sigma) is used when creating a new product or process, rather
than improving an existing one:

Define: Define goals aligned with customer requirements.

Measure: Measure and identify CTQs, capabilities, risks.

Analyse: Analyse to develop design alternatives; select the best design.

Design: Design detailed design; optimise the design.

Verify: Verify the design through simulations and pilots; hand over to process owners.

7.4 Six Sigma Roles (Belt System)

Role Responsibilities

Executive Sponsor Senior management champion who supports and funds Six Sigma initiatives.

Champion Business leaders who identify projects and remove obstacles.

Master Black Belt Full-time Six Sigma experts; train and mentor Black/Green Belts.

Black Belt Lead Six Sigma projects full-time; statistical experts.

Green Belt Part-time Six Sigma practitioners; work on projects alongside regular duties.

Yellow Belt Team members with basic Six Sigma awareness; support project teams.
 8. Computer Aided Software Engineering (CASE)

8.1 What is CASE?

Computer Aided Software Engineering (CASE) refers to the use of software tools to support and automate
tasks in the software development process. Just as CAD (Computer Aided Design) tools help engineers
design hardware, CASE tools help software engineers design, analyse, code, test, and maintain software
systems.

CASE tools help to:

• Speed up development by automating repetitive tasks.

• Improve software quality through consistent application of methods.
• Reduce errors by providing graphical models that are easier to validate.
• Enable better documentation and communication.

CASE Tools Classification

UPPER CASE LOWER CASE

• Planning Tools • Code Generators

• Analysis Tools • Debuggers

• ER Diagram Tools • Testing Tools

• DFD Tools • Compilers/Linkers

• Requirements Mgmt • Maintenance Tools

• Prototyping Tools • Reverse Engg.

8.2 Upper CASE Tools (Front-End Tools)

Upper CASE tools support the early phases of the SDLC: planning, requirements analysis, and system
design. They work on the "what" of the system.
• Analysis tools: Entity-Relationship (ER) modellers, Data Flow Diagram (DFD) tools.
• Requirements tools: Requirements tracking and management tools.
• Design tools: UML modelling tools (class diagrams, sequence diagrams, etc.).
• Prototyping tools: Rapid creation of screen prototypes for user review.

8.3 Lower CASE Tools (Back-End Tools)

Lower CASE tools support the later phases: coding, testing, and maintenance. They work on the "how" of
implementation.

• Code generators: Automatically generate code skeletons from design models.

• Compilers and debuggers: Detect and fix syntax and runtime errors.
• Testing tools: Automated test generation, test execution, and coverage measurement.
• Reverse engineering tools: Analyse existing code to generate design models.

8.4 Integrated CASE (I-CASE) Environments

Integrated CASE environments combine both upper and lower CASE tools into a unified environment with a
shared central repository. This enables seamless flow from requirements through design, code, and test.

Central Repository:
The central repository is the heart of any CASE environment. It stores all project artefacts (requirements,
models, code, test cases) in an integrated database. This provides:

• Version control for all artefacts.

• Consistency checking between different models.
• Impact analysis – determining what is affected when something changes.
• Reuse of components across projects.

8.5 Popular CASE Tools

CASE Tool Purpose

Enterprise Architect UML modelling, requirements, code generation (Sparx Systems)

Visual Paradigm UML diagrams, business process modelling, agile tools

Rational Rose (IBM) Object-oriented modelling, code generation

JIRA Project management, issue tracking, agile sprint planning

Selenium Automated web application testing tool

SonarQube Code quality analysis and technical debt measurement

Git / GitHub Version control and configuration management

 9. Software Maintenance

9.1 What is Software Maintenance?

Software maintenance is the process of modifying a software product after it has been delivered to fix faults,
improve performance, or adapt it to a changed environment. It is one of the most expensive phases of the
software lifecycle, often costing 60-70% of the total lifecycle cost.

9.2 Types of Software Maintenance

Type Description Triggered By Example

Corrective ~20%
Bug reports from users. Fixing a login crash.
Maintenance Fixing faults/bugs discovered after delivery.

Adaptive ~20%
OS upgrade, new hardware.
Making app work on a new OS.
Maintenance Adapting software to changed environment.

Perfective ~50%
New user requirements. Adding dark mode to an app.
Maintenance Enhancing existing features; improving performance.

Preventive ~10%
Technical debt, aging code.
Refactoring messy code.
Maintenance Restructuring code to prevent future problems.

50% Rule
Perfective maintenance accounts for roughly 50% of all maintenance effort. This means most
maintenance is NOT bug fixing – it is adding new features and improving the system.

9.3 IEEE Maintenance Process Model

IEEE defines a standard framework for software maintenance with the following sequential but iterative
activities:

1. Identification & Tracing: Identify what needs to be changed (from bug reports, user requests, or internal
analysis). Classify the maintenance type.

2. Analysis: Analyse the impact of the proposed change on the entire system. Check safety, security, and
cost implications.
3. Design: Design the modification. Update architecture and design documents as needed. Plan the
implementation.

4. Implementation: Code the change. Follow coding standards. Conduct code reviews and unit tests.

5. System Testing: Test the entire system after the change (regression testing) to ensure nothing else was
broken.

6. Acceptance Testing: Have the user/client verify that the change meets their requirements.

7. Delivery: Deploy the updated software. Update all documentation and user manuals.

9.4 Challenges in Software Maintenance

• Most maintenance engineers are new to the code and must understand it before changing it.
• Poor or missing documentation makes maintenance much harder and riskier.
• Changes can unintentionally break other parts of the system ("ripple effect").
• Legacy software may use outdated technologies that few people understand.
• Pressure to deliver fixes quickly often leads to quick fixes that create technical debt.

9.5 Software Re-engineering

Re-engineering is the process of examining and altering existing software to reconstitute it in a new form. It
does not change the functionality, but improves structure and maintainability. Re-engineering activities
include:

• Reverse Engineering: Analysing existing code to recover its design and specifications.
• Restructuring: Reorganising source code structure without changing functionality.
• Forward Engineering: Using the recovered design to re-implement the system (possibly in a new
language or with improved architecture).
 10. Software Configuration Management (SCM)

10.1 What is SCM?

Software Configuration Management (SCM) is a software engineering discipline that systematically
manages, organises, and controls changes to software artefacts throughout the entire Software Development
Life Cycle (SDLC). Its primary goal is to maintain the integrity and traceability of the software product at all
times.

SCM answers the questions: Who changed what? When? Why? What is the current state of the software?
Can we reproduce a specific old release?

SCM Process Flow

1 2 3 4 5

Version Change Status Configuration

Identification
Control Control Accounting Audit

10.2 Why SCM is Needed

• Multiple developers work on the same codebase simultaneously – SCM prevents conflicts.
• Requirements change during development – SCM controls and documents these changes.
• Different customers may run different versions – SCM manages multiple variants.
• Audit trails are required for quality and compliance purposes.

10.3 SCM Activities

1. Configuration Identification
The first step is to identify all software configuration items (CIs) – any product component that will be under
SCM control. CIs include: source code files, executable programs, design documents, test cases, user
manuals, database schemas, and build scripts.

A baseline is a formally reviewed and approved set of CIs at a specific point in time. It serves as the
foundation for further development and can only be changed through formal change control.

2. Version Control
Version control tracks all changes to CIs over time. It allows teams to:
• Maintain a complete history of all changes made.
• Revert to any previous version if a new change introduces problems.
• Support parallel development through branching and merging.
• Identify exactly what changed between any two versions.
Popular version control systems: Git, SVN (Subversion), Mercurial.

3. Change Control
Change control is a formal process for managing modifications to baselined CIs. Without it, uncoordinated
changes cause inconsistencies and defects. The process involves:

• Developer submits a Change Request (CR).

• A Change Control Board (CCB) evaluates the CR for technical merit, priority, cost, and schedule impact.
• Approved changes are planned into future releases; rejected CRs are recorded.
• Approved changes are implemented, tested, and merged back to the baseline.

4. Configuration Status Accounting

This activity records and reports the status of all CIs throughout the project. It provides visibility into:

• What versions of each CI currently exist.

• Which changes have been implemented in each version.
• The current state of all baselines.
Status accounting generates reports that help managers track project progress and understand the impact of
recent changes.

5. Configuration Audit
Configuration audits verify that what was built matches what was specified. Two types:

• Functional Configuration Audit (FCA): Verifies that the software performs all its required functions (tests
against requirements).
• Physical Configuration Audit (PCA): Verifies that all required CIs are present and complete (checks that
all deliverables are accounted for).

10.4 Roles in SCM

Role Responsibilities

Developer Checks out/in code; follows SCM procedures; resolves conflicts.

SCM Manager Plans SCM activities; defines processes; manages the repository.

Change Control Board Reviews and approves/rejects change requests.

Auditor Conducts SCM audits; verifies compliance and completeness.

Release Engineer Manages the build and release process; creates deliverables.
 11. Component-Based Software Development (CBSD)

11.1 What is a Component?

A software component is a self-contained, reusable unit of software that provides a well-defined service
through a well-defined interface. Components have:

• High cohesion: All functions within the component are closely related.
• Low coupling: The component depends minimally on other components.
• Defined interface: The component communicates through a stable, documented API.

■ NOTE
Real-world analogy: Think of components like electrical plugs and sockets. Any plug
(component) fitting the standard socket (interface) will work, regardless of who made it. You
don't need to know how the electricity flows inside – you just plug it in and use it.

11.2 Component-Based Software Engineering (CBSE)

Component-Based Software Engineering (CBSE) is a software development approach in which systems
are built by assembling existing, pre-built components rather than writing everything from scratch. This is also
called "software construction from parts".

Goal: Reduce development time, cost, and risk by maximising software reuse.

11.3 CBD Development Process

1. Component Identification

Identify required functionality. Search for existing components that can fulfil the needs. Evaluate their
suitability.

2. Requirements Modification

Modify requirements to accommodate the capabilities and constraints of available components. Sometimes
you must "bend" requirements.

3. System Design with Reuse

Design the overall system architecture around the selected reusable components. Design glue code
(wrappers/adapters) if needed.

4. Development & Integration

Develop any new components not available for reuse. Write the integration/glue code. Assemble the system
from all components.

5. Verification & Validation

Test the assembled system. Verify that components work correctly together. Validate against original
requirements.

11.4 Benefits of CBSE

Benefit Explanation

Reduced Development Time Reusing tested components avoids rewriting and retesting code.

Lower Cost Less code to write = less effort = lower cost.

Higher Reliability Reused components have been tested extensively in other systems.

Easier Maintenance Updating a component automatically benefits all systems using it.

Better Productivity Developers focus on integration and business logic rather than low-level code.

Standardisation Common interfaces promote consistency across the organisation.

11.5 Challenges of CBSE

• Component trust: Can you trust the reliability of a third-party component you did not write?
• Requirements compromise: You may need to modify your requirements to fit available components.
• Version conflicts: Different systems may need different versions of the same component.
• Integration complexity: Glue code connecting components can become complex and bug-prone.
• Black-box nature: If you cannot see the source code, debugging is harder.

11.6 COTS (Commercial Off-The-Shelf) Software

COTS refers to ready-made software products that can be bought and used without modification (or with
minimal configuration). Examples: Microsoft Office, Salesforce CRM, SAP ERP. Using COTS reduces
development effort but introduces dependency on a vendor.
 12. Quick Revision Summary
Use this section for last-minute revision before exams.

Probability of failure-free operation under specified conditions

Software Reliability
for a specified time.

Fault = code defect; Error = bad internal state; Failure =

Fault → Error → Failure
visible wrong behaviour.

Failures per unit time. ROCOF = No. of failures / observation

ROCOF
time.

MTTF Average running time between failures. MTTF = 1/ROCOF.

MTTR Average repair/fix time. MTBF = MTTF + MTTR.

Availability MTTF / MTBF = fraction of time system is up.

Probability system fails when a request is made. Good for

POFOD
on-demand safety systems.

Earliest RGM; failure rate decreases by fixed amount per

Jelinski-Moranda Model
fault fixed. Assumes equal faults.

NHPP (GO Model) Probabilistic; failures follow Poisson. m(t) = a(1 - e^{-bt}).

Empirical; log-log plot of failure rate is a straight line. Used in

Duane Model
testing.

Proactive process of preventing defects through reviews,

SQA
audits, standards.

International QMS standard; 7 principles including customer

ISO 9001
focus and continual improvement.

1-Initial (chaotic), 2-Managed, 3-Defined, 4-Quantitatively

CMM Levels
Managed, 5-Optimising.

Successor to CMM; integrates SW-CMM + SE-CMM +

CMMI
IPD-CMM into one framework.

Only 3.4 DPMO; 99.99966% defect free. Uses DMAIC

Six Sigma
(improve) or DMADV (design new).

DMAIC Define → Measure → Analyse → Improve → Control.

Software tools automating SDLC. Upper CASE =

CASE Tools
planning/analysis; Lower CASE = coding/testing.

Post-delivery modification. Types: Corrective (20%), Adaptive

Software Maintenance
(20%), Perfective (50%), Preventive (10%).
 Controls changes to software artefacts. Activities:
SCM Identification, Version Control, Change Control, Status
Accounting, Audit.

Building systems from pre-built reusable components.

CBSE
Benefits: speed, cost, reliability.

End of UNIT IV Notes – Software Engineering (BCSES1-601)

Notes compiled from GeeksforGeeks | TutorialsPoint | JavaTPoint | IEEE Standards | PMBOK. For educational
purposes only.