Software Engineering Body of Knowledge (v3) (2014) (811503), страница 49
Текст из файла (страница 49)
V&V processes provide an objective assessmentof products and processes throughout thelife cycle. This assessment demonstrateswhether the requirements are correct, complete, accurate, consistent, and testable.The V&V processes determine whetherthe development products of a given activity conform to the requirements of thatactivity and whether the product satisfiesits intended use and user needs.Verification is an attempt to ensure that theproduct is built correctly, in the sense that theoutput products of an activity meet the specifications imposed on them in previous activities.Validation is an attempt to ensure that the rightproduct is built—that is, the product fulfills itsspecific intended purpose.
Both the verificationprocess and the validation process begin earlyin the development or maintenance phase. Theyprovide an examination of key product featuresin relation to both the product’s immediate predecessor and the specifications to be met.The purpose of planning V&V is to ensure thateach resource, role, and responsibility is clearlyassigned. The resulting V&V plan documentsdescribe the various resources and their roles andactivities, as well as the techniques and tools to beused.
An understanding of the different purposes ofeach V&V activity helps in the careful planning ofthe techniques and resources needed to fulfill theirpurposes. The plan also addresses the management, communication, policies, and procedures ofthe V&V activities and their interaction, as well asdefect reporting and documentation requirements.2.3. Reviews and Audits[9*, c24s3] [16*]Reviews and audit processes are broadly definedas static—meaning that no software programs ormodels are executed—examination of softwareengineering artifacts with respect to standards thathave been established by the organization or project for those artifacts.
Different types of reviewsand audits are distinguished by their purpose, levels of independence, tools and techniques, roles,and by the subject of the activity. Product assurance and process assurance audits are typicallyconducted by software quality assurance (SQA)personnel who are independent of developmentSoftware Quality 10-7teams. Management reviews are conducted byorganizational or project management. The engineering staff conducts technical reviews.• Management reviews evaluate actual projectresults with respect to plans.• Technical reviews (including inspections,walkthrough, and desk checking) examineengineering work-products.• Process assurance audits.
SQA processassurance activities make certain that theprocesses used to develop, install, operate,and maintain software conform to contracts,comply with any imposed laws, rules, andregulations and are adequate, efficient andeffective for their intended purpose [5].• Product assurance audits. SQA productassurance activities make certain to provideevidence that software products and relateddocumentation are identified in and complywith contracts; and ensure that nonconformances are identified and addressed [5].2.3.1. Management ReviewsAs stated in [16*],The purpose of a management review is tomonitor progress, determine the status ofplans and schedules, and evaluate the effectiveness of management processes, toolsand techniques.
Management reviews compare actual project results against plans todetermine the status of projects or maintenance efforts. The main parameters of management reviews are project cost, schedule,scope, and quality. Management reviewsevaluate decisions about corrective actions,changes in the allocation of resources, orchanges to the scope of the project.Inputs to management reviews may includeaudit reports, progress reports, V&V reports, andplans of many types, including risk management,project management, software configurationmanagement, software safety, and risk assessment, among others. (Refer to the Software Engineering Management and the Software Configuration Management KAs for related material.)2.3.2. Technical ReviewsAs stated in [16*],The purpose of a technical review is toevaluate a software product by a team ofqualified personnel to determine its suitability for its intended use and identifydiscrepancies from specifications andstandards.
It provides management withevidence to confirm the technical status ofthe project.Although any work-product can be reviewed,technical reviews are performed on the mainsoftware engineering work-products of softwarerequirements and software design.Purpose, roles, activities, and most importantlythe level of formality distinguish different typesof technical reviews. Inspections are the most formal, walkthroughs less, and pair reviews or deskchecks are the least formal.Examples of specific roles include a decisionmaker (i.e., software lead), a review leader, arecorder, and checkers (technical staff memberswho examine the work-products). Reviews arealso distinguished by whether meetings (face toface or electronic) are included in the process.
Insome review methods checkers solitarily examine work-products and send their results back toa coordinator. In other methods checkers workcooperatively in meetings. A technical reviewmay require that mandatory inputs be in place inorder to proceed:• Statement of objectives• Specific software product• Specific project management plan• Issues list associated with this product• Technical review procedure.The team follows the documented review procedure. The technical review is completed onceall the activities listed in the examination havebeen completed.Technical reviews of source code may include awide variety of concerns such as analysis of algorithms, utilization of critical computer resources,adherence to coding standards, structure and10-8 SWEBOK® Guide V3.0organization of code for testability, and safetycritical considerations.Note that technical reviews of source code ordesign models such as UML are also termed staticanalysis (see topic 3, Practical Considerations).2.3.3. Inspections“The purpose of an inspection is to detect andidentify software product anomalies” [16*].Some important differentiators of inspections ascompared to other types of technical reviews arethese:1.Rules.
Inspections are based upon examininga work-product with respect to a defined setof criteria specified by the organization. Setsof rules can be defined for different types ofworkproducts (e.g., rules for requirements,architecture descriptions, source code).2.Sampling. Rather that attempt to examineevery word and figure in a document, theinspection process allows checkers to evaluate defined subsets (samples) of the documents under review.3.Peer. Individuals holding management positions over members of the inspection teamdo not participate in the inspection. This isa key distinction between peer review andmanagement review.4.Led.
An impartial moderator who is trainedin inspection techniques leads inspectionmeetings.5.Meeting. The inspection process includesmeetings (face to face or electronic) conducted by a moderator according to a formalprocedure in which inspection team members report the anomalies they have foundand other issues.Software inspections always involve the authorof an intermediate or final product; other reviewsmight not. Inspections also include an inspectionleader, a recorder, a reader, and a few (two to five)checkers (inspectors). The members of an inspection team may possess different expertise, such asdomain expertise, software design method expertise, or programming language expertise. Inspections are usually conducted on one relativelysmall section of the product at a time (samples).Each team member examines the software product and other review inputs prior to the reviewmeeting, perhaps by applying an analytical technique (see section 3.3.3) to a small section ofthe product or to the entire product with a focuson only one aspect—e.g., interfaces.
During theinspection, the moderator conducts the sessionand verifies that everyone has prepared for theinspection and conducts the session. The inspection recorder documents anomalies found. A setof rules, with criteria and questions germane tothe issues of interest, is a common tool used ininspections. The resulting list often classifies theanomalies (see section 3.2, Defect Characterization) and is reviewed for completeness and accuracy by the team. The inspection exit decisioncorresponds to one of the following options:1.Accept with no or, at most, minor reworking2.Accept with rework verification3.Reinspect.2.3.4. WalkthroughsAs stated in [16*],The purpose of a systematic walk-throughis to evaluate a software product.
A walkthrough may be conducted for the purposeof educating an audience regarding a software product.Walkthroughs are distinguished from inspections. The main difference is that the author presents the work-product to the other participants ina meeting (face to face or electronic). Unlike aninspection, the meeting participants may not havenecessarily seen the material prior to the meeting. The meetings may be conducted less formally. The author takes the role of explaining andshowing the material to participants and solicitsfeedback. Like inspections, walkthroughs may beconducted on any type of work-product includingproject plan, requirements, design, source code,and test reports.Software Quality 10-92.3.5. Process Assurance and Product Assurance AuditsAs stated in [16*],The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes to applicable regulations, standards,guidelines, plans, and procedures.Process assurance audits determine the adequacyof plans, schedules, and requirements to achieveproject objectives [5].
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
