Wondershare EdrawMind
MindMap Gallery Information document management and configuration management
- 23
- 1
Information document management and configuration management
Information Systems Project Manager (Third Edition) PMBOK (Fifth Edition) Exam Reference Materials.
Edited at 2020-10-09 10:38:04
- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
Information document management and configuration management
- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
- Recommended to you
- Outline
Chapter 14 Information Document Management and Configuration Management 490
14.1 Information system project documentation and management 490
1. Information system documentation concept.
(1) Information system-related information (documents) refers to a certain data medium and the data recorded in it. It is permanent and can be read by humans or machines, and is generally used only to describe something human-readable. In software engineering, documentation is often used to refer to any written or graphical information (including paper documents and electronic documents) that describes, defines, specifies, reports, or certifies activities, requirements, processes, or results.
(2) Information system documentation is the "trace" of the system construction process, a guide for system maintainers, and a tool for system developers to communicate with users. Standardized documentation means that the system is developed in accordance with engineering, which means that the quality of the information system is formally guaranteed. The lack, arbitrariness and irregularity of documentation will most likely lead to the system becoming unmaintainable, unupgradeable and lifeless after the original developers move. Therefore, to establish a good information system, we must not only use modern information technology and correct development methods, but more importantly, do a good job in document management.
(3) In the field of software engineering disciplines, documents and programs are collectively called software. The difference between documents and programs is that the former is readable by humans, while the latter is mainly executed by machines. If you add comments to the source program, it can also become part of the documentation.
2. Software document classification and quality level.
(1) Software documentation is generally divided into three categories: development documentation, product documentation, and management documentation. The contents of each type of document are shown in Table 14-1.
(2) Development documents describe the development process itself, product documents describe the products of the development process, and management documents record project management information.
(3) The quality of each document must be clearly defined during document planning. The quality of documentation can be divided into four levels based on the form of the document and the requirements listed. The contents and applicable situations of each level are shown in Figure 14-2.
(4) Issues that need to be considered in terms of quality should include both the structure and content of the document. Document content can be judged for correctness, completeness, and clarity. Document structure is measured by the order of its components and the simplicity of its overall arrangement. To achieve these 4 quality levels, the investment and resources required gradually increase, and the quality assurance organization must be in an appropriate administrative position to ensure that the desired quality level is achieved.
(5) The standardized management of management information system documents is mainly reflected in several aspects such as document writing specifications, chart numbering rules, document catalog writing standards and document management systems. According to the five stages of the life cycle method, the classification numbering rules are shown in Figure 14-3.
14.2 Configuration Management 492
14.2.1 Concept of configuration management 492
(1) Configuration management is a discipline that identifies system configurations at different points in time in order to systematically control configuration changes, maintain configuration integrity and traceability throughout the system's life cycle.
(2) Configuration management includes 6 main activities: formulation of configuration management plan, configuration identification, configuration control, configuration status report, configuration audit, release management and delivery. GB/T11457-2006 defines a configuration item as: "a collection of hardware, software, or both designed for configuration management, which is treated as a single entity during the configuration management process."
(3) Typical configuration items include project plans, requirements documents, design documents, source code, executable code, test cases, and various data required to run the software. They enter configuration management after being reviewed and inspected. Configuration items can be divided into two categories: baseline configuration items and non-baseline configuration items. Baseline configuration items may include all design documents and source programs; Non-baseline configuration items may include various plans and reports of the project.
(4) The operation permissions of all configuration items should be strictly managed by the CMO. The basic principles are: Baseline configuration items are open to developers for reading; Non-baseline configuration items are open to PM, CCB and related personnel.
(5) The status of configuration items can be divided into three types: "draft", "formal" and "modified". When a configuration item is first created, its status is "Draft". After the configuration item passes the review, its status changes to "official". If the configuration item is changed thereafter, its status changes to "Modified". When the configuration item is modified and passes the review again, its status becomes "formal" again, as shown in Figure 14-4.
(6) Configuration item version number.
1) The version number format of configuration items in "Draft" status is 0.YZ, and the numerical range of YZ is 01~99. As the draft is revised, the value of YZ should be incremented. The initial value and increase of YZ are controlled by the user himself.
2) The version number format of configuration items in the "official" state is X.Y, where X is the main version number and the value range is 1 to 9. Y is the minor version number, ranging from 0 to 9.
The first time a configuration item becomes an "official" file, the version number is 1.0. If the upgrade of the configuration item is relatively small, the changed part can be made into an attachment to the configuration item. The attachment versions are 1.0, 1.1,... When the changes in the attachment accumulate to a certain extent, the Y value of the configuration item can be increased appropriately, and the Y value increases To a certain extent, the X value will increase appropriately. Only when the upgrade of the configuration item is relatively large, the X value is allowed to be directly increased.
3) The version number format of the configuration item in the "modified" state is X.YZ. When the configuration item is being modified, generally only the Z value is increased, and the X.Y values remain unchanged. When the configuration item is modified and the status becomes "official", set the Z value to 0 and increase the X.Y value, see 2).
(7) Configuration item version management: During the project development process, most configuration items need to be modified many times before they are finally finalized. Any modifications to configuration items will produce a new version. Since we cannot guarantee that the new version will be "better" than the old version, we cannot abandon the old version. The purpose of version management is to save all versions of configuration items according to certain rules to avoid version loss or confusion, and to quickly and accurately find any version of a configuration item.
(8) The configuration baseline (often referred to as baseline) consists of a set of configuration items, which form a relatively stable logical entity. The configuration items in the baseline are "frozen" and cannot be modified by anyone at will. Changes to the baseline must follow formal change control procedures.
(9) A set of requirements, design, source code documents with unique identification numbers and corresponding executable code, construction documents and user documentation form a baseline. A test version of the product (which may include requirements analysis specifications, outline design specifications, detailed design specifications, compiled executable code, test outline, test cases, user manuals, etc.) is an example of a baseline.
(10) A product can have multiple baselines or only one baseline. Baselines delivered to external customers are generally called release baselines, and baselines used for internal development are generally called construction baselines.
(11) The configuration library stores configuration items and records all information related to the configuration items. It is a powerful tool for configuration management. Configuration libraries can be divided into three types: development libraries, controlled libraries, and product libraries.
1) Development library, also called dynamic library, programmer library or working library, Used to save configuration entities currently being developed by developers, Such as new modules, documents, data elements or modifications to existing elements. Dynamic configuration items are placed under version management. The dynamic library is the developer's personal workspace and is controlled by the developer. The information in the library may be modified frequently. As long as the user of the development library deems it necessary, there is no need to control the configuration, because this usually does not affect other parts of the project and can be modified at will.
2) Controlled library, also called main library, Contains the current baseline plus changes to the baseline. Configuration items in controlled libraries are placed under full configuration management. At the end of a certain phase of information system development, the current work products are stored in a controlled library. It can be modified, but you need to go through the change process.
3) Product library, also known as static library, distribution library, software warehouse, An archive containing various baselines for published use, placed under full configuration management. After the developed information system product completes system testing, it is stored in the product library as the final product, waiting to be delivered to the user or installed on site. Generally, it is not modified anymore. If you really want to modify it, you need to go through the change process.
(12) There are two modes for building a configuration database: building a database by configuration item type and building a database by task.
The main function of the configuration library ① Record all information related to configuration, of which storing controlled software configuration items is very important. ②The consequences of changes can be evaluated using the information in the library, which is of great significance to change control. ③ Management information of various configuration management processes can be extracted from the library.
Use the information in the configuration repository to answer many configuration management questions, such as: ①Which customers have extracted a specific system version? ②What hardware and system software are required to run a given system version? ③How many versions of a system have been generated so far, and when were they generated? ④If a specific component is changed, which versions of the system will be affected? ⑤How many change requests have been made for a specific version? ⑥How many reported bugs are there for a specific version? ⑦ The use of configuration libraries can help configuration administrators manage various work products in the information system development process, including semi-finished products or stage products and final products, in an orderly manner, so that they will not be confused, confused, or lost.
(13) Configuration library permission setting: The configuration administrator is responsible for assigning operation permissions to the configuration library to each project member.
The permission setting of the configuration library mainly solves the following problems: There are issues such as who can "see", who can "get", who can "modify", and who can "destroy" the configuration items stored in the library. The configuration administrator is responsible for assigning operation permissions to the configuration library to each project member.
(14) The Configuration Control Committee is responsible for evaluating, reviewing configuration changes and supervising the implementation of approved changes. Members of the CCB can include project managers, user representatives, product managers, development engineers, test engineers, quality control personnel, configuration managers, etc. The CCB does not have to be a permanent establishment and can be formed according to the needs of the work. For example, different CCBs can be formed according to the change content and change requests. For small projects, the CCB can be just one person, or even just part-time. Usually, CCB not only controls configuration changes, but is also responsible for more configuration management tasks, such as configuration management plan approval, baseline establishment approval, product release approval, etc.
(15) The configuration administrator is responsible for performing configuration management activities throughout the project life cycle, specifically including the following:
1) Write a configuration management plan.
2) Establish and maintain a configuration management system.
3) Establish and maintain the configuration library.
4) Configuration item identification.
5) Establish and manage baselines.
6) Version management and configuration control.
7) Configure status reporting.
8) Configure auditing.
9) Release management and delivery.
10) Provide configuration management training to project members.
14.2.2 Goals and policies of configuration management 497
Software configuration management is the establishment and maintenance of project product integrity throughout the entire software life cycle. Software configuration management efforts should enjoy adequate financial support, which needs to be negotiated between the customer, management, and specific project leaders. Software configuration management should be implemented for externally delivered software products, as well as those selected support tools used in the project.
The configuration management system is a software system used for configuration management. Its purpose is to strengthen the quality control of the information system development process, enhance the controllability of the information system development process, and ensure configuration by determining configuration management details and providing standardized configuration management software. The completeness, clarity, consistency and traceability of items (including various documents, data and procedures), and the controllability of the status of configuration items.
14.2.3 Daily configuration management activities 498
(1) Configuration control is the change control of configuration items and baselines, including: identifying and recording change applications; analyzing and evaluating changes; approving or rejecting applications; implementing, verifying and releasing modified configuration items.
(2) Change evaluation: CCB is responsible for organizing the evaluation of the change application and determining the following contents.
1) The impact of changes on the project.
2) Whether the changed content is necessary.
3) Whether the scope of the change has been carefully considered.
4) Whether the implementation plan of the change is feasible.
5) Whether the change workload estimate is reasonable.
The CCB decides whether to accept the change and informs the relevant personnel of the decision.
(3) Change control based on configuration library is shown in Figure 14-5.
(4) The configuration status report is also called configuration status statistics. Its task is to effectively record and report the information required for management configuration, and provide the current status of the configuration items in a timely and accurate manner for relevant personnel to understand, so as to strengthen the configuration management work.
(5) The configuration status report should contain the following content.
1) The identification and status of each controlled configuration item. Once a configuration item is placed under configuration control, its version and status for each subsequent progression should be recorded and saved.
2) The status of each change request and the implementation status of approved modifications.
3) The status of current and past versions of each baseline and comparison of versions.
4) Records of other configuration management process activities.
(6) Configuration audit, also called configuration audit or configuration evaluation, includes functional configuration audit and physical configuration audit, which are used to verify the consistency and integrity of current configuration items respectively. The implementation of configuration audit is to ensure the effectiveness of project configuration management, which reflects the most fundamental requirement of configuration management - no confusion is allowed, such as:
Prevent unsuitable products from being delivered to users, such as delivering incorrect versions of user manuals.
Identify imperfect implementations, such as those developed that do not meet the initial specifications or changes that are not implemented as per change requests.
Find out the mismatch or incompatibility between configuration items.
Confirm that the configuration items have been included in the baseline and stored in the inventory after the required quality control review.
Confirm that records and documentation maintain traceability.
Functional configuration audit Functional configuration audit is to audit the consistency of configuration items (whether the actual functions of the configuration items are consistent with their requirements), specifically verifying the following three aspects:
①The development of configuration items has been successfully completed.
②The configuration item has reached the performance and functional characteristics specified in the configuration identification.
③The operation and support documents of the configuration items have been completed and meet the requirements.
Physical configuration audit Physical configuration audit is to audit the integrity of the configuration items (whether the physical existence of the configuration items is consistent with expectations). Specifically, it verifies the following two aspects:
①Whether the configuration item to be delivered exists. ②Whether all required items are included in the configuration items.
publish and deliver The main tasks of release management and delivery activities are: to effectively control the release and delivery of software products and documents, and to properly preserve the master copies of code and documents during the life of the software product.
(1) Storage. The integrity of stored configuration items should be ensured in the following manner. ·Choose storage media to minimize reproduction errors or loss. ·Run or refresh archived configuration items at a certain frequency based on the storage period of the media. · Store copies in separate controlled locations to reduce the risk of loss.
(2) Copy. Copying is the stage of making copies of software. · Procedures should be established to ensure consistency and integrity of replication. · Ensure that distribution media does not contain extraneous items (such as software viruses or test data not suitable for demonstration). ·Suitable media should be used to ensure that the software product complies with reproduction requirements and ensures the integrity of its content throughout the delivery period.
(3) Packing. It should be ensured that delivered media is prepared in accordance with approved procedures. The release mark should be clearly marked in a place easily identifiable by the purchaser.
(4) Delivery. The supplier shall deliver products or services as specified in the contract.
(5) Reconstruction. The software environment should be able to be rebuilt to ensure that released configuration items are reconfigurable for a future period beyond the requirements of the previous version that are retained.
[Additional knowledge points]
1. Main steps in creating a baseline or releasing a baseline.
(1) Configure the administrator to identify the configuration items.
(2) Assign identification to configuration items.
(3) Create a configuration library for the project and assign permissions to each project member.
(4) Each project team member operates the configuration library according to their own permissions.
(5) Create a baseline or issue a baseline and obtain authorization from the CCB.
2. The baselines of configuration management are generally divided into functional baselines, allocation baselines, and management baselines. Baselines can only be modified by designated configuration administrators through the configuration change control process. Its main attributes generally include name, identifier, version, and date.
3. After the information system project is completed, the final product or project results should be placed in the product library. When subsequent development needs to be carried out on this basis, it should be transferred to the controlled library.
4. The configuration management system user representatives are selected from the developers who will use the system to follow the process in the actual project development process in the future. They are responsible for understanding the configuration management system and procedures from the early stages of construction, assisting in formulating and modifying configuration management procedures based on development experience, and assuming partial development roles in pilot projects. This group of members should include software development project managers, designers, coders, testers, and construction and release personnel.
5. Configuration control includes: identifying and recording change requests; analyzing and evaluating changes; approving or denying requests; implementing, verifying, and releasing modified software images. An audit trail should be maintained for each modification, and the reason for the modification and the authorization for the modification should be tracked. All access to controlled software items that handle security or security confidentiality functions should be controlled and audited.
14.3 Document management and configuration management tools 502
14.3.1 Tool Overview 502
(1) Project documents are generally used as part of configuration management and managed in configuration management tools. Therefore, commonly used software configuration management tools are divided into two categories, one is paid commercial software and the other is open source software.
(2) Paid commercial software: CA CCC; Microsoft VSS, CVS.
(3) Open source software: SVN, GIT, CVS.
14.3.2 SVN 503
(1) The SVN server has two operating modes: independent server and running with the help of Apache. Both methods have their own pros and cons, and users can choose by themselves.
SVN is an open source version control system. SVN is the king of centralized version control and is currently the most commonly used configuration management tool among domestic software companies. There are two ways to run the SVN server: independent server and running with apache. Both methods have their own pros and cons, and users can choose by themselves. Advantages of SVN:
①Supports renaming, which is very important for Java development. In order to get better code, frequent refactoring is required during development, and refactoring often involves the refactoring of files.
② It does not have to be locked during development. On the one hand, it makes refactoring inconvenient. On the other hand, it cannot be developed offline. Using SN is different. You can take it home and continue development. When you come back, just submit it.
③Multiple platforms. Can support operations on multiple platforms.
④ Better client support. An SVN client for Windows, TortoiseSVN, is more convenient to use.
⑤ Better integration with peripheral tools.
⑥ Convenience.
⑦The speed and stability look good.
14.3.3 CC 503
(2) ClearCase (CC for short) is one of IBM Rational's flagship products and the world's leading software configuration management tool. It is widely used in many enterprise-level software engineering practices. CC provides configuration management solutions in both C/S and B/S architectures, providing comprehensive software configuration management functions. Clearcase is a centralized version control tool.
Features of CC:
①Unique repository VOB (Version Object Bases)
②Visualized file version tree
③ Parallel development
④Version history
⑤Automatic comparison and merging between versions
⑥Work space management
14.3.4 GIT 504
(3) GIT is different from commonly used version control tools such as CVS and Subversion. It adopts a distributed version library and does not require server-side software support, making the release and exchange of source code extremely convenient.
GIT is an open source distributed version control tool. GIT was originally written by Linus Toryalds as a version control tool for Linux kernel development.
GIT is fast, which is naturally important for big projects like Linux kemel.
The most outstanding thing about GIT is its merge tracking (merge racing) capability. GIT has become very popular abroad, and more and more open source projects have been transferred to GIT.
The main advantages of GIT are: ① More convenient Merge. ② More convenient management. ③More robust system. ④Less dependent on the network.
Comparison between GIT and SVN
In many cases, GIT is far faster than SVN.
SVN is centralized management, and GIT is distributed management. The biggest difference between distributed and centralized is: Under distributed version control, there is a local code repository, and developers can submit it locally; while under centralized version control, there is only one code repository on the server, and it can only be managed uniformly on the server.
SVN is clumsy to use branches, GIT can easily have unlimited branches.
SVN must be connected to the Internet to work properly, and GIT supports local version control.
The old version of SVN will place a .svn in each directory, and GIT will only have a git in the root directory.
14.4 Exercises for this Chapter 505