Software Engineering Body of Knowledge (v3) (2014) (811503), страница 47
Текст из файла (страница 47)
Mellor and M.J. Balcer, ExecutableUML: A Foundation for Model-DrivenArchitecture, 1st ed., Addison-Wesley,2002.[3*] I. Sommerville, Software Engineering, 9thed., Addison-Wesley, 2011.[4*] M. Page-Jones, Fundamentals of ObjectOriented Design in UML, 1st ed., AddisonWesley, 1999.[5*] J.M. Wing, “A Specifier’s Introduction toFormal Methods,” Computer, vol. 23, no. 9,1990, pp. 8, 10–23.[6*] J.G. Brookshear, Computer Science: AnOverview, 10th ed., Addison-Wesley, 2008.[7*] B. Boehm and R.
Turner, Balancing Agilityand Discipline: A Guide for the Perplexed,Addison-Wesley, 2003.CHAPTER 10SOFTWARE QUALITYACRONYMSCMMICoSQCOTSFMEAFTAPDCAPDSAQFDSPISQASQCSQMTQMV&VCapability Maturity ModelIntegrationCost of Software QualityCommercial Off-the-ShelfSoftwareFailure Mode and Effects AnalysisFault Tree AnalysisPlan-Do-Check-ActPlan-Do-Study-ActQuality Function DeploymentSoftware Process ImprovementSoftware Quality AssuranceSoftware Quality ControlSoftware Quality ManagementTotal Quality ManagementVerification and ValidationINTRODUCTIONWhat 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 isoverloaded.
Software quality may refer: to desirable characteristics of software products, to theextent 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 organizationshave defined the term quality differently. To PhilCrosby, it was “conformance to requirements”[1]. Watts Humphrey refers to it as “achievingexcellent levels of “fitness for use” [2]. Meanwhile, IBM coined the phrase “market-drivenquality,” where the “customer is the final arbiter”[3*, p8].More recently, software quality is defined as the“capability of software product to satisfy statedand implied needs under specified conditions” [4]and as “the degree to which a software productmeets established requirements; however, qualitydepends upon the degree to which those established requirements accurately represent stakeholder needs, wants, and expectations” [5].
Bothdefinitions embrace the premise of conformanceto requirements. Neither refers to types of requirements (e.g., functional, reliability, performance,dependability, or any other characteristic). Significantly, however, these definitions emphasize thatquality is dependent upon requirements.These definitions also illustrate another reasonfor the prevalence of software quality throughout this Guide: a frequent ambiguity of softwarequality versus software quality requirements(“the -ilities” is a common shorthand). Softwarequality requirements are actually attributes of (orconstraints on) functional requirements (whatthe system does).
Software requirements mayalso specify resource usage, a communicationprotocol, or many other characteristics. This KAattempts clarity by using software quality in thebroadest sense from the definitions above andby using software quality requirements as constraints on functional requirements. Softwarequality 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 ofthe SWEBOK KAs because it is a basic parameter of a software engineering effort. For all engineered products, the primary goal is deliveringmaximum stakeholder value, while balancing theconstraints of development cost and schedule;this is sometimes characterized as “fitness for10-110-2 SWEBOK® Guide V3.0Figure 10.1.
Breakdown of Topics for the Software Quality KAuse.” Stakeholder value is expressed in requirements. For software products, stakeholders couldvalue price (what they pay for the product), leadtime (how fast they get the product), and softwarequality.This KA addresses definitions and provides anoverview of practices, tools, and techniques fordefining software quality and for appraising thestate of software quality during development,maintenance, and deployment. Cited referencesprovide additional details.BREAKDOWN OF TOPICS FORSOFTWARE QUALITYThe breakdown of topics for the Software QualityKA is presented in Figure 10.1.1. Software Quality FundamentalsReaching agreement on what constitutes qualityfor all stakeholders and clearly communicatingthat agreement to software engineers require thatthe many aspects of quality be formally definedand discussed.A software engineer should understand quality concepts, characteristics, values, and theirapplication to the software under development ormaintenance.
The important concept is that thesoftware requirements define the required qualityattributes of the software. Software requirementsinfluence the measurement methods and acceptance criteria for assessing the degree to whichthe software and related documentation achievethe desired quality levels.1.1. Software Engineering Culture and Ethics[3*, c1s4] [6*, c2s3.5]Software engineers are expected to share a commitment to software quality as part of their culture.A healthy software engineering culture includesmany characteristics, including the understandingthat tradeoffs among cost, schedule, and qualityare a basic tenant of the engineering of any product.
A strong software engineering ethic assumesSoftware Quality 10-3that engineers accurately report information, conditions, and outcomes related to quality.Ethics also play a significant role in softwarequality, the culture, and the attitudes of softwareengineers. The IEEE Computer Society and theACM have developed a code of ethics and professional practice (see Codes of Ethics and Professional Conduct in the Software EngineeringProfessional Practice KA).software product to the customer. External failure costs include activities to respond to softwareproblems discovered after delivery to the customer.Software engineers should be able to use CoSQmethods to ascertain levels of software qualityand should also be able to present quality alternatives and their costs so that tradeoffs betweencost, schedule, and delivery of stakeholder valuecan be made.1.2. Value and Costs of Quality1.3. Models and Quality Characteristics[3*, c24s1] [7*, c2s4] [8*, c17][7*, c17, c22]Defining and then achieving software quality isnot simple.
Quality characteristics may or maynot be required, or they may be required to agreater or lesser degree, and tradeoffs may bemade among them. To help determine the levelof software quality, i.e., achieving stakeholdervalue, this section presents cost of software quality (CoSQ): a set of measurements derived fromthe economic assessment of software qualitydevelopment and maintenance processes. TheCoSQ measurements are examples of processmeasurements that may be used to infer characteristics of a product.The premise underlying the CoSQ is that thelevel of quality in a software product can beinferred from the cost of activities related to dealing with the consequences of poor quality.
Poorquality means that the software product does notfully “satisfy stated and implied needs” or “established requirements.” There are four cost of quality categories: prevention, appraisal, internal failure, and external failure.Prevention costs include investments in softwareprocess improvement efforts, quality infrastructure, quality tools, training, audits, and management reviews. These costs are usually not specificto a project; they span the organization. Appraisalcosts arise from project activities that find defects.These appraisal activities can be categorized intocosts of reviews (design, peer) and costs of testing (software unit testing, software integration,system level testing, acceptance testing); appraisalcosts would be extended to subcontracted softwaresuppliers. Costs of internal failures are those thatare incurred to fix defects found during appraisalactivities and discovered prior to delivery of theTerminology for software quality characteristicsdiffers from one taxonomy (or model of softwarequality) to another, each model perhaps havinga different number of hierarchical levels and adifferent total number of characteristics.
Variousauthors have produced models of software quality characteristics or attributes that can be usefulfor discussing, planning, and rating the qualityof software products. ISO/IEC 25010: 2011 [4]defines product quality and quality in use as tworelated quality models. Appendix B in the SWEBOK Guide provides a list of applicable standardsfor each KA.
Standards for this KA cover variousways of characterizing software quality.1.3.1. Software Process QualitySoftware quality management and software engineering process quality have a direct bearing onthe quality of the software product.Models and criteria that evaluate the capabilities of software organizations are primarily project organization and management considerationsand, as such, are covered in the Software Engineering Management and Software EngineeringProcess KAs.It is not possible to completely distinguish process quality from product quality because processoutcomes include products.
Determining whethera process has the capability to consistently produce products of desired quality is not simple.The software engineering process, discussedin the Software Engineering Process KA, influences the quality characteristics of software products, which in turn affect quality as perceived bystakeholders.10-4 SWEBOK® Guide V3.01.3.2. Software Product QualityThe software engineer, first of all, must determinethe real purpose of the software. In this regard,stakeholder requirements are paramount, and theyinclude quality requirements in addition to functional requirements. Thus, software engineershave a responsibility to elicit quality requirementsthat may not be explicit at the outset and to understand their importance as well as the level of difficulty in attaining them. All software developmentprocesses (e.g., eliciting requirements, designing,constructing, building, checking, improving quality) are designed with these quality requirementsin mind and may carry additional developmentcosts if attributes such as safety, security, anddependability are important.
The additional development costs help ensure that quality obtained canbe traded off against the anticipated benefits.The term work-product means any artifact thatis the outcome of a process used to create thefinal software product. Examples of a work-product include a system/subsystem specification, asoftware requirements specification for a software component of a system, a software designdescription, source code, software test documentation, or reports. While some treatments of quality are described in terms of final software andsystem performance, sound engineering practicerequires that intermediate work-products relevantto quality be evaluated throughout the softwareengineering process.1.4. Software Quality Improvement[3*, c1s4] [9*, c24] [10*, c11s2.4]The quality of software products can be improvedthrough preventative processes or an iterative process of continual improvement, whichrequires management control, coordination, andfeedback from many concurrent processes: (1)the software life cycle processes, (2) the processof fault/defect detection, removal, and prevention, and (3) the quality improvement process.The theory and concepts behind quality improvement—such as building in qualitythrough the prevention and early detection ofdefects, continual improvement, and stakeholderfocus—are pertinent to software engineering.These concepts are based on the work of expertsin quality who have stated that the quality of aproduct is directly linked to the quality of theprocess used to create it.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
