A system can be defined as a collection of components organized to accomplish a specific function or set of functions. Software configuration management (SCM) is a supporting software life cycle process which benefits project management, development and maintenance activities, assurance activities, and the customers and users of the end product. The concepts of configuration management apply to all items to be controlled, although there are some differences in implementation between hardware CM and software CM.
The SCM activities are: management and planning of the SCM process, software configuration identification, software configuration control, software configuration status accounting, software configuration auditing, and software release management and delivery.
SCM controls the evolution and integrity of a product by identifying its elements, managing and controlling change, and verifying, recording, and reporting on configuration information. To plan an SCM process for a project, it is necessary to understand the organizational context and the relationships among the organizational elements. The organizational elements responsible for the software engineering supporting processes may be structured in various ways. Software is frequently developed as part of a larger system containing hardware and firmware elements.
SCM might interface with an organization’s quality assurance activity on issues such as records management and non-conforming items. Perhaps the closest relationship is with the software development and maintenance organizations. It is within this context that many of the software configuration control tasks are conducted. The planning of an SCM process for a given project should be consistent with the organizational context, applicable constraints, commonly accepted guidance, and the nature of the project (for example, size and criticality). To prevent confusion about who will perform given SCM activities or tasks, organizations to be involved in the SCM process need to be clearly identified. Planning for SCM identifies the staff and tools involved in carrying out SCM activities and tasks.
Different types of tool capabilities, and procedures for their use, support SCM activities.
In this example, code management systems support the operation of software libraries by controlling access to library elements, coordinating the activities of multiple users, and helping to enforce operating procedures. A software project might acquire or make use of purchased software products, such as compilers or other tools.
When a software item will interface with another software or hardware item, a change to either item can affect the other. Guidance on the creation and maintenance of an SCMP, based on the information produced by the planning activity, is available from a number of sources, such as IEEE828-98. After the SCM process has been implemented, some degree of surveillance may be necessary to ensure that the provisions of the SCMP are properly carried out.
The use of integrated SCM tools with process control capability can make the surveillance task easier. SCM measures can be designed to provide specific information on the evolving product or to provide insight into the functioning of the SCM process.
Software libraries and the various SCM tool capabilities provide sources for extracting information about the characteristics of the SCM process (as well as providing project and management information). Care must be taken to keep the focus of the surveillance on the insights that can be gained from the measurements, not on the measurements themselves. Audits can be carried out during the software engineering process to investigate the current status of specific elements of the configuration or to assess the implementation of the SCM process. The software configuration identification activity identifies items to be controlled, establishes identification schemes for the items and their versions, and establishes the tools and techniques to be used in acquiring and managing controlled items. A software configuration is the set of functional and physical characteristics of software as set forth in the technical documentation or achieved in a product.
A software configuration item (SCI) is an aggregation of software designated for configuration management and is treated as a single entity in the SCM process. Selecting SCIs is an important process in which a balance must be achieved between providing adequate visibility for project control purposes and providing a manageable number of controlled items. The structural relationships among the selected SCIs, and their constituent parts, affect other SCM activities or tasks, such as software building or analyzing the impact of proposed changes.
A software baseline is a set of software configuration items formally designated and fixed at a specific time during the software life cycle. Commonly used baselines are the functional, allocated, developmental, and product baselines.
Software configuration items are placed under SCM control at different times; that is, they are incorporated into a particular baseline at a particular point in the software life cycle.
Following the acquisition of an SCI, changes to the item must be formally approved as appropriate for the SCI and the baseline involved, as defined in the SCMP.
A software library is a controlled collection of software and related documentation designed to aid in software development, use, and maintenance. The tool(s) used for each library must support the SCM control needs for that library, both in terms of controlling SCIs and controlling access to the library. These libraries are also an important source of information for measurements of work and progress.
Software configuration control is concerned with managing changes during the software life cycle. The first step in managing changes to controlled items is determining what changes to make. This flow of a Change Control Process provides an opportunity for tracking defects and collecting change activity measurements by change type. The authority for accepting or rejecting proposed changes rests with an entity typically known as a Configuration Control Board (CCB). An effective software change request (SCR) process requires the use of supporting tools and procedures ranging from paper forms and a documented procedure to an electronic tool for originating change requests, enforcing the flow of the change process, capturing CCB decisions, and reporting change process information. Approved SCRs are implemented using the defined software procedures in accordance with the applicable schedule requirements. The actual implementation of a change is supported by the library tool capabilities, which provide version management and code repository support. The constraints imposed on a software engineering effort or the specifications produced during the development activities might contain provisions which cannot be satisfied at the designated point in the life cycle. Software configuration status accounting (SCSA) is the recording and reporting of information needed for effective management of the software configuration. The SCSA activity designs and operates a system for the capture and reporting of necessary information as the life cycle proceeds. Some form of automated tool support is necessary to accomplish the SCSA data collection and reporting tasks. Reported information can be used by various organizational and project elements, including the development team, the maintenance team, project management, and software quality activities. In addition to reporting the current status of the configuration, the information obtained by the SCSA can serve as a basis for various measurements of interest to management, development, and SCM.
A software audit is an activity performed to independently evaluate the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures. The software configuration auditing activity determines the extent to which an item satisfies the required functional and physical characteristics.
The purpose of the software FCA is to ensure that the audited software item is consistent with its governing specifications.
The purpose of the software physical configuration audit (PCA) is to ensure that the design and reference documentation is consistent with the as-built software product.
As mentioned above, audits can be carried out during the development process to investigate the current status of specific elements of the configuration. Software building is the activity of combining the correct versions of software configuration items, using the appropriate configuration data, into an executable program for delivery to a customer or other recipient, such as the testing activity. A tool capability is useful for selecting the correct versions of software items for a given target environment and for automating the process of building the software from the selected versions and appropriate configuration data.
Software release management encompasses the identification, packaging, and delivery of the elements of a product, for example, executable program, documentation, release notes, and configuration data. Thu vi?n H?c li?u M? Vi?t Nam (VOER) du?c tai tr? b?i Vietnam Foundation va v?n hanh tren n?n t?ng Hanoi Spring. AssurX’s Change Management Software is a flexible, centralized system used to orchestrate, track and document changes across all functional areas of a business. With easy, full integration to other quality related processes such as corrective action management, audits, nonconformance, customer complaints, document management, training, etc., no matter where an issue triggering a change originates, or how many departments a planned change touches, the system effectively controls the process. The AssurX Change Management system receives any type of proposed change and efficiently manages evaluation, planning, implementation and documentation across every part of your operation—all in a closed-loop workflow. A system of automatic escalation, notices and reminders integrated with e-mail can be easily defined and keeps the process moving to prevent issues and tasks from falling through the cracks.
Unlike other systems that rely on third party tools to generate reports and metrics, AssurX comes with user-configurable built-in dashboards, metrics and ad-hoc query functionality that allows for real time monitoring, trending and analysis. The system combines centralized control of the process with integrated collaboration, review and approvals from designated Subject Matter Experts. For FDA regulated companies, AssurX is fully compliant with 21 CFR Part 11 and Part 820, GMP, ISO and more. With its highly configurable workflows, AssurX is the only vendor that provides a solution flexible enough to manage any type of change across all functional areas. Simple point-and-click configuration of workflows, fields, forms, rules, lists, signatures, etc. OnDemand (Software-as-a-Service) option gets you up and running in days with no hardware or software to install and no waiting for IT staff. Its true zero-client architecture (CATSWeb) means AssurX runs on all browsers and operating systems with no need to install, upgrade, validate or manage client computers. AssurX Change Management integrates easily with external business systems like ERP, PLM, CRM, LIMS and MES solutions to connect all quality related processes and procedures across the enterprise—so change requests triggered from any source can be immediately captured and acted upon.


AssurX’s system of quality and compliance software solutions is designed to be simple to use, maintain and configure to meet each business’ precise needs. What Paradigm 3 can do is … manage a disciplined change request, change investigation and change implementation for processes, products or services.
The change control methodology is designed as a style with a new page and fields to be completed for each sign-off section using the Improvement Module. Paradigm 3 is supplied with a Change Control style ready to go, or you can design your own. SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software.
From the software engineer’s perspective, SCM facilitates development and change implementation activities. Although the responsibility for performing certain SCM tasks might be assigned to other parts of the organization such as the development organization, the overall responsibility for SCM often rests with a distinct organizational element or designated individual. In this case, SCM activities take place in parallel with hardware and firmware CM activities, and must be consistent with system-level CM. Regarding the former, some tems under SCM control might also be project records subject to provisions of the organization’s quality assurance program.
Policies and procedures set forth at corporate or other organizational levels might influence or prescribe the design and implementation of the SCM process for a given project. The major activities covered are: Software Configuration Identification, Software Configuration Control, Software Configuration Status Accounting, Software Configuration Auditing, and Software Release Management and Delivery.
Specific responsibilities for given SCM activities or tasks also need to be assigned to organizational entities, either by title or by organizational element. It addresses scheduling questions by establishing necessary sequences of SCM tasks and identifying their relationships to the project schedules and milestones established at the project management planning stage.
Depending on the situation, these tool capabilities can be made available with some combination of manual tools, automated tools providing a single SCM capability, automated tools integrating a range of SCM (and perhaps other) capabilities, or integrated tool environments which serve the needs of multiple participants in the software engineering process (for example, SCM, development, V&V). Other tools support the process of building software and release documentation from the software elements contained in the libraries.
Planning considers issues that might arise in the implementation of these tools, particularly if some form of culture change is necessary. SCM planning considers if and how these items will be taken under configuration control (for example, integrated into the project libraries) and how changes or updates will be evaluated and managed. In this case, the SCM requirements to be imposed on the subcontractor’s SCM process as part of the subcontract and the means for monitoring compliance also need to be established.
The planning for the SCM process considers how the interfacing items will be identified and how changes to the items will be managed and communicated. It is maintained (that is, updated and approved) as necessary during the software life cycle. There are likely to be specific SQA requirements for ensuring compliance with specified SCM processes and procedures. Some tools facilitate process compliance while providing flexibility for the software engineer to adapt procedures. A related goal of monitoring the SCM process is to discover opportunities for process improvement. For example, information about the time required to accomplish various types of changes would be useful in an evaluation of the criteria for determining what levels of authority are optimal for authorizing certain types of changes.
In-process auditing of SCM provides a more formal mechanism for monitoring selected aspects of the process and may be coordinated with the SQA function. This involves understanding the software configuration within the context of the system configuration, selecting software configuration items, developing a strategy for labeling software items and describing their relationships, and identifying the baselines to be used, along with the procedure for a baseline’s acquisition of the items.
The term is also used to refer to a particular version of a software configuration item that has been agreed on.
The triggering event is the completion of some form of formal acceptance task, such as a formal review. Following approval, the item is incorporated into the software baseline according to the appropriate procedure. At the working library level, this is a code management capability serving developers, maintainers, and SCM.
It covers the process for determining what changes to make, the authority for approving certain changes, support for the implementation of those changes, and the concept of formal deviations from project requirements, as well as waivers of them.
The software change request process provides formal procedures for submitting and recording change requests, evaluating the potential cost and impact of a proposed change, and accepting, modifying, or rejecting the proposed change. Once an SCR is received, a technical evaluation (also known as an impact analysis) is performed to determine the extent of the modifications that would be necessary should the change request be accepted.
In smaller projects, this authority may actually reside with the leader or an assigned individual rather than a multi-person board. A link between this tool capability and the problem-reporting system can facilitate the tracking of solutions for reported problems.
Since a number of approved SCRs might be implemented simultaneously, it is necessary to provide a means for tracking which SCRs are incorporated into particular software versions and baselines. A deviation is an authorization to depart from a provision prior to the development of the item. As in any information system, the configuration status information to be managed for the evolving configurations must be identified, collected, and maintained. This could be a database capability, or it could be a standalone tool or a capability of a larger, integrated tool environment. Reporting can take the form of ad hoc queries to answer specific questions or the periodic production of predesigned reports.
Examples include the number of change requests per SCI and the average time needed to implement a change request. Audits are conducted according to a well-defined process consisting of various auditor roles and responsibilities. The output of the software verification and validation activities is a key input to this audit. In this case, an audit could be applied to sampled baseline items to ensure that performance is consistent with specifications or to ensure that evolving documentation continues to be consistent with the developing baseline item. For systems with hardware or firmware, the executable program is delivered to the system-building activity.
It might be necessary to rebuild an exact copy of a previously built software configuration item. For large projects with parallel development or distributed development environments, this tool capability is necessary.
Outputs of the build process might be needed for future reference and may become quality assurance records. Given that product changes can occur on a continuing basis, one concern for release management is determining when to issue a release. It is useful to have a connection with the tool capability supporting the change request process in order to map release contents to the SCRs that have been received.
Cac tai li?u d?u tuan th? gi?y phep Creative Commons Attribution 3.0 tr? khi ghi chu ro ngo?i l?. It creates a consistent, closed-loop method to process any change type (business process, product design, documentation, materials, packaging, line repair, etc.), even for regulated industries. Feedback on the effectiveness of proposed changes and change plans is automatically requested, tracked and monitored to ensure that changes are properly planned and will deliver the expected results, before they are rolled out across operations. AssurX has simplified and streamlined an end-to-end workflow for processing all event intakes, reportable and non-reportable. The turnkey process is provided with documentation, setup and user guides, validation scripts, template forms and workflows, executive dashboards, and everything else needed for quick deployment. The configurable processes are designed to integrate seamlessly with each other providing a single, all-in-one solution for managing quality and compliance enterprise-wide.
It can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to serve a particular purpose.
Tool support for SCM is limited in that only certain aspects of software development and maintenance are accommodated.
Managing nonconforming items is usually the responsibility of the quality assurance activity; however, SCM might assist with tracking and reporting on software configuration items falling into this category. In addition, the contract between the acquirer and the supplier might contain provisions affecting the SCM process.
In addition, issues such as organization and responsibilities, resources and schedules, tool selection and implementation, vendor and subcontractor control, and interface control are typically considered. The overall authority and reporting channels for SCM should also be identified, although this might be accomplished at the project management or quality assurance planning stage.
Any training requirements necessary for implementing the plans and training new staff members are also specified.
Automated tool support becomes increasingly important, and increasingly difficult to establish, as projects grow in size and as project environments become more complex. Information available from the various SCM tools relates to Royce’s Work and Progress management indicator and to his quality indicators of Change Traffic and Stability, Breakage and Modularity, Rework and Adaptability, and MTBF (mean time between failures) and Maturity. Tools for managing software change requests support the change control procedures applied to controlled software items. The latter includes consideration of what SCM information must be available for effective compliance monitoring. The SCM role may be part of a larger, system-level process for interface specification and control, and may involve interface specifications, interface control plans, and interface control documents. In implementing the SCMP, it is typically necessary to develop a number of more detailed, subordinate procedures defining how specific requirements will be carried out during day-to-day activities. This could involve an SCM authority ensuring that those with the assigned responsibility perform the defined SCM tasks correctly.
Measurements of SCM processes provide a good means for monitoring the effectiveness of SCM activities on an ongoing basis.


Software items with potential to become SCIs include plans, specifications and design documentation, testing materials, software tools, source and executable code, code libraries, data and data dictionaries, and documentation for installation, maintenance, operations, and software use. The design of the identification scheme for SCIs should consider the need to map the identified items to the software structure, as well as the need to support the evolution of the software items and their relationships. The allocated baseline corresponds to the reviewed software requirements specification and software interface requirements specification. Several types of libraries might be used, each corresponding to a particular level of maturity of the software item. It is focused on managing the versions of software items while supporting the activities of multiple developers.
Information derived from these activities is useful in measuring change traffic and breakage, and aspects of rework. Requests for changes to software configuration items may be originated by anyone at any point in the software life cycle and may include a suggested solution and requested priority. A good understanding of the relationships among software (and possibly, hardware) items is important for this task.
There can be multiple levels of change authority depending on a variety of criteria, such as the criticality of the item involved, the nature of the change (for example, impact on budget and schedule), or the current point in the life cycle. Change process descriptions and supporting forms (information) are given in a variety of references.
As part of the closure of the change process, completed changes may undergo configuration audits and software quality verification. More powerful tools can support parallel development and geographically distributed environments. A waiver is an authorization to use an item, following its development, that departs from the provision in some way. Various information and measurements are needed to support the SCM process and to meet the configuration status reporting needs of management, software engineering, and other related activities.
Some information produced by the status accounting activity during the course of the life cycle might become quality assurance records.
Two types of formal audits might be required by the governing contract (for example, in contracts covering critical software): the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA).
When different versions of a software item are available for delivery, such as versions for different platforms or versions with varying capabilities, it is frequently necessary to recreate specific versions and package the correct materials for delivery of the version. Build instructions ensure that the proper build steps are taken and in the correct sequence. In this case, the supporting tools and associated build instructions need to be under SCM control to ensure availability of the correct versions of the tools. The severity of the problems addressed by the release and measurements of the fault densities of prior releases affect this decision. This tool capability might also maintain information on various target platforms and on various customer environments. Our professional services group can also perform your validation and help create your PQ based on industry best practices and the latest regulatory guidelines. Unlimited best practices workflows can be added, and modifications to existing template workflows can be easily done with point-and-click configuration. Configuration management (CM), then, is the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the system life cycle. SCM methods and tools are often viewed as intrusive by developers, a management tool that imposes additional work with little perceived benefit to the tasks of the developer.
This, in turn, requires an understanding of the organizational context for, and the constraints placed on, the design and implementation of the SCM process.
Note that firmware contains hardware and software, therefore both hardware and software CM concepts are applicable. For example, certain configuration audits might be required, or it might be specified that certain items be placed under CM. The results of the planning activity are recorded in an SCM Plan (SCMP), which is typically subject to SQA review and audit. Reporting on these indicators can be organized in various ways, such as by software configuration item or by type of change requested. Other tools can provide database management and reporting capabilities for management, development, and quality assurance activities. In this case, SCM planning for interface control takes place within the context of the system-level process. The software quality assurance authority, as part of a compliance auditing activity, might also perform this surveillance.
Surveillance requirements and the level of flexibility to be provided to the software engineer are important considerations in tool selection. These measurements are useful in characterizing the current state of the process, as well as in providing a basis for making comparisons over time. A revision is a new version of an item that is intended to replace the old version of the item.
A baseline, together with all approved changes to the baseline, represents the current approved configuration.
The developmental baseline represents the evolving software configuration at selected times during the software life cycle.
For example, a working library could support coding and a project support library could support testing, while a master library could be used for finished products.
One source of change requests is the initiation of corrective action in response to problem reports. Finally, an established authority, commensurate with the affected baseline, the SCI involved, and the nature of the change, will evaluate the technical and managerial aspects of the change request and either accept, modify, reject, or defer the proposed change.
The composition of the CCBs used for a given system varies depending on these criteria (an SCM representative would always be present). These tools may be manifested as separate specialized applications under the control of an independent SCM group.
In these cases, a formal process is used for gaining approval for deviations from, or waivers of, the provisions. The types of information available include the approved configuration identification, as well as the identification and current implementation status of changes, deviations, and waivers. An audit can require a number of individuals to perform a variety of tasks over a fairly short period of time. Successful completion of these audits can be a prerequisite for the establishment of the product baseline. In addition to building software for new releases, it is usually also necessary for SCM to have the capability to reproduce previous releases for recovery, testing, maintenance, or additional release purposes.
The packaging task must identify which product items are to be delivered, and then select the correct variants of those items, given the intended application of the product. When software products to be developed have the potential to affect public safety, external regulatory bodies may impose constraints. As mentioned above, the capabilities of several tool types might be integrated into SCM systems, which in turn are closely coupled to various other software activities. Analysis of the measurements may produce insights leading to process changes and corresponding updates to the SCMP.
A variant is a new version of an item that will be added to the configuration without replacing the old version.
Change authority for this baseline typically rests primarily with the development organization, but may be shared with other organizations (for example, SCM or Test). An appropriate level of SCM control (associated baseline and level of authority for change) is associated with each library. Regardless of the source, the type of change (for example, defect or enhancement) is usually recorded on the SCR. The change request process described above will typically document the SCM (and other) approval information for the change. Buckley contrasts the purposes of the FCA and PCA in hardware versus software contexts, and recommends careful evaluation of the need for a software FCA and PCA before performing them. The information documenting the physical contents of a release is known as a version description document.
Finally, the particular software life cycle process chosen for a software project and the tools selected to implement the software affect the design and implementation of the SCM process.
The product baseline corresponds to the completed software product delivered for system integration. Security, in terms of access control and the backup facilities, is a key aspect of library management. When the scope of authority of a CCB is strictly software, it is known as a Software Configuration Control Board (SCCB). Finally, they may be as elementary as a rudimentary change control system provided with an operating system.
The release notes typically describe new capabilities, known problems, and platform requirements necessary for proper product operation. The baselines to be used for a given project, along with their associated levels of authority needed for change approval, are typically identified in the SCMP. The latter can be complicated by the fact that some current users might have versions that are several releases old.
Finally, in some cases, the release management activity might be required to track the distribution of the product to various customers or target systems. An example would be a case where the supplier was required to notify a customer of newly reported problems.



8 secrets of the truly rich download
Transcendental meditation techniques pdf download


 

  1. 15.08.2014 at 23:10:42
    arkadas writes:
    Every a part of your life secular advisor?�so as to avoid the natural tendency to fall into bizarre patterns uMASS.
  2. 15.08.2014 at 23:50:49
    Alsu writes:
    Therapeutic providers into one wonderful every stone and construction, hidden in the hymns of the wind, buried.
  3. 15.08.2014 at 19:48:35
    farcury writes:
    Permitting for spiritual renewal help.
  4. 15.08.2014 at 23:13:29
    XA1000000 writes:
    The general public realized of 38-yr-outdated Ian Thorson's death in a cave within perception Retreat.