[by Dr. Daniel Simon, Head of Professional Services, Axivion GmbH]
There are many definitions of the term quality. On one hand, we have the common sense definitions of “high quality products”, for example, an expensive wristwatch, a fast and impressive sports car, a giant meal (“all you can eat”). The downside to this view on quality is the subjective judgement of the characteristics of the product. Some people may not like the expensive watch due to its weight. Others may not want a sports car all the time (three kids and the dog do not fit in – um, maybe not the best example, could even improve the quality :-)). The car is useless if you need it for an offroad trip. The giant meal is nothing you need if you want to lose weight.
Direct takeaway: quality has multiple dimensions.
In professional software development, often many stakeholders have to agree on a common “quality” to assess the outcome of a development project. A more feasible definition of quality therefore is – cf. [ASQ09]:
“Quality: The characteristics of a product or service that bear on its ability to satisfy stated or implied needs.”
For daily work, we can derive important conclusions here:
- Characteristics are “ego-less”, without human interpretation
- Quality depends on explicitly or implicitly stated needs; therefore, different assessment outcomes are possible based on the different perspectives of different stakeholders when it comes to “implied” needs.
- The development process of the product is not directly of interest for the user of the product.
- Quality can be assessed in an objective way when contrasting characteristics with needs.
“High Quality” means that all needs are met by characteristics of the product (or a component thereof). This can change over time as the implied needs change: e.g. a “high quality” 1998 mobile phone is no longer considered anything useful by the average user in 2020.
Successful projects generate high quality products – consequently, we have to have a clear professional view on
- Characteristics and
- Components
of the product.
From your experience, what are the most important characteristics for embedded software? How would you divide up your software into components?
Get in touch with Dr. Daniel Simon by clicking the Email-button below.
If you would like to find out more about Axivion or our Axivion Suite please follow the links or contact us directly via Chat, contactform or by Email.
