1. Software Quality Warranty
1.1. A technique is using QualiCES method analyzes the consistency among requirement documents and, as a consequence, assumes they are related.
1.2. Another stage of software development is validation, also known as Verification and Validation (V & V). However, “the term ‘validation’ is used inconsistently, both in the literature and in practice”
2. Software Quality Planning
2.1. A quality plan describes how an organisation will achieve its quality objectives. It describes the quality objectives and specifies the quality assurance and control activities to be performed in day-to-day company operations.
3. Software Quality Control
3.1. This includes a set of activities that evaluates information systems (IS) throughout the entire development process to detect anomalies that may negatively affect software quality.
3.2. Techniques
4. Software Quality Culture
4.1. Software culture is that software quality personnel must be knowledgeable of software engineering and design concepts.
4.1.1. A software development culture is encompassing quality is necessary to overcome these kinds of hurdles. Cultural attitudes, such as, "Quality is everybody’s business," and, "Doit right the first time," coupled with a keen perception of software quality can work towards the desired improvement in software products.
5. Software Quality Definition
5.1. Software quality is the extent to which an industry-defined set of desirable features are incorporated into a product so as to enhance its lifetime performance.
5.2. An Engineer called y Peter J. Denning, proposed to reframe the question, from “What is software quality?” to “How do we satisfy the customers of our software?” By making concerns of customer satisfaction central among the criteria for judging software, new actions will appear for making reliable and dependable software.
5.2.1. The job of the software designer is not done until the customer has declared satisfaction. One can distinguish three levels at which a customer can declare satisfaction:
5.2.1.1. (1) All basic promises were fulfilled. The customer assesses that the producer has delivered exactly what was promised and agreed to. This might be called “basic integrity”.
5.2.1.2. (2) No negative consequences were produced. The customer uses the product for a while and encounters no unforeseen problems that cause disruption and perhaps serious losses. The customer assesses that the product’s design has been well thought out and that it anticipates problems that were not apparent at the outset. That this level is distinct from the previous one can be seen in the common anecdotes, “This is what I asked for, but it’s not what I want!” and “It does what they promised but I wish I’d have asked about what it would do in this situation!”
5.2.1.3. (3) The customer is delighted. At this level the product produces no negative consequences and, in fact, goes well beyond the customer’s expectations and produces new, unexpected, positive effects. The customer expresses great delight with the product and often promotes it among others. The customer says the producer is a partner, understands the organization, and contributes to the well being of the customer.
6. Series of Standards ISO/IEC 25000
6.1. Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements
6.1.1. ISO/IEC 2500n, Quality Management Division
6.1.1.1. The International Standards that form this division define all common models, terms and definitions referred to further by all other International Standards from the SQuaRE series. Referring paths (guidance through SQuaRE documents) and high level practical suggestions in applying proper International Standards to specific application cases offer help to all types of users. The division also provides requirements and guidance for a supporting function which is responsible for the management of software product requirements specification and evaluation.
6.1.2. ISO/IEC 2501n, Quality Model Division
6.1.2.1. The International Standard that forms this division presents a detailed quality model including characteristics for internal, external and quality in use. Furthermore, the internal and external software quality characteristics are decomposed into subcharacteristics. Practical guidance on the use of the quality model is also provided.
6.1.3. ISO/IEC 2502n, Quality Measurement Division
6.1.3.1. The International Standards that form this division include a software product quality measurement reference model, mathematical definitions of quality measures, and practical guidance for their application. Presented measures apply to internal software quality, external software quality and quality in use. Measurement primitives forming foundations for the latter measures are defined and presented.
6.1.4. ISO/IEC 2503n, Quality Requirements Division
6.1.4.1. The International Standard that forms this division helps specify quality requirements. These quality requirements can be used in the process of quality requirements elicitation for a software product to be developed or as input for an evaluation process. The requirements definition process is mapped to technical processes defined in ISO/IEC 15288.
6.1.5. ISO/IEC 2504n, Quality Evaluation Division
6.1.5.1. The International Standards that form this division provide requirements, recommendations and guidelines for software product evaluation, whether performed by evaluators, acquirers or developers. The support for documenting a measure as an Evaluation Module is also presented.