Software Engineering Body of Knowledge (v3) (2014) (811503), страница 86
Текст из файла (страница 86)
For example,a standard concerning the design of userdocumentation is described in the SoftwareDesign KA.• Some jointly developed standards are explicitly labeled as joint developments, e.g., ISO/IEC/IEEE 24765. In other cases, the standards have different designations in the twoorganizations. Examples include»» IEEE Std. 12207:2008 (a.k.a. ISO/IEC12207:2008), where “a.k.a.” (“alsoknown as”) is this appendix’s abbreviation to note the designation in the otherorganization;»» IEEE Std. 15939:2008 Standard Adoption of ISO/IEC 15939:2007, an adoption by IEEE of a standard developed inISO/IEC;»» IEEE Std.
1220:2005 (a.k.a. ISO/IEC26702:2007), a “fast-track” by ISO/IECof a standard developed in IEEE.In each of these cases, the standards aresubstantively identical in the two organizations, differing only in front matterand, occasionally, added informationalmaterial.A summary list of all of the mentioned standards is provided at the end of this appendix.ISO/IEC JTC 1/SC 7, SOFTWARE ANDSYSTEMS ENGINEERINGISO/IEC JTC 1/SC 7 is the major source ofinternational standards on software and systemsengineering. Its name is formed taxonomically.Joint Technical Committee 1 (JTC 1) is a childof the International Organization for Standardization (ISO) and the International ElectrotechnicalCommission (IEC); it has the scope of “information technology” and subdivides its work amonga number of subcommittees; Subcommittee 7 (SC7) is the one responsible for software and systems engineering.
SC 7, and its working groups,meets twice a year, attracting delegations representing the national standards bodies of participating nations. Each nation follows its own procedures for determining national positions andeach nation has the responsibility of determiningwhether an ISO/IEC standard should be adoptedas a national standard.SC 7 creates three types of documents:• International Standards: Documents containing requirements that must be satisfied inorder to claim conformance.• Technical Specifications (formerly calledTechnical Reports, type 1 and type 2): Documents published in a preliminary mannerwhile work continues.• Technical Reports (formerly called Technical Reports, type 3): Documents inherentlyunsuited to be standards, usually becausethey are descriptive rather than prescriptive.The key thing to remember is that only thefirst category counts as a consensus standard.The reader can easily recognize the others by thesuffix TS or TR prepended to the number of thedocument.IEEE SOFTWARE AND SYSTEMSENGINEERING STANDARDSCOMMITTEE (S2ESC)IEEE is the world’s largest organization of technical professionals, with about 400,000 membersin more than 160 countries.
The publication ofstandards is performed by the IEEE StandardsAssociation (IEEE-SA), but the committees thatdraft and sponsor the standards are in the variousIEEE societies; S2ESC is a part of the IEEE Computer Society. IEEE is a global standards makerbecause its standards are used in many different countries. Despite its international membership (about 50% non-US), though, the IEEE-SAroutinely submits its standards to the AmericanNational Standards Institute (ANSI) for endorsement as “American National Standards.” SomeS2ESC standards are developed within S2ESC,some are developed jointly with SC 7, and someare adopted after being developed by SC 7.Appendix B B-3IEEE-SA publishes three types of “standards”:• Standards, with a preponderance of the verb“shall”• Recommended Practices, with a preponderance of the verb “should”• Guides, with a preponderance of the verb“may.”All three of these compare to ISO/IEC standards.
IEEE-SA does have the concept of a “TrialUse” standard, which is roughly comparable toan ISO/IEC Technical Specification. However, ithas nothing comparable to an ISO/IEC Technical Report; one would look elsewhere in IEEE fordocuments of this ilk.THE STANDARDSThe remainder of this article allocates the selectedstandards to relevant knowledge areas (KAs) ofthe SWEBOK Guide. There is a section for eachKA. Within each section, the relevant standardsare listed—the ones that principally apply to theKA as well as others that principally apply toother KAs but which are also related to the current one.
Following each standard is a brief summary. In most cases, the summary is a quotationor paraphrase of the abstract or other introductorymaterial from the text of the standard.Most of the standards easily fit into one KA.Some fit into more than one; in such cases,a cross-reference is provided. Two standardsapply to all KAs, so they are listed in a categorycalled “General.” All of the standards related tocomputer-aided software engineering (CASE)tools and environments are listed in the SoftwareEngineering Models and Methods KA section.GENERALThe first two standards are so central that theycould be slotted into all of the KAs. Two more aredescribed in the Software Engineering ProcessKA, but are mentioned here because they providea helpful framework and because the descriptionsof several other standards refer to them.ISO/IEC TR 19759 is the SWEBOK Guideitself. It’s not an IEEE standard because, lackingprescriptive verbs, it doesn’t satisfy the criteriafor any of the IEEE categories.
In ISO/IEC, it is a“technical report”—defined as a document inherently unsuited to be a standard. The 2004 IEEESWEBOK Guide was adopted by ISO/IEC without change. Presumably, ISO/IEC will adopt Version 3 of the SWEBOK Guide.ISO/IEC TR 19759:2005 Software Engineering—Guide to the Software Engineering Body of Knowledge(SWEBOK)Applies to all KAsISO/IEC 19759:2005, a Guide to the SoftwareEngineering Body of Knowledge (SWEBOK),identifies and describes that subset of the bodyof knowledge that is generally accepted, eventhough software engineers must be knowledgeable not only in software engineering, but also,of course, in other related disciplines. SWEBOKis an all-inclusive term that describes the sumof knowledge within the profession of softwareengineering.The text of the SWEBOK Guide is freely available at www.swebok.org/. The ISO/IEC adoptionof the Guide is freely available at http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html.ISO/IEC/IEEE 24765 provides a shared vocabulary for the systems and software engineeringstandards of both SC 7 and S2ESC.ISO/IEC/IEEE 24765:2010 Systems and SoftwareEngineering—VocabularyApplies to all KAsISO/IEC/IEEE 24765:2010 provides a commonvocabulary applicable to all systems and softwareengineering work.
It was prepared to collect andsupport the standardization of terminology. ISO/IEC/IEEE 24765:2010 is intended to serve as auseful reference for those in the information technology field and to encourage the use of systemsand software engineering standards prepared byISO and liaison organizations IEEE ComputerSociety and Project Management Institute. ISO/IEC/IEEE 24765:2010 includes references to theB-4 SWEBOK® Guide V3.0active source standards for each definition so thatthe use of the term can be further explored.The vocabulary is descriptive, rather than prescriptive; it gathers up all of the definitions fromall of the relevant standards, as well as a fewother sources, rather than choosing among competing definitions.The content of the 24765 standard is freelyaccessible online at www.computer.org/sevocab.Two standards, 12207 and 15288, provide acomplete set of processes for the entire life cycleof a system or a software product.
The two standards are aligned for concurrent use on a singleproject or in a single organization. They arementioned here because they are often used as aframework for explaining or localizing the role ofother standards in the life cycle.IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008)Standard for Systems and Software Engineering—Software Life Cycle ProcessesSee Software Engineering Process KAIEEE Std. 15288-2008 (a.k.a.
ISO/IEC 15288:2008)Standard for Systems and Software Engineering—System Life Cycle ProcessesSee Software Engineering Process KASOFTWARE REQUIREMENTSThe primary standard for software and systemsrequirements engineering is a new one thatreplaced several existing IEEE standards. It provides a broad view of requirements engineeringacross the entire life cycle.ISO/IEC/IEEE 29148:2011 Systems and SoftwareEngineering—Life Cycle Processes—RequirementsEngineeringISO/IEC/IEEE 29148:2011 contains provisionsfor the processes and products related to the engineering of requirements for systems and softwareproducts and services throughout the life cycle.It defines the construct of a good requirement,provides attributes and characteristics of requirements, and discusses the iterative and recursiveapplication of requirements processes throughout the life cycle.
ISO/IEC/IEEE 29148:2011provides additional guidance in the applicationof requirements engineering and managementprocesses for requirements-related activities inISO/IEC 12207:2008 and ISO/IEC 15288:2008.Information items applicable to the engineeringof requirements and their content are defined.The content of ISO/IEC/IEEE 29148:2011 canbe added to the existing set of requirementsrelated life cycle processes defined by ISO/IEC12207:2008 or ISO/IEC 15288:2008, or it can beused independently.A multipart ISO/IEC standard provides principles and methods for “sizing” software based onits requirements. The functional size is often useful in the denominator of measurements of quality and productivity in software development. Itmay also play a role in contracting for servicelevel agreements.ISO/IEC 14143 [six parts] Information Technology—Software Measurement—Functional SizeMeasurementISO/IEC 14143 describes FSM (functional sizemeasurement).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
