Software Engineering Body of Knowledge (v3) (2014) (811503), страница 88
Текст из файла (страница 88)
These process tasksdetermine the appropriate breadth and depth oftest documentation. The documentation elementsfor each type of test documentation can then beselected. The scope of testing encompasses software-based systems, computer software, hardware, and their interfaces. This standard appliesto software-based systems being developed,maintained, or reused (legacy, commercial offthe-shelf, nondevelopmental items). The term“software” also includes firmware, microcode,and documentation.
Test processes can includeinspection, analysis, demonstration, verification,and validation of software and software-basedsystem products.IEEE Std. 1008 focuses on unit testing.IEEE Std. 1008-1987 Standard for Software UnitTestingThe primary objective is to specify a standardapproach to software unit testing that can beused as a basis for sound software engineering practice. A second objective is to describethe software engineering concepts and testingassumptions on which the standard approach isbased.
A third objective is to provide guidanceand resource information to assist with the implementation and usage of the standard unit testingapproach.B-8 SWEBOK® Guide V3.0IEEE and ISO/IEC JTC 1/SC 7 are cooperatingin a project to develop a single comprehensivestandard that covers all aspects of testing. Onecan hope for publication of the four-part standardby 2014.
Portions of the content remain controversial. One taxonomical issue is whether “staticmethods”—such as inspection, review, and staticanalysis—should fall within the scope of “testing” or should be distinguished as “verificationand validation.” Although the resolution of theissue is probably of little importance to users ofthe standard, it assumes great importance to thestandards-writers who must manage an integratedsuite of interoperating standards.ISO/IEC/IEEE 29119 [four parts] (Draft) Softwareand Systems Engineering—Software TestingThe purpose of ISO/IEC 29119 Software Testingis to define an internationally agreed standard forsoftware testing that can be used by any organization when performing any form of softwaretesting.Testing of user documentation is described inthe next standard, providing requirements for thetest and review of software user documentationas part of the life cycle processes.
It defines thedocumentation process from the viewpoint of thedocumentation tester and reviewer. It is relevantto roles involved in testing and development ofsoftware and user documentation, including project managers, usability experts, and informationdevelopers in addition to testers and reviewers.IEEE Std.
26513-2010 Standard Adoption of ISO/IEC 26513:2009 Systems and Software Engineering—Requirements for Testers and Reviewers ofDocumentationISO/IEC 26513 provides the minimum requirements for the testing and reviewing of user documentation, including both printed and onscreendocuments used in the work environment by theusers of systems software. It applies to printeduser manuals, online help, tutorials, and user reference documentation.It specifies processes for use in testing andreviewing of user documentation.
It is not limited to the test and review phase of the life cycle,but includes activities throughout the informationmanagement and documentation managementprocesses.Two standards are mentioned here becausesome sources consider software verification andvalidation to be taxonomically included in testing.IEEE Std. 1012-2012 Standard for System and Software Verification and ValidationSee Software Quality KAIEEE Std. 1044-2009 Standard for Classification forSoftware AnomaliesSee Software Quality KASOFTWARE MAINTENANCEThis standard—the result of harmonizing distinctIEEE and ISO/IEC standards on the subject—describes a single comprehensive process for themanagement and execution of software maintenance.
It expands on the provisions of the software maintenance process provided in ISO/IEC/IEEE 12207.IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006)Standard for Software Engineering—Software LifeCycle Processes—MaintenanceISO/IEC 14764:2006 describes in greaterdetail management of the maintenance processdescribed in ISO/IEC 12207, including amendments. It also establishes definitions for the various types of maintenance. ISO/IEC 14764:2006provides guidance that applies to planning, execution and control, review and evaluation, andclosure of the maintenance process. The scope ofISO/IEC 14764:2006 includes maintenance formultiple software products with the same maintenance resources. “Maintenance” in ISO/IEC14764:2006 means software maintenance unlessotherwise stated.Appendix B B-9ISO/IEC 14764:2006 provides the frameworkwithin which generic and specific software maintenance plans may be executed, evaluated, andtailored to the maintenance scope and magnitude of given software products.
It provides theframework, precise terminology, and processesto allow the consistent application of technology (tools, techniques, and methods) to softwaremaintenance.It does not address the operation of softwareand the operational functions, e.g., backup,recovery, and system administration, which arenormally performed by those who operate thesoftware.ISO/IEC 14764:2006 is written primarily formaintainers of software and additionally for thoseresponsible for development and quality assurance. It may also be used by acquirers and usersof systems containing software, who may provideinputs to the maintenance plan.SOFTWARE CONFIGURATIONMANAGEMENTThere is onemanagement.standardforconfigurationIEEE Std.
828-2012 Standard for ConfigurationManagement in Systems and Software EngineeringThis standard establishes the minimum requirements for processes for configuration management(CM) in systems and software engineering. Theapplication of this standard applies to any form,class, or type of software or system. This revisionof the standard expands the previous version toexplain CM, including identifying and acquiringconfiguration items, controlling changes, reporting the status of configuration items, as well assoftware builds and release engineering. Its predecessor defined only the contents of a softwareconfiguration management plan. This standardaddresses what CM activities are to be done, whenthey are to happen in the life cycle, and what planning and resources are required.
It also describesthe content areas for a CM plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminologyin ISO/IEC/IEEE Std. 24765 and the informationitem requirements of IEEE Std. 15939.ISO/IEC JTC 1/SC 7 has not yet determinedwhat action it should take regarding the newIEEE Std. 828. There are issues concerning theextent of compatibility with ISO/IEC/IEEE12207 and other standards in the SC 7 suite.
Itshould be noted, though, that SC 7 does not havea competing standard.SOFTWARE ENGINEERINGMANAGEMENTMost readers will interpret the phrase “softwareengineering management” to mean the management of a project that concerns software. Thereare at least two possible extensions to this generalization, though. Some software activities aremanaged according to a service-level agreement(SLA). SLAs do not meet the criteria for “project” according to some definitions. Also, it hasbecome generally agreed that some managementof software should occur in the organization at alevel above the project, so that all projects canbenefit from a common investment. A commonlycited example is the provision of software processes and tooling by the organization.Software project management can be regardedas a specialization of “project management”—often regarded as a distinct discipline.
The Project Management Institute’s Guide to the ProjectManagement Body of Knowledge (PMBOK®Guide) is often regarded as the authoritativesource for this knowledge. From time to time,IEEE adopts the most recent version of thePMBOK® Guide as an IEEE standard.IEEE Std. 1490-2011 Guide—Adoption of the Project Management Institute (PMI®) Standard, AGuide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth EditionThe PMBOK® Guide identifies that subset ofthe project management body of knowledge generally recognized as good practice.
“Generallyrecognized” means the knowledge and practicesdescribed are applicable to most projects most ofB-10 SWEBOK® Guide V3.0the time and there is consensus about their value andusefulness. “Good practice” means there is generalagreement that the application of these skills, tools,and techniques can enhance the chances of successover a wide range of projects. Good practice doesnot mean the knowledge described should alwaysbe applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for anygiven project. The PMBOK® Guide also providesand promotes a common vocabulary within theproject management profession for discussing,writing, and applying project management concepts. Such a standard vocabulary is an essentialelement of a professional discipline.
The ProjectManagement Institute (PMI) views this standardas a foundational project management referencefor its professional development programs andcertifications.The 2008 revisions of ISO/IEC/IEEE 12207and 15288 provide project management processes for software and systems and relate themto organization-level processes as well as technical processes. The jointly developed 16326standard, replacing two older standards, expandsthose provisions with guidance for application.ISO/IEC/IEEE 16326:2009 Systems and Software Engineering—Life Cycle Processes—ProjectManagementISO/IEC/IEEE 16326:2009 provides normativecontent specifications for project managementplans covering software projects and softwareintensive system projects.
It also provides detaileddiscussion and advice on applying a set of project processes that are common to both the software and system life cycle as covered by ISO/IEC12207:2008 (IEEE Std. 12207-2008) and ISO/IEC15288:2008 (IEEE Std. 15288-2008), respectively.The discussion and advice are intended to aid inthe preparation of the normative content of projectmanagement plans. ISO/IEC/IEEE 16326:2009is the result of the harmonization of ISO/IEC TR16326:1999 and IEEE Std. 1058-1998.Particularly in high-technology applicationsand high-consequence projects, the managementof risk is an important aspect of the overall project management responsibilities.
This standarddeals with that subject.IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006)Standard for Systems and Software Engineering—Software Life Cycle Processes—Risk ManagementISO/IEC 16085:2006 defines a process for themanagement of risk in the life cycle. It can beadded to the existing set of system and softwarelife cycle processes defined by ISO/IEC 15288 andISO/IEC 12207, or it can be used independently.ISO/IEC 16085:2006 can be applied equally tosystems and software.The purpose of risk management is to identify potential managerial and technical problemsbefore they occur so that actions can be taken thatreduce or eliminate the probability and/or impactof these problems should they occur.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
