ISO 9126 Software Quality

ISO 9126 Software Quality
ISO 9126 identifi es six major external software 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;
● effi ciency, which relates to the physical resources used when the software is executed;
● maintainability, which relates to the effort needed to the make changes to the software;
● portability, which relates to the ability of the software to be transferred to a different
environment.
ISO 9126 suggests sub-characteristics for each of the primary characteristics. They are useful as
they clarify
what is meant by each of the main characteristics.
Characteristic Sub-characteristics
Functionality Suitability
Accuracy
Interoperability
Functionality compliance
Security
‘Functionality compliance’ refers to the degree to which the software adheres to application-
related standards
or legal requirements. Typically these could be auditing requirements. Since the original 1999
draft, a
sub-characteristic called ‘compliance’ has been added to all six ISO external characteristics. In
each case,
this refers to any specifi c standards that might apply to the particular quality attribute.
‘Interoperability’ is a good illustration of the efforts of ISO 9126 to clarify terminology.
‘Interoperability’
refers to the ability of the software to interact with other systems. The framers of ISO 9126 have
chosen this
294 So ware Project Management

word rather than ‘compatibility’ because the latter causes confusion with the characteristic
referred to by ISO
9126 as ‘replaceability’ (see below).
Reliability Maturity
Fault tolerance
Recoverability
Reliability compliance
‘Maturity’ refers to the frequency of failure due to faults in a software product, the implication
being that the
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 1/18
more the software has been used, the more faults will have been uncovered and removed. It is
also interesting
to note that ‘recoverability’ has been clearly distinguished from ‘security’ which describes the
control of
access to a system.
Usability Understandability
Learnability
Operability
Attractiveness
Usability compliance
Note how ‘learnability’ is distinguished from ‘operability’. A software tool could be easy to learn
but time-
consuming to use because, say, it uses a large number of nested menus. This might be fi ne for a
package used
intermittently, but not where the system is used for many hours each day. In this case ‘learnability’
has been
incorporated at the expense of ‘operability’.
‘Attractiveness’ is a recent addition to the sub-characteristics of usability and is especially
important where
users are not compelled to use a particular software product, as in the case of games and other
entertainment
products.
Effi ciency Time behaviour
Resource utilization
Effi ciency compliance
Maintainability Analysability
Changeability
Stability
Testability
Maintainability compliance
So ware Quality 295

‘Analysability’ is the ease with which the cause of a failure can be determined. ‘Changeability’ is the
quality
that others call ‘fl exibility’: the latter name is a better one as ‘changeability’ has a different
connotation in
plain English – it might imply that the suppliers of the software are always changing it!
‘Stability’, on the other hand, does not refer to software never changing: it means that there is a
low risk of a
modifi cation to the software having unexpected effects.
Portability Adaptability
Installability
Coexistence
Replaceability
Portability compliance
‘Portability compliance’ relates to those standards that have a bearing on portability.

The use of a standard programming language common to many software/hardware
environments would be an example of this. ‘Replaceability’ refers to the factors that
give ‘upwards compatibility’ between old software components and the new ones.
‘Downwards’ compatibility is not implied by the defi nition.
‘Coexistence’ refers to the ability of the software to share resources with other software
components; unlike ‘interoperability’, no direct data passing is necessarily involved.
ISO 9126 provides guidelines for the use of the quality characteristics. Variation in
the importance of different quality characteristics depending on the type of product is
stressed. Once the requirements for the software product have been established, the
following steps are suggested:
1. Judge the importance of each quality characteristic for the application Thus reliability will be of
particular concern with safety-critical systems while effi ciency will be important for some real-
time
systems.
2. Select the external quality measurements within the ISO 9126 framework relevant to the
qualities
prioritized above Thus for reliability mean time between failures would be an important
measurement,
while for effi ciency, and more specifi cally ‘time behaviour’, response time would be an obvious
measurement.
3. Map measurements onto ratings that refl ect user satisfaction For response time, for example,
the
mappings might be as in Table 13.1.
4. Identify the relevant internal measurements and the intermediate products in which they
appear This
would only be important where software was being developed, rather than existing software
being
evaluated. For new software, the likely quality of the fi nal product would need to be assessed
during
development. For example, where the external quality in question was time behaviour, at the
software
design stage an estimated execution time for a transaction could be produced by examining the
software
code and calculating the time for each instruction in a typical execution of the transaction. In our
view
the mappings between internal and external quality characteristics and measurements suggested
in
A new version of a
word processing pack-

age might read the
documents produced
by previous versions
and thus be able to
replace them, but pre-

vious versions might
not be able to read all

documents created by
the new version.
296 So ware Project Management

the ISO 9126 standard are the least convincing elements in the approach. The part of the
standard that
provides guidance at this point is a ‘technical report’ which is less authoritative than a full
standard. It
concedes that mapping external and internal measurements can be diffi cult and that validation
to check
that there is a meaningful correlation between the two in a specifi c environment needs to be
done. This
refl ects a real problem in the practical world of software development of examining code
structure and
from that attempting to predict accurately external qualities such as reliability.
TABLE 13.1 Mapping measurements to user sa sfac on
Response time (seconds) Rating
<2 Exceeds expectation
2–5 Within the target range
6–10 Minimally acceptable
>10 Unacceptable
According to ISO 9126, measurements that might act as indicators of the fi nal quality of the
software
can be taken at different stages of the development life cycle. For products at the early stages
these
indicators might be qualitative. They could, for example, be based on checklists where compliance
with predefi ned criteria is assessed by expert judgement. As the product nears completion,
objective,
quantitative, measurements would increasingly be taken.
5. Overall assessment of product quality To what extent is it possible to combine ratings for
different
quality characteristics into a single overall rating for the software? A factor which discourages
attempts
at combining the assessments of different quality characteristics is that they can, in practice, be
measured
in very different ways, which makes comparison and combination diffi cult. Sometimes the
presence
of one quality could be to the detriment of another. For example, the effi ciency characteristics of
time
behaviour and resource utilization could be enhanced by exploiting the particular characteristics
of the
operating system and hardware environments within which the software will perform. This,
however,
would probably be at the expense of portability.
It was noted above that quality assessment could be carried out for a number of different
reasons: to
assist software development, acquisition or independent assessment.
During the development of a software product, the assessment would be driven by the need to
focus the
minds of the developers on key quality requirements. The aim would be to identify possible
weaknesses
early on and there would be no need for an overall quality rating.
TABLE 13.2 Mapping response mes onto user sa sfac on
Response time (seconds) Quality score
<2 5
2–3 4
(Contd)
So ware Quality 297
4–5 3
6–7 2
8–9 1
>9 0
Where potential users are assessing a number of different software products in order to choose
the best one,
the outcome will be along the lines that product A is more satisfactory than product B or C. Here
some idea
of relative satisfaction exists and there is a justifi cation in trying to model how this satisfaction
might be
formed. One approach recognizes some mandatory quality rating levels which a product must
reach or be
rejected, regardless of how good it is otherwise. Other characteristics might be desirable but not
essential.
For these a user satisfaction rating could be allocated in the range, say, 0–5. This could be based
on having
an objective measurement of some function and then relating different measurement values to
different levels
of user satisfaction – see Table 13.2.
Along with the rating for satisfaction, a rating in the range 1–5, say, could be assigned to refl ect
how important
each quality characteristic was. 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 for various products are then put in the order of preference. For example, two
products might be
compared as to usability, effi ciency and maintainability. The importance of each of these qualities
might be
rated as 3, 4 and 2, respectively, out of a possible maximum of 5. Quality tests might result in the
situation
shown in Table 13.3.
ISO 9126 is an international standard for software quality that identifies six major characteristics that
contribute to the quality of a software product. These characteristics, along with their sub-
characteristics, provide a comprehensive framework for evaluating software quality. Here’s a summary
of the key points:
1. Functionality
Suitability: How well the software provides the required functions.

Accuracy: The precision of the software’s outputs.
Interoperability: The ability to interact with other systems.
Functionality Compliance: Adherence to standards or legal requirements.
Security: Protection against unauthorized access and vulnerabilities.
2. Reliability
Maturity: Frequency of failure due to faults, often improving with usage.

Fault Tolerance: The software’s ability to maintain performance despite faults.
Recoverability: How easily the software can recover from failures.
Reliability Compliance: Adherence to reliability standards.
3. Usability
Understandability: How easily users can comprehend the software.

Learnability: The ease of learning how to use the software.
Operability: The ease of operation of the software.
Attractiveness: The appeal of the software’s interface.
Usability Compliance: Adherence to usability standards.
4. Efficiency
Time Behaviour: The response time of the software.

Resource Utilization: The physical resources consumed when the software is executed.
Efficiency Compliance: Adherence to efficiency standards.
5. Maintainability
Analysability: The ease of diagnosing issues in the software.

Changeability: How easily the software can be modified (also referred to as flexibility).
Stability: The software’s resilience to changes without unexpected effects.
Testability: The ease with which the software can be tested.
Maintainability Compliance: Adherence to maintainability standards.
6. Portability
Adaptability: The ease of adapting the software to different environments.

Installability: The ease of installing the software in different environments.
Coexistence: The ability of the software to share resources with other software without conflicts.
Replaceability: The software’s ability to replace other software while maintaining compatibility.
Portability Compliance: Adherence to portability standards.
Guidelines for Use:
Importance of Characteristics: Assess the importance of each characteristic based on the

software's intended use (e.g., reliability for safety-critical systems).
Quality Measurements: Select relevant external quality measurements within the ISO 9126
framework.
User Satisfaction Mapping: Map these measurements onto ratings reflecting user satisfaction.
Internal Measurements: Identify internal measurements and intermediate products that
indicate the final quality.
Overall Quality Assessment: Evaluate whether it is possible to combine ratings for different
quality characteristics into an overall quality score, though it can be challenging due to varying
measurement methods and potential trade-offs between characteristics.
ISO 9126 provides a structured approach to evaluating software quality, allowing for both qualitative
and quantitative assessments at different stages of the development lifecycle. The standard
emphasizes the importance of considering the context and specific requirements of the software
when evaluating quality.
13.7 Product versus Process Quality Management

The measurements described above relate to products. With a product-based approach to
planning and control,
as advocated by the PRINCE2 project management method, this focus on products is convenient.
However,
we saw that it is often easier to measure these product qualities in a completed computer
application rather
than during its development. Trying to use the attributes of intermediate products created at
earlier stages to
predict the quality of the fi nal application is diffi cult. An alternative approach is to scrutinize the
quality of
the processes used to develop software product.
The system development process comprises a number of activities linked so that the
output from one activity is the input to the next (Figure 13.2). Errors can enter the
process at any stage. They can be caused either by defects in a process, as when
software developers make mistakes in the logic of their software, or by information
not passing clearly and accurately between development stages.
Errors not removed at early stages become more expensive to correct at later stages.
Each development step that passes before the error is found increases the amount of
rework needed. An error in the specifi cation found in testing will mean rework at all
the stages between specifi cation and testing. Each successive step of development is also more
detailed and
less able to absorb change.
Errors should therefore be eradicated by careful examination of the deliverables of each step
before they are
passed on. One way of doing this is by having the following process requirements for each step.
● Entry requirements, which have to be in place before an activity can start. An example would be
that a
comprehensive set of test data and expected results be prepared and approved before program
testing
can commence.
● Implementation requirements, which defi ne how the process is to be conducted. In the testing
phase,
for example, it could be laid down that whenever an error is found and corrected, all test runs
must be
repeated, even those that have previously been found to run correctly.
Note that Extreme
Programming advo-
cates suggest that the
extra effort needed

to amend software at
later stages can be
exaggerated and is, in
any case, often justi-

fi ed as adding value to
the software.
So ware Quality 299
● Exit requirements, which have to be fulfi lled before an activity is deemed to have
been completed. For example, for the testing phase to be recognized as being
completed, all tests will have to have been run successfully with no outstanding
errors.
EXERCISE 13.4
In what cases might the entry conditions for one activity be different from the exit conditions for
another activity that immediately precedes it?
EXERCISE 13.5
What might be the entry and exit requirements for the process code program shown in Figure
13.2?
Exercise 13.4: Differences Between Entry and Exit Conditions
The entry conditions for one activity might differ from the exit conditions for the preceding activity
due to various factors, including:
1. Additional Preparation or Transformation:

The output of one activity might require additional preparation or transformation before it
is suitable as input for the next activity. For example, after completing the coding phase,
the output might need to be compiled and linked before it can be tested. The entry
requirement for testing might be that a fully compiled and linked version of the software is
available, while the exit condition for coding might simply be that the code has been
written and passed initial code reviews.
2. Verification and Validation:
The exit condition of one activity might be that the work has been completed, but the entry
condition for the next activity might require that the work has been verified or validated to
ensure quality. For instance, the design phase might end with a completed design
document, but the entry condition for the implementation phase might require that the
design has been reviewed and approved by the relevant stakeholders.
3. Dependencies on External Factors:
An activity might depend on external factors or inputs that are not directly related to the
preceding activity. For example, before beginning the testing phase, the entry requirement
might include having a stable testing environment set up, which may not be a direct output
of the preceding coding phase.
Exercise 13.5: Entry and Exit Requirements for the Process Code Program
For the "process code" activity shown in Figure 13.2, which involves coding a software program, the
entry and exit requirements might be as follows:
Entry Requirements:
Approved Design Documentation: Before coding begins, the design documents (such as
UML diagrams, flowcharts, and detailed specifications) must be completed and approved.
Development Environment Setup: The coding environment, including necessary software
tools (e.g., IDE, compilers), libraries, and frameworks, must be installed and configured.
Test Data Prepared: A comprehensive set of test data and expected outcomes should be
prepared and available to the developers to use during the coding process.
Exit Requirements:
Code Reviews Completed: The code must pass peer reviews or code inspections, ensuring
it adheres to coding standards and is free from obvious errors.
Unit Testing Passed: All units of the code should pass the predefined unit tests, confirming
that individual components function correctly.
Documentation Updated: The code must be accompanied by updated documentation,
including inline comments and possibly external documents describing how the code
works.
No Critical Bugs: There should be no critical or high-severity bugs outstanding in the code
before it can be considered ready for the next phase (e.g., integration testing).
These entry and exit requirements help ensure that each step of the software development process is
completed to a high standard, reducing the risk of errors propagating through the later stages of
development.
1. SEI Capability Maturity Model (SEI 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
Characteristics:
❖ Chaotic and ad hoc development processes.
❖ Lack of defined processes or management practices.
❖ Relies heavily on individual heroics to complete projects.
Outcome:
❖ Project success depends largely on the capabilities of individual team members.
❖ High risk of project failure or delays.
2. Level 2: Repeatable
Characteristics:
❖ Basic project management practices like planning and tracking costs/schedules are in
place.
❖ Processes are somewhat documented and understood by the team.
Outcome:
❖ Organizations can repeat successful practices on similar projects.
❖ Improved project consistency and some level of predictability.
vtucode.in
25
3. Level 3: Defined
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.
Outcome:
❖ Consistent and standardized processes across the organization.
❖ Better management of project risks and quality.
4. Level 4: Managed
Characteristics:
❖ Processes are quantitatively managed using metrics.
❖ Quality goals are set and measured against project outcomes.
❖ Process metrics are used to improve project performance.
Outcome:
❖ Focus on managing and optimizing processes to meet quality and performance goals.
❖ Continuous monitoring and improvement of project execution.
5. Level 5: Optimizing
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.
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.
Use of SEI CMM:

1) Capability Evaluation: Used by contract awarding authorities (like the US DoD) to assess
potential contractors' capabilities to predict performance if awarded a contract.
2) Process Assessment: Internally used by organizations to improve their own process capabilities
through assessment and recommendations for improvement. SEI CMM has been instrumental
not
only in enhancing the software development practices within organizations but also in
establishing benchmarks for industry standards.
vtucode.in
26
It encourages organizations to move from chaotic and unpredictable processes (Level 1) to
optimized
and continuously improving processes (Level 5), thereby fostering better quality, efficiency, and
predictability in software development efforts.
Key process areas
The Capability Maturity Model Integration (CMMI) is an evolutionary improvement over its
predecessor,
the Capability Maturity Model (CMM). Here's an overview of CMMI and its structure:
The SEI Capability Maturity Model (SEI CMM) is a widely recognized framework developed by the
Software Engineering Institute (SEI) to evaluate and enhance the maturity of software development
processes within organizations. This model provides a structured approach to process improvement
and helps organizations progress through five levels of maturity. Here’s a breakdown of the SEI CMM
levels:
SEI CMM Levels:
1. Level 1: Initial
Characteristics:
Development processes are chaotic and ad hoc.
There are no standardized processes or management practices in place.
Projects rely heavily on individual efforts and heroics.
Outcome:
Success largely depends on individual team members.
Projects are at high risk of failure or delays due to lack of consistency.
2. Level 2: Repeatable
Characteristics:
Basic project management practices, such as planning and tracking, are established.
Processes are documented to some extent and understood by the team.
Outcome:
Organizations can replicate successful practices on similar projects.
There is improved consistency and predictability in project outcomes.
3. Level 3: Defined
Characteristics:
Processes for both management and development activities are well-defined and
documented.
Roles and responsibilities are clearly outlined across the organization.
Training programs are in place to build team capabilities.
Systematic reviews are conducted to identify and address errors early.
Outcome:
Processes are consistent and standardized across the organization.
Project risks and quality are better managed.
4. Level 4: Managed
Characteristics:
Processes are quantitatively managed using metrics.
Quality goals are set and measured against project outcomes.
Process metrics are leveraged to improve performance.
Outcome:
There is a focus on managing and optimizing processes to meet quality and
performance goals.
Continuous monitoring and improvement of project execution are emphasized.
5. Level 5: Optimizing
Characteristics:
Continuous process improvement is embedded in the organization's culture.
Process metrics are analyzed to identify areas for enhancement.
Lessons learned from projects are used to refine and improve processes.
Innovation and the adoption of new technologies are actively pursued.
Outcome:
The organization experiences continuous innovation and process improvement.
High adaptability to change and efficiency in handling new challenges.
The organization leads in technology adoption and process optimization.
Use of SEI CMM:
1. Capability Evaluation:
The model is used by contract awarding authorities (e.g., the US Department of Defense) to
assess potential contractors' capabilities, helping to predict their performance if awarded a
contract.
2. Process Assessment:
Internally, organizations use SEI CMM to assess and improve their own process capabilities
through evaluation and recommendations for improvement. The model has significantly
contributed to enhancing software development practices and establishing industry
benchmarks.
Evolution to CMMI:
The Capability Maturity Model Integration (CMMI) is an evolutionary improvement over the original
SEI CMM. It builds upon the foundation of CMM by integrating various models and providing a more
comprehensive approach to process improvement across multiple disciplines, not just software
development. CMMI focuses on refining the processes, ensuring quality, and fostering continuous
improvement at an organizational level.
By encouraging organizations to progress from chaotic, unpredictable processes (Level 1) to
optimized, continuously improving processes (Level 5), SEI CMM fosters better quality, efficiency, and
predictability in software development efforts.
13.11 TECHNIQUES TO HELP ENHANCE SOFTWARE QUALITY

The discussion highlights several key themes in software quality improvement over time,
emphasizing
shifts in practices and methodologies:
Three main themes emerge:
Increasing visibility: A landmark in this movement towards making the software development
process
more visible was the advocacy by the American software guru, Gerald Weinberg of egoless
programming. Weinberg encouraged the simple practice of programmer looking at each other
code.
Procedure 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
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.
Inspections :
▪ Inspections are critical in ensuring quality at various development stages, not just in coding but
also in documentation and test case creation.
It is very effective way of removing superficial errors from a piece of work.
• It motivates developers to produce better structured and self-explanatory software.
• It helps spread good programming practice as the participants discuss the advantages and
disadvantages of specific piece of code.
• It enhances team spirit.
▪ Techniques like Fagan inspections, pioneered by IBM, formalize the review process with trained
moderators leading discussions to identify defects and improve quality.
Japanese Quality Techniques:
▪ Learnings from Japanese quality practices, such as quality circles and continuous improvement,
have influenced global software quality standards, emphasizing rigorous inspection and feedback
loops.
vtucode.in
39
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.
• Inspection can be carried out by colleagues at all levels except the very top.
• Inspection can be carried using a predefined set of steps.
• Inspection meeting do not last for more than two hours.
• The inspection is led by a moderator who has had specific training in the techniques.
• The participants have define rules.
• Checklist 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.
Techniques to Enhance Software Quality
Over time, software quality improvement has become a critical focus in the industry. The evolution of
practices and methodologies has brought about various techniques aimed at enhancing software
quality. These techniques revolve around three main themes: increasing visibility, procedural
structure, and checking intermediate stages.
1. Increasing Visibility:
A pivotal movement towards making the software development process more transparent was
the concept of egoless programming advocated by Gerald Weinberg, an American software
expert. Egoless programming encourages developers to review each other's code, fostering an
environment where quality is a shared responsibility rather than an individual task.
2. Procedural Structure:
Initially, software development lacked structured methodologies, leading to inconsistent and
often chaotic processes. However, over time, methodologies with clearly defined processes, such
as Agile and Waterfall, have become prevalent.
Structured programming techniques and methods like clean-room development enforce
procedural rigor, ensuring that each stage of development adheres to best practices, thereby
enhancing overall software quality.
3. Checking Intermediate Stages:
Traditional approaches often involved waiting until a complete version of the software was ready
before beginning the debugging process. However, contemporary practices emphasize checking
and validating software components early in the development cycle. This shift reduces the
dependency on predicting the final software quality based solely on early design documents and
allows for early detection and correction of errors.
Inspections:
Inspections are crucial for ensuring quality at various stages of development, not just during
coding. They also play a significant role in reviewing documentation and test cases.
Inspections help eliminate superficial errors and motivate developers to write better-structured
and self-explanatory code.
They promote good programming practices, encourage discussion about the pros and cons of
specific code segments, and foster team spirit.
Fagan Inspections:
Techniques like Fagan inspections, pioneered by IBM, formalize the review process by involving
trained moderators to lead discussions aimed at identifying defects and improving quality.
Fagan inspections are structured, with predefined steps and rules for participants. The process
involves maintaining statistics to monitor the effectiveness of the inspections.
Japanese Quality Techniques:
Global software quality standards have been influenced by Japanese quality practices, such as
quality circles and the concept of continuous improvement. These practices emphasize
rigorous inspections and feedback loops, contributing to the enhancement of software quality.
Benefits of Inspections:
Inspections are highly effective in eliminating superficial errors and motivating developers to
produce well-structured code.
They enhance team collaboration, foster the spread of good programming practices, and involve
stakeholders from different stages of development, leading to an overall improvement in
software quality.
The principles behind the Fagan method emphasize the importance of inspections across all
major deliverables, the inclusion of all types of defects, and the participation of colleagues at
various levels. Meetings are structured and limited to two hours, with the process led by a
trained moderator and supported by checklists to assist in fault-finding.
By integrating these techniques into the software development process, organizations can
significantly enhance the quality of their software products, leading to more reliable and efficient
outcomes.
explain in simple words
Simple Explanation of Techniques to Improve Software Quality
Improving software quality means making sure the software we build works well and doesn't have
errors. Over time, different techniques have been developed to help with this, and they focus on a few
main ideas:
1. Making the Development Process Clear:
Imagine if everyone on a team could look at each other's work and give feedback. This is what
egoless programming is about. It helps catch mistakes early because more eyes are checking
the work, and everyone helps each other improve.
2. Having a Clear Process:
In the past, making software was often unorganized. Now, we use specific methods like Agile or
Waterfall that guide us on what to do at each step. These methods help us follow a clear path,
so we don't miss important steps and reduce the chances of making mistakes.
3. Checking Work Along the Way:
Instead of waiting until the entire software is done to find and fix problems, we now check and
test parts of it as we go. This way, we can find and fix issues early, which saves time and effort
later on.
Inspections:
Inspections are like formal reviews where team members look at each other's work carefully to
spot any errors. This isn't just about finding problems in the code but also in the planning and
testing stages. Inspections help make sure everything is done right from the start.
Fagan inspections are a specific type of review where a trained person leads the discussion to
make sure the review is thorough and helpful.
Japanese Techniques:
Japanese practices like quality circles focus on constantly improving the way things are done.
This means regularly looking at what can be done better and making small changes to keep
improving the software.
Why These Techniques Are Helpful:
These methods help catch mistakes early, which makes it easier to fix them.
They encourage teamwork and sharing of good practices.
They make the whole process of building software smoother, so the final product is better and
more reliable.
In short, by following these steps, software teams can build better, more reliable software that meets
everyone's needs.
Verification verses Validation:

Both are bug detection techniques which helps to remove errors in software.
The main difference between these two techniques are the following:
❖ Verification is the process of determining whether the output of one phase of software
development conforms to that of its previous phase. For example, a verification step can be to
check if the design documents produced after the design step conform to the requirement
specification.
❖ Validation is the process of determining whether fully developed software conforms to its
requirements specification. Validation is applied to the fully developed and integrated software
to check if it satisfies customer’s requirements.
❖ Verification is carried put during development process to check of the development activities
are
being carried out correctly , where as
❖ Validation is carried out towards the end of the development process to check if the right
product
as required by the customer had been developed.
• All the boxes in the right hand of the V-process model of Fig.13.9 correspond to verification
activities except the system testing block which corresponds to validation activity.
Simple Explanation of Verification vs. Validation
Both verification and validation are techniques used to find and fix errors in software, but they focus
on different parts of the development process:
1. Verification:
This is like checking your work as you go along. It makes sure that each step of the
software development process is done correctly and matches what was planned in the
previous step.
For example, after designing a software feature, verification checks if the design matches
the initial requirements.
It’s done throughout the development process to ensure everything is on track.
2. Validation:
This happens after the software is fully built. Validation checks if the final product meets the
customer’s needs and requirements.
It's like asking, "Did we build the right thing?" to make sure the software does what it’s
supposed to do for the user.
Validation happens towards the end of the development process.
In summary:
Verification is about making sure each step is done correctly.

Validation is about making sure the final product is the right one for the customer.
In the V-process model (a diagram used in software development), most of the steps on the right side
are about verification, except for the last step, which is about validation (system testing).
ChatGPT can make mistakes. Check important info.

ISO 9126 Software Quality

Uploaded by

Copyright:

Available Formats

ISO 9126 Software Quality

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISO 9126 Software Quality

Uploaded by

Copyright:

Available Formats

ISO 9126 Software Quality

ISO 9126 identifi es six major external software quality characteristics:

294 So ware Project Management

So ware Quality 295

‘Portability compliance’ relates to those standards that have a bearing on portability.

word processing pack-

replace them, but pre-

not be able to read all

296 So ware Project Management

So ware Quality 297

Suitability: How well the software provides the required functions.

Maturity: Frequency of failure due to faults, often improving with usage.

Understandability: How easily users can comprehend the software.

Time Behaviour: The response time of the software.

Analysability: The ease of diagnosing issues in the software.

Adaptability: The ease of adapting the software to different environments.

Guidelines for Use:

Importance of Characteristics: Assess the importance of each characteristic based on the

13.7 Product versus Process Quality Management

extra effort needed

any case, often justi-

So ware Quality 299

1. Additional Preparation or Transformation:

1. SEI Capability Maturity Model (SEI CMM)

Use of SEI CMM:

SEI CMM Levels:

Use of SEI CMM:

13.11 TECHNIQUES TO HELP ENHANCE SOFTWARE QUALITY

Techniques to Enhance Software Quality

3. Checking Intermediate Stages:

Japanese Quality Techniques:

explain in simple words

Simple Explanation of Techniques to Improve Software Quality

1. Making the Development Process Clear:

2. Having a Clear Process:

3. Checking Work Along the Way:

Verification verses Validation:

Simple Explanation of Verification vs. Validation

Verification is about making sure each step is done correctly.

You might also like