Application of Current Quality Standards

The criteria by which the quality of a product is judge have been standardised globally. In the case of software development, we will use the following two sets of standards:

• ISO/IEC 25010:2011 (software development)
• World Wide Web Consortium (W3C) for web design and functionality standards

Without globally accepted quality standards, it would be impossible to compare the quality of work between different contractors, and there would be huge variation in the quality of delivered goods.

ISO/IEC 25010:2011

Learn this standard – both by name, and by content. You will want to be able to quote it in the exam.

Before going any further, the ISO Website contains the full text and specification of ISO 25010:2011. Note that you have to buy the texts from the iso website, so it isn’t the best resource.

This website contains the BS ISO 25010 paper in full detail – so really worth a read if you want the full content.

https://www.iso.org/standard/35733.html

In short, ISO 25010 defines eight areas whereby the quality can be judged. Note that the standard doesn’t say what the quality should be – that is for the developer and client to negotiate. What it provides is a framework which lists all of the areas that acceptable quality levels should be agreed. (For example, a client may not understand the value in a system built with future maintenance taken into account; having this as one of the quality metrics forces a conversation to take place).

The eight groups are:

1. Functional Suitability – this means how closely does the product meet the needs? For example, that can involve a question of appropriateness: does it include all of the functionality required? It also includes the question of accuracy: if you are given a brief detailing how something should work (a calculation for example), it needs to be performed accurately, not ‘almost correctly’.
2. Reliability – this concerns the ability of a system to deal with unforeseen issues. These could be fault tolerance (how well does it work if one part breaks?), how much of the time it is available (for example a common figure is 99.9% uptime), or how recoverable is the system (what happens in the event of a catastrophe?).
3. Performance Efficiency – deals with both time-behaviour (for example, it should never take more than two seconds between an input being acknowledged and a response granted), and resource-utilisation: it’s no good having a system which requires more hardware or processing resources than you have access to; in this sense, saying ‘it works’ (but you won’t be able to run it because your hardware isn’t good enough) isn’t acceptable.
4. Operability – These metrics cover areas related to the appearance and usability of the system. While there is no single correct design, a developer should make use of the following:
   • Standard interface conventions (e.g. keyboard shortcuts, context menus etc)
   • Helpfulness – this refers to dialog on the system actually benefitting the user. For instance, an error message that says “Invalid value” is less helpful than one that says “Invalid value; must be between 0 and 99”.
5. Security – covers the management of information and data within the system. The areas in the diagram above are:
   • Confidentiality – data and information is inherently secret; it is only available to the appropriate users, for purposes that have been defined
   • Integrity – the accuracy of the data, and any links between records
   • Non-repudiation – the ability to categorically assert that data has been accessed/input/output by a user
   • Authenticity – a means of validating the source of the information
   • Accountability – a means of ensuring that all actions performed within the system can be assigned to a user
6. Compatibility – this defines ways in which the system should coexist with other products (other software or versions of software for example), how it interoperates with other systems, and how replaceable parts of it are. For example, you could assess whether a software system requires a specific build of a specific operating system, or whether it will work with any OS version – these are important criteria.
7. Maintainability – when software is developed, there are certain approaches which aid in future maintenance. For instance, ensuring code is modular (creating discrete blocks of code that deal with only a single task or process) aids future maintenance, as the code is descriptive and it is clear what each section should do. For the same reason, following a Test Driven Development process ensures testability – that the individual units of code can have tests devised and automated against them. Any changes will result in the test results automatically updating, highlighting any software issues.
8. Transferability – refers to the ability of a system to be installed onto new hardware, and how portable the code is: code portability is more of an issue with low-level languages. Something written in (for example) C# or Java is highly portable, and can run on a huge variety of hardware. Software written in C or assembly code for an embedded system would not be highly portable.

As should be clear, the standard is not defining what the quality of a product should be, but it does define a consistent way in which the quality can be gauged.

World Wide Web Consortium (W3C)

“Created in 1994, W3C is an international community of member organizations that articulates web standards so that websites look and work the same in all webbrowsers. Its mission is to lead the World Wide Web to its full potential by developing standards, protocols and guidelines that ensure its long-term growth”.

Web standards cover:

• HTML standards
• CSS standards
• Legal requirements/accessibility (example)

The W3C provide documentation, training, and testing tools to help ensure the web design is as standardised as possible. You are expected to visit and read this page: W3C standards