You get a bonus - 1 coin for daily activity. Now you have 1 coin

13. IT project configuration management

Lecture




13.1. Identifying Project Configuration Management Objects

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]:

  • developing plans and procedures for the configuration management process;
  • ensuring the implementation of plans and documenting the results;
  • definition of the basic provisions of the project and the content of releases;
  • organization and control of the procedures of the configuration management process;
  • control of the configuration management information storage tools.

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.

(ii) Procedure for creating a new configuration item

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.

(iii) Project Infrastructure

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:

  • workplaces;
  • network;
  • systems (application servers and databases). It is recommended to assign a team leader.

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.

(iv) Example of infrastructure requirements for a project office (fragment)

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:

  • a separate desk;
  • a chair;
  • two electrical outlets;
  • one outlet for access to the information network;
  • one outlet for access to the telephone network (for additional justification);
  • telephone set (for additional justification). Each office space should be provided with:
  • network laser black and white printer with the possibility of two-sided printing on A4 sheets and a print speed of at least 30 pages per minute;
  • hanger for outerwear of all employees, located in the working room;
  • one cabinet for documents.

The project working group should be allocated for use a working room for negotiations, equipped with:

  • meeting table;
  • chairs;
  • flip chart;
  • screen and projector for meetings with 10 people.

Providing members of the project working group with personal computers :

  • the contractor, if possible, involves in the work on the project staff provided with portable computers;
  • the customer’s employees involved in the project work are provided by the customer with personal computers as soon as possible;
  • requirements for the characteristics of personal computers can be specified depending on the specific tasks performed by the employee.

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

  • The customer provides the allocation of a disk sharing resource for organizing a library of project documentation and a library of software applications used by the DLS creation project.
  • The customer ensures the allocation of a working subnet for the organization of interaction between members of the project working group.
  • The customer provides access to the Internet for all members of the project team.
  • The customer ensures the allocation of an email address to each member of the project team.
  • The customer ensures the availability of telephone communication with the possibility of access to the city telephone network for each member of the project working group from the contractor (for additional justification).

Mode and place of work of the members of the joint project working group

  • Work on the project is performed by employees of the contractor or subcontractor on the territory of the customer and / or on the territory of the contractor / subcontractor.
  • The beginning of the working day for members of the project team is 9 hours 00 minutes, the end of the working day is 18 hours 00 minutes, the duration of the lunch break is 1 hour in the time interval from 12:00 to 15:00. Project managers from the customer and the contractor have the right to change the mode of operation for employees involved in the project, subject to the mutual agreement of such changes.
  • The customer provides the opportunity for the contractor’s employees to work on the customer’s territory in the evening and at night, as well as on weekends and public holidays (if necessary, round-the-clock work is possible) upon prior request from the contractor.

(v) Example of project infrastructure creation procedure

To create the infrastructure you need:

  • ensure the supply of material resources - required to order or request the necessary resources;
  • arrange equipment installation - ensure delivery, install and test equipment;
  • provide equipment service maintenance - develop a service schedule;
  • Test the work environment for compatibility with requirements for functionality, compatibility and availability.

13.2. Formation of the project configuration baseline

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.

13.3. Project Configuration Management Organization

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.

13.4. Organization of documenting the status of 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:

  • Microsoft Word 2010 - for the preparation of the text of the project documents;
  • Microsoft Project 2010 - for the preparation of project plans;
  • Visio 2010 - for the graphic description of business processes.

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:

  • What is the characteristic of controlled configuration elements?
  • What should high-level interfaces manage?
  • What is the project time frame?
  • What are the available resources?
  • What are controlled entities?

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 :

  • Definitions are easy and understandable to all project participants?
  • Is there a list that can be easily referenced?
  • Is it necessary to define this term?

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 :

  • Are the policies, already used in the organization, applied in terms of regulations?
  • Is the link really necessary in the plan?

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 :

  • What are the state organization's capabilities to perform CM operations?
  • What is the management structure?
  • What is the management style?
  • Who will be responsible for the operations?
  • What organizational changes can occur during the life of a CM plan?
  • What are the plans to support the current organizational structure?
  • What level of support is needed to implement a CM plan?
  • Is this the only project for management, or does management manage several projects at the same time?
  • How is the responsibility distributed in case of emergency situations?
  • Are there features for this project that may affect the business?
  • What actions does the CER team perform in project management when planning?
  • Are the roles of the participants described transparently?

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 :

  • What are the organizational interfaces?
  • How do processes interact?
  • What is the list of processes for interaction?
  • What are the interfaces between the automation tools used?
  • What is the relationship between them?
  • Is there a hardware dependency?
  • Where are the documents governing the process defined?
  • Are they approved?
  • What are the procedures for making changes to these documents?
  • What are the resources involved (human, equipment)?

3. Configuration Management Program

The Configuration Management Program

3.1 Configuration Identification

Configuration Identification

Questions :

  • Are standard identification methods available?
  • What is the used scheme for the identification of CM objects?
  • Is software and hardware identification (for embedded systems) related?
  • What specifications and management plans should be identified?
  • Is a special identification scheme needed to track third party PS?
  • Is there a difference in the identification of elements depending on the type of application?
  • Are there subtypes (for example, the C ++ compiler can work with files with, avg, h, hpp and others)?
  • Are automated test scripts identified and stored?

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 :

  • What is the basic version selection method?
  • Are the basic versions for all elements based on the same rules?
  • Who allows the creation of basic versions?
  • Who physically creates the basic version?
  • How and by what template are the base versions created?
  • How is the promotion of basic versions?
  • How and by whom is the baseline checked?
  • What is the frequency of inspections?
  • Is the existing (established) label and branch naming standard used? - Is there a hierarchy between the objects? Which one?

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 :

  • What types of requests are planned to use in the CM process?
  • Каков полный цикл запросов на изменения?
  • Будет ли храниться в системе УК справочная информация, или необходимо подключаться к имеющейся справочной информации?
  • В какой информации, возможно, будут нуждаться члены ССВ?
  • Каковы основные ожидания от автоматизации управления изменениями?
  • При иерархической проектной структуре как будут приниматься решения по запросу?
  • Необходимо ли управлять всеми запросами на изменения?
  • Какой уровень детальности управления будет выбран (сколько шагов/этапов)?
  • Обеспечивается ли отслеживание изменений в исходных текстах (есть ли связь между изменениями на верхнем уровнем и описанием изменений на уровне файлов)?
  • Как исходный текст ассоциируется с запросом?
  • Будет ли применена система оповещений ?

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 :

  • What are the authority limits of the group?
  • One group for all projects or several groups, each for their own project?
  • If several, how do they cooperate with each other?
  • Is there a hierarchy of CERs?
  • Who is responsible for communication between CERs?
  • Will the CM system support special requests for organizing meetings and issuing protocols on results?
  • Is there a need to develop regulations to limit the actions of the group (strict regulations for meetings with a high degree of formalism)?
  • How do privilege levels differ in a group?
  • Does the introduction of a CER group change the established decision-making process in an organization?
  • Have all key players been included in the CER, including the QM manager, the project manager, the testers leader, the developers leader, and the architects?
  • What are the procedures for resolving disagreements (release of the protocol of disagreements or something else)?
  • Is this procedure automated?

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 :

  • Is there a need for more than one revision for each basic version?
  • Are subcontractors involved in the audit?

Reports Questions :

  • What metrics are collected during the project?
  • What types of reports do I need to have?
  • What are the ways to present reporting information?
  • Are there external reporting documents for clients?
  • Are the reports differentiated depending on the type of role performed by the participant in the project ?
  • Are reports available?
  • What are the formal steps to get reports?
  • What types of notification messages will apply?
  • Are project trends tracked? What reports?
  • How are records kept (statically, dynamically)?
  • What tools are used to receive reports (it is allowed to use any number of systems to obtain reliable and understandable information on the progress of the project)?

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:

  • release archive with description (Release Media);
  • release notes;
  • description of the functions;
  • a list of solved issues in the release;
  • list of new features;
  • software installation instructions;
  • inventory inventory.

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:

  • description of the system in which the PS is used;
  • a description of the administrative management of the software system;
  • system administrator's manual;
  • user's manual;
  • passport on the substation (general information about the substation, the main characteristics, completeness, acts of acceptance and decommissioning ..., etc.).

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 :

  • Is development only in one organization or in both?
  • What are the procedures for correcting defects in the developed product?
  • Are they automated (fully or partially)?
  • What changes can be made to the customer in the source code after receiving the product?
  • Is the subcontractor informed and to what extent?
  • When and how are the audits performed?
  • What toolkit is used by the customer and subcontractor?
  • Are additional synchronization modules needed (for those cases where the customer and the contractor use different CM systems from different manufacturers)?
  • How is a subcontractor controlled?
  • Who is responsible for working with the subcontractor?
  • Does the subcontractor work according to its processes or does the customer require it to work on its own?
  • How are conflicts resolved?
  • Is the subcontractor allowed to fully assemble the product at home, or does the customer allocate a stand for assembly on its territory?
  • Is the subcontractor allowed to the customer reference information (access to real databases, directories)?

Applications

The composition of the application is not defined by standards. Usually includes such documents as:

  • regulations;
  • instructions on the use of CMs (both user and administrative);
  • various methodological manuals;
  • training plans;
  • instructions for installing and administering UKT tools.

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
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

software project management

Terms: software project management