Секретариат

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

  • 31 октября 2013
  • 3937

Требования пользователей – это та основа, при грамотном обобщении и структурировании которой может быть построена нужная организации СЭД. Что такое управление требованиями? Обработка требований. По каким критериям можно выделить наиболее актуальные из них? Что понимается под анализом требований и как использовать их результаты? Документирование требований

Планируя работы по созданию СЭД, все мы хотим, чтобы система была полезна и востребована сотрудниками организации. Поэтому первый шаг, с которого следует начать,- сбор требований коллег и их анализ, расстановка приоритетов. Активное участие в про­цессе разработки специалистов со стороны заказчика СЭД повы­шает актуальность системы: когда работу по сбору и приоритизации требований берет на себя сотрудник организации-заказчика, шансы получить именно ту СЭД, которую вы ожидаете, возрас­тают.

© О.А. Галкина,

ведущий аналитик департамента разработки тиражных программных продуктов «БОСС-Референт» компании «Логика бизнеса 2.0»

Однако, выдвигая любые требования, надо понимать, что процесс их сбора, а особенно их аккумуляции и анализа, весьма трудоемок и требует больших временных затрат, растущих геометрически с на­коплением общей массы требований. С другой стороны, требования - это та основа, при грамотном обобщении и структурировании которой может быть построена нужная организации систе­ма. В этой статье мы попробуем ответить на сле­дующие вопросы:

• Что такое управление требованиями?

• Как обрабатывать поступающие требования?

• По каким критериям можно выделить наиболее актуальные из них?

• Как определиться, какие из требований необхо­димо в первую очередь принять в разработку, а какие можно отложить?

• Что мы понимаем под анализом требований и как использовать их результаты?


Управление требованиями - это процесс сбора поже­ланий владельцев процессов, первичная обработка и анализ этих запросов, документирование требований, определение наиболее приоритетных из них, контроль их из­менения и контроль реализации.

Во время работы на любом проекте неизбежно возникает большое количество разнообразных пожеланий к функционалу системы. Как же справиться с этим потоком запросов?

Чтобы обработать и использовать требования с максималь­ной выгодой, необходимо их:

• выявить;

• собрать;

• зафиксировать;

• проанализировать;

• максимально полезно использовать при подготовке до­кументов.

Виды требований, порядок их поступления

Первые пожелания к функционалу системы начинают возникать еще на этапе подготовки к началу проекта или на этапе пре-сейла (presale - предпродажная активность). Поступают эти запросы обычно от руководителей, инициирующих внедрение СЭД, и владельцев процессов. Такие потребности верхнего уровня помогают определить скоуп (англ. scope - сфера при­менения) - рамки будущей системы.

Помимо руководителей и ключевых участников автомати­зируемых процессов, источником требований могут являться и нормативные, и законодательные акты, стандарты, регламен­ты предприятия и другие документы.

Требования могут запрашивать как реализацию отдельных функций, так и быть общими нефункциональными требовани­ями ко всей системе.

Функциональные требования (англ. FEAT-Functional Requirements) - определяют функциональность (поведение) программной системы, которая должна быть создана раз­работчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требо­ваний и в контексте пользовательских требований.

Нефункциональные требования (англ. BR-Business Rules) -определяют критерии работы системы в целом, а не отдель­ные сценарии использования. Нефункциональные требования описывают цели и атрибуты качества, ограничения. Содержат или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоратив­ными инициативами, учетными практиками, алгоритмами вычислений и т. д. Они могут определять такие свойства системы в целом, как производительность, удобство сопро­вождения, расширяемость, надежность, условия эксплуата­ции.


Функциональные требования можно описывать в виде сценариев использования (Use Case).

Сценарий использования, вариант использования, пре­цедент или же пользовательский сценарий (англ. Use Case) -в разработке программного обеспечения и системном про­ектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рас­сматриваемой системой.

Функциональные требования могут дополняться графиче­скими моделями. Визуальное моделирование облегчает вос­приятие сложных технических документов. Обычно диаграммы разрабатываются в соответствии с общепринятыми нотация­ми - комплексом условных обозначений и правил их исполь­зования (например, UML, BPMN, IDEF0). Однако вполне до­пустимо и использование своих правил и условных обозначений, которые должны быть описаны и приложены к диаграммам.

Используя визуальное моделирование, надо помнить, что без словесного детального описания любая диаграмма, вне за­висимости от используемой нотации, смысла не имеет и может быть прочитана некорректно.

Далее требования детализируются и используются при написании таких документов, как техническое задание и тех­нический проект.

Словарь

UML (англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использую­щий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документиро­вания, в основном, программных систем.

BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) - си­стема условных обозначений (нотация) для моделирования бизнес-процессов. Последняя версия - 2.0.

IDEF0 (англ. Integrated DEFinition) - методология функционального моделирования. С по­мощью наглядного графического языка IDEF0 изучаемая система предстает перед разработ­чиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков -в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы.


Другой вариант фиксирования требований, получивший популярность в последнее время в связи с использованием методологии SCRUM, - это User Story.

SCRUM - методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. SCRUM делает акцент на качественном контроле процесса разработ­ки. Разработка программного обеспечения ведется коротки­ми итерациями. После каждой итерации происходит сдача законченной части функционала и корректировка целей проекта. Для методологии характерно упрощение в части документирования разработки.

User Story - это краткие описания требований к раз­рабатываемой системе, сформулированных как одно или более предложений на бизнес-языке пользователя.

При применении западных стандартов требования ис­пользуются при подготовке такой документации, как специ­фикация требований, концепция, комплексная модель ва­риантов использования, пользовательские истории (user story).

Какой бы способ описания вы ни выбрали, требования должны содержать понятное описание самой бизнес-ситуа­ции.

Параллельно на первом этапе сбора требований необхо­димо разработать словарь терминов (Glossary). Он позволит обеспечить одно из важнейших качеств требований - понят­ность. А главное, позволит говорить разработчикам и пользо­вателям на одном языке и избежать множества недоразумений. Зачастую под одним и тем же термином специалисты в разных областях подразумевают совершенно разное.

Таким образом, можно выделить следующие виды требо­ваний (рис. 1):

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

• Запросы пользователей (STRQ - Stake Holder Request) -первичное описание запросов, поступивших от бизнес-пользователей.

• Требования к системе (FEAT) - функциональные тре­бования к системе.

• Сценарий использования (BUC - Busyness Use Case) -описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем.

• Элементы словаря (GLS - Glossary) - определение тер­минов, используемых при описании требований.

• Нефункциональные требования (BR - Business Rules) -требования к работе системы в целом: цели и атрибуты качества, ограничения.

При сборе и формулировании требований к системе не­обходимо соблюдать основные критерии их качества:

Понятность (недвусмысленность) - требование долж­но быть понятно сформулировано (исключать неодно­значное толкование).

Требование должно быть определено без использования технического жаргона. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его ин­терпретация. Определение не содержит нечетких фраз, исполь­зование отрицательных и составных утверждений запрещено.

Завершенность - требование полностью определено в одном месте и вся необходимая информация при­сутствует.

Атомарность (неделимость) - требование нельзя раз­делить на более мелкие без потери завершенности.

Единичность - требование описывает одну и только одну вещь.

Уникальность - каждое требование должно однознач­но идентифицироваться (должен использоваться уни­кальный идентификатор требования).

Полнота - требование должно быть определено для всех возможных ситуаций.

Непротиворечивость (последовательность) - требо­вание не противоречит другим требованиям и докумен­тации в целом.

Достаточность детализации - необходимо соблюдать достаточную степень детализации, для того чтобы была возможность завершить реализацию требования.

Прослеживаемость - требование соответствует деловым нуждам, как заявлено заинтересованными лицами и задокументировано.

Проверяемость - реализация требования может быть проверена (протестирована).

Источники требований

Принимая требования, следует в обязательном порядке фик­сировать источник требований. Для адекватности требований также важно, чтобы источником требования являлся компе­тентный сотрудник - руководитель или владелец продукта, владелец процесса, ключевой специалист.

Владелец продукта (англ. Product Owner) - это человек, отвечающий за разработку продукта при работе по методо­логии SCRUM. Как правило, это менеджер продукта для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разра­ботки. Владелец продукта - это единая точка принятия окон­чательных решений для команды в проекте.

На этапе пресейла требования верхнего уровня опреде­ляются руководством компании. Далее необходимо в ходе обследования спускаться глубже в организацию для детали­зации процессов. Как правило, при общении с руководством можно выяснить, к кому конкретно из сотрудников можно обратиться на более низком уровне, чтобы узнать детали про­цессов.

Определиться с требованиями к системе помогут и регла­менты организации, если они актуальны.

Таким образом, источниками требований являются:

• руководство (или владелец продукта);

• владельцы процессов;

• ключевые пользователи;

• документы.

Кто принимает требования

Так как требования поступают из разных источников и в ходе проекта могут меняться, то лица, принимающие их, могут быть разными. Для того чтобы соединить вместе эти потоки запросов и аккумулировать их, должно быть лицо, принимающее и структурирующее требования. Обычно это аналитик проекта.

На этапе предпроектной подготовки (пресейла) требования верхнего уровня, определяющие автоматизируемые процессы, поступают от руководства. Они фиксируются аналитиком, но могут поступать и к руководителю проекта в ходе его общения с топ-менеджерами.

Дальнейший сбор требований происходит на этапе обсле­дования аналитиком. На основании собранных требований аналитик готовит документацию по системе.

После разработки по технической документации, учитыва­ющей собранные требования, система поступает в опытную эксплуатацию. В этот момент начинают приходить новые требо­вания от непосредственных пользователей системы. Как прави­ло, если система разработана качественно, то на этапе опытной эксплуатации поступают небольшие требования по интерфейсу и запросы на расширение функциональности системы.

Очень важно с самого начала выделить сотрудника, от­ветственного за управление требованиями, и определить про­цессы по сбору требований. В противном случае требования начнут теряться. Все эти договоренности необходимо зафик­сировать в документе «План управления требованиями».

Как правило, отвечает за управления требованиями ана­литик проекта. Именно ему должны передаваться абсолютно все требования, поступающие от пользователей любого уровня, вне зависимости от того, кому эти требования из сотрудников рабочей группы проекта сообщались: продавцам, менеджерам, руководителю проекта или инженеру внедрения. Контролирует и управляет процессом сбора требований и обязательностью их передачи аналитику руководитель проекта.

Инструменты для управления требованиями

Требования, поступающие к аналитику из разных источников, надо собирать и хранить таким образом, чтобы они были до­ступны всей рабочей группе. В принципе, инструмент в про­цессе сбора требований не настолько важен как, например, дисциплина и внимательность сотрудников, принимающих требования.

Можно, например, использовать для сбора требований файл, созданный в MS Excel или MS Word. Выглядеть это будет примерно, как на рис. 2:

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

Однако при использовании приложений MS Office может возникнуть ряд проблем, связанных с тем, что такой файл не всегда доступен другим и легко может быть утерян при смене сотрудника, отвечающего за сбор требований к системе.

Кроме того, должен иметься еще ряд возможностей, которые должны обеспечивать инструменты управления требованиями.

Так, каждый запрос должен заводиться как отдельный объект. Тогда можно формировать по заданным правилам от­бора представления требований (фильтры), что позволит делать анализ. При этом можно будет проводить аналитику по этим объектам: фильтровать накопленные требования по определен­ным параметрам, просматривать их представления с заданным набором параметров, а также выгружать их в виде списков для рассмотрения рабочей группой. Помимо этого должна быть возможность связывания требований между собой.

У нас в стране принято оформлять требования в виде до­кумента, а не списка. Поэтому необходима возможность вы­грузки требований в формате определенного документа. На­пример, в виде спецификации требований. Это нужно для того, чтобы не делать двойную работу: в начале заводить требования, а потом оформлять их вручную в виде документа.

Источником требования может быть документ. В этом случае удобно хранить документ целиком, но отображать в виде отдельных требований критичные для будущего функционала СЭД части документа.

Таким образом, инструмент для управления требованиями должен обеспечивать:

• коллективный доступ разного уровня к запросам и требованиям;

• информационный обмен между сотрудниками при смене членов команды;

• хранение, возможность анализа, категоризации и структурирования массива информации в виде от­дельных сущностей (запросов или требований);

• связывание отдельных требований между собой;

• документирование;

• использование частей документов в качестве источ­ников требований;

• отслеживание статуса каждого требования.

Самое простое решение - хранить требования на корпоратив­ном ресурсе. Это может быть папка проекта на сетевом диске, или же файл с требованиями может быть выложен, например, на порта­ле организации, а необходимый уровень доступа к нему будет предо­ставлен сотрудникам, участвующим в управлении требованиями.

Однако максимально удобное управление требованиями обеспечивают специализированные системы, для этого и пред­назначенные: например, специальные программные продукты для управления требованиями компании IBM - Requisite Pro или более функциональный Rational DOORS.

Также для управления требованиями можно использовать такие продукты, как HP Requirements Management, RequirementsWin, BorlandCaliber RM, SybasePowerDesigner и другие.

Ниже на рисунке показан пример представления данных в специализированном инструменте для управления требова­ниями (рис. 3).

Управление требованиями пользователей при разработке СЭД: собираем, анализируем, используем

В специализированных системах автоматически обеспечи­вается: сохранение истории изменения требования (автор, дата, время изменения), версионность и присвоение уникального идентификатора, коллективное управление требованиями на различных уровнях доступа, централизованное хранение ин­формации, возможность анализа и построения различных пред­ставлений данных, связывания требований, автоматического формирования документации в заданном формате, «нарезания» документов на отдельные требования, трассировка исполнения.

Атрибуты требований. Сортировка требований, анализ

Для того чтобы анализировать и манипулировать требования­ми при разработке системы, следует сопроводить их атрибута­ми. Минимально необходимые для оценки атрибуты требова­ний - это стоимость (или трудоемкость) и важность. Также в вашем первичном описании поступившего запроса от заин­тересованного лица обязательно должна быть информация о сотруднике, от которого поступило требование - то есть источник требования (Ф.И.О. и должность владельца требова­ния или иной источник).

Помимо этого, нужно указывать для каждого требования уникальный идентификатор (номер запроса), дату поступле­ния требования, кто зафиксировал требование, статус, важ­ность, трудоемкость, дату рассмотрения рабочей группой проекта, принятое решение по требованию, связанные тре­бования, категорию.

В специализированных системах для управления требо­ваниями атрибуты «уникальный номер» и «автор записи» присваиваются требованиям автоматически.

Поступающие требования можно и нужно анализировать, группировать и структурировать, чтобы создать «скелет», на основании которого будет построена система.

Удобно категорировать требования по видам автоматизи­руемых процессов. Такая группировка требований позволяет увидеть структуру всей системы более ясно, чтобы использовать ее в процессе разработки.

Словарь

Трассировка - отслеживание последовательности исполнения инструкций программы; используется как метод отладки программного кода при разработке компьютерных про­грамм.

На заметку!

При получении изменений требований на этапе опытной эксплуатации их категори-рование также позволяет увидеть слабые места (не-проработанный функционал) системы.

Например, можно подразделять требования по катего­риям: «процесс работы с входящими документами», «раз­работка нового интерфейса», «администрирование и на­стройка» и т. д.

Для того чтобы манипулировать требованиями вышеопи­санным образом, удобно, если каждое требование будет фик­сироваться и оформляться как отдельный объект.

Таким образом, специализированные программные про-I дукты для управления требованиями позволяют делать анализ требований в различных разрезах.

Если проект планируется развивать, то вам стоит подумать о приобретении таких инструментов.

Формализация требований

После обработки всех запросов, их атрибутирования и анализа нужно описать непосредственно требования, которые будут реализованы в системе. Требование к реализации обычно до­статочно сильно отличается от исходного запроса пользовате­ля (STRQ). И это нормально. Описание требования к реализа­ции должно иметь формализованный характер, а зачастую аналитик или разработчик могут предложить пользователю другое, более универсальное или простое, решение проблемы, нежели то, которое видит владелец запроса.

С одним пользовательским запросом может быть связано несколько требований. А иногда требование определяется на основании сразу нескольких запросов. Все эти связи также не­обходимо отображать в атрибутах запросов и требований.

Изменение требований. Корректировка целей

Требования могут меняться на протяжении всего проекта ре­ализации системы (особенно в случае использования методо­логии SCRUM). Правильнее сказать, они не могут не меняться по ряду объективных факторов и субъективных причин.

После разработки основных проектных документов и даже по окончании разработки системы или ее частей (при работе по методологии SCRUM) поступление запросов от пользовате­лей продолжается. Большой поток новых требований или их изменений возникает, когда пользователи впервые встречают­ся лицом к лицу с системой: на этапах приемо-сдаточных ис­пытаний системы или ее частей, на опытной эксплуатации, на презентациях законченной части функционала при работе по SCRUM.

И не всегда то, что пользователи ожидали увидеть, совпа­дет с тем, что создали по их требованиям.

На этапе опытной эксплуатации начинается «притирка» пользователей и СЭД друг к другу. Возникает большое коли­чество новых запросов. Но они уже отличаются от тех, что были на предыдущих этапах пресейла и разработки.

На этапе пресейла и проектирования звучали требования достаточно высокого уровня, например, о необходимости автоматизировать те или иные процессы, а если и предъяв­лялись при этом конкретные требования низкого уровня, то они имели хаотичный характер. На этапе опытной эксплуа­тации при работе с системой уже поступают требования гораздо более детальные.

Любые изменения требований, поступившие на этапе опыт­ной эксплуатации, фиксируются в журнале опытной эксплуа­тации инженерами внедрения или аналитиками вне зависимо­сти от того, будут ли они приняты в разработку и планируется ли дальнейшее развитие системы.

Изменение требований - естественный процесс, и связано это с рядом причин.

Субъективными причинами изменения требований могут быть:

• Недостаточно глубокое и детальное обследование, полу­чение неполной информации от ключевых пользовате­лей и плохая проработка отдельных требований.

Причиной такого искажения и недоработки требований могут быть неправильно запланированные сроки на обсле­дование или низкий уровень компетенции аналитика. До­статочно часто требования меняются из-за плохой их про­работки аналитиком во время обследования или когда аналитик самостоятельно продумывает функционал будущей системы без согласования с заказчиком. При проработке требований аналитику необходимо соблюдать основные кри­терии качества требований, описанные выше.

При работе по SCRUM плохая проработка требований мо­жет быть связана с занятостью, отсутствием интереса или не­желанием брать на себя ответственность у владельца продукта. • Неправильно выделенные владельцы процессов. При­влечение к проекту в качестве ключевых лиц сотрудни­ков компании, не являющихся владельцами процесса или продукта.

Для определения владельцев процессов лучше всего об­ратиться за помощью к руководителю, курирующему раз­работку СЭД.

• Незнание руководством конкретики внутренних про­цессов, которые они планируют автоматизировать.

В этом случае, чтобы снизить риски, целесообразно при­глашать на встречи исполнителя (подрядчика) и заказчика специалистов в области делопроизводства - владельцев про­цессов, которые будут отвечать за проект.

• Неготовность потенциальных пользователей к автома­тизации или изменению процессов.

Справиться с этой проблемой помогает обучение.

Объективные причины заключаются в том, что:

• Заказчик начинает по-другому понимать и видеть про­блему в результате общения с аналитиком и обдумыва­ния требований к системе.

• В процессе реализации проекта меняются владелец продукта или владельцы процессов.

• На длительных проектах могут меняться сами процес­сы компании.

Это нормально, так как любая компания развивается, может расти и менять свою структуру и бизнес-процессы.

В случае изменения требований, поступивших от пользо­вателей, для их отбора и включения в планы разработки нужно в обязательном порядке подключать рабочую группу и владель­ца продукта. Это необходимо для проверки их целесообразности.

Итак, требования поступают как на этапе пресейла, так и на всем протяжении проекта разработки СЭД, а также ее эксплуатации.

Короче говоря, хотим мы этого или нет, но управление требованиями является непрерывным процессом на про­тяжении всего жизненного цикла системы.

Изменение требований является одним из основных рисков проекта. Однако изменения - это неизбежный процесс. Поэто­му нужно не бояться его, а подготовиться к нему заранее и пра­вильно организовать управление требованиями.

Верификация изменений требований

Для минимизации рисков проекта все изменения требований должны проходить верификацию (позднелат. verificatio - до­казательство, подтверждение, от лат. verus - истинный и facio -делаю), так как они влияют на функции системы, которые уже были обозначены в утвержденной ответственными лицами документации.

Для рассмотрения новых требований или их изменения лучше всего организовать рабочую группу из ключевых пред­ставителей заказчика - владельцев процессов и исполнителей проекта. Со стороны исполнителей проекта требования долж­ны в обязательном порядке рассматриваться аналитиками и архитектором проекта (либо разработчиком, исполняющим роль архитектора). Со стороны заказчика в рабочей группе должны присутствовать владельцы автоматизируемых про­цессов.

Документирование требований

Требования к системе служат основой для следующих видов документов, разрабатываемых в соответствии с российскими стандартами:

Техническое задание.

Техническое задание определяет назначение разрабатыва­емого объекта, функциональные требования к системе, пока­затели качества и технико-экономические требования, требо­вания к составу работ по созданию системы, требования к документации и ее состав, а также специальные требования. Является основным документом, определяющим требования к системе при разработке автоматизированных систем у нас в стране.

Технический проект.

Технический проект при необходимости разрабатывается с целью выявления окончательных технических решений (де­тальное описание именно решения, в отличие от технического задания), дающих полное представление о конструкции изделия, когда это целесообразно сделать до разработки рабочей до­кументации. Обычно технический проект требуется для раз­работки с нуля новой автоматизированной системы.

Если же обратиться к западным стандартам, то обычно требования используются при разработке таких документов, как:

Спецификация требований (Requirements Specification).

Спецификация программных требований определяет функ­циональные характеристики системы, обязательные для вы­полнения.

Use Case Model (Модели прецедентов (вариантов использования)).

Это комплексная графическая модель вариантов исполь­зования с описанием.

User Story (Пользовательская история).

Это краткие описания требований к разрабатываемой си­стеме, сформулированных как одно или более предложений на бизнес-языке пользователя; разрабатывается в соответствии с методологией SCRUM (методология для гибкой разработки программного обеспечения).

На заметку!

В случае работы по SCRUM ответственность за верифи­кацию (отбор требований) берет на себя владелец про­дукта (product owner).

Концепция (Vision).

Это документ, содержащий анализ, определение и описание высокоуровневых потребностей пользователей и функций про­дукта.

Итак, в этой статье мы попытались подробно рассказать, что такое управление требованиями, как их удобнее фиксиро­вать, обрабатывать и использовать.

Для того чтобы правильно построить процесс управления требованиями, рекомендую вам предпринять следующие под­готовительные мероприятия:

• Определиться с инструментами приема запросов и управления требованиями в соответствии с данными в этой статье рекомендациями.

• Сформировать рабочую группу проекта и распределить обязанности в команде проекта: кто будет отвечать за управление требованиями, кто будет их принимать, фиксировать и верифицировать.

• Определиться с критериями анализа и порядком реа­лизации требований.

• Решить, каким образом будет происходить верификация требований и их изменений, а также их документиро­вание.

• Описать вышеуказанные правила в документе «План управления требованиями» и согласовать его с заинте­ресованными лицами.

Организация, внедряющая СЭД, может и должна участвовать в управлении своими требованиями, даже если сам продукт раз­рабатывает специально приглашенная для этого ИТ-компания.

Очень надеюсь, что мои советы помогут вам не потерять­ся в потоке требований, максимально использовать их в раз­работке и создать актуальную систему, способную принести выгоду вашей организации.

Подписка на статьи

Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

Рекомендации по теме

Мероприятия

Мероприятия

Проверь свои знания и приобрети новые

Посмотреть

Самое выгодное предложение

Самое выгодное предложение

Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

Мы в соцсетях
Всего один шаг - и документ Ваш!

Только зарегистрированные пользователи могут скачивать материалы с сайта. Регистрация бесплатна и займет менее минуты. После нее Вы сможете загрузить документ, а также получите доступ к материалам и сервисам сайта.

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль
Я тут впервые
И получить доступ на сайт Займет минуту!
Зарегистрироваться
Сайт использует файлы cookie. Они позволяют узнавать вас и получать информацию о вашем пользовательском опыте. Это нужно, чтобы улучшать сайт. Посещая страницы сайта и предоставляя свои данные, вы позволяете нам предоставлять их сторонним партнерам. Если согласны, продолжайте пользоваться сайтом. Если нет – установите специальные настройки в браузере или обратитесь в техподдержку.