Software Engineering Body of Knowledge (v3) (2014) (811503), страница 48
Текст из файла (страница 48)
Approaches such as theDeming improvement cycle of Plan-Do-CheckAct (PDCA), evolutionary delivery, kaizen, andquality function deployment (QFD) offer techniques to specify quality objectives and determinewhether they are met. The Software EngineeringInstitute’s IDEAL is another method [7*].
Quality management is now recognized by the SWEBOK Guide as an important discipline.Management sponsorship supports process andproduct evaluations and the resulting findings.Then an improvement program is developedidentifying detailed actions and improvementprojects to be addressed in a feasible time frame.Management support implies that each improvement project has enough resources to achieve thegoal defined for it.
Management sponsorship issolicited frequently by implementing proactivecommunication activities.1.5. Software Safety[9*, c11s3]Safety-critical systems are those in which a system failure could harm human life, other livingthings, physical structures, or the environment.The software in these systems is safety-critical.There are increasing numbers of applicationsof safety-critical software in a growing numberof industries.
Examples of systems with safetycritical software include mass transit systems,chemical manufacturing plants, and medicaldevices. The failure of software in these systemscould have catastrophic effects. There are industry standards, such as DO-178C [11], and emerging processes, tools, and techniques for developing safetycritical software. The intent of thesestandards, tools, and techniques is to reduce therisk of injecting faults into the software and thusimprove software reliability.Safety-critical software can be categorized asdirect or indirect. Direct is that software embedded in a safety-critical system, such as the flightcontrol computer of an aircraft. Indirect includessoftware applications used to develop safetycritical software. Indirect software is included insoftware engineering environments and softwaretest environments.Software Quality 10-5Three complementary techniques for reducing the risk of failure are avoidance, detectionand removal, and damage limitation.
Thesetechniques impact software functional requirements, software performance requirements, anddevelopment processes. Increasing levels of riskimply increasing levels of software quality assurance and control techniques such as inspections.Higher risk levels may necessitate more thoroughinspections of requirements, design, and codeor the use of more formal analytical techniques.Another technique for managing and controlling software risk is building assurance cases. Anassurance case is a reasoned, auditable artifactcreated to support the contention that its claimor claims are satisfied. It contains the followingand their relationships: one or more claims aboutproperties; arguments that logically link the evidence and any assumptions to the claims; and abody of evidence and assumptions supportingthese arguments [12].2. Software Quality Management ProcessesSoftware quality management is the collection ofall processes that ensure that software products,services, and life cycle process implementationsmeet organizational software quality objectivesand achieve stakeholder satisfaction [13, 14].SQM defines processes, process owners, requirements for the processes, measurements of theprocesses and their outputs, and feedback channels throughout the whole software life cycle.SQM comprises four subcategories: softwarequality planning, software quality assurance(SQA), software quality control (SQC), and software process improvement (SPI).
Software quality planning includes determining which qualitystandards are to be used, defining specific qualitygoals, and estimating the effort and schedule ofsoftware quality activities. In some cases, software quality planning also includes defining thesoftware quality processes to be used. SQA activities define and assess the adequacy of softwareprocesses to provide evidence that establishesconfidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes [5]. SQCactivities examine specific project artifacts (documents and executables) to determine whether theycomply with standards established for the project(including requirements, constraints, designs,contracts, and plans). SQC evaluates intermediate products as well as the final products.The fourth SQM category dealing with improvement has various names within the software industry, including SPI, software quality improvement,and software corrective and preventive action.
Theactivities in this category seek to improve processeffectiveness, efficiency, and other characteristics with the ultimate goal of improving softwarequality. Although SPI could be included in any ofthe first three categories, an increasing numberof organizations organize SPI into a separate category that may span across many projects (see theSoftware Engineering Process KA).Software quality processes consist of tasksand techniques to indicate how software plans(e.g., software management, development, quality management, or configuration managementplans) are being implemented and how well theintermediate and final products are meeting theirspecified requirements. Results from these tasksare assembled in reports for management beforecorrective action is taken. The management ofan SQM process is tasked with ensuring that theresults of these reports are accurate.Risk management can also play an importantrole in delivering quality software.
Incorporatingdisciplined risk analysis and management techniques into the software life cycle processes canhelp improve product quality (see the SoftwareEngineering Management KA for related material on risk management).2.1. Software Quality Assurance[7*, c4–c6, c11, c12, c26–27]To quell a widespread misunderstanding, software quality assurance is not testing. softwarequality assurance (SQA) is a set of activities thatdefine and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriateand produce software products of suitable quality for their intended purposes.
A key attribute ofSQA is the objectivity of the SQA function withrespect to the project. The SQA function mayalso be organizationally independent of the project; that is, free from technical, managerial, and10-6 SWEBOK® Guide V3.0financial pressures from the project [5]. SQA hastwo aspects: product assurance and process assurance, which are explained in section 2.3.The software quality plan (in some industrysectors it is termed the software quality assuranceplan) defines the activities and tasks employedto ensure that software developed for a specificproduct satisfies the project’s established requirements and user needs within project cost andschedule constraints and is commensurate withproject risks. The SQAP first ensures that qualitytargets are clearly defined and understood.The SQA plan’s quality activities and tasks arespecified with their costs, resource requirements,objectives, and schedule in relation to relatedobjectives in the software engineering management, software development, and software maintenance plans.
The SQA plan should be consistent with the software configuration managementplan (see the Software Configuration Management KA). The SQA plan identifies documents,standards, practices, and conventions governingthe project and how these items are checked andmonitored to ensure adequacy and compliance.The SQA plan also identifies measures; statisticaltechniques; procedures for problem reporting andcorrective action; resources such as tools, techniques, and methodologies; security for physicalmedia; training; and SQA reporting and documentation. Moreover, the SQA plan addressesthe software quality assurance activities of anyother type of activity described in the softwareplans—such as procurement of supplier softwarefor the project, commercial off-the-shelf software(COTS) installation, and service after delivery ofthe software. It can also contain acceptance criteria as well as reporting and management activities that are critical to software quality.2.2. Verification & Validation[9*, c2s2.3, c8, c15s1.1, c21s3.3]As stated in [15],The purpose of V&V is to help the development organization build quality into thesystem during the life cycle.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
