Lecture
For an introduction to this section that is relatively rarely submitted for separate consideration, let us define key terms.
Configuration is a named set of elements that are the results of a project.
A configuration item is a project result or a result component that is controlled as part of the configuration management process.
Responsibility for planning, operating, and controlling the configuration management process rests with the configuration manager. If the project is small, these functions are performed by the project manager , but with an increase in the scale of the project, this role becomes the main one and requires a separate assignment.
The duties of the configuration management manager necessarily include [22]:
The definition of configuration management objects is carried out based on the analysis of the planned project results recorded in key project documents: the statutes and the project content. According to the results of the analysis, the structure and organization of the elements necessary for creating the working environment of the configuration management process is established.
Identification of configurations identifies controlled elements, establishes identification schemes for elements and their versions, and also defines the tools and techniques that are used to control these elements. This activity is the basis for all other configuration management work .
Identifying configuration elements that need to be controlled is the first step in organizing change control, in the framework of the described approach, implemented through an integrated change management process. The right choice of configuration items is important to ensure a manageable set of monitored items. The structural relationships between the selected configuration items (and their components) affect the operation of the project. Configuration items evolve as the project progresses. The configuration item version is considered as a specific state of the evolving element. As the project progresses, versions are being updated - a new version of the item intended to replace it with the current, old version.
The objects of configuration management include computer resources, service, tools needed to create the project infrastructure. The timely creation of the project infrastructure is one of the critical success factors at the planning stage.
Configuration elements are formed based on the development of the project work plan. A new configuration item is received from an authorized member of the project team. The element is assigned an identifier, its initial state is determined, and it is placed in the CM repository, where protection against unauthorized access is established.
Infrastructure planning begins with the formation of requirements. As a rule, requirements for computer equipment and related infrastructure are formed on the basis of an analysis of the company's internal information, including an assessment of the performance characteristics of computer equipment. The infrastructure must be assessed with respect to tasks of various profiles, and its assessment at the following levels:
project equipment, creation of working environment, project library. Work on the creation of project infrastructure must be monitored. For the members of the project team at the customer's site, there should be prepared workplaces equipped with office equipment, telephones, personal computers, printers, meeting rooms, training rooms and other material resources. One of the essential elements of the infrastructure is the project library.
Special rooms
For the implementation of the project by the working group in the Zvezdochka group of companies, the customer provides special premises to accommodate the joint project working group.
Requirements for premises
The project office premises must meet the following requirements:
per employee must account for at least 5 m 2 of working area, the workplace of each employee must be provided:
The project working group should be allocated for use a working room for negotiations, equipped with:
Providing members of the project working group with personal computers :
Providing the working group of the project with copying equipment. The working group of the project is provided by the customer with one copying machine with the possibility of two-sided copying of A3 and A4 sheets and automatic feeding of sheets of the original.
Providing the working group of the project with stationery. The working group of the project is provided by the customer with stationery and paper at the request of the project administrator from the contractor.
Ensuring information exchange of members of the project team
Mode and place of work of the members of the joint project working group
To create the infrastructure you need:
The baseline or fixed configuration slice is a set of configuration elements formally defined and fixed in time during the life cycle of an IC. In certain cases, the baseline can be changed only through a formal change control procedure. The fixed slice, in combination with all the approved changes regarding it, is the current approved configuration [21].
Different configuration elements are transferred under configuration control at different points in time and are included in baselines at certain points in the life cycle. The initiating event is the completion of certain forms of formal statement of tasks, such as formal assessment. Examples of configuration items include customized IP modules, user manual, test plans, test databases, and more.
To organize the implementation of the above tasks at the planning stage of the life cycle of the IS, a configuration management plan is developed, where the concept is outlined and the means for automating the process are defined, and all roles and activities are described depending on the stage of the IS life cycle.
A configuration management plan (QM) is developed in the early stages of the planning stage and is part of the project management plan. The structure of the CM plan depends on such factors as the type of project and its duration, the level of process formalization, team size, and so on. This means that the structure of the plan may vary significantly depending on the project. In [19], an analysis of the factors influencing the structure of the plan was performed.
Thus, the presence of several offices complicates the plan, supplementing it with the rules of interaction between offices, affects the overall architecture of the project. The increase in the number of regions affects the level of formalism of the plan.
The relative size of the project affects the number of regulations and their elaboration and detail. Phases, interaction between groups, the passage of change requests are described in more detail. The larger the project, the more formalized the plan should be.
The number of configuration elements only affects a deeper elaboration of the identification of elements. In some cases it is useful to define in terms of all types of configuration elements on the basis of templates.
The number of components and subsystems affect the selection of elements from the repository (the method of sampling and circulation) and the depth of presentation of the section describing the structure of the project catalog. The CM plan usually describes all phases of the IP life cycle. Sometimes when working with subcontractors, it is necessary to more clearly identify the phase in which a subcontractor is connected.
The course of the project and the plan is significantly affected by factors such as the development tools used, the development platform (development on several platforms and for several platforms at the same time is possible). Of great importance are the type and number of means of implementation (automation CC), they belong to one or several vendors. For example, in a project, you can use a version control tool from one vendor, and a change control tool from another. The type of integration between the tools, the integration architecture should be considered in detail in the CM plan.
The level of formalization depends on many factors. Choosing the level of formality and depth of presentation, it is necessary to be guided by outgoing tasks and goals. Factors such as the complexity of the project, regional dispersion, the type of project, the presence of subcontractors, should automatically lead to writing a highly formalized CM plan. Medium and low levels can be applied in relatively short-term projects, projects involving a small number of developers. With the growth of the team, the division of roles, the CM plan should be revised, the level of formalization raised. Table 42 provides an example of the structure of a CM plan.
Depending on the size of the project, some items of the plan may be omitted.
At the planning stage of configuration management, it is also necessary to determine which software and hardware will ensure the achievement of project objectives, develop plans for monitoring and creating project documents, as well as define strategies, standards and project procedures that ensure configuration management, document how to identify and organize and monitored configuration items.
An example of the procedure for ensuring the storage of documents.
All project documentation is stored in the project library. The library is organized to ensure the availability of documents to the project team; registration and storage of copies of modified documents; storage of reference materials, including standards documentation; support of administrative information on the project; storage of current (working) information.
An example of the procedure for sending documents.
Distribution should be made by the authors and maintained for all controlled project documents. The mailing list includes the following information: the recipient's full name, e-mail address, role in the project.
Sample document preparation procedure
All project documents must have a title page, a history of changes, a list of reviewers, a distribution list.
The title page necessarily contains the subject of the document, the author, the date of creation, the date of the last modification of the document, the identifier by which you can make references to the document, the version number of the document by whom the document is approved.
The change history includes the date of the change, the author of the change.
Sample activity reporting procedure
The activity reporting procedure is to set up and maintain a reporting process for project implementation. The project time frame is managed by tracking the results of the work done, the reports of which are part of the reporting provided.
Project documents will be prepared by project teams throughout the project, in accordance with the project work plan.
All project documents will be submitted for approval and approval to the customer. Open questions on the document are recorded in the last section of each document "Open questions for this document" with options for solving the issue. Open questions that cannot be resolved at the level of project teams and the project manager are duplicated in the problem log and open questions, in accordance with the problem management procedure and open questions.
Approved project documents will be the basis for subsequent project work.
The following software will be used to execute documents:
All project documentation will be stored in electronic form in the project library.
Table 13.1. The structure of the configuration management plan (adapted from [18])
Plan section | Plan section | Content requirements | Additional comments |
1. Introduction | Introduction | An introduction to the CM plan is an overview of the contents of the document. Includes goals, scope, definitions, acronyms, abbreviations, references and overview of the configuration management plan . | Introduction allows you to make the document more readable - to explain the main points and to place the correct accents |
1.1 Purpose | Purpose | Contains the purpose of the Configuration Management Plan document. | As a rule, you can include in the assignment a description of the goals that the plan will solve. After all, the plan, depending on the size of the project, on the geographical distribution, may also differ |
1.2 Scope | Scope | A brief description of the scope of the plan; what model it is associated with, other features affecting the document | Often, you can describe the units involved in the CM process. Describe the conditions of use. In determining the scope, it is helpful to answer a number of questions for yourself:
|
1.3 Definitions, acronyms and abbreviations | Definitions, Acronyms and Abbreviations | Represents the definitions of all terms, acronyms and abbreviations required for accurate interpretation of the Configuration Management Plan document . To provide this information, you can use the links to the project dictionary. | We often have to deal with the fact that this section is either ignored altogether or does not attach much importance to it. However, the glossary is an integral and integral part of ANY document, the plan of the Criminal Code, including. All terms of the Criminal Code and the product under development should be reflected and explained here. It must be remembered that a good glossary will allow everyone to be in the same terminological space. Questions :
|
1.4 References | References | This subsection presents a complete list of all documents referenced elsewhere in the Configuration Management Plan . Each document is identified by its title, report number (if any), date and organization that published it. Specify the source from which the specified documents can be obtained. To provide this information, you can use links to applications or other documents. | A CM plan is rarely developed by itself. It is part of the regulatory and methodological support of the project. There is no sense in terms of repeating verbatim sections from other documents. It is easier to form a link to the document, and in this section, specify all sources used (including RUP documents, standards, international and industry standards). Questions :
|
1.5 Review | Overview | Overview of the document by section | It should be understood that not all project participants will read the document from cover to cover. The review is necessary so that later you can read the sections that are currently needed for this role. |
2. Configuration management software | Software Configuration Management | One of the main sections. Describes all the technical and technological aspects of applying a management company in a project or organization. The number of subsections and their nesting may differ from those given below. | |
2.1 Organization, distribution of responsibility and interaction | Organization, Responsibilities and Interfaces | Указывается, кто будет ответственным за выполнение различных задач конфигурационного управления , описанных в ходе процессов конфигурационного управления | Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о разработке, распределенной по нескольким географическим точкам. Эффективное дополнение данного раздела - подраздел, описывающий политику доступа. Это может быть простая таблица, в которой описывается в терминах применяемых средств автоматизации процесса, что можно выполнять отдельному участнику проекту, а что для него запрещено. Обычно для этого выбирают способ описания либо только доступных операций, либо только запрещен-ных.В дальнейшем данная политика перекладывается в средства реализации, где выставляются соответствующие разрешения и запрещения. В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика. Questions :
|
2.2 Toolkit, work environment and infrastructure | Tools, Environment and Infrastructure | We consider the working environment and software that will be used in the performance of configuration management functions during the life cycle of a project or software product. Describes the tools and procedures that need to be used for version control of configuration management objects created during the life cycle of a project or software product. Questions to consider when setting up the configuration management work environment are the estimated data size for the software product; distribution of the working team; location of servers and workers stations | A detailed description of this item will allow, for a start, to understand for ourselves what development tools are used in a company (often no one, except the head of the development department, presents a complete list of means before the introduction into a large company). Full accounting of funds is also needed in order to determine the methods of integrating development tools with CM tools, because it is known that any CM tool has limited capabilities for integration with development tools. The task of the CM manager and the administrator in this case is to select third-party developments that either make the integration more complete, or simply add the integration itself into the development tool used + in the CM tool. It is equally important to describe the execution environment. Not all CM tools are equally placed on all platforms. There may be features.Alternatively: Linux server, Windows clients. Not all assets of the Criminal Code are able to work in such an environment, which must be considered when choosing a means.Questions :
|
3. Configuration Management Program | The Configuration Management Program | ||
3.1 Configuration Identification | Configuration Identification | Questions :
| |
3.1.1 Identification methods | Identification Methods | Describes how the artifacts of a project or software product are named, labeled and numbered. The identification scheme should cover the hardware, system software, products of external developers and all the artifacts of the developed application specified in the directory structure of the software product; for example, models, plans, components, test software, results and data, executable files, etc. | A very important point in which you need to describe all the rules for naming objects of the Criminal Code. Also, the project directory structure should be detailed here. Usually, at the time of implementation of the Criminal Code, the project directory structure develops historically, often spontaneously. The purpose of the description is to develop a new, more efficient structure. Practice shows that a person may see vulnerable or inefficient places during the restoration of the structure. |
3.1.2 Basic project versions | Project Baselines | The base versions provide the official standard on which the subsequent work is based and for which only authorized changes are made. Describes at which point in the life cycle of a project or product base versions should be created. The most common basic versions should be at the end of each of the phases of the survey, project design, system construction and transfer to operation. Basic versions can also be created at the end of iterations within different phases or even more often. Determines who can create the basic versions and what is included in them (usually it is an integrator, but it can be different) | It describes how the work itself will take place in the CM tool: how labels will be put, how releases will be issued, how many branches will be used for the project and what will be the branches. Pay special attention to this item - without it effective work is impossible. When working on an item, regional fragmentation of the team is taken into account (the composition of teams, the number of regions affects), the intensity of changes, the number of releases issued per unit of time. Accordingly, depending on these indicators, the most effective way to manage configurations is selected, which is reflected in this section. Questions :
|
3.2 Control configurations and changes | Configuration and Change Control | As is known, the CM process consists of two parts: change management and version control. Change management is an integral and important part of the process. It is necessary to manage any changes: from user requests to corrected defects. This section contains a complete description of all change requests, including attributes and life cycle. A detailed description is the key to a successful UK process. It is often used to keep track of significant events in a project with various types of notifications. As a rule, these are e-mail notifications (for example, when correcting an error, the tester receives a notification and can start testing). Specify all types of notifications that are used in the project. Questions :
| |
3.2.1 Отработка и утверждение запросов на изменение | Change Request Processing and Approval | Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений | Определяются типы запросов. Как правило, это дефект, запрос на расширение, задача и заявка. Состав типов может существенно меняться, главное - не сводить все управление изменениями к одному типу запросов (очень часто, кроме как дефектами компании, ничем не управляют) |
3.2.2 Группа управления изменениями | Change Control Board (CCB) | Описывается, кто входит в состав группы управления изменениями, и процедуры, которым она следует, для отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы | The decision to accept a request from the user, the decision to implement a new technical idea is almost never made by one person. In any company, this is a group of people. In terms of standards, this group is called CER. In this section, it is necessary to describe the composition of the participants (as a rule, it is an analyst or director, the leader of the development team, the leader of the test team and a representative of the marketing department) and the frequency of meetings. For example, a group of CERs can meet every week (according to the regulations) or according to the need that has arisen (not recommended). Questions :
|
3.3 Considering Configuration Status | Configuration Status Accounting | ||
3.3.1 Storage of project materials and release releases | Project Media Storage and Release Process | Describes storage rules and reservation procedures, contingency actions. The release release process includes their content, who they are for, and whether there are any known problems and installation instructions (can be put in a separate appendix) | |
3.3.2 Reports and audits | Reports and Aidits | The content, format and purpose of the requested reports and configuration status checks are reviewed. Reports are used to obtain data on the quality of a software product at any given time in the life cycle of a software product or project. Defect reporting based on change requests can provide some convenient indicators of quality and therefore caution warn? Because to warn managers and developers of anything from certain critical areas of the development process. | Reports should be given special attention. Only the reports can trace the progress of work. Here it is necessary to define reports on the roles of the project participants and describe their format. It is also recommended to formulate a schedule for collecting a report, that is, how often metrics are collected (in real time, once a day ..., etc.). It is advisable to highlight different types of reports and the frequency of collecting their metrics. Questions :
Reports Questions :
|
3.3.3 Documentation | Documents | Section defines methods and types of documents. | |
3.3.3.1 Version Description | \ eision Description | This document describes discs, CDs, or other media used for software delivery. This section also defines the list of documents supplied with the software version and available to end users. | Approximate list of documents:
This item may contain the basic rules for the formation of documents, reflect the method of issuing documents (manual, automatic). Requirements for the paperwork and document templates should be included in the annex to the CM plan. The list of documents listed refers to the release of the PS for each version, release, patch. Depending on the chosen model of release, the composition of documents, as well as their detail, may vary. |
3.3.3.2 Documenting the process | CM Documents | General documents are required in cases when the product is developed for large organizations, as well as in cases when the product is a software / hardware complex. | Model documents for this section:
Requirements for the paperwork and document templates should be included in the annex to the CM plan |
4. Stages | Milestones | The stages of work for the customer and internal, related to the work on the Criminal Code for a software product or a project are considered in detail. This section usually includes a detailed description of when the configuration management plan itself can be modified . | Depending on the model chosen, the content of the stages may change. It is recommended to describe what is carried out in the Criminal Code, depending on the project phase. |
5. Training and resources | Training and Resources | It considers the tools, personnel and training required to implement the tasks described in the plan. | |
6. Subcontractors and software control by suppliers | Subcontractor and Vendor Software Control | Describes how to integrate software developed outside the project management company environment. | Subcontractors may be involved in project work. This section describes how to work with a subcontractor. Questions :
|
Applications | The composition of the application is not defined by standards. Usually includes such documents as:
| Be guided by the expediency of making certain changes. Evaluate whether everything got into the main sections of the plan. If the main sections have grown too large, you may need to extract some of the information from them into the application. |
Comments
To leave a comment
software project management
Terms: software project management