Software Engineering Body of Knowledge (v3) (2014) (811503), страница 50
Текст из файла (страница 50)
The audit is a formallyorganized activity with participants having specific roles—such as lead auditor, another auditor, arecorder, or an initiator—and including a representative of the audited organization. Audits identifyinstances of nonconformance and produce a reportrequiring the team to take corrective action.While there may be many formal names forreviews and audits, such as those identified in thestandard [16*], the important point is that theycan occur on almost any product at any stage ofthe development or maintenance process.3. Practical Considerations3.1. Software Quality Requirements[9*, c11s1] [18*, c12][17*, c15s3.2.2, c15s3.3.1, c16s9.10]3.1.1. Influence FactorsVarious factors influence planning, management,and selection of SQM activities and techniques,including• the domain of the system in which the software resides; the system functions could besafety-critical, mission-critical, businesscritical, security-critical• the physical environment in which the software system resides• system and software functional (what thesystem does) and quality (how well the system performs its functions) requirements• the commercial (external) or standard (internal) components to be used in the system• the specific software engineering standardsapplicable• the methods and software tools to be used fordevelopment and maintenance and for quality evaluation and improvement• the budget, staff, project organization, plans,and scheduling of all processes• the intended users and use of the system• the integrity level of the system.Information on these factors influences howthe SQM processes are organized and documented, how specific SQM activities are selected,what resources are needed, and which of thoseresources impose bounds on the efforts.3.1.2. DependabilityIn cases where system failure may have extremelysevere consequences, overall dependability (hardware, software, and human or operational) is themain quality requirement over and above basicfunctionality.
This is the case for the followingreasons: system failures affect a large number ofpeople; users often reject systems that are unreliable, unsafe, or insecure; system failure costsmay be enormous; and undependable systemsmay cause information loss. System and software dependability include such characteristicsas availability, reliability, safety, and security.When developing dependable software, tools andtechniques can be applied to reduce the risk ofinjecting faults into the intermediate deliverablesor the final software product. Verification, validation, and testing processes, techniques, methods,and tools identify faults that impact dependabilityas early as possible in the life cycle. Additionally, mechanisms may need to be in place in thesoftware to guard against external attacks and totolerate faults.3.1.3. Integrity Levels of SoftwareDefining integrity levels is a method of riskmanagement.Software integrity levels are a range ofvalues that represent software complexity,criticality, risk, safety level, security level,10-10 SWEBOK® Guide V3.0desired performance, reliability, or otherproject-unique characteristics that definethe importance of the software to the userand acquirer.
The characteristics used todetermine software integrity level varydepending on the intended application anduse of the system. The software is a part ofthe system, and its integrity level is to bedetermined as a part of that system.The assigned software integrity levels maychange as the software evolves. Design, coding,procedural, and technology features implementedin the system or software can raise or lower theassigned software integrity levels. The softwareintegrity levels established for a project resultfrom agreements among the acquirer, supplier,developer, and independent assurance authorities.A software integrity level scheme is a tool used indetermining software integrity levels.
[5]As noted in [17*], “the integrity levels can beapplied during development to allocate additionalverification and validation efforts to high-integrity components.”3.2. Defect Characterization[3*, c3s3, c8s8, c10s2]Software quality evaluation (i.e., software qualitycontrol) techniques find defects, faults and failures. Characterizing these techniques leads to anunderstanding of the product, facilitates corrections to the process or the product, and informsmanagement and other stakeholders of the status of the process or product. Many taxonomiesexist and, while attempts have been made to gainconsensus, the literature indicates that there arequite a few in use.
Defect characterization is alsoused in audits and reviews, with the review leaderoften presenting a list of issues provided by teammembers for consideration at a review meeting.As new design methods and languages evolve,along with advances in overall software technologies, new classes of defects appear, and a greatdeal of effort is required to interpret previouslydefined classes.
When tracking defects, the software engineer is interested in not only the numberof defects but also the types. Information alone,without some classification, may not be sufficientto identify the underlying causes of the defects.Specific types of problems need to be grouped toidentify trends over time. The point is to establisha defect taxonomy that is meaningful to the organization and to software engineers.Software quality control activities discover information at all stages of software development andmaintenance. In some cases, the word defect isoverloaded to refer to different types of anomalies.However, different engineering cultures and standards may use somewhat different meanings forthese terms.
The variety of terms prompts this section to provide a widely used set of definitions [19]:• Computational Error: “the differencebetween a computed, observed, or measuredvalue or condition and the true, specified, ortheoretically correct value or condition.”• Error: “A human action that produces anincorrect result.” A slip or mistake that a person makes. Also called human error.• Defect: An “imperfection or deficiency in awork product where that work product doesnot meet its requirements or specificationsand needs to be either repaired or replaced.”A defect is caused by a person committingan error.• Fault: A defect in source code. An “incorrectstep, process, or data definition in computerprogram.” The encoding of a human error insource code.
Fault is the formal name of a bug.• Failure: An “event in which a system or system component does not perform a requiredfunction within specified limits.” A failure isproduced when a fault is encountered by theprocessor under specified conditions.Using these definitions three widely used software quality measurements are defect density(number of defects per unit size of documents),fault density (number of faults per 1K lines ofcode), and failure intensity (failures per use-houror per test-hour). Reliability models are builtfrom failure data collected during software testing or from software in service and thus can beused to estimate the probability of future failuresand to assist in decisions on when to stop testing.One probable action resulting from SQM findings is to remove the defects from the productunder examination (e.g., find and fix bugs, createnew build).
Other activities attempt to eliminateSoftware Quality 10-11the causes of the defects—for example, root causeanalysis (RCA). RCA activities include analyzingand summarizing the findings to find root causesand using measurement techniques to improvethe product and the process as well as to track thedefects and their removal. Process improvementis primarily discussed in the Software Engineering Process KA, with the SQM process being asource of information.Data on inadequacies and defects found bysoftware quality control techniques may be lostunless they are recorded. For some techniques(e.g., technical reviews, audits, inspections),recorders are present to set down such information, along with issues and decisions. When automated tools are used (see topic 4, Software Quality Tools), the tool output may provide the defectinformation.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
