Talk:Software quality

Industry data reference

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)

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.  Done--𝔏92934923525 (talk) 09:07, 25 February 2021 (UTC)

Removed reference

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)

Software Quality in 1-2 Sentences

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)

I definitely agree with that: in my humble opinion, this article represents a partial perspective on quality. Although the CISQ standard looks fine (won't debate here about its relevance), it should be highlighted that many others have addressed this: garvin, kitchenham and pfleeger, among others. I'll try to give some common definitions for better objectivity, with references. Don't hesitate to argue on this. Boris Baldassari (Talk) 09:44, 5 February 2013 (UTC)

Conformance to requirements

It seems a little contradictory to talk of software quality being defined by conformance to requirements when one of the biggest problems of software development is the difficulty in specifying clear requirements.

Defining software quality this way also implies a concious planned development from formal specifications. It ignores organic software development methods such as agile or open source; most people would agree that Linux is a high-quality piece of code but what are the original requirements that Linus Torvalds was supposed to comply to? Does anyone know or care if those were met?

Software is, at least to some degree, an art. "Well written" code is entirely a human concept since the average computer doesn't seem to care. Now art, by its very nature, isn't about meeting pre-defined requirements; it is said that the merchant who commissioned the Mona Lisa refused it because it didn't look enough like his wife.

-- Shanky

Couldn't agree more. As a expert in the field, it seems to me that Software Quality is not accurately described solely conformance to standards. This article currently only represents a single (and somehwat dogmatic) point of view. Please, BOLDLY edit this article. I certainly intend to. Mmcdougall 18:49, 8 Jun 2005 (UTC)

I think software quality is defined not only by its technical aspects, but also by the user experience. Many software packages have great internals, but rather bad GUI. I added a section on usability (quality in the eye of the beholder). It needs a lot more work. Philippe 12:36, 4 May 2006 (UTC)

Agreed whole heartedly. There may be a lot of praise on Linux. But, most are from the technical people. It is a fact. This means it meets the technical users' expectation. However, it is also a fact that Linux is not very successful in taking up by non-technical users even it is free and available in so many forms (distributions). This also means that it does not meet the end users' expectation. Therefore, whether it is a quality product is actually depend on who is the user. 220.253.152.240 (talk) 18:44, 2 April 2010 (UTC)

I'd like to propose that the software quality is better defined as the "ability of the software to satisfy a quantified business outcome through the provision of technical and functional capabilities". Even though in many situations a quantified business outcome may not have been provided, that does not mean the the software was necessarily of poor quality? (My potential conflict of interest that I would like to declare is that I have spent years looking at the problem of software requirements and developed a commercial tool to solve the problem - <<spamlink redacted>>) Colinrhammond (talk) 08:02, 25 April 2019 (UTC)

First, I'm not sure what change you're proposing. I get the feeling that you want to add to or replace the existing definitions.

Second, I'm not sure that's a good definition let alone good grammar.

Finally, we you have a reliable source that would support that definition?

I would argue that we should actually gather what reliable sources have stated software quality is and add them to the article. Walter Görlitz (talk) 03:52, 27 April 2019 (UTC)

Quality Factors and the Human Factor

I think the word Quality points at a collecion of things. Herein is one of the aspects I think makes it subjective. We all seem to have our own personal collection of things we point at when we talk about Quality. Moreover, each project seems to have their own collective rendition of what Quality software means to them: what they find acceptable. So, any discussion of Quality ignoring this simple reality seems doomed to devolve in to sounding dogmatic and definitive. I never forget that software engineering is not just a technical task, but a human one as well (art?).

As for Usability and Reliability and GUI issues, I am inclined to agree with Bertrand Meyer how there are Internal and External Quality Factors. Internal pointing at those quality factors experienced by those who design, code and test and External pointing towards those experienced by any level of end user who sees and interacts with whatever interface the software presents (graphical or otherwise).

The best way to continue the discussion is by either clearer language about what a Quality Factor is and what it looks like in real code in a real project. Also within the human context of agreement as well.

Internal Quality Factor: Understandibility. What does it point to? Perhaps a list will help fill in the meaning:

1. Coding Standards (technical and style) --> Directly impacts the "quality" of the code text itself. Agreed upon coding and style standards makes the code text more understandable. 2. Design Patterns --> Another direct contributor to code "quality". The code is more understandable when predictable design patterns are used in the code text. 3. UML Tools --> These have a first step of having indirect impact on the understandibility of the code, but as they move towards actual production code text, they take on more impact. 4. Extreme or Agile methods --> It has been shown more than once, how the methods of agile and extreme programming improve the readibility of the code text (just one aspect of a larger affect).

External Quality Factory: Understandibility. I can see how quality factors cannot help but carry up fom the code text to the user interface itself. So, whenever I think about and deal with quality factors, I know that whatever I do in the code text is going to directly or indirectly impact the user interface at some point.

1. GUI Standards --> Such as those that Microsoft uses for GUI design standards. 1. UML Tools --> One of the aspects of UML is to bring standard style, agreement, consistency and such things to the GUI. I think this has a direct impact on the User Understandibility of the software.

When I think about the example notions above, what I see is how agreed upon standards for how to design, write and test software, I see how the word quality quickly moves from the essoteric and subjective to the very concrete and real. What remains always a gray area is what people agree to and find helpful in any situation.

More on Software Quality

Aren't there tools or techniques that provide some sort of measure of quality? The first that come to my mind is "code coverage", which is the combination of test cases and evaluation that shows that the test cases executes a high percentange of source code. The test case and source code combineed determine quality in its ability to weed out defects, particularly if the test case includes "unexpected" data sets.--96.244.248.77 (talk) 02:23, 3 March 2011 (UTC)

Other measures of quality include evaluation of the documentation of the code, whether it be as simple as the number of comment lines per source line, or procedurally by other external methods (such as existance and review of user manuals, how-to-test documentation, independent code reviews, sustainability requirements, or other methods). Much has been written about this, but time-to-market seems to drive activities that result in shortcuts to quality. Fundamentally - quality takes time to create, but pays dividends in the long run. --96.244.248.77 (talk) 02:23, 3 March 2011 (UTC)

Hi, this comment seems dated and unspecific. I provide a couple of tools here, which relate to software quality. This is by no means a commercial ad or recommendation. Further understanding of you project needs must be elaborated to derive the right solutions. Speaking from experience, it is very likely and normal that several different tools are needed to achieve full software quality, plus additional customer-consulting metrics and engineering to cover the non-machine tricky areas. Also know that tools keep evolving: What used to be a pure Requirements tool can become a full ALM tool 1-2 years later or turn into a software code quality suite after several M&As.  --𝔏92934923525 (talk) 11:50, 17 March 2021 (UTC)

• https://www.tiobe.com/tiobe-index/
• https://www.sonarqube.org/
• https://polarion.plm.automation.siemens.com/products/polarion-alm
• IBM DOORS/DOORS Next Gen/JAZZ: https://jazz.net/
• https://www.getzephyr.com/
• https://www.gurock.com/testrail/
• https://www.synopsys.com/software-integrity.html
• https://www.jacoco.org/jacoco/
• https://www.adacore.com/gnatpro/toolsuite/gnatdashboard
• https://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html

Note: The list above purposely lists different tools to give you an idea what's existing, some cover RM, some QA. Different language, different tools. Different industry, different tools.

Conformance to standards?

I think conformance to standards is necessary to improve software quality, especially what regards the Internet. Paulo Oliveira 11:55, 6 Jun 2005 (UTC)

I agree that quality is a vague term, but disappoint to hear that requirements conformance should not be used to measure software quality. A product could be technically brilliant, but failing to meet users expectation can never earn it the recognition of quality. For software development, requirements are the expression of users expectation. -- Francis Law 02:44, 12 February 2007 (UTC)

Requirements can be wrong or unattainable. Often during coding there are things that can't be done as requested or plain wrong. This leads to a requirement refinement. At the end requirements should be strong enough and the software should be capable of showing conformance. If a technically brilliant product doesn't meet the user expectation then either one (or both) is wrong.Javier Ortiz Bultrón 01:01, 20 July 2010 (UTC)

This argument is between Quality (in terms of actually meeting customer expectations, e.g. Validation - was the right product built? ) and quality of requirements (was it specified correctly, or Verification - was it built "right"). This is basic Systems Engineering discipline. The objective, of course, is to satisfy the customer needs (validation) which is sometimes subjective. Often challenging, which is why documentation, reviews, and good communications remain important in the management of complex systems. --96.244.248.77 (talk) 02:35, 3 March 2011 (UTC)

Hi, there are several standards and guidelines linked, see ISO or IEEE. This discussion seems out-dated, unspecific, and should if necessary restarted with concrete goal. Calling it therefore done.  --𝔏92934923525 (talk) 11:16, 17 March 2021 (UTC)

Merge with Software reliability (done) Software assurance?

Someone added a suggestion to merge this article with Software reliability, but there doesn't seem to be any discussion of exactly why. I'm going to speculate that "quality" is somehow a more expansive topic than "reliability"—I don't have any argument with that. Just wanted to bring it up here. I haven't even read this page; it looks to sparse to even bother. What's with the fascination with lists of other pages in the software-related pages? (While I'm here, the Computer software page itself needs more help. Why try to define so many software sub-topics when the primary page is not very good? Brent 01:18, 18 October 2005 (UTC)

I agree with User:Conan's merge suggestion. Software testing is great, but Software reliability and Software quality are overlapping ideas with each other. Perhaps Software quality and reliability is better? FWIW, Computer software looks better now than SR and SQ. -- Perfecto  21:03, 5 November 2005 (UTC)

I disagree. Reliability is only one aspect of quality, there is too much to say in only one article.--Thv 08:42, 7 November 2005 (UTC)

I agree with Thv that reliability is only one aspect of software quality. However, I think this article needs more effort to become more valuable. I would suggest to start with planning the flow of thought before filling in content and information. Then, associate it with other topic, such as Quality, Quality Standards, etc. -- Francis Law 13:10, 12 February 2007 (UTC)

I agree with former contributors that Reliability is one of the aspects. As for structuring the content of this page I would suggest to follow one of the "public domain" software quality reference models, ie. McCall [1977], Boehm [1978] and ISO 9126/1993. Furthermore I would advice to simply "define "Software Quality" as "Software meeting requirements" and would focus the discussion on structuring and defining these requirements, and the process of (automated) validation. --Rob Snelders (talk) 15:33, 19 February 2010 (UTC)

I agree that there is a distinction between Software Quality and Software Reliability. Reliability is only a subset of Quality. Quality is a combination of reliability, suitability, availability, maintainabilty, performance, cost effectiveness, and other factors. E.g. quality tends to cover all the "-illities" of a system. (Yes, I probably missed some, so please feel free to add...) --96.244.248.77 (talk) 02:44, 3 March 2011 (UTC)

I disagree. Software Assurance is a big trend supported by the US DHS and DoD, which focus almost exclusively on security and vulnerabilities, which is a very restricted notion by definition. For example, poor efficiency (performance, ressources comsumption..etc ) or poor maintainability of an IT system, or of an embedded system, CANNOT be classified as “vulnerabilities”. This would have no sense. Security is a subset of software quality, and as such, it may make sense to integrate Software Assurance into Software Quality. An alternative would be to redefine the Software Assurance definition, to make it broader. In all cases, the structure of the resulting page would have to be very clear. DamienPo (talk) 20:08, 11 February 2013 (UTC)

I would like to add a vote to leave Software assurance as a separate page. As others note, Software Assurance is a more specific term; not as broadly used as Software Quality. As an example, I work for a major medical device manufacturer and we do not use the term Software Assurance, although we perform many activities that other organizations would specifically label Software Assurance. Our use of the term, Software Quality, however, is closely aligned with much of the content of the Software quality page, its references, and with industry use in general. Casualhacker (talk) 18:51, 8 May 2013 (UTC)

Hi, this seems a bit dated now, clearly and speaking with decades of professional expertise: Software quality is not (just) Software assurance. Unfortunately there is a lot of confusion. I provide some of my POVs:

• Software testing - Black box, etc. a specialty, contributing to Reliability, Safety, Security.
• Quality assurance - Very close to Software quality, but unspecific in terms of software: Could cover hardware too.
• Software quality assurance - Often means Testing, Testmanagement and related processes, but doesn't include Safety or sometimes Security or Maintainability or Performance
• Performance testing - Specific, only one aspect of overall QA/Testing and not covering other areas
• Software reliability - Doesn't cover Security or needs to specifically cover it, could be hardening, could mean Safety, e.g. for critical systems
• Software suitability - The full-cycle of requirements to testing. Functional requirements mainly, are they 'suitable' and 'testable', verifyable?
• What else, did I means anything? I hope this makes it clear.  --𝔏92934923525 (talk) 11:59, 17 March 2021 (UTC)

Application- vs. infrastructure software

It may be a good idea to discuss the topic from the above two perspectives. Just to kick off some topics:

• Infrastructure software is designed to be stable eg. for the long run
• Application software is usually dealing with constant changes in requirements, the design may not be so stable
• High availabilty, scalability (technical features in general) usually implemented at the infrastructure level. Application development should not directly deal with them.
• Meanwhile UI requirements against application softwares are generally higher then against infrastructure softwares...

Copy violation?

The recent additions to this article by 203.128.4.253 appear to be directly copied from some workshop notes, and as such are probably copyright, besides being in an unencyclopaedic tone. Colonies Chris 15:37, 10 August 2006 (UTC)

Yeah, I agree. Right now it doesn't look like an encyclopaedic article at all. I'd suggest removing those edits entirely or heavily modifying them ASAP. Sarg 16:27, 18 August 2006 (UTC)

Restored most of section 3 from the history.

Not a Definition Problem

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)

Quality, what quality?

This discussion has been going on in business and University environments for the past 30 years so I don't expect to end soon.I think the present definition covers the technical aspects of software quality fairly well, and covers the software reliability quite well. However, there are other aspects of quality not covered at all, primarily the business side.

In 2000 ISO has gone back and redefined Software Quality as "...meeting or exceeding customer expectations...". This was due, in part, because of the dot-bombs making software with no customers or business value.

In engineering fields product always has to meet technical and business constraints, including cost, time to market, and return on investment. One question SQA asks is "Did we build the product right?", (verification), the other is "Did we build the right product?" (validation). If software was truely an engineering discipline, Universities would apply the same curriculum standards that apply to all other engineering fields and software engineers would know how to balance and meet all technical and business requirements and constraints. The top 3 tech companies are software companies, they do not give their product away for free, and seem to have done this quite well.

This discussion has been going on in business and University environments for the past 30 years so I don't expect to end soon.

Alhenry2006 20:07, 31 March 2007 (UTC)Al

Hi, your comment has never been answered and is very old. Software quality IS defined and well-worked with over the last 30 years. The main article has been improved dramatically and you can see the many links to ISO, IEEE, etc. Of course the definition will always be evolving, but there is a basic setting for software quality which covers it. The "Did we build the product right?" depends on your requirements engineering, POs, etc. Verification and validation is clearly defined and a well-established activity in industrial and even scientific discipline, where the focus is even more on "the right, validated results" rather than on the build-quality. I hope this answers you comment.  --𝔏92934923525 (talk) 12:03, 17 March 2021 (UTC)

Cleanup

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)

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)

Agree, article is not well written and outdated. Let's start with closing meta-discussions also and get working, calling this section done. Done--𝔏92934923525 (talk) 08:46, 24 February 2021 (UTC)

What is quality?

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:

1. Expected quality is unlimited and ever changing;
2. Expected quality is subjective and not measurable;
3. 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)

I'm by no means a quality expert, but it seems the page reads very dryly. Obviously, there exists the quality aspect of code to requirements, would the page benefit from lower level information, eg software quality metrics, links to any unit testing, code coverage pages?

Sorry if I'm out of line, new here :p

Minkythecat (talk) 16:58, 5 March 2008 (UTC)

The message may be dry but I think it touches the basic truth. Minky's message probably misses the main point of the message. I'm not talking about the importance of requirement or coding. I'm defining what is quality with respect to software product. Quality cannot be achieved by a single factor or a single element. It is the accumulated results of many factors.

Most discussion focus in areas people working with. However, it seldom try to view the quality from the user perspective. User is the ultimate judge on the quality of product. How often does a technically brilliant product fails to please users? Usually, developer complaint that users can't understand the beauty of the product. I'm no exception and I did that in the past. However, I start to realize the cause is most likely the product fails to meet users' expectation. Therefore, the technically brilliant product becomes a technically brilliant rubbish to the users.

This sounds very harsh. But, I truly believe in this.

Francis Law (talk) 09:38, 2 April 2010 (UTC)

Where is Software Reliability Modeling?

Some entry should discuss operational profiles, reliability allocation, the use of software reliability models (e.g., Shooman, Jelinski-Moranda, Goel-Okumoto, Musa, Moranda Geometric, Musa-Okumoto, various S-shaped models) to monitor testing, the use of this approach on each spiral in spiral development to support Statistical Process Control, etc. 151.190.254.108 (talk) 11:34, 1 July 2008 (UTC)

Hi, good, then why not edit the article? There exists material, e.g. https://link.springer.com/chapter/10.1007/978-3-642-82014-4_22 or https://www.hpl.hp.com/techreports/tandem/TR-96.1.pdf or go broader: https://www.google.com/search?tbm=bks&q=software+reliability+models, but it all dates or peaked around 90s(?) see https://books.google.com/ngrams/graph?content=software+reliability+models&year_start=1800&year_end=2019&corpus=26&smoothing=3&direct_url=t1%3B%2Csoftware%20reliability%20models%3B%2Cc0#t1%3B%2Csoftware%20reliability%20models%3B%2Cc0, so if you want to bring this in, then maybe something fresh? Ok, here is a publication from 2018: https://www.morebooks.shop/store/gb/book/some-software-reliability-models/isbn/978-613-9-82805-0 Also interesting, looking at the keywords from the previous material.

Keywords: Hausdorff Distance, Software Reliability Models, confidence bounds, cumulative number of failures, debugging theory, uniform distance, Goel model, Goel-Okumoto model, deterministic curve model, discrete Gompertz, new Gompertz-Makeham, transmuted deterministic, Yamada-exponential, Logistic-exponential, Yamada-Rayleigh, generalized inverted exponential, transmuted inverse exponential, transmuted log-logistic, Kumaraswamy-Dagum log-logistic, Kumaraswamy quasi Lindley

Now that is a lot(!) of theoretical approaches I would say. And finally, we have this NASA article from 2001: Practical software reliability modeling (https://ieeexplore.ieee.org/document/992668?arnumber=992668) with 4 indicated paper citations...

I conclude: I try to mention (include it), but definitely is a specialty in the last 5% of Software quality.--𝔏92934923525 (talk) 20:51, 24 February 2021 (UTC)

Hi again, I take my done back, because the reliability part of the main article cannot be amended briefly, it should be re-written and I currently do not have my resource available for detail-change.--𝔏92934923525 (talk) 20:57, 24 February 2021 (UTC)

Software security has no place in this article

The software security should not be included in this article: it is a completely separate topic. How does this:

Does the software protect itself and its data against unauthorized access and use? Does it allow its operator to enforce security policies? Are security mechanisms appropriate, adequate and correctly implemented? Can the software withstand attacks that can be anticipated in its intended environment? Is the software free of errors that would make it possible to circumvent its security mechanisms?

relate to software quality? I am currently writing an open source program for mathematical computations. As such, it has no security features whatsover. What does "unauthorised access" mean to a computational open source program? Please, move software security to a software security article, where it belongs. 95.33.126.194 (talk) 12:56, 13 June 2009 (UTC)

You are mistaken. Security is an important quality factor of software. It is not a feature and it is not optional. You are right that many of the features listed will not be relevant to many programs. Not all questions you list are relevant to your program, but the last one is. Rp (talk) 12:29, 29 October 2009 (UTC)

Security is certainly an important factor that contributes to the overall quality. It is one of the sub-characteristics identified in the Software Quality Model ISO/IEC 9126. The model can help to achieve quality in product. However, a product may have considered all characteristics and sub-characteristics in the model. But, it can still be labelled as poor quality if it cannot meet it user's expectation. Therefore, the model should be a tool to help materialize the user's expectation into atomic and testable requirements. Francis Law (talk) 23:45, 3 April 2010 (UTC)

Hi, closing this discussion because it's 2021 and Security has a clear place in overall software quality cycle. Main article including Security as part of quality characteristic of a product. Yes of course Security is its own highly specialized area of software engineering, but nevertheless, bad security grills your software and company immediately (see IBM data breach report) and must be governed by overall quality management.  --𝔏92934923525 (talk) 12:07, 17 March 2021 (UTC)

Who Wants to Help?

I am currently studying Software Engineering and am researching Measuring Software Quality. I will begin editing this page soon. I will review the comments posted in this discussion and try to act on them as best as possible. Dfletter (talk) 00:06, 13 February 2009 (UTC)

I have just flagged my interests to update this page before I notice your post. How's your update? I think this page requires a well thought out plot and a major restructure. Francis Law (talk) 02:08, 4 April 2010 (UTC)

software quality is indeed an age old subject! I am retired now but I started dealing with these issues something like 35 years ago. I even wrote guidelines for Fortran developers in those days. Anyhow this is not at all well developed for business systems on which so much relies and I am willing to contribute but I am not sure how to proceed. I would like to add a specific section describing what critical architecture issues and source code quality checks to ensure reliability, performance efficiency, and maintainability of IT business applications. Please adviseFrancois grassot (talk) 13:20, 18 August 2010 (UTC)

Hi, this comment seems very old and in the meantime hopefully you completed your studies. Closing so we can have clearer picture of the Talk page. Feel free to reach out with a specific new comment/section if you have a new question or request for help. --𝔏92934923525 (talk) 12:04, 17 March 2021 (UTC)

Proposal for contribution

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).

I have been an IT practitioner for over 25 years now, mostly as a consultant (I was head of Technology Consulting - which included System Integration - for the Financial Service Industry at BearingPoint in North America) but in the past few years, I have been working for a major swiss bank first as interim CTO for their North American Wealth Management group and now as Head of Strategy for the Global CTO organization.

Software quality is of major importance to us and we are in the process of setting up a bank-wide Key Performance Indicator aiming at measuring, improving and monitoring the quality of our software portfolio and I would like to share the perspective I gained and that we are gaining from this and prior experience.

It seems to me that the article as of now has a wealth of information but some of it might be extraneous and confusing to the reader, so my first suggestion would be to restructure (refactor!) the content to make it more concise and helpful to anyone consulting this article.

In that context, I would suggest that the first thing to do is to reword the definition section to present a simple but not simplistic definition of the topic – with another section presenting alternative view: with respect to the formal definition and in keeping with the suggestions made by others in that page, I would submit that that software quality regroup two very complementary but rather distinct notions: functional quality and structural quality.

Unless someone has an alternative proposal, I’ll propose a more structured approach based on my recent work at the CISQ, a SEI and OMG joint effort, http://en.wiki.x.io/wiki/CISQ where I’ve had the chance to get exposed to the work performed by luminary industry experts in SW quality, universities’ research labs, as well as Caper Jones, http://en.wiki.x.io/wiki/Capers_Jones CISQ Distinguished Advisor.

Citation

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)

I did insert the link to one of the key document published by CISQ: (see CISQ 2009 Executive Forums Report) — Preceding unsigned comment added by Mbarberony (talk • contribs) 20:59, 8 November 2011 (UTC)

Also, I added the CISQ document on http://it-cisq.org/cisqwiki/images/a/a2/CISQ_Function_Point_Specification.pdf which is the first first metric standard published by CISQ - It deals with Automated Function Points measurement. CISQ has also announced to its membership that definitions for metrics associated to for the four Quality Characteristics—Maintainability, Reliability, Security, and Performance Efficiency—will be released and submitted to OMG in Request for Comment form at its March 2012 Technical Meeting. — Preceding unsigned comment added by Mbarberony (talk • contribs) 20:44, 28 November 2011 (UTC)

Automated Function Points specification was updated to beta 2 and can be found at https://www.omg.org/spec/AFP/1.0/Beta2/ 210.9.30.170 (talk) 03:36, 6 March 2018 (UTC)

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.  Done--𝔏92934923525 (talk) 08:51, 24 February 2021 (UTC)

Major Cleanup

• 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)

Hi, I started working on it. I'm a SW/QA/RM professional. Done--𝔏92934923525 (talk) 09:19, 25 February 2021 (UTC)

re-Major Cleanup for objectivity: article is too CISQ-oriented

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)

I propose the following plan for a major rewrite:

1. Software quality: Definitions of Garvin, Kitchenham, Feigenbaum, Juran, Deming, Shewhart, Ishikawa, and others. (I can provide them all).
2. Software Measurement
   1. Issues with software measurement: fenton, pfleeger,
   2. Methods for software measurement: Basili's GQM, Lessons learned from software measurement programs.
3. Software quality models
   1. Early models: McCall, Boehm, Dromey
   2. Standards: ISO 9126, ISO SQuaRE,
   3. FLOSS quality models: OSMM Capgemini, OSMM Navia, QSOS, OpenBRR, QualiPSo, QualOSS, SQO-OSS

Boris Baldassari (Talk) 12:30, 5 February 2013 (UTC)

The CISQ is a neutral, non-profit consortium, backed by the OMG and the Software Engineering Institute, Carnegie Mellon University, which is a good and credible voice of the IT industry, which does not focus only on embedded system. It’s actually good to talk about software quality for business IT, and not only – as it is too often the case – for embedded system. The latest is sometime “life critical”, and as such very important, but IT is business critical. Nothing wrong with that I think. Also, it’s a consortium open to everyone, free of charge membership.

DamienPo (talk) 19:13, 11 February 2013 (UTC)

But referencing them directly rather than using WP:SECONDARY sources may not be ideal. --Walter Görlitz (talk) 19:31, 11 February 2013 (UTC)

DamienPo, you missed my point. CISQ is free, open, fine, and so on, ok. But it doesn't mean it defines quality. I mean, I've nothing against CISQ, really, and like what they are doing. But software quality (for IT and embedded/desktop/whatsoever software, btw) is a lot more than just what CISQ includes. An encyclopaedic article must talk about what has been said before, and what is said apart from, one single source. Having CISQ- or IT-related information seems fine to me, but having only it completely misses the objectivity and completeness requirements of wikipedia. What about the few arguments I've listed above? Boris Baldassari (Talk) 21:59, 13 February 2013 (UTC)

Reference to Software Engineering: A PRACTITIONER’S APPROACH

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)

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)

CISQ quality characteristics

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)

Hi, I updated the part.--𝔏92934923525 (talk) 12:17, 28 January 2021 (UTC)

Adding a Done to this section  Done--𝔏92934923525 (talk) 08:46, 24 February 2021 (UTC)

Interpretation regarding to W. Edwards Deming??

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)

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 http://en.wiki.x.io/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)

Talk-page restructuring

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)

Motivation

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)

DeMarco quote

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)