Chapter 10: Software Quality - Revision history

Daniel Robbins: /* Software Quality Tools */

2015-08-29T15:09:23Z

‎Software Quality Tools

Show changes

Daniel Robbins: /* Software Quality Tools */

2015-08-29T14:35:07Z

‎Software Quality Tools

Daniel Robbins: /* Software Quality Measurement */

2015-08-29T14:26:53Z

‎Software Quality Measurement

Daniel Robbins: /* Process Assurance and Product Assurance Audits */

2015-08-29T14:18:23Z

‎Process Assurance and Product Assurance Audits

Show changes

Daniel Robbins at 13:20, 29 August 2015

2015-08-29T13:20:24Z

Show changes

Daniel Robbins at 12:17, 29 August 2015

2015-08-29T12:17:10Z

Daniel Robbins: Created page with "{{TOC}} {{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}} {{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}} {{Acronym|name=COTS|..."

2015-08-29T12:08:34Z

Created page with "{{TOC}} {{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}} {{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}} {{Acronym|name=COTS|..."

New page

{{TOC}}
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}
{{Acronym|name=FTA|description=Fault Tree Analysis}}
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}
{{Acronym|name=QFD|description=Quality Function Deployment}}
{{Acronym|name=SPI|description=Software Process Improvement}}
{{Acronym|name=SQA|description=Software Quality Assurance}}
{{Acronym|name=SQC|description=Software Quality Control}}
{{Acronym|name=SQM|description=Software Quality Management}}
{{Acronym|name=TQM|description=Total Quality Management}}
{{Acronym|name=V&V|description=Verification and Validation}}
}}

← Older revision		Revision as of 14:35, 29 August 2015
Line 1,021:		Line 1,021:
	* Tools that support tracking of software problems provide for entry of anomalies discovered during software testing and subsequent analysis, disposition, and resolution. Some tools include support for workflow and for tracking the status of problem resolution.		* Tools that support tracking of software problems provide for entry of anomalies discovered during software testing and subsequent analysis, disposition, and resolution. Some tools include support for workflow and for tracking the status of problem resolution.
	* Tools that analyze data captured from software engineering environments and software test environments and produce visual displays of quantified data in the form of graphs, charts, and tables. These tools sometimes include the functionality to perform statistical analysis on data sets (for the purpose of discerning trends and making forecasts). Some of these tools provide defect and removal injection rates; defect densities; yields; distribution of defect injection and removal for each of the life cycle phases.		* Tools that analyze data captured from software engineering environments and software test environments and produce visual displays of quantified data in the form of graphs, charts, and tables. These tools sometimes include the functionality to perform statistical analysis on data sets (for the purpose of discerning trends and making forecasts). Some of these tools provide defect and removal injection rates; defect densities; yields; distribution of defect injection and removal for each of the life cycle phases.
		+
		+	{{EndSection\|title=Further Readings\|body=
		+
		+	N. Leveson, ''Safeware: System Safety and Computers'' [20]
		+
		+	This book describes the importance of software
		+	safety practices and how these practices can be
		+	incorporated into software development projects.
		+
		+	T. Gilb, ''Principles of Software Engineering Management'' [21].
		+
		+	This is one of the first books on iterative and
		+	incremental development techniques. The Evo
		+	Method defines quantified goals, frequent timeboxed
		+	iterations, measurements of progress
		+	toward goals, and adaptation of plans based on
		+	actual results.
		+
		+	T. Gilb and D. Graham, ''Software Inspection'' [22].
		+
		+	This book introduces measurement and statistical
		+	sampling for reviews and defects. It presents
		+	techniques that produce quantified results for
		+	reducing defects, improving productivity, tracking
		+	projects, and creating documentation.
		+
		+	K.E. Wiegers, ''Peer Reviews in Software: APractical Guide'' [23].
		+
		+	This book provides clear, succinct explanations
		+	of different peer review methods distinguished by
		+	level of formality and effectiveness. Pragmatic
		+	guidance for implementing the methods and how
		+	to select which methods are appropriate for given
		+	circumstances is provided.
		+
		+	N.R. Tague, ''The Quality Toolbox'', 2nd ed., [24].
		+
		+	Provides a pragmatic how-to explanation of a
		+	comprehensive set of methods, tools, and techniques
		+	for solving quality improvement problems.
		+	Includes the seven basic quality control
		+	tools and many others.
		+
		+	''IEEE Std. P730-2013 Draft Standard for
		+	Software Quality Assurance Processes'' [5].
		+
		+	This draft standard expands the SQA processes
		+	identified in IEEE/ISO/IEC 12207-2008. P730
		+	establishes standards for initiating, planning,
		+	controlling, and executing the software quality
		+	assurance processes of a software development
		+	or maintenance project. Approval of this draft
		+	standard is expected in 2014.}}

← Older revision		Revision as of 14:26, 29 August 2015
Line 1,000:		Line 1,000:
	Software Engineering Management and Software		Software Engineering Management and Software
	Engineering Process KAs.		Engineering Process KAs.
		+
		+	==Software Quality Tools==
		+
		+	Software quality tools include static and dynamic
		+	analysis tools. Static analysis tools input source
		+	code, perform syntactical and semantic analysis
		+	without executing the code, and present results to
		+	users. There is a large variety in the depth, thoroughness,
		+	and scope of static analysis tools that can be applied to artifacts including models, in
		+	addition to source code. (See the Software Construction,
		+	Software Testing, and Software Maintenance
		+	KAs for descriptions of dynamic analysis
		+	tools.)
		+
		+	Categories of static analysis tools include the
		+	following:
		+
		+	* Tools that facilitate and partially automate reviews and inspections of documents and code. These tools can route work to different participants in order to partially automate and control a review process. They allow users to enter defects found during inspections and reviews for later removal.
		+	* Some tools help organizations perform software safety hazard analysis. These tools provide, e.g., automated support for failure mode and effects analysis (FMEA) and fault tree analysis (FTA).
		+	* Tools that support tracking of software problems provide for entry of anomalies discovered during software testing and subsequent analysis, disposition, and resolution. Some tools include support for workflow and for tracking the status of problem resolution.
		+	* Tools that analyze data captured from software engineering environments and software test environments and produce visual displays of quantified data in the form of graphs, charts, and tables. These tools sometimes include the functionality to perform statistical analysis on data sets (for the purpose of discerning trends and making forecasts). Some of these tools provide defect and removal injection rates; defect densities; yields; distribution of defect injection and removal for each of the life cycle phases.

← Older revision		Revision as of 12:17, 29 August 2015
Line 15:		Line 15:
	{{Acronym\|name=V&V\|description=Verification and Validation}}		{{Acronym\|name=V&V\|description=Verification and Validation}}
	}}		}}
		+
		+	{{IntroSection\|title=Introduction\|body=
		+
		+	What is software quality, and why is it so important
		+	that it is included in many knowledge areas
		+	(KAs) of the ''SWEBOK Guide''?
		+
		+	One reason is that the term ''software quality'' is
		+	overloaded. Software quality may refer: to desirable
		+	characteristics of software products, to the
		+	extent to which a particular software product possess
		+	those characteristics, and to processes, tools,
		+	and techniques used to achieve those characteristics.
		+	Over the years, authors and organizations
		+	have defined the term quality differently. To Phil
		+	Crosby, it was “conformance to requirements”
		+	[1]. Watts Humphrey refers to it as “achieving
		+	excellent levels of “fitness for use” [2]. Meanwhile,
		+	IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”
		+	[3*, p8].
		+
		+	More recently, software quality is defined as the
		+	“capability of software product to satisfy stated
		+	and implied needs under specified conditions” [4]
		+	and as “the degree to which a software product
		+	meets established requirements; however, quality
		+	depends upon the degree to which those established
		+	requirements accurately represent stakeholder
		+	needs, wants, and expectations” [5]. Both
		+	definitions embrace the premise of conformance
		+	to requirements. Neither refers to types of requirements
		+	(e.g., functional, reliability, performance,
		+	dependability, or any other characteristic). Significantly,
		+	however, these definitions emphasize that
		+	quality is dependent upon requirements.
		+
		+	These definitions also illustrate another reason
		+	for the prevalence of software quality throughout
		+	this ''Guide'': a frequent ambiguity of ''software quality'' versus ''software quality requirements''
		+	(“the -''ilities''” is a common shorthand). Software
		+	quality requirements are actually attributes of (or
		+	constraints on) functional requirements (what
		+	the system does). Software requirements may
		+	also specify resource usage, a communication
		+	protocol, or many other characteristics. This KA
		+	attempts clarity by using ''software quality'' in the
		+	broadest sense from the definitions above and
		+	by using ''software quality requirements'' as constraints
		+	on functional requirements. Software
		+	quality is achieved by conformance to all requirements
		+	regardless of what characteristic is specified
		+	or how requirements are grouped or named.
		+
		+	Software quality is also considered in many of
		+	the SWEBOK KAs because it is a basic parameter
		+	of a software engineering effort. For all engineered
		+	products, the primary goal is delivering
		+	maximum stakeholder value, while balancing the
		+	constraints of development cost and schedule;
		+	this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements.
		+	For software products, stakeholders could
		+	value price (what they pay for the product), lead
		+	time (how fast they get the product), and software
		+	quality.
		+
		+	This KA addresses definitions and provides an
		+	overview of practices, tools, and techniques for
		+	defining software quality and for appraising the
		+	state of software quality during development,
		+	maintenance, and deployment. Cited references
		+	provide additional details.}}
		+	[[File:Breakdown of Topics for the Software Quality.jpg\|thumb\|300px\|frame\|Figure 10.1: Breakdown of Topics for the Software Quality KA]]
		+	{{IntroSection\|title=Breakdown of Topics for Software Quality\|body=
		+	The breakdown of topics for the Software Quality KA is presented in Figure 10.1.}}