13.6 Software Configuration Management
Any software development is an iterative process, that is to say, in the design process will identify problems in the requirements specification, design errors will expose in the implementation process. In addition, over time, customer demand will more or less change. Therefore, in the software development process, the change (or change) is both necessary and inevitable. However, the change is also very easy to lose control, if not properly controlled and managed change, is bound to cause confusion and produce many serious mistakes.
Software Configuration Management is a set of activities managing change throughout the life of the software. Specifically, this group of activities to: ① identify changes; ② change control; ③ ensure proper realization of the change; ④ people who need to know such information reporting change.
Software Configuration Management is different from software maintenance. Maintenance is due to occur before the software users, and configuration management software is started at the start of the project, and continued until a set of software to track and control activities after retirement termination.
Target software configuration management is to make the change more accurately and more easily adapt to reduce the amount of work it takes for change when necessary.
13.6.1 Software Configuration
1. Software Configuration Item
Output from the software process can be divided into three categories: ① computer program (source code and executable programs); ② a computer program described in a document (for art or users); ③ the data (the program contained in the external program or ). These items make up all the information generated in the software process, we configure the software to them collectively, and these items is the software configuration items.
With the progress of the software development process, rapid increase in the number of software configuration items. Unfortunately, due to the aforementioned various reasons, software configuration items of content may change at any time. In order to develop high-quality software products, software developers must not only strive to ensure that each software configuration item correctly, and must ensure that all software configuration items are exactly the same.
Can configure the software management as applied to the entire software process software quality assurance activities, quality assurance activities is software dedicated to managing change.
2. Baseline
The baseline is a software configuration management concepts, it helps us in without seriously hamper reasonable change of control down the change. IEEE is defined as the baseline: You have gone through a formal review of the specification or intermediate products, which can be used as a basis for further development, and it can only be changed through a formal change control process.
In short, the baseline is the configuration items through a formal review of the software . Before the software configuration items become baselines, you can modify it quickly and informally. Once the baseline is established, although you can still achieve change, however, it must be application-specific, formal process (called rules) to evaluate, implement and validate each change.
In addition to software configuration items, many software engineering organizations to be placed under configuration management software tool, that is, the specific version of the editors, compilers and other CASE tools, as part of the software configuration of the "fixed" down. Because when modifying software configuration items must use these tools to prevent different versions of the results generated by different tools , software tools should be baselined, and included into the comprehensive configuration management process.
13.6.2 Software Configuration Management Process
Software configuration management software is an important part of quality assurance, its main task is to control the change is also responsible for various software configurations and software versions of the logo, software configuration audit and report any changes occur to software configuration.
Specifically, the software configuration management there are five tasks: identification, version control, change control, configuration auditing and reporting.
1. Identify the target software configuration
To control and configuration management software items, each configuration item must be individually named, and object-oriented method of organization thereof. You can identify two types of objects: Basic objects and aggregated objects (objects can be gathered as a representative of a mechanism for the full version of the software configuration). The basic object is a software engineer to create out of the analysis, design, coding or testing process "text unit", for example, a paragraph requirements specification, a module of the source list or a set of test cases. Aggregate object is a collection of basic objects and other objects gathered.
Each object has a unique set of features can identify it: name, description, resource tables and "to achieve." Wherein the object name is a string that unambiguously identifies the object.
When pattern design software to identify the object, the object must be recognized throughout the life cycle has been in evolution, therefore, designed to identify patterns must be able to unambiguously identify the different versions of each object.
2. Version Control
Joint use version control procedures and tools to manage different versions of configuration objects in the software engineering process created. By means of a control version, the user can specify the configuration by selecting an appropriate software version. The method of achieving this goal is the attribute associated with each version up of software and configuration to specify the desired configuration and the description of a set of desired properties.
The above-mentioned "attribute", may be assigned only to a simple configuration object for each specific version number, the complex may be a Boolean variable string that identifies the specific type of function applied to the system change.
Non-release version, as long as the changes in version, each version can not override
3. Change Control
For large software development projects, uncontrolled changes will quickly lead to confusion. Change control procedures put people and automated tools combine to provide a control mechanism for change. Typical variation control process is as follows: to a change request after the first assessment of the variation losses and gains in technology, possible side effects, the overall impact on other system functions and configuration objects and modifying the estimated cost. The results of the evaluation form "Change Report" , report for the "Change Control approver" review. The so-called change of control approvals by either a person may also consist of a group of people, whose state of change and the priority to make the final decision.
For each approved changes will generate an "engineering change order", which describes the changes to be implemented, it must comply with the restrictions and the review and audit standards. To the modified objects from the project database "extract (check out)" to move the project out [object locking, others can not be modified] , modify and apply the appropriate SQA activities. Finally, the modified object "submit (check in)" into the database [unlock] others can modify and create the next version of the software with the appropriate version control mechanism.
"Submit" and "extraction" process to achieve a change in control of the two main functions - access control and synchronization control. Access control which software engineers have the right to access and modify a specific configuration object decision helps ensure synchronization control by two different software engineers to complete a parallel modification will not overwrite each other.
Before a software configuration items become baselines, only an informal application change control. The configuration object developers can it make any reasonable modifications (as long as the modifications do not affect the system needs outside developers working range). Once the object is through a formal technical review and approval, it creates a baseline. Once a software configuration items into a baseline, began to implement project-level change control. Now, in order to modify the developer must obtain the approval of the project manager (if the change is "local"), if the change affects other software configuration item, control changes also must be approved by the approver. In some cases, you can omit the formal change request, change reporting and engineering change orders, however, must evaluate each track and review changes and all changes.
4. Configure audit
to ensure proper realization of the changes needed, usually taken from both of the following measures: ① formal technical review; ② software configuration audit.
Formal technical review (see Section 13.5.2) focus on technical correctness of the configuration object is modified. Reviewers examine the objects to determine its consistency with other software configuration items, and check for missing or side effects.
Software configuration audit by features that are not normally considered in the review process to assess configuration objects (for example, whether to follow when modifying the software engineering standards, whether in the configuration items marked conspicuously the changes made, indicate whether the modification date and modified by, whether it is appropriate to update all the relevant software configuration items, whether to follow a marked change, changes in recording procedures and reporting changes), and complement formal technical review.
5. Status report
writing configuration status report is a task of software configuration management, it answers the following questions: ① What happened? ② matter who did it? ③ When did it happen? ④ What other things will affect?
Configuration status change has a significant impact on the success of large-scale software development projects. When large numbers of people working together, a person may not know what the other person is doing. Two developers might try to follow conflicting ideas to modify the configuration items of the same software; software engineering team may take several man-months of work instructions for developing software based on outdated hardware specifications; aware of the proposed changes have serious side effects people You may not know the modifications in progress. Configuration Status Reporting by improving communication between all stakeholders, to help eliminate these problems.
13.7 Capability Maturity Model
Capability Maturity Model Software Engineering Institute, established in the late 1980s under the US Department of Defense-funded Carnegie Mellon University (capability maturity model, CMM), is the ability to evaluate software for software process maturity of the organization model. Initially, the main purpose of the establishment of this model is to provide a comprehensive and objective review of the basis for bidding activities of large software projects , developed later, at the same time this model has been applied to many processes within the software organization improvement activities .
Over the years, the software crisis that has plagued many software development organizations. Many people try to solve the problems in software productivity and software quality issues through the use of new software development technology, but the effect is not very satisfactory. These facts prompted further investigation software process, to discover the key issue is the management of software process unsatisfactory. It turns out that under the irregular and chaotic management, advanced technology and tools can not play its due role. There is growing recognition, improve the management of software process is to remove the software crisis breakthrough, a key role in the management of software process can no longer be ignored.
The basic idea of the Capability Maturity Model, due to the problem is caused by the way we manage the software process caused by improper, so the use of new software technology does not automatically improve productivity and quality of software. Capability Maturity Model helps software development organizations to establish a regular, mature software process. The improved software process to develop better quality software, so that more software projects suffer from time and cost overruns it.
Software process includes a variety of activities, techniques and tools, so it actually includes both the technical aspects of software development also includes the management. CMM's strategy is an attempt to improve the management of software process, but improvements in technology is the inevitable result.
CMM software process improvement in the role is mainly to guide software organizations by determining current process maturity and identifies issues play a key role in process improvement, process improvement so clear direction and strategy. By focusing on process improvement and carry out the direction and strategy of a consistent set of process improvement activities, software organizations will be able to steadily and effectively improve its software process, so that the software process capability is improved step by step.
To improve the software process is completed in a gradual process of improvement and a small step on ongoing basis, rather than a complete revolution overnight. CMM process into the software from disorder to order evolution five stages, and to sort these stages, five-layer is formed to improve the level. These five maturity levels define an ordinal scale for measuring software organization software process maturity and evaluate its software process capability, these levels can also help improve the work should be done in software organizations to prioritize. Maturity level is the way to advance the platform mature software organization properly defined, each maturity level will continue to improve the software process to provide a higher level.
CMM described in five maturity levels characteristic described major changes between different levels of the software process. From "Level 1" to "Level 5", reflecting a software mechanism to achieve from a disorderly, chaotic evolution of software process to an orderly, disciplined purposes and mature software process, must go through way process improvement activities. Each maturity level is a step forward that the software organization along the way ways to improve its processes, the maturity level is a goal before the evolution of a level of software process.
Each level of maturity of CMM contains a set of process improvement goals, a software process to meet these objectives mechanism evolves from the current level to the next level of maturity; each to reach the next level of maturity level of the frame, the software process bodies have been improved and optimized to some extent, but also makes the process capability is improved; with the increasing maturity level, the process of the agency's improvement activities achieved more significant results, so that the software process be further improved and optimization. CMM is the manner described above support software organizations improve their software process activities.
CMM capability maturity is defined by five levels to guide software development organizations continue to identify defects in their software process, and pointed out what should be done to improve, but it does not provide specific measures to make these improvements.
5 capability maturity levels from low to high is: an initial stage (also referred to as Level 1), Repeatable (also known as stage 2), defined level (also referred to as level 3), has the management level ( also known as grade 4) and optimization level (also known as 5). Here are five levels of features.
1. Initial level
Characteristics of software process is disordered, and sometimes even chaotic. Almost nothing is the result of the process defined (ie, process models do not have a finalized ), the success of the project depends entirely on the ability of individual developers.
This is at the lowest maturity level of software organization, virtually no sound software engineering management system, its software process depends entirely on the staff of the project team with so unpredictable, people have changed the process has changed. If a project happens to be borne by an outstanding team of managers and developers experienced, capable, this project may be successful. However, a more common situation is the lack of sound management and careful planning, cost overruns and late delivery situation often occurs as a result, most of the action is only to deal with the crisis, rather than a complete pre-planned tasks.
In short, in a maturity level 1 software organization, process capability is unpredictable, it is unstable software process and product quality can only be predicted based on the ability to process individual work ability of personnel to the institutions, rather than software.
2. Repeatable
Software institutions to establish a basic project management process (process models) , can track cost, schedule, functionality and quality. Has established the necessary process specifications, the new project planning and management process is based on previous experience in similar projects, so that software projects have experienced similar applications to be successful again. Achieve a target level of 2 is the project management process is stable, so that the agency can duplicate software project software engineering practice in previous successful projects ever undertaken.
Software organizations in maturity level 2, software for the project has been undertaken to establish the basic software management control system. Through observation and analysis of previous projects, it may present constraints for ongoing projects. Project Leader tracking software product development cost and functionality and quality of products as well as progress and identify problems in order to meet the constraints should be addressed. It has to do software requirements principled, and its integrity is controlled. We have developed a project standards, and software organizations to ensure strict implementation of these standards. The project team with the client and the contractor has established a stable, manageable work environment.
Software process capability of Level 2 organizations in maturity can be summarized as, planning and project tracking software is stable, repeatable project has provided the environment for the successful practice before a disciplined management process . Software project activity is under the effective control of the project management system, the implementation of the plan and in line with previous guidelines based on realistic projects.
3. Defined Level
Software organizations have defined a complete software process (process models) , software process has been documented and standardized. All project team using documented, approved through the process to develop and maintain software. It contains all the features of a second stage.
In the software organization maturity level 3, there is a fixed group engaged in the process of software process engineering activities. When needed, the process team can take advantage of the process model instantiation process activities in order to obtain a process for a particular instance of a software project, and put into operation the process and carry out effective practice of software engineering projects. Meanwhile, the team can also advance the process of software process improvement activities organization. The software within the organization implement training programs to ensure that all project leaders and project developers have the knowledge and skills to complete the required tasks undertaken.
Software process capability of Level 3 organizations in maturity can be summarized as, whether active management or engineering activities are stable . Software development cost and schedule as well as the function and quality of the products are under control , and the quality of the software product traceability . This capability is based on a common understanding of the activities have a process model has been defined, staff and responsibilities in software organizations.
4. Managed Class
Software agency software process (process models and process instances) and software products have established quantitative quality goals, all project activities are important processes measurable . The collection agency software product and process metrics and measurement methods to be used, can be quantitatively understand and control software processes and software products, and laid the foundation for the project assessment process quality and product quality. It contains all the features of a third stage.
Software mechanism in a process capability maturity level 4 can be summarized as measurable software process, software process operating within the range of measurement. This level of process capability allows the software process and product quality institutions predict trends in the quantitative range of measures can be taken when the deviation occurs in a timely manner to be corrected, and can be expected to be of high quality software products.
The optimization stage
Software organization focused on continuous improvement of software processes . This level is a software mechanism to prevent institutional defects as the goal, it has the ability to identify weak links in the software process elements, and have sufficient means to improve them . In such a body, you can get statistics on the effectiveness of the software process, the use of these data can be the cost of new technology / benefit analysis, and can optimize the best new technologies in software engineering practice that can be adopted. It contains all the features of a fourth stage.
This is a software mechanism may be the cause of a defect by analyzing and determining the performance of the process instance to prevent this type of defect occurs again; the lessons learned through the analysis of any instance of a process obtained can become the software to optimize its effective mechanism in accordance with the process model, so that the process of other project examples optimized. Such software can be obtained by means of the quantitative process embodiment of the feedback information, while the use of new ideas and technologies to test them, to continue to improve and optimize the software process.
Software process capability of Level 5 organizations in maturity can be summarized as, software process is optimized. This level of software organizations to continually improve its process capability, both continuous improvement and optimization of existing process instance, to realize the future of new technologies and process improvement methods used and the aid.
Some statistics indicate that enhance a full maturity level will take about 18 months to 3 years, but up from level 1 to level 2 and sometimes takes three years or even five years. To date indicating that a software organization is still in chaos and passive way of action to instill systematic way, how difficult.
13.8 Summary
Software engineering technology, including content and management aspects, is closely integrated technology and product management. Only in science and strict management, advanced technical methods and excellent software tools can really play the power. Therefore, effective management is the key to success for large software projects.
Software Project Management Plan Project began, and the first planned activity is estimated. In order to estimate the project workloads and deadlines, first of all we need to predict the scale of the software.
Measure the size of software technology used mainly in technical and functional point of lines of code technology. Both technologies have advantages and disadvantages, should be based on characteristics of the project and the people who work in the program familiarity with these two technologies, the choice of appropriate technology.
Depending on the software can estimate the size needed to complete the project effort, commonly used estimation model for the static single-variable model, dynamic multi-variable model and COCOMO2 model. In order to make the estimates closer to actual value is generally the same time at least two of the above-described three models. The use of estimates derived by comparing the different models and coordination, it is possible to obtain more accurate estimates. Cost estimation models typically estimate equation also provides software development time, so that the estimated development time is the normal development time, experience has shown that up to the developers to reduce the increased use of method development time to 75% of the normal development time.
Managers must develop a sufficiently detailed schedule, in order to monitor project progress and control the entire project. Commonly used tools to develop schedule Gantt charts and project network, these two tools have advantages and disadvantages, usually combined use of Gantt charts and project network schedule to develop and oversee the progress of the project.
Developers of high-quality and reasonable organizational structure of the project team, is the key to the success of software projects. The typical organizational structure programmers democracy group, the main group of programmers and modern set of three kinds of programmers, application of occasions these three are not the same organization.
Software quality assurance software is active every step of the process are carried out. Software quality assurance measures are based on testing of non-executive (also referred to as the review), based on tests performed (commonly referred to as test) and proof of program correctness. Software review is one of the most important software quality assurance activities, its advantage is able to detect and eliminate errors in the software to correct errors cost is relatively low.
Software configuration management activities are applied to the entire software protection process, change management is a set of activities throughout the life of the software. Target software configuration management that can make the change more accurately and more easily adapt and reduce the workload for this purpose spent in the need to modify the software.
Capability Maturity Model (CMM) is an effective strategy to improve the software process. The basic idea is, because the problem is the way to manage software process caused by improper, so the use of new technology does not automatically improve software productivity and software quality, should make great efforts to improve the management of software processes. In fact the software process improvements can not be achieved, therefore, CMM incrementally to gradually introduce changes, it clearly defines five levels of maturity, a software development organization can be improved with a series of small steps into the higher the maturity level.
