Как внедрить Cradle в проект

How to Deploy Cradle into a Project
Перевод: Юлия Куксенок

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

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

Существует шесть аспектов внедрения Cradle:

  1. Определение процесса, который Cradle должен поддерживать.
  2. Разработка схемы настройки Cradle для поддержки этого процесса.
  3. Создание Руководства по проекту или аналогичного документа, описывающего процессы и как им следовать, используя Cradle.
  4. Подготовка материалов для обучения пользователей.
  5. Обучение пользователей.
  6. Начало использования Cradle.

Мы рассмотрим первые четыре пункта в следующих подразделах.

Определение процесса, который Cradle должен поддерживать

Применение Cradle не может начаться без понимания процесса, который он должен поддерживать. В данном случае, процесс — это описание работы, которую люди должны выполнять для достижения целей проекта. У многих организаций уже есть исчерпывающее описание их процессов, как правило, в виде Плана управления системным проектированием (System Engineering Management Plan, SEMP), который разделяется на несколько частей, например:

  • План управления разработкой требований (Requirements Engineering Management Plan, REMP)
  • План управления тестированием и приемкой (Test and Evaluation Management Plan, TEAMP)
  • План управления конфигурацией (Configuration Management Plan, COMP)

Процессы системной инженерии, в том числе процессы управления требованиями, — предмет многих книг и стандартов. Мы не будем сейчас вдаваться в детали этих процессов. Важно, чтобы процессы, которые должен поддерживать Cradle были идентифицированы, т.е.:

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

identity_processes

Лучше всего разрабатывать описание процессов с помощью графических нотаций. Для этого хорошо подходят диаграммы типа Process Flow Diagrams (PFD), которые можно разрабатывать прямо в Cradle.

process_flow_diagrams

Описание процесса может быть представлено как серия фаз. Для каждой фазы задается:

  • имя;
  • описание;
  • одна или несколько целей;
  • входные данные, необходимые для выполнения этой фазы и достижения целей;
  • выходные данные, полученными на этом этапе, когда цели уже достигнуты;
  • дополнительным элементом «начальный рубеж» (start gate), т.е. рядом критериев, которые должны быть удовлетворены, прежде чем начнется фаза;
  • дополнительным элементом «конечный рубеж» (end gate), т.е. рядом критериев, которые должны быть удовлетворены, прежде чем завершится фаза.

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

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

а также:

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

Создание схемы Cradle

В Cradle термин «схема» используется для обозначения всех аспектов настройки проекта, включая:

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

Есть две части схемы:

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

Схему данных лучше всего отображать графически. erd-classДля этого хорошо подходят диаграммы сущность-связь (Entity-Relationship Diagram, ERD), которые можно создавать прямо в Cradle. Также подойдут и диаграммы классов (CD) — Cradle поддерживает и их.

Жизненный цикл информации может быть показан с помощью Диаграммы изменения состояний (STD) или Диаграммы состояний (SCD).

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

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

Схема данных

Схема данных определяет информацию, необходимую для поддержки задач во всех фазах процесса. Она создается путем изучения каждой задачи. При этом составляется список типов данных, необходимых для входов и выходов этой задачи и определяются связи между этими типами данных.

Каждый тип данных затем становится отдельным типом элемента в Cradle. Для каждого типа элемента необходимо выполнить следующие действия:

  • Перечислить атрибуты, необходимые для записи всех данных, которые нужны для каждой задачи.item_types
  • Решить, что является уникальным идентификатором для каждого элемента выбранного типа данных, и выяснить, может ли эта информация измениться, даже если сами данные останутся неизменными. Если может, то подумайте об использовании автоматически сгенерированных идентификаторов, которые остануться уникальными в любом случае. Нередкий случай когда исходная информация (например, требования) приходит из внешних документов, где для идентификации элементов используется раздел и номер пункта. Но эти номера могут измениться, если будут добавлены или удалены какие-то разделы. В таких случаях обычно используются автоматически сгенерированные идентификаторы, а атрибут Ключ используется для сохранения номера раздела или пункта.
  • Решить, могут ли элементы быть организованы в иерархии и, если могут то, какой атрибут будет содержать иерархический номер, а также выбрать тип иерархической нумерации —  обычно это точка или дефис.
  • Описать тип данных каждого атрибута и привязать его к атрибуту Cradle. В Cradle cуществует несколько вариантов атрибутов:
    • Ключ предопределенный атрибут, который по умолчанию сушествует у всех типов элементов. Он может использоваться, ittem_type_settingsчтобы сохранять иерархические номера, которые будут обновляться каждый раз, когда Cradle выполнит определенные иерархические операции, такие как переупорядочение, создание дочерних элементов и создание элементов того же уровня (с этой целью также могут использоваться коды категорий).
    • Группа предопределенный атрибут, который автоматически создается для всех типов элементов, опционально — со списком выбора значений.
    • Комментарий — предопределенный атрибут, который автоматически создается для всех типов элементов.
    • Описание — предопределенный атрибут, который автоматически создается для всех типов элементов.
    • Код категории — настраиваемый атрибут, который доступен для быстрого поиска, фильтрации в запросах, и сортировки.
    • Фрейм  — настраиваемый атрибут до 1 TB любого типа данных, хранящихся в базе данных Cradle или во внешнем файле, URL или ссылка по идентификатору на объекты в другой среде.
    • Вычисление  — атрибут, значение которого не сохраняется в базе данных, но при необходимости вычисляется на основе  значений другого числового атрибута или атрибута данных с помощью формулы, которую вы и определяете.
  • Решить, должна ли быть включена история изменений для типов элементов и при каких условиях она должна записываться.
  • Выбрать цвет текста и фона для иконок типов элементов, чтобы представлять элементы этого типа в разных местах в интерфейсе Cradle, в том числе, на узлах деревьев и веб-интерфейсах.

Можно определить любое количество кодов категорий; каждому типу элемента могут быть присвоены до 32 из этих категорий. Категории могут быть представлены в виде:

  • Текста в свободном формате.
  • Одиночного значения, выбираемого из списка значений.
  • Множественного значения, выбираемого из списка значений.
  • Даты.
  • Целого.
  • Положительного целого.
  • Вещественного числа.

Фреймы могут хранить большое количество любых типов данных. frame_typesФреймы без заданного типа хранят простой текст. Фреймы также могут хранить значение кода категории. Тип фрейма определяет тип данных, сохраненных во фрейме или на которые он дает ссылки. Типы фреймов определяются пользователем. Вместе с Cradle компания 3SL предоставляет более 30 типов фреймов, включая:

  • базовые типы данных, перечисленные выше;
  • PDF, Microsoft Office и Open Office документы;
  • изображения;
  • данные других приложений.

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

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

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

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

После того, как все типы перекрестных ссылок определены, убедитесь, что есть только один способ, с помощью которого каждый тип данных косвенно связан с любым другим типом данных. Если это не так, то проанализируйте схему и подумайте над ее изменением. Это не влияет на правильную работу Cradle, но это хорошая практика по созданию схем.

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

link_rules

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

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

Рассмотрите возможность использования Системы конфигурационного управления Cradle (CMS) в этих жизненных циклах. Например, если необходимо провести рецензирование каких-либо элементов — будет ли оно происходить внутри CMS, или отдельно.

Если необходимо управлять изменениями в элементах, как только они достигли определенной зрелости, в таком случае подходят базовые линии CMS. Если необходимо использовать CMS, тогда изменения в элементах базовой линии будут управляться с помощью Запросов на изменения (Change Requests)  и Задач на изменения (Change Tasks). Если это так, то рекомендуется, чтобы ваша схема не позволяла пользователям копировать элементы базовой линии.

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

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

В Cradle, полная схема данных будет состоять из:

  • кодов категорий;
  • типов фреймов;
  • типов элементов, включая присвоение кодов категорий и фреймов;
  • типов связей;
  • правил связей;

Функциональная схема

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

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

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

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

  • Чтобы у каждого человека был один профиль пользователя для каждой роли, которую он выполняет в проекте (при этом может использоваться механизм смены пользователя, чтобы упростить переключение профилей)
  • Чтобы пользователи получали минимальные привилегии, необходимые для их роли
  • Чтобы создавалось минимальное число команд.
  • Чтобы иерархия команд создавалась только, если для этого существует определенная причина.
  • Если используется CMS, убедитесь, что:
    • каждый рецензент обладает привилегией APPROVAL ;
    • у каждой команды есть пользователь с привилегией TEAM_LEADER;
    • если используется формальный механизм проведения изменений CMS, убедитесь, что были назначены соответствующие привилегии для управления Запросами на изменение (Change Requests) и Задачами на изменение (Change Tasks);

Если у вашего проекта есть план, решите, необходимо ли отображать Структурную декомпозицию работ (WBS) в Cradle. Например, некоторые организации включают WBS в Cradle и соединяют проектные данные (требования, риски и др.) с элементами WBS. Вы можете использовать интеграцию с MS Project, чтобы автоматически «залить» структуру работ в Cradle.

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

Решите, каким образом должно поддерживаться сотрудничество между пользователями Cradle. Сюда может входить:

  • Включение механизма дискуссий в проекте: у пользователей должна присутствовать привилегия ANNOTATE (Аннотирование)
  • Или же решите, как должны быть представлены комментарии: в качестве атрибутов элементов или как отдельные элементы с перекрестными ссылками, после этого обновите схему данных.

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

  • kpiЗапросы — для поиска информации в базе данных.
  • Представления  для отображения полученных с помощью запросов элементов в виде списков, таблиц или деревьев.
  • Формы  для отображения одиночных элементов.
  • Навигации  для выбора, какие перекрестные ссылки должны использоваться при генерации представлений или навигации по базы данных.
  • Метрики  для подсчета статистики по проекту.
  • Отчеты  для быстрого и легкого вывода результатов.
  • Графики  для представления информации по управлению данными в ходе проекта или по его завершению
  • Приборные панели — для вычисления KPI, которые помогут при управлении состоянием проекта.

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

Решите, хотите ли вы позволить пользователям или руководителям группы самим создавать определения, если да, то убедитесь, чтобы у их профилей была привилегия CREATE_DEFS.

auto-defМногие определения Cradle генерируются автоматически на основании созданной схемы данных, в частности: запросы, представления и формы. Рекомендуется, чтобы вы использовали их везде, где это возможно, потому что это значительно уменьшает работу по настройке, более того, Cradle постоянно их обновляет, после того как были внесены какие-либо изменения в схему.

auto-def-view

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

  • Создайте представления вложенных таблиц для каждого набора перекрестных ссылок. Будут необходимы 2 представления, по одному с каждой стороны связи.
    nested_views
  • Создайте многоуровневые или транзитивные представления вложенных таблиц для каждых косвенных связей между типами элементов, которые являются значимыми для проекта. Будут необходимы 2 представления, по одному с каждой стороны связи.
  • Подумайте над созданием навигации для каждого из ваших типов связей. Это особенно важно, если с типом элементов связано несколько типов связей, в этом случае навигации, которые будут  выделять один тип связи  будут особенно полезны.
  • Для каждого из вышеупомянутых представлений создайте запросы, которые показывают только те элементы, у которых есть связь с элементами другого типа. Подумайте над вложенными запросами, которые показывают элементы, соединенные с другими элементами, соответствующими определенным критериям.
  • Рассмотрите возможность создания матриц  для отражения прямых или косвенных связей между наборами элементов. Матрицы – это очень хороший способ показать, какие элементы связаны между собой, а какие нет. Они помогают рецензированию, позволяя рассматривать каждую клетку в матрице отдельно, чтобы проверить какие перекрестные ссылки действительно существуют, а также выявить отсутствующие.
  • Создайте отчеты для каждого прямого или косвенного вложенного представления и каждой матрицы.
  • Создайте метрики для каждого важного состояния жизненного цикла каждого типа элемента.
  • Рассмотрите возможность создания отчетов для каждой метрики.
  • Определите KPI для имеющей значение статистики элементов проекта в важных состояниях и соберите их на одной или нескольких приборных панелях.
  • Подумайте о создании графиков для отслеживания прогресса элементов. Как правило, одно из состояний элемента в жизненном цикле может оказаться особенно значимым, поэтому оно может стать предметом метрик и/или ключевых показателей эффективности. Даты, когда элементы достигают такого состояния, могут использоваться для создания графиков прогресса элементов, и это является очень полезным инструментом для управления проектом.

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

Итоговым и наиболее важным аспектом функциональной схемы является Иерархия фаз. phase_hierarchyЭто определяемый пользователем интерфейс, который скрывает все специфические детали Cradle от конечного пользователя, таким образом, пользователям нужно лишь понимать сам процесс, чтобы иметь возможность эффективно использовать Cradle в проекте.

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

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

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

Разработка Руководства по проекту

Компания 3SL рекомендует, после того, как вы создали свою схему проекта, разработать Руководство по проекту. Этот документ предназначен для конечных пользователей, который связывает ваш процесс со схемой Cradle и описывает:

  • Какие части процесса будут выполняться в Cradle;
  • Какими данными будет управлять Cradle;
  • Как эти части процесса будут выполняться в Cradle;

Руководство по проекту будет содержать в себе общее описание вашего процесса и роль Cradle в рамках этого процесса. Оно также будет состоять из следующих разделов:

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

Все инструкции в Руководстве по проекту будут относиться к тем частям иерархии фаз, которые будут созданы, чтобы выполнять их как можно проще. Инструкции должны быть максимально короткими. Любые универсальные инструкции должны быть объединены в отдельный раздел в конце руководства. Примеры универсальных инструкций: как отредактировать элементы в таблицах, как начать дискуссии, как участвовать в уже существующей дискуссии и др.

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

Разработка учебных материалов для пользователей

Компания 3SL рекомендует, чтобы новые пользователи были ознакомлены с проектом и Cradle при помощи специализированного учебного курса, который вы создаете из вашего:

  • Процесса
  • Схемы
  • Руководства по проекту

Важно понимать, что это не курс по Cradle. 3SL и наши партнеры предоставляют курсы по работе с Cradle.

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

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

По большому счету, материалы по обучению пользователей представляют собой слайды и соответствующие заметки. Этот курс научит и расскажет:

  • О структуре Руководства по проекту.
  • О том, как войти в систему Cradle.
  • О ряде параметров процесса проекта, поддерживаемого Cradle.
  • О том, из чего состоит иерархия фаз и как по ней перемещаться.
  • О типах представлений, созданных из иерархии фаз и как ими пользоваться.
  • Об общих задачах, таких как, рецензирование и обсуждение.
  • О связях между Cradle и внешними системами, такими как, электронная почта и управление проектами.

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

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