MODULE 5 Flashcards
- Describe in detail about software quality models.
- McCall’s Quality Model (1977)
* Purpose: Focuses on bridging the gap between users and developers by categorizing
quality attributes into three categories:
o Product Operation: Attributes related to the software’s functionality during
use.
o Product Revision: Attributes related to the ease of maintaining and updating
the software.
o Product Transition: Attributes related to the software’s ability to adapt to
changes.
* Quality Factors: Includes correctness, reliability, efficiency, integrity, usability,
maintainability, testability, flexibility, and portability.
* Evaluation Criteria: Defines measurable criteria to evaluate these factors. - Boehm’s Quality Model (1978)
* Purpose: A hierarchical model that identifies quality characteristics and their
interrelationships.
* Top-Level Characteristics: Includes correctness, reliability, efficiency, usability,
maintainability, testability, understandability, portability, and reusability.
* Structure: Breaks down high-level characteristics into primitive metrics for evaluation. - ISO/IEC 9126 Model (1991) (Replaced by ISO/IEC 25010)
* Purpose: Provides a comprehensive framework for assessing software quality.
* Six Characteristics: - Functionality: Suitability, accuracy, interoperability, security.
- Reliability: Maturity, fault tolerance, recoverability.
- Usability: Understandability, learnability, operability.
- Efficiency: Time behavior, resource utilization.
- Maintainability: Analyzability, changeability, stability, testability.
- Portability: Adaptability, installability, co-existence, replaceability.
* Sub-characteristics: Each characteristic has specific measurable attributes. - ISO/IEC 25010 (2011)
* Purpose: Successor to ISO/IEC 9126, this model emphasizes modern software quality
requirements.
* Eight Characteristics: - Functional Suitability
- Performance Efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
* Key Advantage: Updated for contemporary software environments, including cloud
and mobile applications. - GQM Model (Goal, Question, Metric)
* Purpose: Focuses on aligning software quality goals with organizational objectives.
* Approach: - Define goals for the software.
- Frame questions to evaluate the achievement of these goals.
- Identify metrics to answer these questions quantitatively.
- Dromey’s Quality Model
* Purpose: Highlights the relationship between software properties and quality.
* Approach: Considers the quality of components, correctness of interactions, and
satisfaction of functional requirements.
Importance of Software Quality Models - Standardization: Provide a common language for discussing quality attributes.
- Evaluation and Measurement: Define measurable metrics for assessing quality.
- Improvement: Help identify weaknesses and areas for improvement.
- Compliance: Ensure adherence to industry standards and regulatory requirements.
. Elaborate the place of software quality in project planning
● Step 1: Identify project scope and objectives Some objectives could relate to the qualities
of the application to be delivered.
● Step 2: Identify project infrastructure Within this step, activity 2.2 identifies installation
standards and procedures. Some of these will almost certainly be about quality.
● Step 3: Analyse project characteristics In activity 3.2 (‘Analyse other project characteristics
– including quality based ones’) the 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 that the entry, exit
and process requirements are identified for each activity. This is described later in this chapter.
● Step 8: Review and publicize plan At this stage the overall quality aspects of the project plan
are reviewed.
Illustrate the ISO 9126 model in detail.
The ISO 9126 standard, introduced in 1991, aimed to define software quality and serve as a
foundational framework for developing more detailed standards. Initially a concise 13-page
document, it has since evolved into comprehensive and extensive standards to address the
diverse interests in software quality.
Key Stakeholders:
1. Acquirers: Focused on assessing quality to ensure the software from external suppliers
meets their requirements.
2. Developers: Concerned with building software products that conform to quality
benchmarks.
3. Independent Evaluators: Assess software quality on behalf of a user community,
ensuring tools meet the needs of professionals relying on them.
The ISO 9126 standard provides separate documents to address the needs of acquirers,
developers, and independent evaluators, focusing solely on defining software quality
attributes. To complement this, ISO 14598 outlines the procedures for assessing how well a
software product meets these attributes. Interestingly, ISO 14598 can also assess quality using
other characteristics if needed.
Types of Quality in ISO 9126
1. Internal and External Quality: Attributes related to the software itself and its
operation.
2. Quality in Use: Focuses on the user experience and includes:
o Effectiveness: Achieving goals accurately and completely.
o Productivity: Using resources efficiently, avoiding unnecessary effort.
o Safety: Minimizing risks to people, businesses, and the environment.
o Satisfaction: Ensuring users have a positive experience.
“Users” include operators, maintainers, and enhancers of software. Quality in use depends
on both the software and its context. For example, software mainly used for photocopier
maintenance might perform well, but a shift to more printer jobs could reveal hidden bugs.
Over time, as errors are fixed, the software becomes more reliable or “mature.”
- Illustrate the drome’s model with neat diagram
Drome’s Quality Model Overview
Drome’s Quality Model focuses on the relationship between the quality of software
components and the overall software quality. The model provides a systematic approach to
connect the properties of software components to the high-level quality attributes desired in
the final product.
Key Aspects of Drome’s Model
1. High-Level Quality Attributes: Characteristics like functionality, reliability, usability,
efficiency, maintainability, and portability.
2. Software Properties: These include correctness, consistency, and completeness of
components, which directly influence quality attributes.
3. Component Quality: The quality of individual components is assessed to ensure they
align with the desired high-level attributes.
Drome’s Model Diagram
Here’s a textual representation of the diagram (since I can’t draw directly here):
High-Level Quality Attributes
┌──────────┬──────────┬──────────┐
│Functionality│ Reliability │ Usability │
└────┬───────┴─────┬─────┴───────┬───┘
│ │ │
Software Properties (Correctness, Completeness, etc.)
┌─────────────────────────┐
│ Component Quality │
└─────────────────────────┘
|
High-Quality Final Product
This structure connects the properties of software components to the overall software
quality by ensuring that component-level quality drives the satisfaction of higher-level goals.
- Describe product versus quality management with neat diagram
- Product-Based Focus:
o Measuring product quality is easier after development is complete.
o Predicting final product quality from early-stage outputs is challenging. - Process-Based Approach:
o Focus on improving development processes to ensure better product quality.
o Fixing errors early is cheaper; later corrections require more rework across
stages. - Development Stage Challenges:
o Errors found later in the process (e.g., during testing) cause rework across
multiple stages.
o As development progresses, changes become harder to implement. - Process Requirements:
o Entry Requirements: Conditions before starting an activity (e.g., test data
prepared before testing).
o Implementation Requirements: Rules for conducting activities (e.g., retest all
cases after fixing an error).
o Exit Requirements: Conditions for completing an activity (e.g., all tests must
pass with no errors).
- Describe in detail about weighted quality scores for an ISO 9126 model.
- Functionality: The software’s ability to meet user needs.
- Reliability: The software’s capability to maintain consistent performance.
- Usability: The effort required to use the software effectively.
- Efficiency: The resources consumed when the software runs.
- Maintainability: The effort needed to modify the software.
- Portability: The software’s ability to adapt to different environments.
Functionality Compliance measures how well software adheres to standards or legal
requirements, like auditing rules. Since 1999, a “compliance” sub-characteristic has been
added to all six ISO quality attributes, focusing on adherence to relevant standards for each
attribute.
Interoperability refers to the software’s ability to interact with other systems. ISO 9126 uses
“interoperability” instead of “compatibility” to avoid confusion with “replaceability,” another
characteristic in the standard.
Maturity refers to the frequency of failures due to faults, with the idea that more usage
uncovers and removes more faults. Additionally, recoverability is distinct from security; while
recoverability focuses on the ability to recover from failures, security pertains to controlling
system access.
Attractiveness is a recent sub-characteristic of usability, particularly important for software
products where users have a choice, such as games or entertainment software, and are not
required to use them
Analysability refers to how easily the cause of a failure can be identified. Changeability (or
flexibility) refers to how easily the software can be modified. Stability means the risk of
unexpected effects from changes is low, not that the software never changes.
- Describe the process diagram in details
When organizations have well-structured processes, they can track and monitor activities like
how many issues are reported and how many defects are found during testing. They can also
measure how much effort is spent on each step, allowing them to fix problems quickly and
manage processes effectively. This is called Level 4 process management.
At Level 5, the focus shifts to improving the processes themselves. For example, if frequent
changes to software requirements are causing many problems, the organization can adjust
the process. One solution might be to simulate hardware components using software tools,
helping engineers create better designs and reduce changes. This also allows testing of
software with simulated hardware earlier, solving problems faster and at a lower cost.
Using the diagram:
1. Define Software Requirements: Start with hardware definitions and identify software
requirements.
2. Review Requirements: Analyze and agree on suggested changes to ensure clarity and
feasibility.
3. Architecture Design: Develop an architecture based on agreed requirements and prepare
work packages.
4. Develop Software: Build software based on the design and handle change requests.
5. Debugging: Identify and fix initial errors in software modules.
6. System Testing: Use test cases to validate the software, and feed error reports back for
improvements.
7. Release Software: Once testing is successful and all issues are resolved, release the final
product
Elaborate the techniques to help to enhance software quality
- Increasing Visibility: Gerald Weinberg introduced “egoless programming,” encouraging
peer code reviews to improve software quality. Techniques like walkthroughs, inspections, and
reviews have become common. - Procedural Structure: Software development has evolved from unstructured approaches to
methodologies with defined steps for each development stage, including structured
programming and clean-room development. - Checking Intermediate Stages: Early focus was on debugging imperfect models. Now,
emphasis is on building smaller, independent components tested early, along with carefully
checking designs to predict quality. - Japanese Influence: Inspired by Japanese practices like quality circles, techniques for
improving quality through collaboration and inspection have gained traction
