Software quality model: Difference between revisions

Content deleted Content added
correction to URL after section heading cleanup
 
(One intermediate revision by one other user not shown)
Line 1:
#REDIRECT [[Software quality#Measurement]] {{R to section}}
<!-- Please do not remove or change this AfD message until the issue is settled -->
{{Article for deletion/dated|page=Software quality model|timestamp=20120424234653|year=2012|month=April|day=24|substed=yes}}
<!-- For administrator use only: {{Old AfD multi|page=Software quality model|date=24 April 2012|result='''keep'''}} -->
<!-- End of AfD message, feel free to edit beyond this point -->
 
'''Software quality''' can be defined as 'conformance to requirements' and/or 'fitness of use'. Quality achievements start with a clear definition of what "quality of source code" means to the organization or project. In simple terms all the [[Project stakeholder|stakeholder]]s must be well informed of what is expected, what the goals to be achieved are, what the evaluation criteria will be and how they can contribute to achieve the goal.
 
==Procedure==
The first step in this direction is to decide the goals and their definitions, for example the following are some of the common goals of any [[software]] development / maintenance project.
 
*Testability: Ease of testing.
*Maintainability: The ease of change.
 
This solves the first level of ambiguity, but the job of defining software quality has just begun. The very next step is to determine what predicates a quality goal. There can be several factors which can influence a particular goal positively or negatively, these factors can be [[predicate (mathematical logic)|predicate]]s of a goal and these predicates can be as simple as a naming convention to be followed or as complex as a desired "useful" comments percentage per class. In general these predicates are nothing but the "[[best practices]]" to be followed and standard "[[software metrics]]" which are collected to determine different quality aspects of the software solution.
 
===Goal-oriented measurement===
The software metric "[[cyclomatic complexity]]" has considerable influence on the [[software testability|testability]] of a function, module and eventually the software as a whole. In simple terms cyclomatic complexity increases as the number of [[conditional construct]]s in a [[Function (computer science)|function]] increases, which actually mean that more testing effort is needed. So, cyclomatic complexity is a predicate for the goal "testability", and as CC increases, testability becomes tougher (decreases).
 
===Predicate contribution===
There can be many factors which can influence the quality goal "Testability". Simply, by setting weights it is possible to control which predicates contribute more to the goal of concern.
 
==See also==
{{Portal|Java}}
* [[Software quality assurance]]
 
==External links==
{{no footnotes|date=February 2011}}
*[http://www.sqa.net/softwarequalityattributes.html Software Quality Attribute Models]
*[http://www.sqa.net/iso9126.html ISO 9126 Software Quality Characteristics]
*[http://www.spago4q.org Spago4Q Web Site]
 
[[Category:Software metrics]]
[[Category:Java development tools]]
[[Category:Software quality]]