Software Engineering Body of Knowledge (v3) (2014) (811503), страница 33
Текст из файла (страница 33)
Successfulcompletion of these audits can be a prerequisitefor the establishment of the product baseline.5.1. Software Functional Configuration Audit[2*, c11s2.1]The purpose of the software FCA is to ensure thatthe audited software item is consistent with itsgoverning specifications. The output of the software verification and validation activities (seeVerification and Validation in the Software Quality KA) is a key input to this audit.5.2. Software Physical Configuration Audit[2*, c11s2.2]The purpose of the software physical configuration audit (PCA) is to ensure that the design andreference documentation is consistent with theas-built software product.5.3. In-Process Audits of a Software Baseline[2*, c11s2.3]As mentioned above, audits can be carried outduring the development process to investigatethe current status of specific elements of the configuration.
In this case, an audit could be appliedto sampled baseline items to ensure that performance is consistent with specifications or toensure that evolving documentation continues tobe consistent with the developing baseline item.6. Software Release Management andDelivery[2*, c14] [3*, c8s2]In this context, release refers to the distribution of a software configuration item outsidethe development activity; this includes internalreleases as well as distribution to customers.
Whendifferent versions of a software item are availablefor delivery (such as versions for different platforms or versions with varying capabilities), it isfrequently necessary to recreate specific versionsand package the correct materials for delivery ofthe version. The software library is a key elementin accomplishing release and delivery tasks.6.1. Software Building[4*, c29s4]Software building is the activity of combining thecorrect versions of software configuration items,using the appropriate configuration data, into anexecutable program for delivery to a customer orother recipient, such as the testing activity. Forsystems with hardware or firmware, the executableprogram is delivered to the system-building activity. Build instructions ensure that the proper buildsteps are taken in the correct sequence.
In additionto building software for new releases, it is usuallyalso necessary for SCM to have the capability toreproduce previous releases for recovery, testing,maintenance, or additional release purposes.Software is built using particular versions ofsupporting tools, such as compilers (see Compiler Basics in the Computing Foundations KA).It might be necessary to rebuild an exact copy ofa previously built software configuration item. Inthis case, supporting tools and associated buildinstructions need to be under SCM control toensure availability of the correct versions of thetools.A tool capability is useful for selecting the correct versions of software items for a given targetenvironment and for automating the process ofbuilding the software from the selected versionsand appropriate configuration data.
For projectswith parallel or distributed development environments, this tool capability is necessary. Mostsoftware engineering environments provide thiscapability. These tools vary in complexity fromrequiring the software engineer to learn a specialized scripting language to graphics-orientedapproaches that hide much of the complexity ofan “intelligent” build facility.The build process and products are often subject to software quality verification. Outputs of6-12 SWEBOK® Guide V3.0the build process might be needed for future reference and may become quality assurance records.7. Software Configuration Management Tools[3*, c26s1] [4*, c8s2]6.2. Software Release ManagementWhen discussing software configuration management tools, it is helpful to classify them.
SCMtools can be divided into three classes in termsof the scope at which they provide support: individual support, project-related support, and companywide-process support.Individual support tools are appropriate andtypically sufficient for small organizations ordevelopment groups without variants of theirsoftware products or other complex SCM requirements. They include:[4*, c29s3.2]Software release management encompasses theidentification, packaging, and delivery of theelements of a product—for example, an executable program, documentation, release notes, andconfiguration data. Given that product changescan occur on a continuing basis, one concern forrelease management is determining when to issuea release. The severity of the problems addressedby the release and measurements of the fault densities of prior releases affect this decision.
Thepackaging task must identify which product itemsare to be delivered and then select the correctvariants of those items, given the intended application of the product. The information documenting the physical contents of a release is knownas a version description document.
The releasenotes typically describe new capabilities, knownproblems, and platform requirements necessaryfor proper product operation. The package to bereleased also contains installation or upgradinginstructions. The latter can be complicated by thefact that some current users might have versionsthat are several releases old. In some cases, releasemanagement might be required in order to trackdistribution of the product to various customersor target systems—for example, in a case wherethe supplier was required to notify a customer ofnewly reported problems.
Finally, a mechanismto ensure the integrity of the released item can beimplemented—for example by releasing a digitalsignature with it.A tool capability is needed for supportingthese release management functions. It is useful to have a connection with the tool capabilitysupporting the change request process in order tomap release contents to the SCRs that have beenreceived. This tool capability might also maintaininformation on various target platforms and onvarious customer environments.• Version control tools: track, document, andstore individual configuration items such assource code and external documentation.• Build handling tools: in their simplest form,such tools compile and link an executableversion of the software. More advancedbuilding tools extract the latest version fromthe version control software, perform quality checks, run regression tests, and producevarious forms of reports, among other tasks.• Change control tools: mainly support thecontrol of change requests and events notification (for example, change request statuschanges, milestones reached).Project-related support tools mainly supportworkspace management for development teamsand integrators; they are typically able to support distributed development environments.
Suchtools are appropriate for medium to large organizations with variants of their software productsand parallel development but no certificationrequirements.Companywide-process support tools can typically automate portions of a companywide process, providing support for workflow managements, roles, and responsibilities. They are ableto handle many items, data, and life cycles.
Suchtools add to project-related support by supportinga more formal development process, includingcertification requirements.Software Configuration Management 6-131.3. Planning for SCM1.3.1. SCM Organization andResponsibilities1.3.2. SCM Resources andSchedules1.3.3. Tool Selection andImplementation1.3.4. Vendor/SubcontractorControl1.3.5. Interface Control1.4. SCM Plan1.5. Surveillance of SoftwareConfiguration Management1.5.1. SCM Measures andMeasurement1.5.2. In-Process Audits ofSCM2. Software ConfigurationIdentification2.1. Identifying Items to BeControlled2.1.1. Software Configuration2.1.2. Software ConfigurationItem2.1.3. Software ConfigurationItem Relationships2.1.4. Software Versionintroductionc6, ann.D,ann.Ec6, ann.D,ann.Ec2Sommerville 2011[4*]c6, ann.DMoore 2006[5*]Hass 2003[3*]1. Management of the SCMProcess1.1. Organizational Context forSCM1.2. Constraints and Guidancefor the SCM ProcessIEEE 828-2012[2*]MATRIX OF TOPICS VS.
REFERENCE MATERIALc29c19s2.2c29 introc23c29ann.Ds5–6c10–11c29 introann.Ds8c23c26s2; s6c13c13s9–c14s2c12ann.Dc24s4c23c29s5c29s1c11s3c9s2;c25s2–s3c1s1c29s1.1c8s2.2c29s1.1c29s1.1c7s4c29s32.1.5. Baseline2.1.6. Acquiring SoftwareConfiguration Items2.2. Software Library3. Software ConfigurationControl3.1. Requesting, Evaluating, andApproving Software Changes3.1.1. Software ConfigurationControl Board3.1.2. Software ChangeRequest Process3.2. Implementing SoftwareChanges3.3. Deviations and Waivers4. Software ConfigurationStatus Accounting4.1. Software ConfigurationStatus Information4.2. Software ConfigurationStatus Reporting5. Software ConfigurationAuditing5.1. Software FunctionalConfiguration Audit5.2. Software PhysicalConfiguration Audit5.3. In-Process Audits of aSoftware Baseline6. Software ReleaseManagement and Delivery6.1. Software Building6.2. Software ReleaseManagement7. Software ConfigurationManagement ToolsSommerville 2011[4*]Moore 2006[5*]Hass 2003[3*]IEEE 828-2012[2*]6-14 SWEBOK® Guide V3.0c18c1s3c29s1.2c9c29s2c9s2.4c29s2c9s2.2c11s1c29s2c1s4, c8s4c29c10c10s2.1c10s2.4c1s5, c9s1,c17c11c11s2.1c11s2.2c11s2.3c14c8s2c29s3c29s4c29s3.2c26s1Software Configuration Management 6-15FURTHER READINGSREFERENCESStephen P.
Berczuk and Brad Appleton,Software Configuration ManagementPatterns: Effective Teamwork, PracticalIntegration [6].[1] ISO/IEC/IEEE 24765:2010 Systems andSoftware Engineering—Vocabulary, ISO/IEC/IEEE, 2010.This book expresses useful SCM practices andstrategies as patterns. The patterns can be implemented using various tools, but they are expressedin a tool-agnostic fashion.“CMMI for Development,” Version 1.3, pp.137–147 [7].This model presents a collection of best practices to help software development organizationsimprove their processes.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
