Talk:Software quality

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

Contents

[edit] 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)

[edit] 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)


[edit] 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.

[edit] 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)

[edit] Merge with Software reliability?

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

[edit] 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...

[edit] 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.

[edit] 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)

[edit] 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

[edit] 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)

[edit] 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 toany unit testing, code coverage pages?

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

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