add reference to quality.arc42.org, a cleaner and pragmatic quality model
gernotstarke opened this issue · comments
the ISO 25010 model lacks important properties (like energy efficiency, deployability, safety), and the strict hierarchy is a nuisance too.
Therefore I created a pragmatic and simple proposal to overcome the known shortcomings of ISO. Without any exam relevance, I propose to add this model plus a reference to the curriculum. Proper LG would be LG 4-1
As I am the author of this model, I ask somebody else to take over with this issue.
PLEASE could anybody add some opinion on the topic!
Opinion: It's about time this topic gets an overhaul. I suppose this might become a long journey bit big thanks to @gernotstarke for getting things started.
I don't have a clear opinion on this.... but I would rather use a global standard... we (iSAQB) could make suggestions to ISO to extend the quality model, right?
Fact: The global standard suffers from some deficits.
I tried to identify any person working on the ISO committee, ended up with anonymous DIN working groups, then gave up.
The ISO has relied upon a strictly hierarchical model since 1996 - so I assume it's impossible to convince them of a tagged model...
(btw - the same holds for the (imho insufficient) notion of "quality tree": It's clearly a graph...
Suggestion: officially make one last try with ISO via iSAQB? Many customers I know have to use ISO. I would like to avoid competing models. If we don't succeed, maybe we can consider developing an "iSAQB Architecture Quality Model". But that will be a long process....
maybe this is the wrong spot for such a discussion, but the official agenda of the iSAQB is not research but qualification and training.
Developing new methodological approaches is, imho, not our intention as a group and association (but left to private or corporate initiatives).
I will publish the aforementioned enhanced and improved arc42 quality model in various papers and at conferences, so it might become better referencable in the near future.
“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” – Buckminster Fuller
I don't think that spending time arguing the legislatosaurus will yield a pragmatic solution any time soon. My students are searching for something that helps them to deliver better software. They don't care whether it's got official approval of being "the one and only right method". There is no such thing - neither in engineering nor in academia.
And they really need it. So I'm in favor of giving @gernotstarke 's proposal a try and see if it flies.
It would be nice to set up an improvement and/or extension process because e.g. for my mental model it's useful to distinguish whether this is a requirement on the system, its architecture or on the development process, but this is another discussion. My point is: Make it work in a way that delivers value to the people that use it and be open for improvement.
As I mentioned earlier, I don't have a clear opinion on this. Referencing something in a curriculum requires a certain maturity and/or review process. This is independent of my personal belief that Gernot's work is always of high quality. My automotive and public sector participants are required to use industry standards. But of course, any trainer can recommend to his/her customers what to use. An official reference in the syllabus reflects the opinion of the iSAQB. Maybe we should wait until the next version? I have been in the quality assessment field for years, so the topic is relevant to me. Right now, it is moving too fast for me to form a clear opinion on the proposal. Besides, I barely have time to look at it.
I'm all for decoupling the curriculum from 25010. This doesn't mean we can't cross-reference there. We should, however, make sure that we don't have 25010 references in the exam. (The mock exam has one.)
What's important to me is fixing the associated terminology.
- "Quality" refers to the attributes a software system has - not primarily the architecture.
- This includes "functionality".
- We should distinguish between attributes and their metrology. (And thus eliminate all the "degree to which" weasly wordings.)
- We should recognize that scenarios are not the only way to measure quality attributes.
- We should distinguish between attributes and requirements of those attributes / their measurements.
- We should distinguish between requirements and tests of those requirements.
- We should not distinguish between "quality requirements" and "functional requirements", as functionalities are part of a system's quality.
I like Q42 as a starting point, but would have some suggestions on refining both the taxonomy and clarifying these terminology boundaries.
From my perspective there is (a lot) more I agree with in @mikesperber 's post than there are tiny island of the topic where I disagree. But as this is way beyond scope of this ticket I decided to start communicating with Mike directly instead of overloading this ticket.
@mikesperber If you think this is the wrong approach, please feel free to copy my (lengthy) text here or open up a new ticket on the lines of "Propagate a novel useful notion of system quality..." ;-)
Concerning this ticket: IMHO we should reference both, ISO25010 and quality.arc42.org.
we added Q42 in the references section. Another issue calls for adding it (together with Bass+2021) to LG-4-1
I have not read Q42 until now. I haven't had the time so far, unfortunately. It would be good to know who has done a review about it or who could still do it.
PS: I am currently in talks with the ISTQB about a joint curriculum regarding software quality. Istqb has contacted me about this.
Personal note: Software quality is NOT only about testing, imho the traditional approach ("quality departement tries to test quality into a product") has failed... When creating a "software quality" curriculum, we should enforce a constructive approach (e.g. something like fitness functions or automated quality acceptance criteria where ever possible) - instead of a "test-based" approach... (most likely THIS issue is a bad place for such a discussion). Btw - I'm currently writing a book about that topic ("Quality Driven Software Architecture").
Exactly, that's why istqb contacted me. Just because software quality is not only a test topic :-). I am glad about your book! Sounds good to me. I can review parts if you need reviewers.
My two cents: I really would like to keep the ISO 25010 standard in the curriculum. It may have drawbacks, but it is still a good list of quality characteristics. I think it is always good to reference international standards. With any standard, there are advantages and disadvantages, but at least it's a place to start and many of my class participants were already aware of ISO 25010.
I also tell my participants, that this is one of many sources for quality characteristics, including Wikipedia (I was not aware about Q42 until now).
P.S. there is a new version of ISO 25010 that also adds Safety as a major section.
My two cents: I really would like to keep the ISO 25010 standard in the curriculum.
That's the intention. @gernotstarke and I propose to keep ISO but make clear that this is only one of several options.
Could you give your feedback on that in #357 ?
I'm all for decoupling the curriculum from 25010. This doesn't mean we can't cross-reference there. We should, however, make sure that we don't have 25010 references in the exam. (The mock exam has one.)
What's important to me is fixing the associated terminology.
- "Quality" refers to the attributes a software system has - not primarily the architecture.
- This includes "functionality".
- We should distinguish between attributes and their metrology. (And thus eliminate all the "degree to which" weasly wordings.)
- We should recognize that scenarios are not the only way to measure quality attributes.
- We should distinguish between attributes and requirements of those attributes / their measurements.
- We should distinguish between requirements and tests of those requirements.
- We should not distinguish between "quality requirements" and "functional requirements", as functionalities are part of a system's quality.
I like Q42 as a starting point, but would have some suggestions on refining both the taxonomy and clarifying these terminology boundaries.
I'm fine with making Quality Characteristics / Attributes as an exam-relevant topic (R1) in the curriculum, with the ISO 25010 and Q42 as possible sources (R3). It should, however, be clear, what attributes are relevant.
@mike: I agree with most of what you say, but I'm especially confused about the last point. I'm not sure what you mean by "functionalities are part of system quality". I don't agree with this as it is stated. The quality would be whether the required functionalities are correctly implemented, but the functionality itself is not the same as quality.
@ALL: Would love to have the discussion with you. I don't think it makes sense in the forum. It would make sense to have a short meeting regarding this topic.
nitpicking: The "new version" is a draft, and as of Feb.23, not an official document.
I'd also welcome a personal discussion (well, or remote personal, but you get the meaning). 🙂
let's try to schedule an in-person-meeting to discuss these topics. "Short" won't be enough, I assume.
We could hijack part of the members' meeting in Mannheim, May 25th or May 26th for that, as our schedules are all tight...
"Functionality" definitely belongs to system qualities (it's part of ISO standards since 1996 and other quality models since the 70's). But aspects like time-to-market also is a quality... which e.g. ISO ignores completely.
"Functionality" isn't part of the quality requirements, rather "functional suitability" "functional correctness" etc. which are for me totally different.
Unfortunately, I am not able to attend the iSAQB meeting this year. It would be nice if we could meet virtually at some point. I'm free most days after 17:00.
Functional suitability
I'm very much in favor of a (virtual) meeting, although a retreat ("Klausurtagung") would be much better.
However, before we continue, let's get a rough sketch of the desired outcome. I can only do that from my point of view and for sure will miss some of your requirements.
Find a means to describe, communicate and document the currently very fuzzy notion of "Quality" regarding IT systems, their architecture and their development process. This means should have the following properties (which still need to be prioritized):
- useful in practice
- easy to learn and teach
- easy to apply
- easy to transition to from currently used means
- easy to communicate
- helpful for deriving concrete actions for the future development of an IT system
- help with making quality measurable (which is not necessarily quantifiable)
- useful also in the case that a precise measurement is not feasible
- precise and concise (yes, there already is a very obvious trade-off)
- hard to misunderstand
- grounded in existing (academic/practical) work on this topic
- easy to adapt to own needs without diluting/abandoning the underlying concept
- extensible for future developments and needs
- provide obvious advantages compared to existing means (yes, we have to convince people to use it)
You might want to add things to this wish list. ;-)
I'd be happy if we set a priority on separating quality requirements from architecture reviews.
Another point is to make clear that they are (one of) the basis for documenting the architecture (what and why), assessing architectures, making decisions, etc.
@rhoadesre You wrote: "I'm not sure what you mean by "functionalities are part of system quality". I don't agree with this as it is stated. The quality would be whether the required functionalities are correctly implemented, but the functionality itself is not the same as quality."
This is splitting hairs a bit, but what your wording describes is a requirement on the functionality. If it's incorrectly implemented, this incorrect functionality is still a property / "quality attribute" of the system.
"Functionality" isn't part of the quality requirements, rather "functional suitability" "functional correctness" etc. which are for me totally different.
This is a a category error: "Functionality" is not a requirement, but a quality attribute, as are "functional suitability" and "functional correctness". This is similar to the way that "system throughput" is a possible quality attribute, and "the system must handle at least 100 req/s" is a requirement on that attribute.
ISO 250xx is - for all its faults - careful to make this distinction. 25010 is only about the attributes, and 25030 is about requirements.