Handout13.docx

**Week\#14 - Quality Management** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - Software quality...

**Week\#14 - Quality Management** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - Software quality | | | | - Standards for software | | | | - Inspections and reviews | | | | - Agile development and quality management | | | | - Software measurement | +-----------------------------------------------------------------------+ **Managing the quality of software** Controlling whether a software product meets the necessary standards for quality. There are three main issues that quality management focuses on: - At the organizational level, it establishes a framework of standards and procedures that will result in high-quality software. - Applying specific quality methods and ensuring that they have been followed are part of quality management at the project level. - Another aspect of quality management at the project level is developing a quality strategy for a project. The quality plan should include information on the project\'s quality objectives as well as the policies and guidelines that will be adhered to. **Quality control procedures** Quality control independently examines the software development process. In order to ensure that the project deliverables are in line with the organization\'s goals and standards, they are reviewed as part of the quality management process. To examine the product objectively, the quality team should be separate from the development team. They may talk about software quality as a result without being influenced by problems with software development. Figure 14.1. The development of software and quality management **Quality planning** A quality plan highlights the main quality variables, describes the wanted product attributes, and describes how they are evaluated. The quality strategy has to outline the procedure for evaluating quality. When necessary, it should identify new standards to be used and specify which organizational standards should be used. In quality plan, the following details should be concerned:- - A suitable plan\'s structure - Product plans - Outlined processes - Quality objectives - Risks and risk control. **Guidelines for quality control** For large, complicated systems, quality control is especially crucial. As the development team changes, the quality documentation serves as a record of progress and promotes development continuity. Less documentation is required for smaller systems, and quality management should concentrate on creating a quality culture. Agile development requires the evolution of methods. **Software quality** Simply said, quality means that a product need to adhere to its specifications. This presents a challenge for software systems. - Some quality requirements are challenging to define in a clear manner. - There is a disagreement on the standards for customer and developer quality. - Software specifications are typically incomplete and frequently inconsistent. \'Fitness for purpose\' may be the main consideration rather than specification fulfilment. Fitness for the purpose of the software:- - Is the software\'s performance suitable for everyday use? - Is the application trustworthy enough to be used? - Can the application be used? - Were the development process\'s coding and documentation standards followed? - Is the program well-organized and easy to use? - Has the software undergone adequate testing? Characteristics of good quality software ------------------------------------------ ------------------- -------------- Usability Efficiency Learnability Security Robustness Resilience Safety Understandability Testability Portability Reliability Modularity Complexity Reusability Adaptability **Non-functional properties** A software system\'s non-functional properties have a significant role in determining its subjective quality. This is consistent with real-world user experience; if a piece of software doesn\'t perform as intended, users will frequently just find a method to get around it. They will, however, be unable to accomplish their objectives if the program is unstable or too slow. **Quality conflicts** Any system cannot be optimized for all of these characteristics; for instance, increasing robustness may result in decreased performance. Therefore, the most crucial quality characteristics for the software that is being built should be defined in the quality plan. A definition of the quality assessment process, which is a common method of determining whether a certain quality, like robustness or maintainability, is present in the product, should also be included in the plan. **Quality of the production process and the final product** The standard of the production process has an impact on the quality of a generated product. Because some aspects of product quality are challenging to evaluate, this is crucial in software development. It is extremely complicated and poorly understood how software development practices relate to product quality. Software development places a high priority on the use of an individual\'s unique abilities and experience; nonetheless, external factors like the innovation of an application or the necessity for a quick turnaround time may degrade the quality of the final product.  Figure 14.2. Process-based quality **Quality culture** Quality managers need to establish a \"quality culture\" within the software development team in order to achieve a high level of product quality. Teams should be encouraged to take responsibility for the quality of their work and to generate original suggestions for improving it. They should encourage all team members to act professionally and help those who are interested in the intangible components of excellence. **Standards of Software** Standards specify the qualities that a method or product must have. They are essential to quality management. Standards could be organizational, national, international, or project-specific. **Standards\' importance** Including best practices prevents repeating previous errors. They provide a framework for defining what quality means in a certain context, or from the perspective of that organization. They offer continuity since new employees can understand the organization by familiarizing themselves with the standards that are applied. **Standards for processes and products** - **Process standards**: These describe the steps that must be taken when creating software. Process standards could include descriptions of the specification, design, and validation procedures as well as the documentation that needs to be produced throughout each of these stages. - **Product standards**: Apply them to the software that is being developed. They include document standards, which define things like the format of requirements papers and comment headers in documentation, as well as coding standards, which outline how a programming language should be used. +-----------------------------------+-----------------------------------+ | Standards for processes and | | | products | | +===================================+===================================+ | Process standards | **Product standards** | +-----------------------------------+-----------------------------------+ | - Conduct design reviews | - Form for design review | | | | | - submission of fresh software | - Structure of requirements | | for system creation | documents | | | | | - Versioning procedure | - Format for method headers | | | | | - Process for approving a | - programming language Java | | project plan | | | | - Format for a project plan | | - Change management procedure | | | | - Request for Change form | | - Trial recording procedure | | +-----------------------------------+-----------------------------------+ **Difficulties with standards** - They could not be considered current and relevant by software engineers. - They frequently need to fill out excessive amounts of paperwork. - If they are not supported by software tools, complicated form-filling effort is frequently needed to keep the standards\' associated documentation current. **Standards establishment** Participate in development as practitioners. Engineers need to be aware of a standard\'s justification. Regularly evaluate standards and their application. The credibility of standards is lowered among practitioners because they might soon become out of date. Specialized tool support should be available for detailed standards. The most significant standard-violating complaint is excessive clerical work. **Framework of standards ISO 9001** a group of international norms that can serve as the foundation for creating quality management systems. The most inclusive of these standards, ISO 9001, is applicable to businesses that create, develop, and support products, including software. A framework for creating software standards is provided by the ISO 9001 standard. It describes core quality principles, specifies quality processes generally, and lays out the standards for organizations and procedures that are required to be created. These ought to be listed in a manual on organizational quality. Figure 14.3. Core processes of ISO 9001 standard framework **Certification to the ISO 9001 standard** An organizational quality manual should contain documentation of the quality standards and practices. A third party may certify for the ISO 9000 compliance of a company\'s quality handbook. Although the necessity for flexibility in this area is becoming more and more acknowledged, some consumers demand that providers have an ISO 9000 certification. **Quality software and ISO 9001** Being that complying with standards is how quality is defined in the ISO 9001 certification, it is insufficient. It gives no consideration to how well the program is received by users. For instance, a business could establish test coverage requirements that require all methods in every object to be used at least once. Unfortunately, this requirement can be satisfied by software testing that is only partially complete and does not include tests using various method parameters. The business may be granted ISO 9001 certification provided that the specified testing methods are followed and test records are kept. **Quality Reviews and inspections** To identify potential issues, a group evaluates all or a portion of a process or system, as well as its documentation. At a review, software or documentation may be \"signed off,\" indicating that management has approved moving on to the next development step. There are various review formats with various goals:- - Reviews for progress assessment (product and process). - Inspections for fault removal (product). - Quality reviews (product and standards). In Quality reviews, a software system\'s documentation and some or all of it are carefully inspected by a group of people. It is possible to review code, designs, specs, test plans, standards, etc. At a review, software or documentation may be \"signed off,\" indicating that management has approved moving on to the next development step. **The review procedure\'s phases** - **Pre-review**: focus on planning and preparing for reviews. - **The meeting for review**: During the review meeting, the author of the software product or document being analyzed should \"walk through\" the document with the review panel. - **Post-review**:  take care of the issues and difficulties brought up during the review meeting.  Figure 14.4. The process of software review procedure's phases **Review distribution** The following review procedures presuppose that the review team meets in person to discuss the software or papers under evaluation. However, it is difficult for team members to physically meet because project teams are now frequently distributed, sometimes across continents. Remote reviewing can be facilitated by using shared documents that review team members can each annotate with their remarks. **Software inspections** These peer assessments involve engineers looking at the system\'s origin in an effort to find defects and anomalies. Inspections can be utilized prior to implementation because they don\'t call for system execution. They can be used with any type of system representation, including requirements, designs, configuration data, test results, etc. They have been proven to be a useful method for locating programming faults. **Checklists for inspections** The inspection should be guided by a checklist of common errors. Error checklists depend on the programming language and reflect the typical errors that are most likely to occur in the language. In general, the checklist grows larger the \"weaker\" the type checking. Examples include initialization, name constants, ending loops, array boundaries, etc. +-----------------------------------+-----------------------------------+ | Checklists for inspections | | +===================================+===================================+ | Fault class | **Inspection check** | +-----------------------------------+-----------------------------------+ | Fault input/output | - Is every input variable being | | | used? | | | | | | - Do all output variables | | | receive values prior to being | | | output? | | | | | | - Can data be corrupted by | | | unplanned inputs? | +-----------------------------------+-----------------------------------+ | Storage management errors | - If a connected structure is | | | changed, have all links been | | | successfully reassigned? | | | | | | - If shifting storage is being | | | used, has space been | | | allocated properly? | | | | | | - Does storage that is no | | | longer required get | | | deallocated explicitly? | +-----------------------------------+-----------------------------------+ | Data errors | - Do all variables in a program | | | start off with a certain | | | value before being used? | | | | | | - Has a name been assigned to | | | each constant? | | | | | | - Size-1 or the array\'s size | | | should be the upper bound on | | | arrays? | | | | | | - When character strings are | | | utilized, is a delimiter | | | explicitly assigned? | | | | | | - Is it possible for a buffer | | | to overflow? | +-----------------------------------+-----------------------------------+ | Control errors | - For each conditional | | | sentence, is the condition | | | true? | | | | | | - Is the conclusion of each | | | loop guaranteed? | | | | | | - Is the right bracketing used | | | in compound statements? | | | | | | - Do case statements take into | | | account all possible | | | scenarios? | | | | | | - Has a break been provided if | | | one is necessary after each | | | case in case statements? | +-----------------------------------+-----------------------------------+ | Interaction errors | - Does each call to a function | | | or method have the | | | appropriate number of | | | parameters? | | | | | | - Do the formal and practical | | | parameter types correspond? | | | | | | - Is the order of the | | | parameters correct? | | | | | | - When components access shared | | | memory, do they utilize a | | | similar model of the memory | | | sharing structure? | +-----------------------------------+-----------------------------------+ | Faults in exception management | - Have all potential mistake | | | scenarios been considered? | +-----------------------------------+-----------------------------------+ **Agile development and quality management** Agile development uses informal quality management rather than document-based quality management. It depends on creating a culture of quality in which every team member feels accountable for the quality of the program and takes steps to keep it that way. The agile community has a strong aversion to what it perceives as the administrative burdens associated with standards-based methods and quality procedures, such as those represented in ISO 9001. **Common practice in agile development** - Check before check-in: Once the work is examined in the development system, programmers are responsible for organizing their own code reviews with teammates. - Team members shouldn\'t check in code that breaks the build or otherwise negatively affects the system. To ensure that their code modifications function as expected, developers must test them against the entire system. - Address issues as they arise: If a programmer finds issues or opacities in code created by someone else, they can address these issues themselves rather than reporting them to the original developer. - **Pair reputation**: Due to concerns about delaying the project, pairs may be unwilling to seek for mistakes. - **Mutual misunderstandings**: A pair may have two people who have different understandings of the system requirements. Discussions might validate these mistakes. - **Working relationships**: The pair\'s close working connection, which frequently results in unwillingness to criticize work partners, is likely to hinder their capacity to find defects. **Agile Quality Management on large systems development** - If the client is a major corporation, it can have its own quality management procedures and require the software development firm to provide progress reports that are in line with those procedures. - Informal communications may not be practicable when there are numerous teams located far apart working on development, possibly from different companies. - Without documentation, it may be difficult for new team members to comprehend the development of systems with a long lifespan since the team responsible for the development will change. **Software measurement** The goal of software measurement is to generate a numerical number for each characteristic of a software product or process. This makes it possible to compare methods and procedures in an unbiased manner. Although some businesses have implemented measurement programs, most organizations still don\'t employ software measurement in a systematic way. In this field, there aren\'t many set standards. **Software metric** - Any measurement involving a software system, a procedure, or associated paperwork. The Fog index, the number of person-days needed to produce a component, and the lines of code in a software. - Can be used to anticipate product characteristics or regulate the software development process. - Permit quantification of the software and software process. - Product metrics can be used to identify uncommon sections or make general forecasts. **Process metric types** - The time required to accomplish a specific process: This can include calendar time, the total time allotted to the process, the time committed to the process by specific engineers, etc. - The elements needed for a specific process: Total effort measured in person-days, travel expenses, or computer resources are examples of resources. - The frequency of an event: For instance the number of problem reports in a system that has been deployed, the number of requirements modifications requested, the number of defects discovered during code inspection, the typical amount of lines of code that are changed when a requirement does, and other events can all be tracked. Figure 14.5. Control and predictor measurements **Measuring methods** - To give system quality attributes a numerical number. - To determine whether system components are of poor quality. **Assumptions for metrics** Accurate measurement is possible for software properties. What we can measure and what we wish to know are related in some way. We can only measure internal characteristics, yet exterior characteristics of software are frequently of more relevance. This connection has been acknowledged and formalized. It could be challenging to connect quantifiable qualities to desirable external quality attributes.  Figure 14.6. Software connections between internal and external quality properties **Measurement issues in the industry** - The return on investment of implementing an organizational metrics program cannot be measured. - Neither software metrics standards nor established procedures for measurement and analysis exist. - Software development procedures are frequently not standardized, poorly defined, and managed. - The majority of research on software measurement has concentrated on plan-driven development processes and code-based metrics. But more and more software is currently created by modifying COTS or ERP systems. - Processes take additional overhead when measurement is introduced. **Empirical software engineering** The foundation of empirical software engineering is software measurement and metrics. In this field of study, assumptions concerning software engineering approaches and methodologies have been formed and validated through the use of experiments on software systems and data collection on actual projects. Software engineering practice has not been significantly impacted by empirical software engineering research. It can be challenging to connect general research to a project that is unrelated to the research topic. **Product measurements** Product quality should be predicted by a quality metric. Product metric classes include:- - **Static metrics**, which are gathered through evaluations of system representations. Complexity, understandability, and maintainability can all be evaluated using static metrics. It is connected inadvertently to qualities of quality. The link between these measurements and qualities like complexity, understandability, and maintainability must be determined. - **Dynamic metrics**, which are gathered through observations of software in use. Dynamic measurements are used to evaluate effectiveness and consistency. It is strongly related to the qualities of high-quality software. Measuring the number of failures (reliability attribute) or a system\'s response time (performance attribute) is comparatively simple. Example of static metrics --------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Attributes **Description** Cyclomatic complexity This gauges a program\'s level of control complexity. The program\'s understandability may be connected to this control complexity. Fog index This is a gauge of the typical word and sentence length of documents. The difficulty of understanding a document increases with the Fog index value. Size of the code This serves as a gauge for program size. In general, a component\'s code size indicates how complex and error-prone that component is likely to be. One of the most accurate measures for forecasting component error-proneness has been found to be code length. Fan-in/Fan-out The number of methods or functions that call another function (let\'s say I) is referred to as the fan-in. Fan-out is the total number of functions that function I has called. A high fan-in value indicates that I is closely related to the other components of the design and that changes to I will have significant ripple effects. A high number for fan-out indicates that the complexity of the control logic required to coordinate the called components may be contributing to the overall complexity of I. Conditional nesting depth This gauges how deeply if-statements are nested within a program. If-statements that are deeply nested are difficult to grasp and may be mistake-prone. Identifiers\' length This gauges the typical length of identifiers---variable, class, function, etc.---used in a program. The software will be easier to understand because longer IDs are more likely to have meaning. **Analysis of software components** A variety of metrics can be used to assess each system component independently. These measures\' values can then be compared for various components and possibly with historical measurement information gathered on earlier projects. Anomalous measurements, which considerably depart from the average, may point to issues with the components\' quality. Figure 14.7. The procedure for evaluating products **Uncertainty in the measurement** - You must study the quantitative data you gather about software and software processes in order to comprehend its meaning. - It is simple to analyze data incorrectly and draw erroneous conclusions. - You can\'t just examine the data on your own. The setting in which the data was gathered must also be taken into account. **Surprises in measurement** The amount of help desk calls rises as the number of errors in a program decreases. Because the application is now regarded as being more dependable, it has a larger, more varied market. Although the number of users calling the help desk may have increased overall, the percentage may have declined. When compared to a system where users try to get around the bugs, a more dependable system is used in a different way. More help desk calls result from this. **Summary** - The goal of software quality management is to ensure that there are few errors in software and that it meets the necessary criteria for maintainability, reliability, portability, etc. Software standards are crucial for quality control because they identify \"best practice.\" Standards offer a reliable basis for creating high-quality software while developing it. - A group of professionals review the deliverables of the software process to ensure that quality standards are being upheld. The most popular method for evaluating quality is reviews. - In a peer review or program inspection, a small team thoroughly examines the code. They carefully read the code and scan it for any potential mistakes or omissions. A code review meeting is held to discuss the issues found. - Agile quality management is dependent on creating a culture of quality where the development team collaborates to increase software quality. - Quantitative information about software and the software process can be gathered through software measurement. - Making conclusions about the quality of the products and processes may be possible using the values of the software metrics that are gathered. - Metrics for product quality are very helpful for identifying atypical components that might have quality issues. Then, a more thorough analysis of these components is required.