Software Engineering Body of Knowledge (v3) (2014) (811503), страница 51
Текст из файла (страница 51)
Reports about defects are providedto the management of the organization.3.3. Software Quality Management Techniques[7*, c7s3] [8*, c17] [9*, c12s5, c15s1, p417][16*]Software quality control techniques can be categorized in many ways, but a straightforwardapproach uses just two categories: static anddynamic. Dynamic techniques involve executingthe software; static techniques involve analyzingdocuments and source code but not executing thesoftware.3.3.1. Static TechniquesStatic techniques examine software documentation (including requirements, interface specifications, designs, and models) and software sourcecode without executing the code. There are manytools and techniques for statically examining software work-products (see section 2.3.2).
In addition, tools that analyze source code control flowand search for dead code are considered to bestatic analysis tools because they do not involveexecuting the software code.Other, more formal, types of analytical techniques are known as formal methods.
They arenotably used to verify software requirements anddesigns. They have mostly been used in the verification of crucial parts of critical systems, suchas specific security and safety requirements. (Seealso Formal Methods in the Software Engineering Models and Methods KA.)3.3.2. Dynamic TechniquesDynamic techniques involve executing the software code. Different kinds of dynamic techniquesare performed throughout the development andmaintenance of software.
Generally, these aretesting techniques, but techniques such as simulation and model analysis may be considereddynamic (see the Software Engineering Modelsand Methods KA). Code reading is considered astatic technique, but experienced software engineers may execute the code as they read throughit. Code reading may utilize dynamic techniques.This discrepancy in categorizing indicates thatpeople with different roles and experience in theorganization may consider and apply these techniques differently.Different groups may perform testing duringsoftware development, including groups independent of the development team. The SoftwareTesting KA is devoted entirely to this subject.3.3.3. TestingTwo types of testing may fall under V&V becauseof their responsibility for the quality of the materials used in the project:• Evaluation and tests of tools to be used onthe project• Conformance tests (or review of conformance tests) of components and COTS products to be used in the product.Sometimes an independent (third-party orIV&V) organization may be tasked to performtesting or to monitor the test process V&V maybe called upon to evaluate the testing itself: adequacy of plans, processes, and procedures, andadequacy and accuracy of results.The third party is not the developer, nor is itassociated with the development of the product.Instead, the third party is an independent facility, usually accredited by some body of authority.Their purpose is to test a product for conformanceto a specific set of requirements (see the SoftwareTesting KA).10-12 SWEBOK® Guide V3.03.4. Software Quality Measurement[3*, c4] [8*, c17] [9*, p90]Software quality measurements are used tosupport decision-making.
With the increasingsophistication of software, questions of qualitygo beyond whether or not the software works tohow well it achieves measurable quality goals.Decisions supported by software quality measurement include determining levels of softwarequality (notably because models of softwareproduct quality include measures to determinethe degree to which the software product achievesquality goals); managerial questions about effort,cost, and schedule; determining when to stop testing and release a product (see Termination undersection 5.1, Practical Considerations, in the Software Testing KA); and determining the efficacyof process improvement efforts.The cost of SQM processes is an issue frequently raised in deciding how a project or a software development and maintenance group shouldbe organized.
Often, generic models of cost areused, which are based on when a defect is foundand how much effort it takes to fix the defect relative to finding the defect earlier in the development process. Software quality measurement datacollected internally may give a better picture ofcost within this project or organization.While the software quality measurement datamay be useful in itself (e.g., the number of defective requirements or the proportion of defectiverequirements), mathematical and graphical techniques can be applied to aid in the interpretationof the measures (see the Engineering FoundationsKA).
These techniques include• descriptive statistics based (e.g., Paretoanalysis, run charts, scatter plots, normaldistribution)• statistical tests (e.g., the binomial test, chisquared test)• trend analysis (e.g., control charts; seeThe Quality Toolbox in the list of furtherreadings)• prediction (e.g., reliability models).Descriptive statistics-based techniques andtests often provide a snapshot of the moretroublesome areas of the software product underexamination. The resulting charts and graphsare visualization aids, which the decision makers can use to focus resources and conduct process improvements where they appear to be mostneeded.
Results from trend analysis may indicatethat a schedule is being met, such as in testing, orthat certain classes of faults may become morelikely to occur unless some corrective action istaken in development. The predictive techniquesassist in estimating testing effort and scheduleand in predicting failures. More discussion onmeasurement in general appears in the SoftwareEngineering Process and Software EngineeringManagement KAs.
More specific information ontesting measurement is presented in the SoftwareTesting KA.Software quality measurement includes measuring defect occurrences and applying statisticalmethods to understand the types of defects thatoccur most frequently. This information may beused by software process improvement for determining methods to prevent, reduce, or eliminatetheir recurrence. They also aid in understandingtrends, how well detection and containment techniques are working, and how well the development and maintenance processes are progressing.From these measurement methods, defectprofiles can be developed for a specific application domain. Then, for the next software projectwithin that organization, the profiles can be usedto guide the SQM processes—that is, to expendthe effort where problems are most likely to occur.Similarly, benchmarks, or defect counts typical ofthat domain, may serve as one aid in determiningwhen the product is ready for delivery.
Discussion on using data from SQM to improve development and maintenance processes appears in theSoftware Engineering Management and SoftwareEngineering Process KAs.4. Software Quality ToolsSoftware quality tools include static and dynamicanalysis tools. Static analysis tools input sourcecode, perform syntactical and semantic analysiswithout executing the code, and present results tousers. There is a large variety in the depth, thoroughness, and scope of static analysis tools thatSoftware Quality 10-13can be applied to artifacts including models, inaddition to source code. (See the Software Construction, Software Testing, and Software Maintenance KAs for descriptions of dynamic analysistools.)Categories of static analysis tools include thefollowing:• Tools that facilitate and partially automatereviews and inspections of documents andcode. These tools can route work to different participants in order to partially automateand control a review process.
They allowusers to enter defects found during inspections and reviews for later removal.• Some tools help organizations perform software safety hazard analysis. These toolsprovide, e.g., automated support for failuremode and effects analysis (FMEA) and faulttree analysis (FTA).• Tools that support tracking of software problems provide for entry of anomalies discovered during software testing and subsequentanalysis, disposition, and resolution. Sometools include support for workflow and fortracking the status of problem resolution.• Tools that analyze data captured from software engineering environments and software test environments and produce visualdisplays of quantified data in the form ofgraphs, charts, and tables.
These tools sometimes include the functionality to performstatistical analysis on data sets (for the purpose of discerning trends and making forecasts). Some of these tools provide defectand removal injection rates; defect densities;yields; distribution of defect injection andremoval for each of the life cycle phases.10-14 SWEBOK® Guide V3.0c24s1c2s4c1s4c17c11s3c4–c6,c11,c26–272.2. Verificationand Validationc2s2.3,c8, c15s1.1,c21s3.32.3. Reviewsand Auditsc24s3*Wiegers 2003[18*]c11s2.4c17,c22Moore 2006[17*]Voland 2003[10*]c24IEEE Std.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
