1. What is software-configurationmanagement? Also, discuss, in brief, the variou

Question

1.      What is software-configurationmanagement? Also, discuss, in brief, the varioussoftware-configuration management activities.

Explanation / Answer

x.X face="Verdana">SOFTWARE CONFIGURATION MANAGEMENT Software configuration management encompasses the disciplines and techniques of initiating, evaluating, and controlling change to software products during and after the development process. It emphasizes the importance of configuration control in managing software production. SOFTWARE CONFIGURATION MANAGEMENT ACTIVITIES 1 Configuration Identification 1.1 Specification Identification Configuration Item Selection and Definition Size and scope of each Configuration Item (CI) must take into consideration the impacts of CI interfaces, host/target systems (location), language dependencies, testing issues, documentation concerns, design constraints, life cycle cost and schedule, change control, intended usage, support equipment/software (off the shelf software) and classification, prior to selection. Inappropriate CIs can adversely affect cost, schedule, development, design, test and overall performance. The goal is to establish practical configuration item identification that can be employed throughout the engineering or development cycle with a high degree of confidence that no significant re-definition will be necessary. Each project is partitioned into one or more subsystems. Small projects may consist of a single subsystem. Larger projects should be split along natural boundaries. Each product deliverable within a single project is a candidate for being a separate subsystem. Significantly shared subsystems may be best configured as independent projects. To that extent, project(s) consists of several sub-systems, namely: Modem Controller Assembly, Transmitter Receiver Assembly, Indoor Management Processor, Subscriber Unit, and Host Configuration and Control Software. This project will also include Test Software deliverable that will be used by our development, verification, field trial, and service groups, as well as other internally developed software for test or manufacturing purposes. Subsystems are further divided into modules, and modules consist of individual objects (function, variable and other declarations). A "C" module sometimes has two parts: a ".C" file and the corresponding ".H" file. This results in the following component hierarchy: Product (Product A, Product B, etc.) Product Items/Subsystem Modules/Files Outputs (Object, IMG, EXE, DLL) SCM ignores individual outputs (object files), and normally tracks changes only at the module/file level and above. Labeling and numbering scheme for documents and files Files and documents will be labeled upon baseline builds, I&V release and Customer release. Upon I&V and customer release, the object files for that release will be put under configuration control and labeled with the I&V or customer release label. Individual versions of the files will be tracked automatically by the software configuration management tool (see tools section). How identification between documents and files relate Description of identification tracking scheme Software baselines are labeled with informal labels, generally of the convention:     %PROJECT%_CHKPNT_%REV#% Releases to Integration and Verification are of the form:     Vx.yy.zz Where "x" is the number of major releases, "yy" is the number of minor releases, and "zz" is the number of bug fix releases. This identification scheme addresses versions and releases as required. 1.2 Change Control Form Identification Numbering scheme for each of the forms used ECOs have a numbering scheme assigned by the System Change Analyst which is therefore outside the scope of this document. 1.3 Project Baselines Identify various baselines for the project Baselines are established to designate significant milestones during the engineering and development cycle, as well as to document CI requirements, design and applicable processes. Multiple baselines are defined to capture the engineering process during critical phases. The files included in a baseline are all of the CIs as earlier described.     * Required information for Baseline creation:     * How and when it is created     * Who authorizes and who verifies it     * The purpose     * What goes into it (software and documentation) 1.4 Libraries     * Identification and control mechanisms used     * Number of libraries and the types     * Backup and disaster plans and procedures     * Recovery process for any type of loss     * Retention policies and procedures     * What needs to be retained, for who, and for how long     * How is the information retained (on-line, off-line, media type and format) 2 Configuration Control The Configuration Management tool accounts for all changes (problems or enhancements) to baselined configuration items. The primary objectives of configuration control are to maintain integrity and consistency of each baseline established and prevents unauthorized changes to baselined software. 2.1 Procedures for changing baselines There are three classifications of baselines, informal checkpoints, integration and verification, and release. For informal baselines the Configuration Manager must notified of the change. The change must be tested and built by the developer, then built by the Configuration Manager to ensure that the build process is not broken by the change. The Configuration Manager then baselines the configuration with a "checkpoint" label. Integration and verification baselines must be approved by the team leads and the Software Engineering Manager. 2.2 Procedures for processing change requests and approvals-change classification scheme     * Change reporting documentation     * Change control flow diagram 2.3 Organizations assigned responsibilities for change control Change Control Board     * Charter     * Members     * Role     * Procedures     * Approval mechanisms 2.4 Level of control Software Baselines require the approval of the configuration manager, a description of the change, and a completed successful build that incorporates the change. Software Release to I&V requires consensus among the Software Development Team leads and the approval of the Software Engineering Manager, as well as detailed descriptions of change, and a complete tested build that incorporates the change. Software Release to customer requires Change Control Board approval, detailed description of changes and test reports, a review of the integration and compatibility matrix, and completion of required customer documentation. 2.5 Handling Document Revisions Documents in the Software Development team are identified as Configuration Items and are controlled in the same way as source code. If a document is required to be released company-wide, or i

Related Questions

Navigate

• Browse (All)
• Browse 1
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.