Unit IV: Software Qualities and Software Quality Assurance - Software Engineering - BCA Notes (Pokhara University)

Breaking

Monday, September 9, 2019

Unit IV: Software Qualities and Software Quality Assurance - Software Engineering

Software Qualities:

The term software quality describes to what extent is the software good rather best to be implemented for the purpose it has been proposed and developed. It is very important to maintain the software quality because every individual or every company are always willing to use the best system.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Thus, quality refers to the measurable characteristics things that we can compare to known standards such as length, colour, electrical properties and malleability. Based on the measurable characteristics of an item, software quality can be classified into two kinds:

1. Quality of Design:

It refers to the characteristics that the designer specify for an item. The quality of software on the design basis is influenced by the grade of the materials, tolerances and performance specifications. Use of higher-grade materials contribute to higher tolerances and thus specify greater levels of performances, finally increasing the design quality of the product.

2. Quality of Conformance:

It is the degree to which the design specifications are followed during manufacturing. The greater the degree of conformances the higher the level of quality of conformances will be.

Software Quality Factors:

Developing methods that can produce high-quality software is another fundamental goal of software engineering. Factors that affect the quality of software are explained below:
Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

1. Flexibility and Extensibility:

Flexibility is the ability of software to add/modify/remove functionality without damaging the current system. Extensibility is the ability of software to add functionality without damaging system, so it may be thought of as a subset of flexibility. Those functionality changes may occur according to changing requirements, or an obligation if the development process is one of the iterative methods. Change is inevitable in software development and so, this is one of the most important properties of quality software.

2. Maintainability and Readability:

Maintainability is a little similar with flexibility but it focuses on modifications about error corrections and minor function modifications, not major functional extensibilities. It can be supported by user interface definitions, documentation, and self-documenting code and/or code documentation. The more correct and useful documentation exists, the more maintainability can be performed.

3. Performance and Efficiency:

Performance is mostly about the response time of the software. This response time should be in acceptable intervals (e.g. max. a few seconds), and should not increase if transaction count increases. And also, resources are expensive. Efficiency must be supported by resource utilization. As an exaggerated example, the ability to perform a simple function only by using a 32 processor machine or 1 TB disk space is not acceptable. Optimal source/performance ratio must be aimed. 

4. Scalability:

A scalable system responds to user actions in an acceptable amount of time, even if load increases. Of course, more hardware may be added for handling increasing user transaction, but the architecture should not change while doing this. This is called vertical scalability. The ability to run on multiple, increasing count of machines is multiple processing. If the software can perform that type of processing, this is called horizontal scalability. A preferred scalable system should suit both of these methods.

5. Availability, Robustness, Fault Tolerance and Reliability:

A robust software should not lose its availability even in most failure states. Even if some components are broken down, it may continue running. Besides, even if the whole application crashes, it may recover itself using backup hardware and data with fault tolerance approaches. There should always be B and even C, D… plans. Reliability also stands for the integrity and consistency of the software even under high load conditions. So it is relevant with availability and scalability. An unreliable system is also unscalable.

6. Usability and Accessibility:

User interfaces are the only visible parts of software according to the viewpoint of the user. So, simplicity, taking less time to complete a job, fast learnability etc. are very important in this case. The most well-known principle for this property is KISS (Keep It Simple Stupid). Simple is always the best. Usable software should also support different accessibility types of control for people with disabilities.

7. Platform Compatibility and Portability:

Quality software should run on as much various platforms as they can. So, more people can make use of it. In different contexts we may mention different platforms, this may be OS platforms, browser types etc. And portability is about adapting software that can run on different platforms, for being more platform compatible. In this sense, portability is also related to flexibility.

8. Testability and Manageability:

Quality software requires quality testing. Source code should be tested with the most coverage and with the most efficient testing methods. This can be performed by using encapsulation, interfaces, patterns, low coupling etc. techniques correctly. Besides testability, qualified software should be manageable after deployment. It may be monitored for e.g. performance or data usage status or may enable the developer to configure the system easily. Creating a successful logging system is another very important issue about manageability.

9. Security:

Security is a very important issue on software development, especially for web or mobile-based ones which may have millions of users with the ability of remote accessing to the system. We should construct a security policy and apply it correctly by leaving no entry points. This may include authorization and authentication techniques, network attack protection, data encryption and so on. All possible types of security leaks should be considered, otherwise one day only one attack may crash our whole application and the whole company.

10. Functionality and Correctness:

Functionality (or correctness) is the conformity of the software with actual requirements and specifications. In fact, this is the precondition attribute of an application, and maybe not a quality factor but we wanted to point out that as the last quality factor, for taking attention: Quality factors are not meaningful when we are talking about unfunctional software. First, perform desired functionality and produce correct software, then apply quality factors on it. If we can perform both parallelly, it is the best.

Software Quality Assurance (SQA):

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,
Software Quality Assurance is the process of providing the management with the data necessary to be informed about product quality, thus getting confidence that the product quality is meeting its goal. It provides the management with data that identify problems, as a result, the management will be conscious and responsive towards the problems and apply the necessary resources to solve the quality issues.

Software Quality Assurance is a process which works parallel to the development of software. It focuses on improving the process of development of software so that problems can be prevented before they become a major issue. Software Quality Assurance is a kind of Umbrella activity that is applied throughout the software process.

Various persons like software engineers, project managers, customers, salespersons and individuals who serve within the SQA group are responsible for software quality assurance. The SQA group serves as the customer’s representative i.e. people who perform SQA must look at the software from a customers point of view.

Software Quality Assurance Has:

1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism

Software Quality Assurance Activities:

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

1. Creating an SQA Management Plan:

The foremost activity includes laying down a proper plan regarding how the SQA will be carried out in our project. Along with what SQA approach will be we are going to follow, what engineering activities will be carried out, and it also includes ensuring that we have the right talent mix in our team.

2. Setting The Checkpoints:

The SQA team sets up different checkpoints according to which it evaluates the quality of the project activities at each checkpoint/project stage. This ensures regular quality inspection and working as per the schedule.

3. Apply Software Engineering Techniques:

Applying some software engineering techniques aids a software designer in achieving high-quality specification. For gathering information, a designer may use techniques such as interviews and FAST (Functional Analysis System Technique). Later, based on the information gathered, the software designer can prepare the project estimation using techniques like WBS (Work Breakdown Structure), SLOC (Source Line Of Codes), and FP (Functional Point) estimation.

4. Executing Formal Technical Reviews:

An FTR is done to evaluate the quality and design of the prototype. In this process, a meeting is conducted with the technical staff to discuss the actual quality requirements of the software and the design quality of the prototype. This activity helps in detecting errors in the early phase of SDLC and reduces rework effort in the later phases.

5. Having a Multi-Testing Strategy:

By multi-testing strategy, we mean that one should not rely on any single testing approach, instead, multiple types of testing should be performed so that the software product can be tested well from all angles to ensure better quality.

6. Enforcing Process Adherence:

This activity insists on the need for process adherence during the software development process. The development process should also stick to the defined procedures. This activity is a blend of two sub-activities which are explained below in detail:

a. Product Evaluation:
This activity confirms that the software product is meeting the requirements that were discovered in the project management plan. It ensures that the set standards for the project are followed correctly.

b. Process Monitoring:
This activity verifies if the correct steps were taken during software development. This is done by matching the actually taken steps against the documented steps.

7. Controlling Change:

In this activity, we use a mix of manual procedures and automated tools to have a mechanism for change control. By validating the change requests, evaluating the nature of change and controlling the change effect, it is ensured that the software quality is maintained during the development and maintenance phases.

8. Measure Change Impact:

If any defect is reported by the QA team, then the concerned team fixes the defect. After this, the QA team should determine the impact of the change which is brought by this defect fix. They need to test not only if the change has fixed the defect, but also if the change is compatible with the whole project. For this purpose, we use software quality metrics which allows managers and developers to observe the activities and proposed changes from the beginning till the end of SDLC and initiate corrective action wherever required.

9. Performing SQA Audits:

The SQA audit inspects the entire actual SDLC process followed by comparing it against the established process. It also checks whatever reported by the team in the status reports were actually performed or not. This activity also exposes any non-compliance issues.

10. Maintaining Records and Reports:

It is crucial to keep the necessary documentation related to SQA and share the required SQA information with the stakeholders. The test results, audit results, review reports, change requests documentation etc. should be kept for future reference.

11. Manage Good Relations:

In fact, it is very important to maintain harmony between the QA and the development team. We often hear that testers and developers often feel superior to each other. This should be avoided as it can affect the overall project quality.

Software Quality Standards:

In technical terms, Standards can be defined as a set of obligatory requirements established by a general agreement and maintained by a recognized body to impose a uniform disciplined practice.

To get a clear picture let us consider an example, for a global company such as Xiaomi Corporation, who developed the Redmi smartphones. It is working across multiple countries such as Nepal, India, Malaysia, Singapore, Indonesia, Philippines, and South Africa. This means that they are often working across multiple languages, cultures, and ways of operating. Although this could be a potentially dangerous recipe for mistakes and delays when it comes to the development and production of such products. In such cases, the company must follow some protocol/guidelines to ensure that different business units communicate better, reduce the potential for confusion, and quality is never compromised and to make their product globally acceptable. These guidelines/protocols are referred to as “Standards“.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

There are different standards for different products. For example, Xiaomi Corporation may be following below Standards which are applicable for smartphones:

1. ISO/IEC 24755:2007 Standard defines screen icons and symbols with their related functions for Redmi phones.
2. ISO 9241 standard evaluate the software quality of apps
3. ISO 9126 checks external quality such as reliability, usability, portability in different types of smartphones Android or iOS.

In the same manner, ISO / IEC / IEEE with the number 29119 is intended for software testing as a compilation of internationally approved standards in software tests that are followed for any SDLC model in software development for any organization. When we implement the standards, we adopt internationally recognized test standards that will eventually offer our organization a quality focus on the test.

What Are The Basis For Standards?

Here we will consider some points that constitute the pillar for any Standard:
Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

1. Communication:

There is a very important role in common terminology in defining Standards. The Incident Command System (ICS) is a standardized approach that establishes common terminology that allows various incident management and support organizations to work together in a wide variety of area.

2. Certification/Compliance Schemes:

Product certification is the process of certifying a certain product has passed the quality control tests, the performance tests, and meets the qualification criteria. Most of the certification bodies are accredited according to ISO / IEC 17065.

3. Guidelines For The Benchmark Of Good Industry Practice:

Guidelines define “What they are and how to use them?” Benchmarking is the continuous process of comparing business performance metrics and processes with the best-known methods of the industry. The dimensions typically measured are time, quality, and cost.

4. Importance of Interoperability and Consistency:

These terms play a key role in designing a Standard. Interoperability refers to the basic ability of a system to easily connect and communicate with each other, even if they were developed by very different manufacturers in different countries. Consistency is the condition of a product of being consistent in different types of environment.

Importance of Standards:

Standards provide mutually agreed guidelines and instructions to people and organizations with a basis for mutual comprehension and are used as tools to facilitate measurement. 

Here Are A Few More Reasons:

1. Standards facilitate business interaction.
2. Instruct companies to comply with relevant laws and regulations.
3. They are responsible for the introduction of innovative products to the market.
4. Aims to provide interoperability between new and existing products, processes and services.

Some Organizations With Their Standards:

1. ISO Software Testing Standards:

The International Organization for Standardization (ISO) having headquartered in Geneva, Switzerland, and works in 164 countries. Over twenty thousand standards have been developed and publish by ISO covering everything from technology, software quality to manufactured product, agriculture, and healthcare.

We Have Five Standards Within The ISO/IEC 29119 International Software Testing Standard:
a) ISO/IEC 29119-1: This was published in Sep 2013 and deals with concepts and definitions of software.

b) ISO/IEC 29119-2: This Standard deals with test processes in a product and was published in Sep 2013.

c) ISO/IEC 29119-3: This was published in Sep 2013 and deals with test documentation of the product.

d) ISO/IEC 29119-4: This Standard was published one year later in 2014 and deals with testing techniques and strategies used in software testing.

e) ISO/IEC 29119-5: This Standard was published in the year 2015 and deals with keyword-based software testing.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

ISO/IEC 9126:
This ISO standard deals with the following key aspects to determine the quality of a software application:
1. Overview of Quality model
2. Defining External metrics
3. Defining Internal metrics
4. Quality standard in use metrics

This standard ensures that the software must have the following characteristics to ensure the quality:

1. Functionality:
Functionality is defined as a set of attributes that perform the specified task. Some of the attributes of functionality are suitability, accuracy, interoperability, security, and functionality compliance.

2. Reliability:
Reliability is the capacity of software to maintain a failure-free software operation for a specified period in a specified environment. Some of the attributes of reliability are Maturity, fault tolerance, recoverability, and reliability compliance.

3. Usability:
Usability refers to the effort a user needs to put while exploring products or systems, including websites, software, devices, etc. Some of the attributes of usability are understandability, learnability, operability, attractiveness, and Usability compliance.

4. Efficiency:
Efficiency is defined as the ratio of output to input expressed in terms of percentage. It is the calculation between the level of performance of the software and the number of resources used, under predefined conditions. Some of the attributes of efficiency are time behaviour, resource utilization, and efficiency compliance.

5. Maintainability:
Maintainability is the amount of effort needed to make specified modifications. It is the measures of the time and speed with which a system needs to restore after a failure occurs. Some of the attributes of maintainability are analyzability, changeability, stability, testability, and maintainability compliance.

6. Portability:
Portability is the ability of software to be transferred from one environment to another. Some of the attributes of portability are adaptability, installability, co-existence, replaceability, and portability compliance.

ISO/IEC 9241-11:
This standard deal with the extent that a product maybe utilized by a specific user to attain some goals with effectiveness, potency, and satisfaction during a fixed context of use.

This standard suggested a framework that identifies and describes the usability components and the relationship between them. User performance and satisfaction are the key points for usability in this standard. According to ISO 9241-11, usability depends on the context of use and therefore the level of usability can amendment because the context changes.

ISO/IEC 25000:2005:
ISO/IEC 25000:2005 this standard provides the guidelines for Software Quality Requirements and Evaluation (SQuaRE). SQuaRE replaces ISO-9126 and ISO-14598 old ISO Standards. This standard helps in organizing and enhancing the method associated with code quality necessities and their evaluations. 

SQuaRE Is Divided Into Sub-parts Such As:
1. ISO 2500n − This standard is known as Quality Management Division
2. ISO 2501n − This standard is known as Quality Model Division
3. ISO 2502n − This standard is known as Quality Measurement Division
4. ISO 2503n − This standard is known as Quality Requirements Division
5. ISO 2504n − This standard is known as Quality Evaluation Division

The Main Contents Provided By SQuaRE Are:
1. Terms and definitions used for the product
2. Reference Models used for development
3.  A general guide for the users
4. Individual division guides for the users

All Standard related to Requirement Engineering (i.e. specification, planning, measurement, and evaluation process)

ISO/IEC 12119:
This standard applies to software packages. It defines the requirements for software packages and instructions on how to test a software package against these requirements. This standard does not deal with the production process only with software packages as offered and delivered.

The Main Contents Are Related To The Following Items:
1. Establishment of the requirements for software packages.
2. Define and describe instructions for testing a delivered software package against the specified requirements.

2. IEEE - Software Testing Standards:

The Institute of Electrical and Electronics Engineers (IEEE) having its corporate office in New York City and its operations centre in Piscataway, New Jersey.  As of 2018, it has more than 423,000 members in over 160 countries around the world. IEEE publishes tutorials and standards related to electrical and electronics engineering and computer science fields.
Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

IEEE series defines an internationally-agreed set of standards for software testing of software testing standards. The main purpose of the IEEE series is to provide such guidelines that can be used by any organization when performing any form of software testing.

1. IEEE 829: IEEE Standard defines a for the format for software test documentation. These documents are used in different stages of software testing.

2. IEEE 1061: This standard defines the approach for constructing quality requirements, analyzing, identifying, implementing validating the process, and product of software quality metrics.

3. IEEE 1059: This standard provides a complete guide for Software Verification and Validation Plans.

4. IEEE 1008: This standard provides a complete standard for unit testing.

5. IEEE 1012: This standard provides a complete standard for Software Verification and Validation.

3. CMM (Capability Maturity Model) Software Testing Standard:

The Capability Maturity Model (CMM) is a development model created by the software community in 1986. The US. Department of Defence-funded this research.

Capability Maturity Model was developed by the software community in 1986. It describes the principles and practices for the underlying software development lifecycle. It is meant to assist software system organizations to improve the maturity of their software system processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes.
Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,
The Capability Maturity Model Is Organized Into Five Maturity Levels:
1. Initial Level:
Defines the disciplined process, standard, predictable process, consistent process, continuously improving process, etc.

2. Repeatable Level:
This level specifies the key practice areas such as requirements management, Software project tracking & oversight, Software project planning, Software subcontract management, Software configuration management, Software quality assurance, etc.

3. Defined:
This level of CMM concentrates on the key practice areas which are organization process focus, software product engineering, organization process definition, integrated software management, training program, intergroup coordination, Peer reviews, etc.

4. Manageable:
The key practice areas for this level can be quantitative process management and software quality management.

5. Optimizing:
This level specifies guidelines for defect prevention, technology change management, and process change management.

4. SEI Software Testing Standard:

The Software Engineering Institute (SEI) is headquartered in Pittsburgh, Pennsylvania. This project was initiated by the U.S. Defense Department to improve software development processes.

Software Engineering Institute (SEI) initiated by the U.S. Defense Department to motivate the improvement of software development processes. 

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

The SEI Addresses Significant And Generalized Software Engineering Problems For:
1. Creation of prototypes and open-source software.
2. Identify and add value to new innovative technologies, emergent or underutilized technologies.
3. Motivating research.
4. Improvement and adaptation of existing solutions.

The SEI Capability Maturity Model (SEI CMM) helped organizations to improve the quality of the software they develop. SEI was established to optimize the process of acquiring, developing, and maintaining heavily software-reliant systems. SEI advocates industry-wide adoption of the CMM. The SEI CMM is similar to ISO 9001, one of the ISO 9000 series of standard.

5. ANSI Software Testing Standard:

The American National Standards Institute (ANSI) publishes some software-related standards in conjunction with the IEEE and ASQ. Headquarter of this organization is in Washington, DC, and operations office is located in New York City.

The American National Standards Institute (ANSI) is a non-profit organization with a private membership that coordinates the development of the voluntary national standards of the United States and is the member of the United States of the International Organization for Standardization (ISO).

American National Standards Institute publishes some standards related to the software in conjunction with IEEE and ASQ (American Society for Quality).

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,
The ANSI / IEEE 829-1983 Standard Describes A Test Plan Such As:
“A document that describes the focus, scope, timeline, resources and of the planned test activities. Identify the characteristics of be tested, test elements, the test tasks, who will perform each task and any a risk that requires contingency planning.”

1. The standards should provide a description of the characteristics from which competitive and interoperable implementations can be developed.

2. ANSI strongly discourages any use of software that is inconsistent with this set of guidelines.

3. ANSI recommends that copyrighted software be included for informational purposes only or in ways that do not require particular implementations of the standard.

4. The object code should never be included in a standard as a regulatory requirement. ANSI recognizes that there may be circumstances in which software is included if it is accompanied by the appropriate legal permits. It can facilitate the development of multiple, competitive and interoperable implementations of the standard.

Software Review:

Software Review is a systematic inspection of software by one or more individuals who work together to find and resolve errors and defects in the software during the early stages of Software Development Life Cycle (SDLC). A software review is an essential part of Software Development Life Cycle (SDLC) that helps software engineers in validating the quality, functionality and other vital features and components of the software. It is a whole process that includes testing the software product and it makes sure that it meets the requirements stated by the client.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Usually performed manually, software review is used to verify various documents like requirements, system designs, codes, test plans and test cases.

Objectives of Software Review:

1. To improve the productivity of the development team.
2. To make the testing process time and cost-effective.
3. To make the final software with fewer defects.
4. To eliminate the inadequacies.

Process of Software Review:

The process of software review is a simple one and is common for all its types. It is usually implemented by following a set of activities, which are laid down by IEEE Standard 1028. All these steps are extremely important and need to be followed rigorously, as skipping even a single step can lead to a complication with the development process, which can further affect the quality of the end product.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

1. Entry Evaluation:

A standard check-list is used by entry criteria to ensure an ideal condition for a successful review.

2. Management Preparation:

During this stage of the process, a responsible management ensures that the software review has all the required resources, which includes things like staff, time, materials, and tools.

3. Review Planning:

To undergo a software review, an objective is identified. Based on the objective, a recognized team of resources is formed.

4. Preparation:

The reviewers are held responsible for preparing group examination to do the reviewing task.

5. Examination and Exit Evaluation:

In the end, the result made by each reviewer is combined all together. Before the review is finalized, verification of all activities is done that are considered necessary for an efficacious software review.

Types of Software Review:

There are mainly three types of software reviews, all of which are conducted by different members of the team who evaluate various aspects of the software. Hence, the types of software review are:

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

1. Software Peer Review:

Peer review is the process of evaluating the technical content and quality of the product and it is usually conducted by the author of the work product, along with some other developers. According to "Capacity Maturity Model", the main purpose of peer review is to provide “a disciplined engineering practice for detecting or correcting defects in the software artefacts, preventing their leakage into the field operations”. In short, peer review is performed to determine or resolve the defects in the software, whose quality is also checked by other members of the team.

Types of Peer Review:
1. Code Review:
To fix mistakes and to remove vulnerabilities from the software product, systematic examination of the computer source code is conducted, which further improves the quality & security of the product.

2. Pair Programming:
This is a type of code review, where two programmers work on a single workstation and develop code together.

3. Informal:
As suggested by its name, this is an informal type of review, which is extremely popular and is widely used by people all over the world. Informal review does not require any documentation, "entry criteria", or a large group of people. It is a time-saving process that is not documented.

4. Walkthrough:
Here, a designer or developer lead a team of software developers to go through a software product, where they ask a question and make necessary comments about various defects & errors. This process differs from "software inspection" and technical review in various aspects.

5. Technical Review:
During the process of technical review a team of qualified personnel review the software and examine its suitability to define its intended use as well as to identify various discrepancies.

6. Inspection:
This is a formal type of peer review, wherein experienced & qualified individuals examine the software product for bugs and defects using a defined process. Inspection helps the author improve the quality of the software.

2. Software Management Review:

These reviews take place in the latter stages by the management representatives. The objective of this type of review is to evaluate the work status. Also, based on such reviews decisions regarding downstream activities are taken.

3. Software Audit Reviews:

"Software Audit" review or software review is a type of external review, wherein one or more auditors, who are not a part of the development team conduct an independent examination of the software product and its processes to assess their compliance with stated specifications, standards, and other important criterion's. This is done by managerial level people.

Cost Impact of Software Defects:

The cost of defects identified during Software Testing, completely depends on the impact of the defects found. The earlier the defect is found, easier and less costly it is to fix these defects. For instance, if there is a defect found in the project requirement specifications and analysis, then it is relatively cheaper to fix it.

Similarly, if the defects or failures are found in the design of the software, then the product design is corrected and then re-issued. However, if these defects somehow get missed by testers and if they are identified during the user acceptance phase, then it can be way too expensive to fix such type of errors.

If during the software development process, an error is made and the consequent defect is detected in the requirements phase itself, then it is relatively cheaper to fix it. This is because the software is not yet in a developing stage and it is easy to make requirement specified changes.

However, if an error is made during the requirement phase and goes undetected until it is found during the designing phase, then it can be a little bit expensive to fix this error. In this case, the error is made in the requirement phase. Now, the software is designed according to these faulty requirements. Hence, when the error is found, it becomes a little expensive to revert back the mistakes done in the requirement phase.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Now the same concept can be applied to understand why it is highly costly to fix defects found in the construction phase. Consider an error made in the developing phase and the consequent defect is not found until the acceptance testing is done or even till the time when the system has been first implemented. In that case, it will be very expensive to redo the entire work to match the specifications and design needed. Moreover, this one defect may very well propagate to other parts of code and design for which testing is done again to reach the point of confidence in the software quality.

Sometimes, it may also happen that the defects that are detected at a very late stage are not even corrected because the cost of fixing that defect is very high. This greatly depends on how serious the defect detected is.

Defect Amplification and Removal:

The defect amplification model can be used to describe the detection and generation of errors during preliminary design, detail design and coding steps of the software engineering procedure. The model is describing schematically in the given Figure Defect Amplification Model a box is represents a software development steps. In the duration of these steps the step, errors may be inadvertently occurring. 

The review may fail to uncover newly generated errors and errors from previous steps resulting in some number of errors which are passed by. Some cases errors passed by from earlier steps which are amplified (amplification factor, x) through current work. The box subdivisions represent each of these characteristics and the percent efficiency for detecting bugs a function of the thoroughness of review.

In Figure Defect Amplification No Reviews describes a hypothetical example of defect amplification for a software development procedure in that no reviews are conducted. Describe in the figure each test step is supposed to uncover and correct 50 % of all incoming errors without introducing any new errors an optimistic assumption 10 preliminary design errors are amplified to 94 errors the previous testing commences. 12 latent defects are released to the area. 

The Figure Defect Amplification Review Conducted considers the similar conditions except which code and design reviews are conducted as categorised of each development step. In this case, ten initial preliminary design errors are amplified to 24 errors previously testing commences. Only 3 latent defects exist. Through recalling the relative costs related to the correction and discovery of errors overall cost with and without review for our hypothetical example can be built. In the Table, it can be seen which total cost for maintenance and development when reviews are organized is 783 cost units when no reviews are conducted total cost is 2177 units-nearly 3 times more costly.

To conduct reviews a developer must expend effort and time and the development company must spend money.  Moreover, the results of the preceding example leave little doubt which we have encountered a pay now or pay much more lately syndrome. The formal technical reviews for design and other technical activities give a demonstrable cost advantage. They should be organized.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,
Fig: Defect, Amplification Model,
Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,
Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Formal Technical Review (FTR):

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

The FTR (Formal Technical Review) is a software quality assurance activity with objectives such as:
1. To uncover errors in function, logic or implementation for any representation of the software.
2. To verify that the software under review meets its requirements.
3. To ensure that software has been represented according to predefined standards.
4. To achieve software that is developed uniformly.
5. To make projects more manageable.

FTR (Formal Technical Review) is also a learning ground for junior developers to know more about different approaches to software analysis, design and implementation. It also serves as a backup and continuity for the people who are not exposed to software development so far. FTR (Formal Technical Review) activities include walkthroughs, inspection and round-robin reviews and other technical assessments.

Review Meeting:

Every review meeting should abide by the following constraints:
1. Between 3 to 5 people (typically) should be involved in the review.
2. Advance preparation should occur but should require no more than two hours of work for each person.
3. The duration of review meeting should be less than two hours.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Given these constraints, it should be clear that an FTR focuses on a specific (and small) part of overall software so that the FTR has a higher likelihood of uncovering errors. The focus of FTR is on a work product (example: a portion of requirement modes, a detailed component design source code, etc.). The individual who has developed the work product (producer) informs the project leader that the product is complete and review is required.

The project leaders contacts a review leader, who evaluates the product for readiness, generates copies of product material and distribute them to reviewers for advance preparation. Each review is expected to spend 1 to 2 hours, reviewing the product, making notes, and otherwise become familiar to work. Concurrently, the review leader also reviews the product and establishes an agenda for the review meeting, which is typically scheduled for the next day.

The review meeting is attended by the review leader and all the reviewers and the producer. One of the reviewers takes on the role of recorder i.e. who records (in writing) all important issues raised during the review.

The FTR begins with the introduction of the agenda and a brief introduction by the producer. When valid problems or errors are discovered the recorder note each. At the end of the review, all attendees of the FTR must decide whether to:
1. Accept the product without further modifications.
2. Reject the product due to server errors (once corrected another review must be performed).
3. Accept the product provisionally (minor errors have been encountered and must be correct, but no additional review will be required)

After complete, all reviewer needs to sign off.

Review Reporting and Record-Keeping:

During the FTR, a reviewer (the recorder) actively records all issues that have been raised. These are summarized at the end of the review meeting, and the review issues list is produced. Also, an FTR summary report is completed. 

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

A Review Summary Report Answers Three Questions:

1. What was reviewed?
2. Who reviewed it?
3. What were the findings and the conclusions?

A review summary report is a single-page form (with possible attachments). It becomes part of the project historical record and may be distributed to the project leader and other interested parties. 

The Review Issue List Provides/Serves Two Purposes:

i. To identify problem areas within the product and
ii. To serve as an action item checklist that guides the producer as corrections are made. An issue list is normally attached to the summary report.

Review Guidelines:

Guidelines for the conducting of formal technical review must be established in advance. These guidelines must be distributed to all reviewers, agreed upon, and then followed.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Guideline For Review May Include Following Things:

1. Concentrate on work product only. That means to review the product, not the producers.
2. Set an agenda of a review and maintain it.
3. When certain issues are raised then debate or arguments should be limited. Reviews should not ultimately result in some hard feelings.
4. Find out problem areas, but don’t attempt to solve every problem noted.
5. Take written notes (it is for record purpose)
6. Limit the number of participants and insists upon advance preparation.
7. Develop a checklist for each product that is likely to be reviewed.
8.  Allocate resources and time schedule for FTRs to maintain the time schedule.
9. Conduct meaningful training for all reviewers to make reviews effective.
10. Reviews earlier reviews which serve as the base for the current review being conducted.

Review Checklist:

Review phase includes checking for the right use of language is information provided accurate and does it simplify the task at hand for the users. While reviewing a technical document, follow this checklist to ensure a document is complete and error-free.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Some Important Aspects of the Review Checklist Are:

1. Audience & Purpose:
Check if the document:
a) Clearly defines the individuals who should read this document.
b) Tells what the document will help the audience do.
c) Uses words readers can understand.

2. Usability:
Check the document for:
a) Readability issues: Ensure the document uses everyday words, short sentences, active voice, verbs not nouns, personal pronouns.
b) Conciseness: Make sure the document has no unnecessary content, not wordy.
c) Findability: Check key terms match users’ language, the page title is informative, headings and links use key terms.
d) Scannability: Verify page looks uncluttered, the page is structured well uses good headings, makes use of paragraphs, lists, tables, images, links etc.

3. Accessibility:
Check if:
a) Images have appropriate text alternatives.
b) Links are clearly worded.
c) Headings use correct heading tags (h1, h2, h3).
d) No tags are used purely for visual effect.

4. Editing:
Check the document for:
a) Use of present tense and active voice
b) Unnecessary words
c) Gender-neutral wording.
d) Lower, mixed, and upper case combinations. Check if the title is consistent across the document.
e) Numbering, ensure the task starts with numbers
f) Consistent use of the product name
g) Adherence to the company style guide
h) Use of UK and US English in the same document.
i) Procedures, the steps/procedures should start with verbs (action verbs).
j) Subject/verb agreement
k) Misspelt words (do not rely solely on a spell checker).
l) Correct use of punctuation
m) Bulleted and numbered lists have parallel construction and consistent punctuation.
n) Numbers, spell out isolated numbers from one to ten.
o) Apostrophe (‘), Find every apostrophe (‘) and replace all contractions with the fully spelt out words, for example, “don’t” becomes “do not.”
p) En dash -, em dash —, and noun groups, use them correctly.
q) And and or, no sentence should use and /or together.
r) Parallelism
s) Hyperlinks, check if all hyperlinks work.

5. Design:
Check the document for:
a) Consistent use of the version number
b) Consistent use of logos
c) Figures and tables numbered correctly and appear in the correct location.
d) Figures, tables and appendices referred to accurately
e) Heading levels, heading levels should follow sequentially. If we create one subhead, we must have at least two. For example, do not create heading 1.1.1 without a heading 1.1.2. If the information for only one subhead exists, it should all appear under the main heading, 1.1.

6. Pagination:
a) Glossary, it should identify all key terms.
b) Table Of Content (TOC) and Index entries show updated and validated TOC and index entries.
c) Check if the document looks fine. That is, how does it look in page preview? Are there any windows/orphans, or lost heads? Is there enough white space? Is there wasted white space? etc.

A good reviewer ensures the document is error-free both factually and grammatically. A review checklist is a handy guide to follow for all the technical writers while reviewing a document. Always check the document for scannability, accessibility, and consistent design.

Formal Approaches to SQA:

Software quality can be achieved through competent software engineering practice as well as through the application of technical review, testing strategies, better control of software work products and the changes made to them, standard accepted, etc. But the software engineering community has argued that a more formal approach to SQA is required.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

It can be argued that a computer program is a mathematical object. Syntax and semantics can be defined for every programming language and approach to the specification of software requirements are available. So, different approaches are necessary for Software Quality Assurance.

1. Prepares An SQA Plan For A Project.

This type of plan is developed during project planning and is reviewed by all interested parties. The quality assurance activities performed by the software engineering team and the SQA group are governed by the plan. 

The Plan Identifies:
1. Evaluations to be performed
2. Audits and reviews to be performed
3. Standards that apply to the project
4. Procedures for error reporting and tracking
5. All the documents to be produced by the SQA group
6. Total amount of feedback provided to the software project team.

2. Every Participate In The Development Of The Project’s Software Process Description:

The software team has to select a process for the work to be performed. The process description is reviewed by the SQA group for conformance with organizational policy, internal software standards, externally imposed standards and other parts of the software project plan.

3. Software Engineering Activities Are Reviewed To Verify Compliance With The Defined Software Process:

The work of the SQA group is to identify documents and to track deviations from the process and to verify that corrections have been made.

4. Financial Inspection Designated Software Work Products To Verify Conformance With Those Defined As Part Of The Software Process:

The SQA group reviews selected work products; identifies, documents, and tracks deviations; verifies that corrections have been made; and periodically reports the results of its work to the project manager.

5. Ensures That Deviations In Products Are Documented And Handled According To A Documented Procedure:

Deviations in software work and work products may be faced in the project plan, process description, applicable standards or technical work products.

6. Records Reports To Senior Management And Noncompliance:

Noncompliance items are tracked until they are resolved.

Proof of Correctness:

Correctness from a software engineering perspective can be defined as the adherence to the specifications that determine how users can interact with the software and how the software should behave when it is used correctly. If the software behaves incorrectly, it might take a considerable amount of time to achieve the task or sometimes it is impossible to achieve it.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

Important Rules:

Below are some of the important rules for effective programming which are consequences of the program correctness theory:
1. Defining the problem completely.
2. Develop the algorithm and then the program logic.
3. Reuse the proved models as much as possible.
4. Prove the correctness of algorithms during the design phase.
5. Developers should pay attention to the clarity and simplicity of our program.
6. Verifying each part of a program as soon as it is developed.

Statistical Software Quality Assurance:

Statistical SQA reflects the growing trend throughout the industry to become more quantitative about quality. 

Statistical Quality Assurance For Software Implies The Following Steps:

1. Information about software errors and defects is collected and categorized.
2.  An attempt is made to trace each error, and defect to its underlying cause.
3. Using the Pareto principle (80% of the defects can be traced to 20% of possible causes) isolate the 20% (vital few).
4. Once the vital few causes have been identified move to correct the problems that have caused errors and defects.

Example:


Error
Total Number %
Serious Number %
Moderate Number %
Minor Number %
IES
205
22
34
27
68
18
103
24
MCC
156
17
12
9
68
18
76
17
IDS
48
5
1
1
24
6
23
5
VPS
25
3
0
0
15
4
10
2
EDR
130
14
26
20
68
18
36
8
ICI
58
6
9
7
18
5
31
7
EDL
45
5
14
11
12
3
19
4
IET
35
10
12
9
35
9
48
11
IID
36
4
2
2
20
5
14
3
PLT
60
6
15
12
19
5
26
6
HCI
28
3
3
2
17
4
8
2
MIS
56
6
0
0
15
4
41
9
Total
942
100
128
100
379
100
435
100

1. IES: Incomplete or Erroneous Specifications
2. MCC: Misinterpretation of Customer Communication
3. IDS: Intentional Deviation form Specs
4. VPS: Violation of Programming Standard
5. EDR: Error in Data Representation
6. EDL: Error in Design Logic

Clean Room Engineering:

Clean Room Engineering is a software development philosophy that is based on avoiding software defects by using formal methods of development and a rigorous inspection process. The name “clean room” was derived by analogy with semiconductor fabrication units. In these units, defects are avoided by manufacturing in an ultra-clean atmosphere. The objective of this approach is zero-defect software development.

Software Qualities and Software Quality Assurance, Software quality, Software quality assurance, Software quality factors, SQA activates, Software quality standards, SEI, ISO, Software reviews, Cost impact of software defects, Defect amplification and removal, Formal technical reviews, The review meeting, Review reporting and record keeping, Review guidelines, A review checklist, Formal approaches to SQA, Proof of correctness, Statistical quality assurance, The clean room process, Clean Room Engineering,

The Clean Room Approach To Software Development Is Based On Five Keys Strategies:

a. Formal Specification
b. Incremental Development
c. Structured Programming
d. Static Verification
e. Statistical Testing of System.

No comments:

Post a Comment

If you have any doubt, then don't hesitate to drop comments.