Producing Quality Software

What is quality software?

Quality Software is all a hotch-potch and trying to sort all the pieces can be simply agitating. The challenge lies in creating and adhering to a balanced system that suits the needs of your users. The quality of software is assessed by a number of variables. These variables can be divided into external and internal quality criteria. External quality is what a user experiences when running the software in its operational mode. Internal quality refers to aspects that are code-dependent, and that are not visible to the end-user. External quality is critical to the user, while internal quality is meaningful to the developer only.
Software quality is not the production of defect-free software—because it is extremely difficult to find and remove every defect from a software application of any significant complexity or size. The absolute number of defects found in software to date, or the relative number, measured against lines of code or Function Points, may serve as an indicator of the quality of a system, but it cannot be the final and only measure of quality.

Measuring software quality:

  • Use automated tools when possible.
  • Use written rules in code reviews.
  • Use passing code reviews as a performance metric (Metric – a way of applying a measurement to a quantity, which allows us to make comparison).

Who is responsible for software quality?

The answer is actually simple- everyone involved with the production of the system is responsible for its quality. However, a number of roles have key responsibilities related to the production of quality software:
  • Users – The customer’s stakeholders and end-users working with the team producing the software have the first level of responsibility. They must be fully engaged and make an effort to communicate clearly their needs and to ensure that the emerging designs will meet their needs.
  • Project Managers – They are responsible for producing a quality system through the application of disciplined processes, clearly defined responsibilities and careful planning. If the Project Managers are unresponsive, indecisive, sloppy, demanding, or uncooperative, we should not be surprised when a system fails to meet its objectives.
  • Business Analysts – Defects in a system are first introduced by Business Analysts when they miss requirements or specify them incorrectly. Thus, Analysts are responsible for quality, and must ensure that the requirements are complete, clear (unambiguous), consistent, verifiable, solution independent, and traceable.
  • Architect– The Architect is responsible for producing a quality system by designing an optimal solution which is cost-effective, uses available technology, meets the specified requirements, will be easy to maintain and enhance, and introduces custom built components only where truly necessary.
  • Designers/Developers – Coders are also responsible for software quality. They need to use good design principles, apply test-driven designs including creating unit test plans before they begin coding, produce clear documentation, and thoroughly test their modules.
  • Documenter(s) – Team members who produce training materials, interactive help, and documents such as procedure manuals are also responsible for producing a quality system by ensuring that what they produce is correct, accurate, and helpful.
  • Configuration Manager– The Configuration Manager is responsible for producing quality software by ensuring that the right version of every required component is present at each stage of integration and testing, and when the system is promoted into the production environment.
  • Testers – By the time a system reaches System Testing, it will either be a quality system or it will not be. Yet, along with all other roles, Testers are responsible for producing a quality software by ensuring that the system’s functionality meets the specified requirements, performs (e.g. meets minimum expected response and transaction processing times), and feeds data correctly to other systems with which it integrates.

Conclusion:

Every application has a natural lifespan. Maintenance should extend this life by fulfilling requirements at the lowest possible cost of software quality. Any major increase to complexity of the application should be subject to cost benefit analysis.

image credit: theiia.org