Software Engineering Body of Knowledge (v3) (2014) (811503), страница 93
Текст из файла (страница 93)
The model isapplicable to both computer systems andsoftware products.The characteristics defined by both modelsare relevant to all software products and computer systems. The characteristics and subcharacteristics provide consistent terminology forspecifying, measuring, and evaluating systemand software product quality.
They also providea set of quality characteristics against whichstated quality requirements can be compared forcompleteness.B-22 SWEBOK® Guide V3.0Although the scope of the product qualitymodel is intended to be software and computersystems, many of the characteristics are also relevant to wider systems and services.ISO/IEC 25012 contains a model for data quality that is complementary to this model.The scope of the models excludes purely functional properties, but it does include functionalsuitability.The scope of application of the quality modelsincludes supporting specification and evaluationof software and software-intensive computer systems from different perspectives by those who areassociated with their acquisition, requirements,development, use, evaluation, support, maintenance, quality assurance and control, and audit.The models can, for example, be used by developers, acquirers, quality assurance and controlstaff, and independent evaluators, particularlythose responsible for specifying and evaluatingsoftware product quality.
Activities during product development that can benefit from the use ofthe quality models include• identifying software and system requirements;• validating the comprehensiveness of arequirements definition;• identifying software and system designobjectives;• identifying software and system testingobjectives;• identifying quality control criteria as part ofquality assurance;• identifying acceptance criteria for a softwareproduct and/or software-intensive computersystem;• establishing measures of quality characteristics in support of these activities.Some documents in the SQuaRE series deal specifically with the characteristic of usability.
TheCommon Industry Format (CIF) for usability reporting began at the US National Institute for Standardsand Technology (NIST) and was moved into ISO/IEC JTC 1/SC 7 for purposes of standardization.ISO/IEC 25060 through 25064 Software Engineering—Software Product Quality Requirements andEvaluation (SQuaRE)—Common Industry Format(CIF) for UsabilityA family of international standards, named theCommon Industry Formats (CIF), documentsthe specification and evaluation of the usabilityof interactive systems. It provides a general overview of the CIF framework and contents, definitions, and the relationship of the framework elements.
The intended users of the framework areidentified, as well as the situations in which theframework may be applied. The assumptions andconstraints of the framework are also enumerated.The framework content includes the following:• consistent terminology and classification ofspecification, evaluation, and reporting;• a definition of the type and scope of formatsand the high-level structure to be used fordocumenting required information and theresults of evaluation.The CIF family of standards is applicable tosoftware and hardware products used for predefined tasks. The information items are intendedto be used as part of system-level documentationresulting from development processes such asthose in ISO 9241-210 and ISO/IEC JTC 1/SC 7process standards.The CIF family focuses on documenting thoseelements needed for design and development ofusable systems, rather than prescribing a specificprocess.
It is intended to be used in conjunctionwith existing international standards, including ISO 9241, ISO 20282, ISO/IEC 9126, andthe SQuaRE series (ISO/IEC 25000 to ISO/IEC25099).The CIF family of standards does not prescribeany kind of method, life cycle or process.Not everyone agrees with the taxonomy ofquality characteristics in ISO/IEC 25010. Thatstandard has a quality factor called “reliability”that has subfactors of maturity, availability, faulttolerance, and recoverability. IEC TC 65, whichhas responsibility for standards on “dependability,” defines that term as a nonquantitative composite of reliability, maintainability, and maintenance support. Others use the term “reliability”Appendix B B-23to denote a measure defined by a mathematicalequation. The disagreement over the use of thesewords means that the standards on the subject areinherently unaligned.
A few will be noted below,but the words like those noted above may meandifferent things in different standards.IEEE Std. 982.1-2005 Standard for Dictionary ofMeasures of the Software Aspects of DependabilityA standard dictionary of measures of the software aspects of dependability for assessing andpredicting the reliability, maintainability, andavailability of any software system; in particular,it applies to mission critical software systems.IEEE Std.
1633-2008 Recommended Practice forSoftware ReliabilityThe methods for assessing and predicting the reliability of software, based on a life cycle approachto software reliability engineering, are prescribed inthis recommended practice. It provides informationnecessary for the application of software reliability(SR) measurement to a project, lays a foundationfor building consistent methods, and establishesthe basic principle for collecting the data needed toassess and predict the reliability of software. Therecommended practice prescribes how any user canparticipate in SR assessments and predictions.IEEE has an overall standard for softwareproduct quality that has a scope similar to theISO/IEC 250xx series described previously. Itsterminology differs from the ISO/IEC series, butit is substantially more compact.IEEE Std.
1061-1998 Standard for Software QualityMetrics MethodologyA methodology for establishing quality requirements and identifying, implementing, analyzing,and validating the process and product softwarequality metrics is defined. The methodologyspans the entire software life cycle.One approach to achieving software quality isto perform an extensive program of verificationand validation. IEEE Std. 1012 is probably theworld’s most widely applied standard on this subject. A revision was recently published.IEEE Std. 1012-2012 Standard for System and Software Verification and ValidationVerification and validation (V&V) processes areused to determine whether the development products of a given activity conform to the requirements of that activity and whether the productsatisfies its intended use and user needs.
V&V lifecycle process requirements are specified for different integrity levels. The scope of V&V processesencompasses systems, software, and hardware, andit includes their interfaces. This standard applies tosystems, software, and hardware being developed,maintained, or reused [legacy, commercial off-theshelf (COTS), nondevelopmental items]. The termsoftware also includes firmware and microcode,and each of the terms system, software, and hardware includes documentation. V&V processesinclude the analysis, evaluation, review, inspection, assessment, and testing of products.There are other standards that support the verification and validation processes.
One describestechniques for performing reviews and auditsduring a software project.IEEE Std. 1028-2008 Standard for Software Reviewsand AuditsFive types of software reviews and audits,together with procedures required for the execution of each type, are defined in this standard.This standard is concerned only with the reviewsand audits; procedures for determining the necessity of a review or audit are not defined, and thedisposition of the results of the review or auditis not specified.
Types included are managementreviews, technical reviews, inspections, walkthroughs, and audits.B-24 SWEBOK® Guide V3.0In many cases, a database of software anomalies is used to support verification and validationactivities. The following standard suggests howanomalies should be classified.use of each part and the combined use of multipleparts.
Coverage of assurance for a service beingoperated and managed on an ongoing basis is notcovered in ISO/IEC 15026.IEEE Std. 1044-2009 Standard for Classification forSoftware AnomaliesThe second part of the standard describes thestructure of an “assurance case,” which is intendedas a structured argument that the critical propertyhas been achieved. It is a generalization of variousdomain-specific constructs like “safety cases.”This standard provides a uniform approach to theclassification of software anomalies, regardlessof when they originate or when they are encountered within the project, product, or system lifecycle. Classification data can be used for a variety of purposes, including defect causal analysis, project management, and software processimprovement (e.g., to reduce the likelihood ofdefect insertion and/or increase the likelihood ofearly defect detection).In some systems, one particular property of thesoftware is so important that it requires specialtreatment beyond that provided by a conventional verification and validation program.
Theemerging term for this sort of treatment is “systems and software assurance.” Examples includesafety, privacy, high security, and ultrareliability.The 15026 standard is under development to dealwith such situations. The first part of the four-partstandard provides terminology and concepts usedin the remaining parts. It was first written beforethe other parts and is now being revised for complete agreement with the others.IEEE Std. 15026.1-2011 Trial-Use Standard Adoption of ISO/IEC TR 15026-1:2010 Systems and Software Engineering—Systems and Software Assurance—Part 1: Concepts and VocabularyThis trial-use standard adopts ISO/IEC TR15026-1:2010, which defines terms and establishes an extensive and organized set of conceptsand their relationships for software and systemsassurance, thereby establishing a basis for sharedunderstanding of the concepts and principles central to ISO/IEC 15026 across its user communities.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
