Software Engineering Body of Knowledge (v3) (2014) (811503), страница 87
Текст из файла (страница 87)
The concepts of functional sizemeasurement (FSM) are designed to overcome thelimitations of earlier methods of sizing software byshifting the focus away from measuring how thesoftware is implemented to measuring size in termsof the functions required by the user.FSM is often known as “function point counting.” The four standards listed below are alternative methods for function point counting—allmeet the requirements of ISO/IEC 14143. Thedominant method, in terms of market share, isthe IFPUG method, described in ISO/IEC 20926.Other methods are variations intended to improvethe validity of the count in various circumstances.For example, ISO/IEC 19761—COSMIC isAppendix B B-5notably intended to be used on software with areal-time component.ISO/IEC 19761:2011 Software Engineering—COSMIC: A Functional Size Measurement MethodISO/IEC 20926:2009 Software and Systems Engineering—Software Measurement—IFPUG Functional Size Measurement MethodISO/IEC 20968:2002 Software Engineering—MkII Function Point Analysis—Counting PracticesManualISO/IEC 24570:2005 Software Engineering—NESMA Functional Size Measurement Method Version 2.1—Definitions and Counting Guidelines forthe Application of Function Point AnalysisSometimes requirements are described in natural language, but sometimes they are describedin formal or semiformal notations.
The objectiveof the Unified Modeling Language (UML) is toprovide system architects, software engineers,and software developers with tools for analysis,design, and implementation of software-basedsystems as well as for modeling business andsimilar processes. The two parts of ISO/IEC19505 define UML, revision 2. The older ISO/IEC 19501 is an earlier version of UML.
Theyare mentioned here because they are often used tomodel requirements.ISO/IEC 19501:2005 Information Technology—Open Distributed Processing—Unified ModelingLanguage (UML) Version 1.4.2See Software Engineering Models andMethods KAISO/IEC 19505:2012 [two parts] Information Technology—Object Management Group Unified Modeling Language (OMG UML)See Software Engineering Models andMethods KASOFTWARE DESIGNThe software design KA includes both softwarearchitectural design (for determining the relationships among the items of the software and detaileddesign (for describing the individual items). ISO/IEC/IEEE 42010 concerns the description ofarchitecture for systems and software.ISO/IEC/IEEE 42010:2011 Systems and SoftwareEngineering—Architecture DescriptionISO/IEC/IEEE 42010:2011 addresses the creation, analysis, and sustainment of architectures of systems through the use of architecturedescriptions.
A conceptual model of architecturedescription is established. The required contentsof an architecture description are specified. Architecture viewpoints, architecture frameworks andarchitecture description languages are introducedfor codifying conventions and common practicesof architecture description. The required contentof architecture viewpoints, architecture frameworks and architecture description languagesis specified. Annexes provide the motivationand background for key concepts and terminology and examples of applying ISO/IEC/IEEE42010:2011.Like ISO/IEC/IEEE 42010, the next standard treats software “design” as an abstraction,independent of its representation in a document.Accordingly, the standard places provisions onthe description of design, rather than on designitself.IEEE Std. 1016-2009 Standard for InformationTechnology—Systems Design—Software DesignDescriptionsThis standard describes software designs andestablishes the information content and organization of a software design description (SDD).
AnSDD is a representation of a software design to beused for recording design information and communicating that design information to key designB-6 SWEBOK® Guide V3.0stakeholders. This standard is intended for use indesign situations in which an explicit softwaredesign description is to be prepared.
These situations include traditional software constructionactivities (when design leads to code) and reverseengineering situations (when a design descriptionis recovered from an existing implementation).This standard can be applied to commercial, scientific, or military software that runs on digitalcomputers. Applicability is not restricted by thesize, complexity, or criticality of the software.This standard can be applied to the descriptionof high-level and detailed designs. This standard does not prescribe specific methodologiesfor design, configuration management, or quality assurance. This standard does not require theuse of any particular design languages, but establishes requirements on the selection of designlanguages for use in an SDD.
This standard canbe applied to the preparation of SDDs captured aspaper documents, automated databases, softwaredevelopment tools, or other media.By convention, this appendix treats user documentation as a part of a software system. Therefore, the various aspects of user documentation—its design, its testing, and so forth—are allocatedto different KAs.
The next standard deals with thedesign of user documentation.IEEE Std. 26514-2010 Standard Adoption of ISO/IEC 26514:2008 Systems and Software Engineering—Requirements for Designers and Developers ofUser DocumentationThis standard provides requirements for thedesign and development of software user documentation as part of the life cycle processes. Itdefines the documentation process from the viewpoint of the documentation developer and alsocovers the documentation product. It specifies thestructure, content, and format for user documentation and also provides informative guidance foruser documentation style.
It is independent of thesoftware tools that may be used to produce documentation and applies to both printed documentation and onscreen documentation. Much of thisstandard is also applicable to user documentationfor systems including hardware.SOFTWARE CONSTRUCTIONThe term “software construction” refers to thedetailed creation of working, meaningful softwarethrough a combination of coding, verification,unit testing, integration testing, and debugging.There are few standards on the details of software coding. It has been found through (mostlybad) experience that coding conventions are notappropriate for standardization because, in mostcases, the real benefit comes from the consistency of applying an arbitrary convention ratherthan the convention itself. So, although codingconventions are a good idea, it is generally leftto the organization or the project to develop sucha standard.Nevertheless, the subject of secure coding hasattracted attention in recent years because somecoding idioms are insecure in the face of attack.A Technical Report prepared by ISO/IEC JTC 1/SC 22 (programming languages) describes vulnerabilities in programming languages and howthey can be avoided.ISO/IEC TR 24772:2013 Information Technology—Programming Languages—Guidance to AvoidingVulnerabilities in Programming Languages throughLanguage Selection and UseISO/IEC TR 24772:2013 specifies software programming language vulnerabilities to be avoidedin the development of systems where assuredbehavior is required for security, safety, mission-critical, and business-critical software.
Ingeneral, this guidance is applicable to the software developed, reviewed, or maintained for anyapplication.Vulnerabilities are described in a generic manner that is applicable to a broad range of programming languages. Annexes relate the genericguidance to a selection of specific programminglanguages.Appendix B B-7The Technical Report is freely available at http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html.Two standards are mentioned here because unittesting is often regarded as an activity of softwareconstruction. IEEE and ISO/IEC are cooperatingin the development of a four-part joint standard,29119, that will provide a comprehensive treatment of testing and supplant IEEE Std.
1008.IEEE Std. 1008-1987 Standard for Software UnitTestingSee Software Testing KAISO/IEC/IEEE 29119 [four parts] (Draft) Softwareand Systems Engineering—Software TestingSee Software Testing KAThe next standard provides for the developmentof user documentation during an agile development process. It is mentioned here becauseagile development is sometimes regarded asconstruction.ISO/IEC/IEEE 26515:2012 Systems and SoftwareEngineering—Developing User Documentation in anAgile EnvironmentSee Software Engineering Models andMethods KACoding is not the only way to create a softwareproduct.
Often code (as well as requirements anddesign) is reused from previous projects or engineered for reuse in future projects. IEEE Std. 1517is mentioned here because it provides a commonframework for extending the system and softwarelife cycle processes of IEEE Std. 12207:2008 toinclude the systematic practice of reuse.IEEE Std. 1517-2010 Standard for InformationTechnology—System and Software Life Cycle Processes—Reuse ProcessesSee Software Engineering Process KASOFTWARE TESTINGOddly, there are few standards for testing.
IEEEStd. 829 is the most comprehensive.IEEE Std. 829-2008 Standard for Software and System Test DocumentationTest processes determine whether the development products of a given activity conform to therequirements of that activity and whether the system and/or software satisfies its intended use anduser needs. Testing process tasks are specifiedfor different integrity levels.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
