Module 5

Chapter -13

13.1 Introduction
we need to define the qualities required for a system. We need to judge the objectively whether
system meets the quality requirements and this needs to be measured.

13.2 The place for Software Quality in Project Planning

Quality is of concern at all stages of project planning and execution. Fig 13.1 shows the following
steps which are important.
Step 1 : Identify project scope and objectives : Some objectives related to the qualities of the
application development.
Step 2 : Identify project infrastructure : This identifies the installation standards and
procedures.
Step 3 : Analyze project characteristics: application to be implemented is examined to see if it
has any special quality requirements.
Step 4 : Identify the products and activities of the project : It is at this point of that the entry, exit
and process requirements identified for each activity.
Step 8: Review and publicize plan: At this stage the overall quality aspects of the project plan are
reviewed.
13.3 Importance of Software Quality
• Increasing criticality of software: The customer or user is anxious about the reliability of
the software. The organization relies more on their computer systems and software is used in
more safety-critical applications.
• The intangibility of software: This makes difficult to know that the tasks of the project
completed satisfactorily. It can be made tangible by demanding the developers to produce
deliverables and later they can be examined.
• Accumulating errors during software development: system development comprises of
steps and the errors from one step to another keep on accumulating in the deliverables
that are developed in later stages. So fixing errors become more expensive in the project and
debugging becomes difficult to control.
For these reasons quality management is an essential part of overall project management.

13.4 Defining Software Quality

Following details are required software quality specifications:

• Definition/description – definition of quality characteristics.

• Scale – the unit of measurement.
• Test – the practical test of the extent to which the attribute quality exists.
• Minimally acceptable – the worst value which might be acceptable, and below which the
product would have to be rejected.
• Target range – the range of values within which planned quality measurement value
should lie.
• Now – the value that applies currently.
There could be several measurements applicable to quality characteristics.

• Availability – the percentage of a particular time interval that a system is usable.

• Mean time between failures – Total service time divided by the number of failures.
• Failure on demand – the probability that a system will not be available at the time
required.
• Support activity – the number of fault reports that are generated and processed.
• Maintainability – how quickly a fault once detected, can be corrected.
• Changeability – the ease with which the software can be modified.
13.5 Software Quality Models
Galvin’s quality demission:
Defines the quality of any product in terms of eight general attributes.

• Performance – how well it performs the jobs.

• Features – how well it supports the required features.
• Reliability – probability of a product working satisfactorily within a specific period of time.
• Conformance – degree to which the product meets the requirements.
• Durability – measure of the product’s life.
• Serviceability – speed and effectiveness maintenance.
• Aesthetics – the look and feel of the product.
• Perceived quality – user’s opinion about the product quality.

McCall Model
Defines the following eleven attributes of the software.

• Correctness – the extent to which a software product satisfies its specifications.

• Reliability – the probability of the software product working satisfactorily over a given
duration.
• Efficiency – the amount of computing resources required to perform the required
function.
• Integrity – the extent to which the data of the software product remains valid.
• Usability – the effort required to operate the software product.
• Maintainability – the ease with which it is possible to locate and fix bugs in the software
product.
• Flexibility – the effort required to adapt the software product to changing requirements.
• Testability – the effort required to test the software product to ensure that it performs its
intended function.
• Portability – the effort required to transfer the software product from one hardware or
software system environment to another.
• Reusability – the extent to which a software can be reused in other applications.
• Interoperability – the effort required to integrate the software with other software.
Dromey’s model
Dromey’s hierarchical quality model is shown in fig 13.2. The model proposes four major high-
level properties of the software: Correctness, internal characteristics, contextual
characteristics and certain descriptive properties.

Boehm’s model
The quality of a software can be defined based on three high-level characteristics. These high-
level characteristics are:

• As-is utility – how well (easily, reliably and efficiently) can it be used?
• Maintainability – how easy it is to understand, modify and then retest the software?
• Portability – how difficult would it be to make the software in a changed environment?
Fig 13.3 shows the Boehm’s hierarchical quality model based on wider range of software
attributes with greater focus on maintainability.
13.6 ISO 9126
• ISO 9126 standard was introduced in 1991 to tackle the question of the definition of
software quality.
• The documents are very lengthy and has separate documents to cater for these three
sets of needs.
• Acquirers – who are obtaining software from external suppliers.
• Developers – who are building a software product.
• Independent evaluators – who are assessing the quality of software product, not for
themselves but for a community of users.
• ISO 9126 identifies six major external quality characteristics:
• Functionality – which covers the functions that a software product provides to satisfy
user needs.
• Reliability – which relates to the capability of the software to maintain its level of
performance.
• Usability - which relates to the effort needed to use the software.
• Efficiency – which relates to the physical resources used when software is executed.
• Maintainability – which relates to effort needed to make changes to the software.
• Portability – which relates to the ability of the software to be transferred to a different
environment.

ISO 9126 also suggests sub-characteristics for each of the above primary characteristics.

Functionality:

• Interoperability – refers to the ability of the software to interact with other systems.
Reliability:

• Maturity – frequency of failure due to faults in a software product.

Usability:

• Learnability – refers to a software tool easy to learn, but it is distinguishable from

operability.
Efficiency and Maintainability:

• Analyzability – is the ease with which the cause of failure can be determined.
• Stability – refers to low risk of a modification to the software having unexpected effects.
Portability:

• Replaceability – refers to the factors that give upwards compatibility between old software
components and the new ones.
• Coexistence – refers to the ability of the software to share resources with other software
components.

Map measurements onto ratings that reflect user satisfaction:

Mappings might be as shown in table 13.1

• According to ISO9126, measurements that act as indicators of the final quality of the
software can be used at different stages of software development life cycle.
• User satisfaction can be allocated in the range, say 0-5.
• Table 13.2 shows objective measurement of some function and then relating different
measurement values to different levels of user satisfaction.

• The scores for each quality could be given due weight by multiplying it by its importance
weighting.
• These weighted scores can then be summed to obtain an overall score for the product.
• The scores of various products are then put in the order of preference.
• For example, as shown in table 13.3 two products may be compared to usability,
efficiency and maintainability.
13.7 Product and Process Metrics
• The developers can ensure the quality of a software product based on the measurement
of attributes called product and process metrics.
• Product metrics
measures the characteristics of a product being developed such as
✓ LOC (lines of code) and
✓ function point metrics used to measure the size.
✓ PM(person-month) metric used to measure effort required to develop a
product and time required to develop a product is measured in months.
• Process metrics
✓ Measures how a development process is performing. Examples of process
metrics are review effectiveness,
✓ average number of defects found per hour of inspection,
✓ average defect correction time,
✓ productivity,
✓ average number of failures during testing per LOC.

13.8 Product versus Process Quality Management

The system development process comprises of the following activities as shown in the fig 13.4.
Activities are linked so that output from one activity is input to next activity. Errors should be
eradicated by careful observation pf deliverables.
It can be done by using following process requirements steps.
Entry requirements:
Which is to be there before an activity starts. For example, set of test data and expected results
be prepared before testing activity starts.
Implementation requirements:
Defines how the process to be conducted. For example, whenever an error is found and
corrected, all test runs should be repeated.

Exit requirements:
Which have to be fulfilled before an activity is deemed to have been completed. For example, for
testing phase to be completed, all tests will have to be run successfully with no outstanding
errors.

13.9 Quality Management Systems

ISO 9001:2000 Overview

ISO 9001:2000 is part of the ISO 9000 series, which sets forth guidelines and requirements for
implementing a Quality Management System (QMS).
The focus of ISO 9001:2000 is on ensuring that organizations have effective processes in place to
consistently deliver products and services that meet customer and regulatory requirements.
Key Elements:

1. Fundamental Features:

o Describes the basic principles of a QMS, including customer focus, leadership, involvement of
people, process approach, and continuous improvement.
o Emphasizes the importance of a systematic approach to managing processes and resources.

2. Applicability to Software Development:

o ISO 9001:2000 can be applied to software development by ensuring that the development
processes are well-defined, monitored, and improved.
o It focuses on the development process itself rather than the end product certification (unlike
product certifications such as CE marking).
3. Certification Process:

o Organizations seeking ISO 9001:2000 certification undergo an audit process conducted by an

accredited certification body.
o Certification demonstrates that the organization meets the requirements of ISO 9001:2000 and
has implemented an effective QMS.

4. Quality Management Principles:

o Customer focus: Meeting customer requirements and enhancing customer satisfaction.

o Leadership: Establishing unity of purpose and direction.
o Involvement of people: Engaging the entire organization in achieving quality objectives.
o Process approach: Managing activities and resources as processes to achieve desired
outcomes.
o Continuous improvement: Continually improving QMS effectiveness.

Principles of BS EN ISO 9001:2000

1. Customer Focus:
o Understanding and meeting customer requirements to enhance satisfaction.
2. Leadership:
o Providing unity of purpose and direction for achieving quality objectives.
3. Involvement of People:
o Engaging employees at all levels to contribute effectively to the QMS.
4. Process Approach:
o Focusing on individual processes that create products or deliver services.

o Managing these processes as a system to achieve organizational objectives.

5. Continuous Improvement:
o Continually enhancing the effectiveness of processes based on objective measurements and
analysis.
6. Factual Approach to Decision Making:
o Making decisions based on analysis of data and information.
7. Mutually Beneficial Supplier Relationships:
o Building and maintaining good relationships with suppliers to enhance capabilities and
performance.
Activities in BS EN ISO 9001:2000 Cycle

1. Understanding Customer Needs:

o Identifying and defining customer requirements and expectations.
2. Establishing Quality Policy:
o Defining a framework for quality objectives aligned with organizational goals.
3. Process Design:
o Designing processes that ensure products and services meet quality objectives.
4. Allocation of Responsibilities:
o Assigning responsibilities for meeting quality requirements within each process.
5. Resource Management:
o Ensuring adequate resources (human, infrastructure, etc.) are available for effective process
execution.
6. Measurement and Monitoring:
Designing methods to measure and monitor process effectiveness and efficiency.

o Gathering data and identifying discrepancies between actual performance and targets.

7. Analysis and Improvement:

o Analyzing causes of discrepancies and implementing corrective actions to improve processes
continually.

Detailed Requirements
1. Documentation:
o Maintaining documented objectives, procedures (in a quality manual), plans, and records that
demonstrate adherence to the QMS.

o Implementing a change control system to manage and update documentation as necessary.

2. Management Responsibility:
o Top management must actively manage the QMS and ensure that processes conform to quality
objectives.
3. Resource Management:
o Ensuring adequate resources, including trained personnel and infrastructure, are allocated to
support QMS processes.
4. Production and Service Delivery:
o Planning, reviewing, and controlling production and service delivery processes to meet
customer requirements.
o Communicating effectively with customers and suppliers to ensure clarity and alignment on
requirements.
5. Measurement, Analysis, and Improvement:
o Implementing measures to monitor product conformity, QMS effectiveness, and process
improvements.
o Using data and information to drive decision-making and enhance overall organizational
performance.

13.10 Process Capability Models

1. SEI Capability Maturity Model (CMM) and CMMI:

o Developed by the Software Engineering Institute (SEI), CMM and CMMI provide a
framework for assessing and improving the maturity of processes.
o They define five maturity levels, from initial (ad hoc processes) to optimized (continuous
improvement).
o CMMI (Capability Maturity Model Integration) integrates various disciplines beyond
software engineering.

2. ISO 15504 (SPICE):

o ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability
Determination), is an international standard for assessing and improving process
capability.
o It provides a framework for evaluating process maturity based on process attributes and
capabilities.

3. Six Sigma:

o Six Sigma focuses on reducing defects in processes to a level of 3.4 defects per million
opportunities (DPMO).
o It emphasizes data-driven decision-making and process improvement methodologies
like DMAIC (Define, Measure, Analyze, Improve, Control).
SEI capability maturity model (CMM)

The SEI Capability Maturity Model (CMM) is a framework developed by the Software Engineering
Institute (SEI) to assess and improve the maturity of software development processes within
organizations.
It categorizes organizations into five maturity levels based on their process capabilities and
practices:

SEI CMM Levels:

1. Level 1: Initial
o Characteristics:
▪ Chaotic and ad hoc development processes.
▪ Lack of defined processes or management practices.
▪ Relies heavily on individual heroics to complete projects.
o Outcome:
▪ Project success depends largely on the capabilities of individual team
members.
▪ High risk of project failure or delays.
2. Level 2: Repeatable

o Characteristics:
▪ Basic project management practices like planning and tracking
costs/schedules are in place.
▪ Processes are somewhat documented and understood by the team.
o Outcome:
▪ Organizations can repeat successful practices on similar projects.
▪ Improved project consistency and some level of predictability.

▪ High adaptability to change and efficiency in handling new challenges.

▪ Leading edge in technology adoption and process optimization.

3. Level 3: Defined

o Characteristics:
▪ Processes for both management and development activities are
defined and documented.
▪ Roles and responsibilities are clear across the organization.
 ▪ Training programs are implemented to build employee capabilities.
▪ Systematic reviews are conducted to identify and fix errors early.
o Outcome:
▪ Consistent and standardized processes across the organization.
▪ Better management of project risks and quality.

4. Level 4: Managed

o Characteristics:
▪ Processes are quantitatively managed using metrics.
▪ Quality goals are set and measured against project outcomes.
▪ Process metrics are used to improve project performance.
o Outcome:
▪ Focus on managing and optimizing processes to meet quality and
performance goals.
▪ Continuous monitoring and improvement of project execution.

5. Level 5: Optimizing

o Characteristics:
▪ Continuous process improvement is ingrained in the organization's culture.
▪ Process metrics are analyzed to identify areas for improvement.
▪ Lessons learned from projects are used to refine and enhance processes.
▪ Innovation and adoption of new technologies are actively pursued.
o Outcome:
▪ Continuous innovation and improvement in processes.

▪ High adaptability to change and efficiency in handling new challenges.

▪ Leading edge in technology adoption and process optimization.
CMMI (Capability Maturity Model Integration)

Structure and Levels of CMMI

1. Levels of Process Maturity:

o Like CMM, CMMI defines five maturity levels, each representing a different stage of
process maturity and capability. These levels are:
Level 1: Initial (similar to CMM Level 1)
Level 2: Managed (similar to CMM Level 2)
Level 3: Defined (similar to CMM Level 3)
Level 4: Quantitatively Managed (an extension of CMM Level 4)
Level 5: Optimizing (an extension of CMM Level 5)

2. Key Process Areas (KPAs):

o Definition: Similar to CMM, each maturity level in CMMI is characterized by a set of Key
Process Areas (KPAs). These KPAs represent clusters of related activities that, when
performed collectively, achieve a set of goals considered important for enhancing
process capability.
o Gradual Improvement: KPAs provide a structured approach for organizations to
incrementally improve their processes as they move from one maturity level to the next.
▪ Integration across Domains: Unlike the specific CMMs for various disciplines, CMMI
uses a more abstract and generalized set of terminologies that can be applied uniformly
across different domains.
Benefits of CMMI

▪ Broad Applicability: CMMI's abstract nature allows it to be applied not only to software
development but also to various other disciplines and industries.

• Consistency and Integration: Provides a unified framework for improving processes,

reducing redundancy, and promoting consistency across organizational practices.

• Continuous Improvement: Encourages organizations to continuously assess and refine

their processes to achieve higher levels of maturity and performance. ISO/IEC 15504,
also known as SPICE (Software Process Improvement and Capability Determination), is a
standard for assessing and improving software development processes.

ISO 15504 Process Assessment

Process Attributes:

Nine Process Attributes: ISO 15504 assesses processes based on nine attributes, which are:

1. Process Performance (PP): Measures the achievement of process-specific objectives.

2. Performance Management (PM): Evaluates how well the process is managed and controlled.
3. Work Product Management (WM): Assesses the management of work products like
requirements specifications, design documents, etc.
4. Process Definition (PD): Focuses on how well the process is defined and documented.
5. Process Deployment (PR): Examines how the process is deployed within the organization.
6. Process Measurement (PME): Evaluates the use of measurements to manage and control the
process.
7. Process Control (PC): Assesses the monitoring and control mechanisms in place for the
process.

8. Process Innovation (PI): Measures the degree of innovation and improvement in the process.
9. Process Optimization (PO): Focuses on optimizing the process to improve efficiency and
effectiveness.
Benefits and Application

▪ Benefits: ISO 15504 helps organizations:

o Evaluate their current processes against a recognized standard.

o Identify strengths and weaknesses in their processes.
o Implement improvements based on assessment findings.

▪ Application: The standard is used by organizations to conduct process assessments

either internally for improvement purposes or externally for certification purposes.
When assessors are judging the degree to which a process attribute is being fulfilled they
allocate one of the following scores:

Implementing process improvement

A project for a new control system is controlled by a Project Engineer with overall responsibility of
both the hardware and software sides of the project. CMMI help us identify the order in which
improvements have to take place. Fig below shows how a project control system could be taken
care at the level of maturity.
Fig 13.4 shows the processes involved in each stage of development life cycle
Six Sigma
Implementing Six Sigma Methodology at UVW
UVW, a company specializing in machine tool equipment with sophisticated control software,
can benefit significantly from implementing Six Sigma methodologies.
Here’s how UVW can adopt and benefit from Six Sigma:
Overview of Six Sigma
Six Sigma is a disciplined, data-driven approach aimed at improving process outputs by
identifying and eliminating causes of defects, thereby reducing variability in processes. The goal is
to achieve a level of quality where the process produces no more than 3.4 defects per million
opportunities.
Steps to Implement Six Sigma at UVW

1. Define:
o Objective: Clearly define the problem areas and goals for improvement.
o Action: Identify critical processes such as software development, testing, and
deployment where defects and variability are impacting quality and delivery timelines.
2. Measure:
o Objective: Quantify current process performance and establish baseline metrics.
o Action: Use statistical methods to measure defects, cycle times, and other relevant
metrics in software development and testing phases.
3. Analyse:
o Objective: Identify root causes of defects and variability in processes.
o Action: Conduct thorough analysis using tools like root cause analysis, process mapping,
and statistical analysis to understand why defects occur and where process variations
occur.
4. Improve:

o Objective: Implement solutions to address root causes and improve process

performance.
o Action: Develop and implement process improvements based on the analysis findings.
This could include standardizing processes, enhancing communication between teams
(e.g., software development and testing), and implementing better change control
procedures.
5. Control:
o Objective: Maintain the improvements and prevent regression.
o Action: Establish control mechanisms to monitor ongoing process performance.
Implement measures such as control charts, regular audits, and performance reviews to
sustain improvements.
Benefits of Six Sigma

• Improved Quality: Reduced defects and variability in software products.

• Enhanced Efficiency: Streamlined processes leading to faster delivery times.

• Cost Savings: Reduced rework and operational costs associated with defects.

13.11 Techniques to enhance software quality

The discussion highlights several key themes in software quality improvement over time,
emphasizing shifts in practices and methodologies:

1. Increasing Visibility:

• Early practices like Gerald Weinberg's 'egoless programming' promoted code review
among programmers, enhancing visibility into each other's work.

• Modern practices extend this visibility to include walkthroughs, inspections, and formal
reviews at various stages of development, ensuring early detection and correction of
defects.
2. Procedural Structure:

• Initially, software development lacked structured methodologies, but over time,

methodologies with defined processes for every stage (like Agile, Waterfall, etc.) have
become prevalent.

• Structured programming techniques and 'clean-room' development further enforce

procedural rigor to enhance software quality.

3. Checking Intermediate Stages:

• Traditional approaches involved waiting until a complete, albeit imperfect, version of

software was ready for debugging.

• Contemporary methods emphasize checking and validating software components early in

development, reducing reliance on predicting external quality from early design
documents.
4. Inspections:
• Inspections are critical in ensuring quality at various development stages, not just in
coding but also in documentation and test case creation.

• Techniques like Fagan inspections, pioneered by IBM, formalize the review process with
trained moderators leading discussions to identify defects and improve quality.
5. Benefits of Inspections:

• Inspections are noted for their effectiveness in eliminating superficial errors, motivating
developers to write better-structured code, and fostering team collaboration and spirit.

• They also facilitate the dissemination of good programming practices and improve overall
software quality by involving stakeholders from different stages of development.

The general principles behind Fagan Method

• Inspections are carried out on all major deliverables.
• All types of defects are noted – not just logic or function errors.
• Inspections can be carried out by colleagues at all levels except the very top.
• Inspections are carried out using a predefined set of steps.
• Inspection meetings do not last for more than two hours.
• The inspection is led by a moderator who has had specific training in the technique.
• The other participants have defined roles. For example, one person will act as a recorder
and note all defects found, and another will act as reader and take the other participants
through the document under inspection.
• Checklists are used to assist the fault-finding process.
• Material is inspected at an optimal rate of about 100 lines an hour.
• Statistics are maintained so that the effectiveness of the inspection process can be
monitored.

Formal methods

It seems like you're discussing formal methods in software development and the concept of
software quality circles. Here's a summary of the points covered:

Formal Methods in Software Development

• Definition: Formal methods use unambiguous, mathematically based specification

languages like Z and VDM. They define preconditions (input conditions) and
postconditions (output conditions) for procedures.

• Purpose: These methods ensure precise and unambiguous specifications and allow for
mathematical proof of algorithm correctness based on specified conditions.

• Adoption: Despite being taught widely in universities, formal methods are rarely used in
mainstream software development. Object Constraint Language (OCL) is a newer,
potentially more accessible development in this area.
Software Quality Circles (SWQC)

• Purpose: SWQCs are adapted from Japanese quality practices to improve software
development processes by reducing errors.

• Structure: Consist of 4 to 10 volunteers in the same department who meet regularly to

identify, analyze, and solve work-related problems.

• Process: The group selects a problem, identifies its causes, and proposes solutions.
Management approval may be required for implementing improvements.

• Benefits: Enhances team collaboration, spreads best practices, and focuses on

continuous process improvement.

13.12 Testing
The text discusses the planning and management of testing in software development, highlighting
the challenges of estimating the amount of testing required due to unknowns, such as the number
of bugs left in the code.
It introduces the V-process model as an extension of the waterfall model, emphasizing the
importance of validation activities at each development stage.

1. Quality Judgement:
• The final judgement of software quality is based on its correct execution.
2. Testing Challenges:
• Estimating the remaining testing work is difficult due to unknown bugs in the code.
3. V-Process Model:
• Introduced as an extension of the waterfall model.

• Diagrammatic representation provided in Figure 13.5.

• Stresses the necessity for validation activities matching the project creation activities.
4. Validation Activities:
• Each development step has a matching validation process.

• Defects found can cause a loop back to the corresponding development stage for rework.
5. Discrepancy Handling:
• Feedback should occur only when there is a discrepancy between specified requirements
and implementation.

• Example: System designer specifies a calculation method; if a developer

misinterprets it, the discrepancy is caught during system testing.
6. System Testing:
Original designers are responsible for checking that software meets the specified
requirements, discovering any misunderstandings by developers.

Framework for Planning:

• The V-process model provides a structure for making early planning decisions
about testing.

Types and Amounts of Testing:

• Decisions can be made about the types and amounts of testing required from the
beginning of

Verification versus validation

1. Objectives:

• Both techniques aim to remove errors from software.

2. Definitions:

• Verification: Ensures outputs of one development phase conform to the previous phase's
outputs.

• Validation: Ensures fully developed software meets its requirements specification.

3. Objectives Clarified:

• Verification Objective: Check if artifacts produced after a phase conform to those from
the previous phase (e.g., design documents conform to requirements specifications).

• Validation Objective: Check if the fully developed and integrated software satisfies
customer requirements.
4. Techniques:

• Verification Techniques: Review, simulation, and formal verification.

• Validation Techniques: Primarily based on product testing.

5. Process Stages:

• Verification: Conducted during the development process to ensure development

activities are correct.
• Validation: Conducted at the end of the development process to ensure the final product
meets customer requirements.
6. Phase Containment of Errors:

• Verification aims for phase containment of errors, which is a cost-effective way to

eliminate bugs and an important software engineering principle.
7. V-Process Model Activities:

• All activities on the right side of the V-process model are verification activities except for
the system testing block, which is a validation activity.

Test Case Design Approaches

1. Black-Box Testing:

• Test cases are designed using only functional specifications.

• Based on input/output behavior without knowledge of internal structure.
• Also known as functional testing or requirements-driven testing.

2. White-Box Testing:

• Test cases are designed based on the analysis of the source code.
• Requires knowledge of the internal structure.
• Also known as structural testing or structure-driven testing.
Levels of Testing

1. Unit Testing:
• Tests individual components or units of a program.

• Conducted as soon as the coding for each module is complete.

• Allows for parallel activities since modules are tested separately.

• Referred to as testing in the small.

2. Integration Testing:

• Checks for errors in interfacing between modules.

• Units are integrated step by step and tested after each integration.

• Referred to as testing in the large.

3. System Testing:

• Tests the fully integrated system to ensure it meets requirements.

• Conducted after integration testing.

Test Automation

1. Importance of Test Automation:

• Testing is the most time-consuming and laborious software development activity.

• Automation reduces human effort, time, and improves testing thoroughness.

• Enables sophisticated test case design techniques.

2. Benefits of Test Automation:

• More testing with a large number of test cases in a short period without significant cost
overhead.

• Automated test results are more reliable and eliminate human errors.

• Simplifies regression testing by running old test cases repeatedly.

• Reduces monotony, boredom, and errors in running the same test cases repeatedly.
• Substantial cost and time reduction in testing and maintenance phases.
Estimating Errors Based on Code Size

1. Historical Data:

• Use historical data to estimate errors per 1000 lines of code from past projects.
• Apply this ratio to new system development to estimate potential errors based on the
code size.

Error Seeding Technique

1. Seeding Known Errors:

• Known errors are deliberately left in the code during desk checks.
• Example: If 10 errors are seeded and after testing, 30 errors are found, including 6 seeded
errors, 60% of seeded errors are detected.
• This suggests that around 40% of errors are still to be detected.
• Formula to estimate total errors:

Independent Reviews

1. Tom Gilb's Approach:

• Two independent reviewers or groups are asked to inspect or test the same code.
• They must work independently of each other.
• Three counts are collected for better error estimation.

Using these methods helps in obtaining a better estimation of latent errors, providing a clearer
understanding of the remaining testing effort needed to ensure software quality.
13.13 Software reliability

1. Definition and Importance:

• Software reliability denotes the trustworthiness or dependability of a software product.

• It is defined as the probability of the software working correctly over a given period of time.

• Reliability is a crucial quality attribute for software products.

2. Defects and Reliability:

• A large number of defects typically indicate unreliability.

• Reducing defects generally improves reliability.

• It is challenging to create a mathematical formula to relate reliability directly to the

number of latent defects.

3. Execution Frequency and Defect Impact:

• Errors in infrequently executed parts of the software have less impact on overall
reliability.

• Studies show that 90% of a typical program's execution time is spent on 10% of its
instructions.

• The specific location of a defect (core or non-core part) affects reliability.

4. Observer Dependency:

• Reliability is dependent on user behavior and usage patterns.

• A bug may affect different users differently based on how they use the software.

5. Reliability Improvement Over Time:

• Reliability usually improves during testing and operational phases as defects are identified
and fixed.
• This improvement can be modeled mathematically using Reliability Growth Models
(RGM).
6. Reliability Growth Models (RGM):

• RGMs describe how reliability improves as failures are reported and bugs are corrected.
• Various RGMs exist, including the Jelinski–Moranda model, Littlewood–Verall’s model,
and Goel–Okutomo’s model.
• RGMs help predict when a certain reliability level will be achieved, guiding decisions on
when testing can be stopped.

13.14 Quality plans

Purpose of Quality Plans:

• Quality plans detail how standard quality procedures and standards from an
organization's quality manual will be applied to a specific project.

• They ensure all quality-related activities and requirements are addressed.

Integration with Project Planning:

• If a thorough project planning approach, like Step Wise, is used, quality-related activities
and requirements are often already integrated into the main planning process.

• In such cases, a separate quality plan might not be necessary.

Client Requirements:

• For software developed for external clients, the client's quality assurance staff may
require a quality plan to ensure the quality of the delivered products.

• This requirement ensures that the client’s quality standards are met.

Function of a Quality Plan:

• A quality plan acts as a checklist to confirm that all quality issues have been addressed
during the planning process.

• Most of the content in a quality plan references other documents that detail specific
quality procedures and standards.