ГОСТ Р 56715.4-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных.
ГОСТ Р 56715.4-2015
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРОЕКТНЫЙ МЕНЕДЖМЕНТ. СИСТЕМЫ ПРОЕКТНОГО МЕНЕДЖМЕНТА
Часть 4
Данные и модель данных
Project management. Project management systems. Part 4. Data, data model
ОКС 03.100.40
Дата введения 2016-07-01
Предисловие
1 ПОДГОТОВЛЕН Автономной некоммерческой организацией "Международная академия менеджмента и качества бизнеса" (АНО "Международная академия качества бизнеса") на основе собственного перевода на русский язык немецкоязычной версии стандарта, указанного в пункте 4, совместно с Закрытым акционерным обществом "Проектная ПРАКТИКА" (ЗАО "Проектная ПРАКТИКА") при участии Открытого акционерного общества "Научно-исследовательский центр контроля и диагностики технических систем" (АО "НИЦ КД")
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 17 ноября 2015 г. N 1827-ст
4 Настоящий стандарт идентичен стандарту ДИН 69901-4:2009* "Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных" (DIN 69901 -4:2009 "Project management - Project management systems - Part 4: Data, data model", IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
6 ПЕРЕИЗДАНИЕ. Февраль 2020 г.
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Настоящий стандарт разработан рабочим комитетом NA 147-00-04 АА "Техника сетевого планирования и проектный менеджмент" NA 147 (NQSZ).
Комплекс национальных стандартов ДИН 69901 имеет общий заголовок "Проектный менеджмент. Системы проектного менеджмента" и состоит из следующих частей:
- Часть 1: Основные положения;
- Часть 2: Процессы и процессная модель;
- Часть 3: Методы;
- Часть 4: Данные и модель данных;
- Часть 5: Термины и определения.
Разработанные на основе техники сетевого планирования и неоднократно переизданные национальные стандарты по проектному менеджменту ДИН 69901, ДИН 69902, ДИН 69903, ДИН 69904 и ДИН 69905 прошли этапы обобщения, реструктуризации и обновления в соответствии с актуальными условиями и существенными деталями и нашли свое отражение в частях комплекса стандартов ДИН 69901. Ядром новой системы стандартов является процессная модель системы проектного менеджмента. Комплекс стандартов по проектному менеджменту содержит терминологию из различных стандартов в данной области и устанавливает соответствующую модель данных. Рисунок 1 показывает взаимосвязи между отдельными частями комплекса стандартов ДИН 69901.
|
 |
Рисунок 1 - Взаимосвязи между отдельными частями ДИН 69901
Настоящий стандарт представлен в форме, удобной для пользования всеми заинтересованными сторонами на международном, региональном, национальном или муниципальном уровнях. Настоящий стандарт предназначен для использования вместе с национальными, международными стандартами или руководствами, касающимися деятельности организации в области проектного менеджмента, или в процессе их подготовки.
Выполнение требований, установленных в настоящем стандарте, является добровольным, оно предназначено для поддержки деятельности организации в области проектного менеджмента.
________________
1 Область применения
Настоящий стандарт устанавливает модель данных программного обеспечения, применяемого в области проектного менеджмента, и может использоваться совместно с ДИН 69901-1, ДИН 69901-2, ДИН 69901-3 и ДИН 69901-5:
a) разработчиками программного обеспечения в области проектного менеджмента;
b) разработчиками программного обеспечения, применяемого для обмена данными с другими системами в области проектного менеджмента;
c) организациями, которые хотят внедрить, поддерживать и улучшить свое программное обеспечение в области проектного менеджмента;
d) всеми лицами, в составе организации и/или вне ее, кто проводит консультации в отношении выбора подходящего программного обеспечения для системы проектного менеджмента.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения).
DIN 69900, Project management. Project network techniques. Descriptions and concepts (Проектный менеджмент. Техника сетевого планирования. Термины и определения)
DIN 69901-1, Project management. Project management systems. Part 1. Fundamentals (Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения)
DIN 69901-2, Project management. Project management systems. Part 2. Processes, process model (Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель)
DIN 69901-3, Project management. Project management systems. Part 3. Methods (Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы)
DIN 69901-5, Project management. Project management systems. Part 5. Concepts (Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения)
_______________
ISO/IEC 19501:2005, Information technology. Open distributed processing. Unified Modeling Language (UML). Version 1.4.2 [Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2]
3 Термины и определения
В настоящем стандарте применены термины по ДИН 69900 и ДИН 69901-5, а также следующие термины с соответствующими определениями:
3.1 многоязычный (Multi Language, ML): Текстовый атрибут, для которого в XML-представлении должна существовать возможность ввода значений на нескольких языках.
3.2 глобальный уникальный идентификатор (Global Unique Identifier, GUID): Информационный объект, который можно однозначно идентифицировать с помощью кода.
Примечание - При этом код является однозначным не только для всех объектов одного типа, но и для всех объектов всех типов.
3.3 первичная ассоциация (Primary Association, РА): Ассоциация, которая используется в процессе генерации схемы для построения иерархической структуры XML-элементов.
3.4 совокупное значение (Aggregated Value, AGG): Атрибут, который применяется в структуре проекта.
Примечание - Его значение либо абсолютно точно ссылается на структурный элемент, либо включает в себя в качестве агрегированного значения все значения подчиненных структурных элементов.
4 Описание модели данных
4.1 Общие положения
4.1.1 Предназначение модели данных
Представленная в настоящем стандарте модель данных описывает на профессиональном уровне элементарные структуры данных проектного менеджмента. Модель данных можно использовать для:
a) архивирования данных проектного менеджмента;
b) обмена данными проектного менеджмента между организациями и различными системами программного обеспечения;
c) спецификации требований к программному обеспечению проектного менеджмента (в качестве исходных данных).
4.1.2 Представление модели данных
Представление модели данных осуществляется вербально и дополняется диаграммами (немецкие соответствия английских текстов см. в таблицах A.1-A.12). Названия элементов и их описание находятся в таблицах 1-12. Диаграммы соответствуют положениям ИСО/МЭК 19501 "Унифицированный язык моделирования (UML)". Они представляют собой базовые элементы данных (классы) и выражают их с помощью соответствующих подэлементов (атрибутов), которые сами не являются объектами стандартизации. Специфичные для отрасли, предприятия или проекта расширения возможны путем добавления других классов и/или атрибутов.
Из 13 типов UML-диаграмм (см. рисунки 2-13) для создания модели данных используются только диаграммы классов. К применяемым языковым конструкциям относятся пакеты, классы, атрибуты, ассоциации, специализации и параметры. Все конструкции используются в соответствии со стандартом. Тем не менее используются некоторые специфичные параметры:
- ML (англ.: Multi Language).
Этот параметр характеризует текстовые атрибуты, для которых в XML-представлении должно быть разрешено занесение в память значений на нескольких языках. Так, например, станет возможным указывать имя проекта более чем на одном языке;
- GUID (англ.: Global Unique Identifier).
Этот параметр характеризует классы, которые представляют собой специализации класса GUID-Object. Класс GUID описывает информационный объект, который можно однозначно идентифицировать с помощью кода.
Примечание - При этом код является однозначным не только для всех объектов одного типа, но и для всех объектов всех типов;
- РА (англ.: Primary Association).
Этот параметр используется для обозначения ассоциаций, которые в рамках генерации схемы используются для построения иерархической структуры XML-элементов;
- AGG (англ.: Aggregated Value).
Этот параметр используется только для атрибутов, которые применяются в рамках структуры проекта. Атрибуты с этим параметром могут сохраняться в двух вариантах: как относящееся к процессу значение, которое точно ссылается на структурный элемент, и как агрегированное значение, которое дополнительно включает все подчиненные структурные элементы. Этот параметр можно использовать со ссылкой на классы. В этом случае он действует для всех атрибутов класса.
4.1.3 Правила присвоения имени
Элементам данных присваиваются английские и русские названия. Однозначные согласованные названия приведены ниже.
Элементы данных называются существительными и всегда используется в единственном числе. Элементы данных могут называться также двумя существительными, при этом, если возможно, для определения иерархии понятий используется позиция (порядок следования) существительного. Так, существует, например, иерархическое отношение между элементами данных Initiative (объект управления) и InitiativeGroup (группа объектов управления). Это отношение можно определить только по одному названию элементов. Для лучшего понимания присвоение имени из нескольких существительных происходит с использованием дефисов.
Для технического использования спецификатор поля данных указывается на английском языке, который следует тем же правилам, но дефисы для структурирования отсутствуют. Вместо этого для удобства чтения английских спецификаторов полей данных используется написание с заглавной/строчной буквы.
4.2 Исходные данные проекта
|
 |
Рисунок 2 - Исходные данные проекта
В модели данных с различной степенью детализации представлены результаты моделирования единиц исполнения задания с помощью элемента Initiative (объект управления). Для построения структурного плана проекта объекты могут располагаться в виде иерархии. Кроме того, иерархия предназначена для распределения проектов по программам и портфелям проектов.
Благодаря распределению объектов по типам объектов можно определить, о каких единицах исполнения задания идет речь. Так, например, могут различаться программы, проекты, пакеты работ и процессы.
Элемент InitiativeStatusType (тип статуса объекта) выражает, в каком состоянии или статусе находится объект. Для отдельных типов объектов могут быть определены различные типы статуса объекта. Если переход между состояниями (например, смена фаз проекта) требует определенного разрешения, то это устанавливается типом элемента InitiativeStatusApproval (одобрение статуса объекта). Он представляет собой специализацию элемента GenericApproval (одобрение общее). Одобрение может сопровождаться соответствующими документами [элемент Document (документ)].
Элемент InitiativeGroup (группа объектов управления) предназначен для объединения объектов в специальные группы. При этом следует учитывать, что каждая группа может охватывать несколько объектов. И наоборот, каждый объект может охватывать (принадлежать) нескольким группам.
Таблица 1 - Названия элементов и их описания для структуры данных - исходные данные проекта
|
|
Название элемента (название поля данных) | Описание |
Документ (Document) | См. 4.13 |
Одобрение общее (GenericApproval) | Элемент предназначен для хранения общей информации о приемке, одобрении или контроле (проверке) объекта |
Объект (Initiative) | Элемент описывает любую единицу исполнения задания как часть структурного плана проекта. Он также может определять программу и портфель проекта. Результаты, такие как контрольные точки, также могут определяться элементом "Объект", причем используются только данные, значимые для события |
Группа объектов (InitiativeGroup) | С помощью этого элемента можно соединить объекты в группы. Эти группы, в свою очередь, могут быть подчинены одному объекту. Такая группировка может быть необходимой для создания отчетности или графического изображения планов проекта |
Одобрение статуса объекта (InitiativeStatusApproval) | Элемент позволяет хранить информацию о статусах объекта. Таким образом, можно документировать решение (приемку), которое ведет к изменению статуса |
Тип статуса объекта (InitiativeStatusType) | Элемент описывает различные состояния (статусы), которые могут быть определены для объекта. Таким образом, выражается, в какой фазе жизненного цикла или на каком этапе реализации находится объект. Для каждого типа объекта могут быть определены различные статусы |
Тип объекта (InitiativeType) | Элемент позволяет определять различные типы объектов. Он позволяет, например, осуществлять дифференцирование на пакеты работ и проекты. Таким образом, пользователь всегда может определить для себя любые типы объектов |
4.3 Планирование продукта и результата
|
 |
Рисунок 3 - Планирование продукта и результата
В модели данных результат проекта может храниться в форме структуры продукта. Структура продукта состоит из элементов продукта (ProductElement), которые могут быть организованы в виде иерархии с помощью подэлементов (SubElement). Дополнительно могут учитываться зависимости между элементами продукта. У каждого элемента продукта могут быть различные версии элемента продукта (ProductElementVersion). Как для элементов продукта, так и для версии элемента продукта назначаются ответственные сотрудники (Staff).
По каждому объекту может регистрироваться любое количество запросов на изменение (ChangeRequest), между ними могут иметься зависимости. Запросы на изменение могут касаться элементов продукта или версии элемента продукта. Одновременно они соотносятся с одним объектом (Initiative), как правило, проектом. Если запрос на изменение рассматривается как единица исполнения задачи (например, если проводится соответствующий учет затрат), то может быть прикреплен соответствующий объект.
Таблица 2 - Названия элементов и их описание для структуры данных - планирование продукта и результата
|
|
Название элемента (название поля данных) | Описание |
Запрос на изменение (ChangeRequest) | С помощью запросов на изменение лицо, заинтересованное в проекте, документально выражает желание внести изменение в информацию о результате проекта или ходе его реализации. В качестве альтернативы с помощью этой структуры данных могут отображаться также запросы на сервис и поддержку |
Сотрудники (Staff) | См. 4.6 |
Элемент продукта (ProductElement) | Элемент описывает структуру результата проекта. Отдельные элементы могут иерархически располагаться в форме схемы Гозинто, чтобы можно было увидеть вышестоящие и нижестоящие элементы структуры продукта. Кроме того, может отображаться зависимость между элементами |
Версия элемента продукта (ProductElementVersion) | В модели данных можно к одному отдельному элементу продукта прилагать различные его версии (поддерживается версионность), чтобы документировать процесс развития и сохранять промежуточные состояния |
Подэлемент (SubElement) | С помощью этого элемента определяется взаимосвязь (количественная) нижестоящего элемента продукта с вышестоящим элементом продукта |
4.4 Управление закупками
|
 |
Рисунок 4 - Управление закупками
В модели данных сохраняются основные данные выполнения заказа. Элемент InitiativeContractData (данные договора объекта) предназначен для сохранения важнейших данных по коммерческим предложениям, заказам и счетам соответствующего Initiative (объекта управления). Кроме того, может учитываться соответствующая информация о счетах [элемент Initiativelnvoice (счет объекта)]. К счету, в свою очередь, могут прикрепляться отдельные Transactionltem (позиции бухгалтерской проводки), которые вытекают из счета.
Для каждого объекта заказчик и подрядчик устанавливают соответствие с конкретным Resource (ресурсом), т.е. могут быть определены ресурсы, которые рассматриваются в качестве заказчика или подрядчика.
Таблица 3 - Названия элементов и их описание для структуры данных - управление закупками
|
|
Название элемента (название поля данных) | Описание |
Позиция бухгалтерской проводки (Transactionltem) | См. 4.11 |
Ресурс (Resource) | См. 4.6 |
Объект (Initiative) | См. 4.2 |
Счет объекта (Initiativelnvoice) | С помощью этого элемента может регистрироваться некоторая информация о счете, выставленном заказчику для конкретного объекта. В одном блоке "данные договора объекта" могут сохраняться несколько счетов |
Данные договора объекта (InitiativeContractData) | Элемент содержит всю информацию по объекту, которая касается исполнения коммерческого предложения, заказа или счета |
4.5 Управление сроками
|
 |
Рисунок 5 - Управление сроками
Построение сети процессов представляется в модели данных с помощью элемента Initiative (объект) и указания предшествующих и последующих процессов. При этом элемент InitiativePrecedence (отношения взаимозависимости объекта) используется для того, чтобы более подробно специфицировать взаимозависимости (например, здесь можно ввести интервалы времени). Отношения взаимозависимостей объекта можно дополнить календарем, который содержит информацию о том, как следует интерпретировать возможные интервалы времени. Такой календарь можно определить для объекта управления, в этом случае он определяет, как следует рассчитывать продолжительность существования объекта в целом.
Связанные процессы представляются путем ссылки/ссылкой объекта управления (связанного процесса) на другие объекты управления. Они являются объектами, которые определяют другие связанные процессы и устанавливают их продолжительность.
Результат планирования сроков учитывается с помощью элемента InitiativeSchedulingData (данные сроков объекта). Кроме того, этот элемент содержит касающуюся объекта информацию по управлению процессом планирования сроков.
Таблица 4 - Названия элементов и их описание для структуры данных - управление сроками
|
|
Название элемента (название поля данных) | Описание |
Календарь (Calendar) | См. 4.6 |
Объект (Initiative) | См. 4.2 |
Отношения взаимозависимости объектов (InitiativePrecedence) | Элемент отображает всю информацию, которая необходима для построения сетевого графика. В каждом случае он устанавливает отношение между двумя объектами и содержит информацию, как, например, тип отношений взаимозависимости или возможные интервалы времени |
Данные сроков объекта (InitiativeSchedulingData) | Элемент содержит всю информацию по объекту, которая рассчитывается с помощью техники сетевого планирования или управляет техникой сетевого планирования |
4.6 Исходные данные о ресурсах
|
 |
Рисунок 6 - Исходные данные о ресурсах
Ресурсы представляются элементом Resource (ресурсы). Ресурсы могут располагаться в виде иерархии, чтобы показать, что ресурс содержит другой ресурс (вложенность ресурсов).
Каждый ресурс может быть отнесен к одному или нескольким ResourceType (типам ресурсов), которые объединяют ресурсы в массивы ресурсов одного вида. Типы ресурсов можно расположить в виде иерархии. В этом случае иерархия представляет собой конкретизацию критериев, по которым осуществляется группировка ресурсов.
Каждый ресурс может в зависимости от времени (сроков) привязываться к календарю (Calendar) [элемент ResourceCalendarAssignment (привязка ресурсов к календарю)]. Календарь состоит из нескольких календарных записей (CalendarEntry), которые относятся к типам CalendarEntryType (тип записи в календаре). С помощью типа записи в календаре определяется, как календарная запись должна интерпретироваться в части содержания.
Распределение ресурсов (взаимное соответствие задач и ресурсов) может осуществляться с помощью элементов ResourceAssignmentProfile (профиль распределения ресурсов). Они определяют, как запланированные расходы должны быть распределены по ходу реализации проекта. Каждый ресурс проекта может быть связан с конкретным профилем. Профиль распределения ресурсов состоит из множества элементов ResourceAssignmentProfileDiscreteValue (значения профиля распределения ресурсов).
Если в контексте ресурса речь идет о Staff (сотруднике), то происходит соответствующее распределение.
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.