Software Engineering Body of Knowledge (v3) (2014) (811503), страница 89
Текст из файла (страница 89)
It is a critical tool for continuously determining the feasibility of project plans, for improving the searchfor and identification of potential problems thatcan affect life cycle activities and the quality andperformance of products, and for improving theactive management of projects.The analysis of risk and risk mitigation dependscrucially upon measurement. This internationalstandard provides an elaboration of the measurement process from ISO/IEC/IEEE 15288:2008and ISO/IEC/IEEE 12207:2008.IEEE Std.
15939-2008 Standard Adoption of ISO/IEC 15939:2007 Systems and Software Engineering—Measurement ProcessISO/IEC 15939 defines a measurement processapplicable to system and software engineering and management disciplines. The process isdescribed through a model that defines the activities of the measurement process that are requiredto adequately specify what measurement information is required, how the measures and analysis results are to be applied, and how to determineAppendix B B-11if the analysis results are valid. The measurementprocess is flexible, tailorable, and adaptable to theneeds of different users.ISO/IEC 15939:2007 identifies a process thatsupports defining a suitable set of measures thataddress specific information needs.
It identifies theactivities and tasks that are necessary to successfully identify, define, select, apply, and improvemeasurement within an overall project or organizational measurement structure. It also providesdefinitions for measurement terms commonly usedwithin the system and software industries.to produce or manage documentation, and appliesto both printed documentation and onscreen documentation. Much of its guidance is applicable touser documentation for systems including hardware as well as software.Software projects often require the development of user documentation.
Management of theproject, therefore, includes management of thedocumentation effort.A set of useful quality practices that can beselected and applied during one or more steps ina software acquisition process is described. Thisrecommended practice can be applied to softwarethat runs on any computer system regardless ofthe size, complexity, or criticality of the software,but is more suited for use on modified-off-theshelf software and fully developed software.ISO/IEC/IEEE 26511:2012 Systems and SoftwareEngineering—Requirements for Managers of UserDocumentationISO/IEC/IEEE 26511:2012 specifies proceduresfor managing user documentation throughout thesoftware life cycle.
It applies to people or organizations producing suites of documentation, tothose undertaking a single documentation project,and to documentation produced internally, as wellas to documentation contracted to outside serviceorganizations. It provides an overview of the software documentation and information managementprocesses, and also presents aspects of portfolioplanning and content management that user documentation managers apply.
It covers managementactivities in starting a project, including settingup procedures and specifications, establishinginfrastructure, and building a team. It includesexamples of roles needed on a user documentationteam. It addresses measurements and estimatesneeded for management control, and the use ofsupporting processes such as change management,schedule and cost control, resource management,and quality management and process improvement.
It includes requirements for key documentsproduced for user documentation management,including documentation plans and documentationmanagement plans. ISO/IEC/IEEE 26511:2012 isindependent of the software tools that may be usedSometimes software or system components areacquired rather than developed.IEEE Std. 1062-1998 Recommended Practice forSoftware AcquisitionSometimes user documentation is acquiredregardless of whether the software it describeswas acquired. The following standard deals withthat subject.ISO/IEC/IEEE 26512:2011 Systems and SoftwareEngineering—Requirements for Acquirers and Suppliers of User DocumentationISO/IEC/IEEE 26512:2011 was developed toassist users of ISO/IEC/IEEE 15288:2008 or ISO/IEC/IEEE 12207:2008 to acquire or supply software user documentation as part of the softwarelife cycle processes.
It defines the documentationprocess from the acquirer’s standpoint and thesupplier’s standpoint. ISO/IEC/IEEE 26512:2011covers the requirements for information items usedin the acquisition of user documentation products:the acquisition plan, document specification, statement of work, request for proposals, and proposal.It provides an overview of the software user documentation and information management processeswhich may require acquisition and supply of software user documentation products and services.It addresses the preparation of requirements forB-12 SWEBOK® Guide V3.0software user documentation.
These requirementsare central to the user documentation specificationand statement of work. It includes requirementsfor primary document outputs of the acquisitionand supply process: the request for proposal andthe proposal for user documentation products andservices. It also discusses the use of a documentation management plan and a document plan asthey arise in the acquisition and supply processes.ISO/IEC/IEEE 26512:2011 is independent of thesoftware tools that may be used to produce documentation and applies to both printed documentation and onscreen documentation. Much of itsguidance is applicable to user documentation forsystems including hardware as well as software.The next two standards are mentioned herebecause they supply information used in management decision-making.IEEE Std. 1028-2008 Standard for Software Reviewsand AuditsSee Software Quality KAIEEE Std.
1061-1998 Standard for Software QualityMetrics MethodologySee Software Quality KAThe next standard is mentioned because itincludes the manager’s role in developing userdocumentation in an agile project.ISO/IEC/IEEE 26515:2012 Systems and SoftwareEngineering—Developing User Documentation in anAgile EnvironmentSee Software Engineering Models andMethods KASOFTWARE ENGINEERING PROCESSSoftware and systems engineering processesare central to the standardization of those twodisciplines—not just because many are interested in process improvement, but also becauseprocesses are effective for the description ofimproved practices. For example, one might propose an improved practice for software requirements analysis. A naïve treatment might relatethe description to an early stage of the life cyclemodel. A superior approach is to describe thepractice in the context of a process that can beapplied at any stage of the life cycle.
The requirements analysis process, for example, is necessary for the development stage, for maintenance,and often for retirement, so an improved practicedescribed in terms of the requirements analysisprocess can be applied to any of those stages.The two key standards are ISO/IEC/IEEE12207, Software Life Cycle Processes, and ISO/IEC/IEEE 15288, System Life Cycle Processes.The two standards have distinct histories, butthey were both revised in 2008 to align their processes, permitting their interoperable use across awide spectrum of projects ranging from a standalone software component to a system with negligible software content.
Both are being revisedagain with the intent of containing an identicallist of processes, but with provisions specializedfor the respective disciplines.IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008)Standard for Systems and Software Engineering—Software Life Cycle ProcessesISO/IEC 12207:2008 establishes a commonframework for software life cycle processes, withwell-defined terminology that can be referencedby the software industry.ISO/IEC 12207:2008 applies to the acquisition of systems and software products and services and to the supply, development, operation,maintenance, and disposal of software productsand the software portion of a system, whetherperformed internally or externally to an organization.
Those aspects of system definition neededto provide the context for software products andservices are included.ISO/IEC 12207:2008 also provides a processthat can be employed for defining, controlling,and improving software life cycle processes.The processes, activities and tasks of ISO/IEC12207:2008—either alone or in conjunction withISO/IEC 15288—may also be applied during theacquisition of a system that contains software.Appendix B B-13IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008)Standard for Systems and Software Engineering—System Life Cycle ProcessesISO/IEC 15288:2008 establishes a commonframework for describing the life cycle of systems created by humans.
It defines a set ofprocesses and associated terminology. Theseprocesses can be applied at any level in thehierarchy of a system’s structure. Selected setsof these processes can be applied throughoutthe life cycle for managing and performing thestages of a system’s life cycle. This is accomplished through the involvement of all interestedparties, with the ultimate goal of achieving customer satisfaction.ISO/IEC 15288:2008 also provides processesthat support the definition, control, and improvement of the life cycle processes used within anorganization or a project.
Organizations andprojects can use these life cycle processes whenacquiring and supplying systems.ISO/IEC 15288:2008 concerns those systemsthat are man-made and may be configured withone or more of the following: hardware, software,data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities.
When a system element issoftware, the software life cycle processes documented in ISO/IEC 12207:2008 may be used toimplement that system element.ISO/IEC 15288:2008 and ISO/IEC 12207:2008are harmonized for concurrent use on a singleproject or in a single organization.Those two standards specify that processesmay produce items of information but do not prescribe their content or format.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
