Talk:Software quality

message: I just read the presentation that is cited as [4] in the article:
"Industry data demonstrate that poor application structural quality in core business applications (such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) or large transaction processing systems in financial services) results in cost and schedule overruns and creates waste in the form of rework (up to 45% of development time in some organizations [4])".
This presentation does not support this claim and also does not included references to scientific papers that would support it. I think this sentence should be removed. Michel  — Preceding unsigned comment added by 82.171.173.73 (talk) 14:55, 15 October 2011 (UTC)
replies: text: Hi, article re-worked. Reference is indeed crap, removed. Part not to be confused with "Software quality cost engineering" but text is written to ask for referencing of why SQ is contributing to Cost Mgmt, or basically, why SQ is saving the company money. Two articles on this, https://www.techrepublic.com/article/report-software-failure-caused-1-7-trillion-in-financial-losses-in-2017/ and https://medium.com/@ryancohane/financial-cost-of-software-bugs-51b4d193f107, but also papers. The citation, as mentioned in above comment, also more from a Requirements angle, which is fine too, but not useful. I also recommended https://www.researchgate.net/publication/319637731_Software_Failures_An_Overview and will site the paper. --𝔏92934923525 (talk) 09:07, 25 February 2021 (UTC)
thread_title:  Industry data reference 

message: I removed this reference as it broke the references header and I could not discern what it meant to cite. If anyone has a clue or has this reference, please do re-insert it appropriately.
:"O. Alshathry, H. Janicke, Optimizing Software Quality Assurance, Computer Software and Applications Conference Workshops (COMPSACW), 2010 IEEE 34th Annual, pp.87 - 92"
Sangrolu (talk) 19:31, 8 March 2011 (UTC)
thread_title: Removed reference

message: This article could benefit tremendously from a concise definition of Software Quality (no easy task). Need help! Putting my first go at it. Please revise, and discuss. Dalvizu 02:07, 18 August 2007 (UTC)
thread_title: Software Quality in 1-2 Sentences

message: Ask youselves, quality with respect to what?
Quality is measured. You're (maybe) correct, stating that LINUX evolved
from something without clear objectives. But by no means, this
translates to saying that you measure LINUX quality against that.
Got it?
I'll clarify. Keeping with the same example, Linux is good because 
Linux does this and does that. Fine. In saying so, you defined
your quality scale and you claim Linux is good with respect
to that. Period.
The best picture, of course, is to define the requirements
in advance. This is one of the challenges of SW engineering.
Look carefully; you'll see that the definition, as "conformance
to requirements", is correct. The same problem arises in other
engineering areas involving complex products. So we shift
the discussion from the definition, to the challenge of
ensuring quality of the final product.
The definition is also in agreement with what was done when
we wrote ISO/IEC 9126 and, lately, ISO/IEC 25000 (I was part
of it).
200.175.4.236 16:13, 13 November 2006 (UTC)
thread_title:  Not a Definition Problem 

message: This page has been flagged for cleanup for almost two years. Let's see if we can fix it. A quick glance makes me think it needs inline citations, as well as improvement in the prose. Comments from others? Arthurrh (talk) 23:22, 13 December 2007 (UTC)
replies: text: This is a very difficult subject.  It is an age old subject, but not very well developed in the software/IT industry.  I am not an expert in the area, but willing to give it a go.  However, I am not sure what should I do before editing it.  Do I need to obtain consent from anybody or reaching an agreement before I start updating it?  I think it needs a thorough thought and major restructure.  Francis Law (talk) 01:14, 4 April 2010 (UTC)
replies: text: Agree, article is not well written and outdated. Let's start with closing meta-discussions also and get working, calling this section done.--𝔏92934923525 (talk) 08:46, 24 February 2021 (UTC)
thread_title:  Cleanup 

message: I am not an expert in software quality.  However, I have been using the following definition for my works.
: Quality products are products that meet or exceed expected quality.
Software is a product that is developed to solve some problems.  Therefore, it suits this definition.  Some people may argue that quality could be defined differently, but I find this is what we really mean by "quality".  However, this definition put every business in a spin quickly because:
# Expected quality is unlimited and ever changing;
# Expected quality is subjective and not measurable;
# Exceed expected quality means over production which is not acceptable to most business.
This explain why most people complain on quality of products including software while software companies struggle to achieve a reputation in quality.  To be practical, the definition is adjusted into:
: Quality products are products that meet agreed quality.
Again, this definition does not resolve issue #2 above.  To resolve this issue, we have to turn ambiguous "quality" into something verifiable, i.e. requirements.  To ensure quality of requirements, we could adopt Software Quality Model such as that described in ISO/IEC 9126.
Some people may argue software could be developed without requirements.  I think this only an excuse.  No matter what, software is developed to do something.  That "something" is the requirements to the software being developed.  Declaring no requirements is only an excuse to avoid managing requirements.  This make the software being developed a failure already.
Francis Law (talk) 06:11, 4 January 2008 (UTC)
thread_title:  What is quality? 

message: Software Quality has been a subject of great interest and importance to me -- I would like to help contribute to the discussion and the content of the page. Mbarberony (talk) 00:03, 18 June 2011 (UTC)
replies: text: Hi, can we call this section closed? Comments nearly a decade old and CISQ is a real thing today. References exist. Let's move this article and discussion into a new light. Inserting a Done here. --𝔏92934923525 (talk) 08:51, 24 February 2021 (UTC)
thread_title:  Proposal for contribution 

message: Could you please add a citation for where the CISQ criteria come from - is there a formal document somewhere? (I like the definition, but where does it come from? I couldn't find anything on the CISQ website).
129.215.63.105 (talk) 09:41, 22 August 2011 (UTC)
replies: text: Hi, can we call this section closed? Comments nearly a decade old and CISQ is a real thing today. References exist. Let's move this article and discussion into a new light. Inserting a Done here. --𝔏92934923525 (talk) 08:51, 24 February 2021 (UTC)
thread_title:  Citation 

message: * As proposed in my last entry, I updated the introduction section a few weeks back and I just changed the overall definition and regroup some material in other section. I am working on a more systematic description of quality characteristics which I will be able to post very soon.  
* Added end of the edit today -- I will be working on adding links to the text particularly by leveraging the links in the previous version.
— Preceding unsigned comment added by Mbarberony (talk • contribs) 17:28, 21 July 2011 (UTC)
replies: text: Hi, I started working on it. I'm a SW/QA/RM professional.--𝔏92934923525 (talk) 09:19, 25 February 2021 (UTC)
thread_title:  Major Cleanup 

message: After some thoughts, I believe this article mainly covers CISQ's definition of quality, which is a partial and incomplete point of view. The article is fine and quite well written, but I believe this should be moved to something more CISQ-specific, like a specific section in the CISQ wikipedia's main page. Here are my arguments:
* Many others have had different (and quite more generic) views on quality. They should be cited as reference, instead of quoting only one vision on this hot subject of debate.
* Many quality models have been published, for many different organisation types and domains. CISQ covers only a part of what is addressed in other quality models. This is unfair for them.
* The attributes of quality are partial. They mainly cover the manufacturing view on quality (which is the most proeminent view in the industry, ok), but miss several aspects (e.g. transcendental view from Garvin, conformance to requirements from Feigenbaum, fitness for use from Juran, community in FLOSS models...).
* Recent research in software quality models has highlighted many shortcomings in modern standards (ISO 9126, SQuaRE, or even CMM), and CISQ doesn't behave better than other models. In that sense, the article misses many aspects of quality models and once again constitutes a partial view on quality and quality models.
Boris Baldassari (Talk) 12:17, 5 February 2013 (UTC)
replies: text: But referencing them directly rather than using WP:SECONDARY sources may not be ideal. --Walter Görlitz (talk) 19:31, 11 February 2013 (UTC)
thread_title:  re-Major Cleanup for objectivity: article is too CISQ-oriented 

message: The reference mentions the author as Scott Pressman. The book bears the name of Roger S Pressman. Is this the same person? Also I have access to the 5th edition of the book (electronic), and I cannot find the definition near the specified page. Can someone verify the reference. Doesn't seem right that something as basic as the definition will not exist in the 5th edition.  — Preceding unsigned comment added by 193.205.92.108 (talk) 15:52, 13 December 2011 (UTC)
replies: text: It's clear that the author of the book is Roger S. Pressman, who perhaps has the middle name Scott. I updated the reference. I don't have a copy handy to verify it. It is odd that we have both full references and a bibliography - seems that we should simplify this. Faught (talk) 17:45, 21 December 2017 (UTC)
thread_title:  Reference to Software Engineering: A PRACTITIONER’S APPROACH 

message: There are not five but four characteristics defined in the CISQ software quality model as I read it now. I could not find if historically it was the case, but Size should not be listed at the same level as the other 4, and it should sit under Maintainability.  — Preceding unsigned comment added by Lucian.ciufudean (talk • contribs) 09:18, 8 February 2018 (UTC)
replies: text: Hi, I updated the part.--𝔏92934923525 (talk) 12:17, 28 January 2021 (UTC)
replies: text:  Adding a Done to this section --𝔏92934923525 (talk) 08:46, 24 February 2021 (UTC)
thread_title:  CISQ quality characteristics 

message: Does this statement have any reference/source? "As a consequence, code quality without the context of the whole system, as W. Edwards Deming described it, has limited value." --Ignxst (talk) 20:16, 13 July 2020 (UTC)
replies: text: Hi, it does not make sense. The whole article needs to be re-focused away from generalists in quality such as Deming towards the software specialty with its own experts and gurus. Combing Deming with software quality, an interesting article can be found here https://deming.org/software-code-reviews-from-a-deming-perspective/ but the meaning above is without reference no good. I agree however that the system context needs to be understood, but from a quality perspective and with focus on software the "software systems" as such needs to be understood and measured. This article https://deming.org/applying-w-edwards-demings-ideas-in-software-development/ combines Deming with software but points to "management system" and its behaviors. Now, the following article https://www.sciencedirect.com/science/article/abs/pii/002627149290058S is mapping Deming's 14-points (see here https://deming.org/explore/fourteen-points/ or https://en.wikipedia.org/wiki/W._Edwards_Deming) to software (quality). "Deming's system" is a bit different from a "technical system". To conclude: Firstly, I would not call it (or ask) "code quality" but rather "software quality". There is different. Secondly, the meaning here is that "software quality" (driven by the excellence of a quality department or group) influences the value of an overall product or service, and that can be a sofware or system. Thridly, as the article mentions, "The traditional technique is too focused: the final code." and hence, it is highly recommended to look at the "whole system" and "Improve constantly and forever the system development process", again, meaning the system-context here. The connection with value is not ideal, but the connection "whole system" (but meaning a technical system, such as a embedded ECU) is valid. Text should therefore be altered, maybe I do it later.--𝔏92934923525 (talk) 09:23, 24 February 2021 (UTC)
thread_title:  Interpretation regarding to W. Edwards Deming?? 

message: Hi, I noticed many old talk sections. I will re-structure and re-name for more clarity so we drill down the situation as the main article clearly needs updating. --𝔏92934923525 (talk) 20:58, 24 February 2021 (UTC)
thread_title:  Talk-page restructuring 

message: Major cleanup of motivation part. Removing the following which is not cited and connected to the motivation aspect:
"However, the distinction between measuring and improving software quality in an embedded system (with emphasis on risk management) and software quality in business software (with emphasis on cost and maintainability management) is becoming somewhat irrelevant. Embedded systems now often include a user interface and their designers are as much concerned with issues affecting usability and user productivity as their counterparts who focus on business applications. The latter are in turn looking at ERP or CRM system as a corporate nervous system whose uptime and performance are vital to the well-being of the enterprise. This convergence is most visible in mobile computing: a user who accesses an ERP application on their smartphone is depending on the quality of software across all types of software layers.
Both types of software now use multi-layered technology stacks and complex architecture so software quality analysis and measurement have to be managed in a comprehensive and consistent manner, decoupled from the software's ultimate purpose or use. In both cases, engineers and management need to be able to make rational decisions based on measurement and fact-based analysis in adherence to the precept "In God (we) trust. All others bring data" ((mis-)attributed to W. Edwards Deming and others)."''
Further, the Deming quote is mis-attributed. We don't need such stuff on a QUALITY page. "Embedded systems now often include a user interface" is a bit of a joke, thanks for that. And this "uptime and performance are vital to the well-being of the enterprise." ... seriously, the well-being of the enterprise? Doubt it, despite knowing what for example an SAP does. Uptime is a very specific topic. Agree with "a user who accesses an ERP application on their smartphone is depending on the quality of software across all types of software layers." but without referencing this not ideal.--𝔏92934923525 (talk) 09:24, 25 February 2021 (UTC)
thread_title:  Motivation 

message: Hi, I cannot find the quote "a product's quality is a function of how much it changes the world for the better." which was referenced to https://www.cutter.com/search?search_api_fulltext=Tom%20DeMarco&f%5B0%5D=author%3A38806&f%5B1%5D=authored_on%3A1998&f%5B2%5D=authored_on_mobile%3A1998 ... from 1999, there is nothing from DeMarco at Cutter in 1999.--𝔏92934923525 (talk) 22:21, 24 February 2021 (UTC)
thread_title:  DeMarco quote