Структуризация процесса проектирования с использованием модели трассировки проектных данных и 3SL Cradle

Инна Курносова
ведущий программист СПбГПУ

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

Данная статья описывает:

  • исходные технологические условия,
  • анализ текущего процесса проектирования,
  • новые технологические условия, доступные при использовании 3SLCradle,
  • разработанную под новые условия структуру проектных данных (модель трассировки),
  • анализ нового процесса проектирования
  • и пример выполнения данного процесса с использованием 3SL Cradle.

Исходные технологические условия и анализ текущего процесса проектирования

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

Процесс проектирования, используемый организацией, в которой я работаю, является типовым для небольших групп разработки и соответствует 2-ому уровню CMM. Второй уровень СММ – Repeatable (воспроизводимый) характеризуется значительным опытом участников процесса и их высокой мотивацией, что позволяет им успешно воспроизводить процесс и своевременно получать требуемые результаты, несмотря на отсутствие формализованных регламентов работы (документированных процессов).

Рассматриваемый технологический процесс  имеет следующие основные этапы:

Этап создания системы Технология выполнения

1

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

  • выявление входных данных и накладываемых ограничений;
  • выявление требуемых функций;
  • проектирование архитектуры системы. Выделение подсистем и связей между ними, с детализацией функциональности для каждой подсистемы отдельно.
Система разбивается на блоки. Каждый блок системы имеет свой набор требований. Оптимизация  требований в целом к системе не выполняется потому, что постепенно разрабатываются отдельные блоки системы, при  реализации система дополняется и расширяется, а общая база требований и проектных решений, доступная всем участникам, отсутствует.   Из-за этого часто появляется избыточность. В результате общий объем работ может увеличиваться, соответственно увеличивается время реализации, трудозатраты, объем ПО.
3 Проектирование базы данных системы. Формируется ответственным за данный этап специалистом, согласовывается со всеми разработчиками на основании требований. При разработке документируется частично, при сдаче документации полностью.
4 Проектирование пользовательского интерфейса. Формируется согласовано со всеми разработчиками на основании требований. Могут быть большие изменения при изменении требований. Описание структуры связей таблиц и полей БД с элементами интерфейсов существует только в головах разработчиков и в коде ПО.
5 Распределение рабочих ресурсов – какой разработчик, какую часть реализует. Распределяются в зависимости от компетентности и загруженности. Разные разработчики могут поддерживать одни и те же блоки. При этом разными разработчиками одни и те же функции могут реализовываться в разных блоках, что влечет к увеличению объема работ и увеличению времени на реализацию изменений в данных функциях. Больше кода написанного разными людьми, больше времени на понимание кода.
6 Реализация – формирование базы данных (БД), написание программной реализации (ПО). (каждый занимается своей частью). Каждый задействованный разработчик занимается своей частью. Проводится устное согласование при реализации смежных блоков. Результаты согласования фиксируются частично, каждым разработчиком на своё усмотрение.
7 Формирование документации. Последовательная работа с интерфейсом системы для описания каждой формы, иногда с просмотром программной реализации. Трудоёмкий процесс при описании алгоритма работы с формой.

 

Основными особенностями такого типового процесса являются:

  • Направленность на быструю реализацию требований в коде.
  • Отсутствие документирования изменений в требованиях и проектных решениях, за исключением схемы базы данных. Знания распределены по разработчикам, которые могут быть недоступны по той или иной причине (болезнь, командировка).
  • Анализ требований к системе в целом выполняется редко. Выполняется анализ конфликтующих требований, но детальный анализ дублирующихся требований и проектных решений в рамках системы в целом не производится.
  • При изменении требований необходимо проводить анализ самого кода, интерфейсов и схемы БД. При этом за счет ротации доступных специалистов по задачам приходится изучать как свой, так и чуждой код.

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

  1. Увеличение трудоёмкости вследствие дублирования реализаций функций. Ситуация дублирования появляется в случае необходимости использования одной и той же функции в разных подсистемах. У каждого разработчика может быть своя реализация функции, которая используется и других модулях, написанных не им. Это происходит из-за отсутствия явного описания связей между функций системы и программной реализацией, связями между экранными формами интерфейсов и программной реализацией.
  2. Задача поиска связей между элементами структуры БД и программной реализацией крайне трудоемка, т.к. из-за отсутствия описания структуры связей между полями (таблицами) БД и программной реализации выполняется полный поиск по коду.
  3. Аналогично, из-за отсутствия описания структуры связей между полями (таблицами) БД и экранными формами пользовательского интерфейса выполняется просмотр всех возможных форм и кода их реализации, поэтому трудоёмкость поиска связей между экранными формами пользовательского интерфейса и полями (таблицами) БД крайне велика.

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

  1. Оценки времени (трудозатрат)
  2. Реализации (проведении) корректировки.

На первом этапе, находятся все места в ПО, интерфейсах, БД, связанные с внесенным изменением в требованиях к системе. Это значит, что сработают все три пункта недостатков, описанных выше. Разберем действие первого пункта — изменение задействовано в дублирующихся функциях: время на корректировку возрастает на n(k-1), где:

n = (время на поиск + время на принятия решения на изменение + время реализации)

k – количество дублирующихся функций.

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

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

Выводы по текущему процессу проектирования

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

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

Новые технологические условия, доступные при использовании 3SL Cradle

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

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

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

3SL Cradle позволяет создавать различные типы проектных данных и назначать семантику связям между ними. Например, в моем случае, каждому блоку данных — БД, ПО, интерфейсы можно сопоставить свой тип, используя Item type, при этом каждый элемент можно связать с любым другим, задав связи отношений между ними.

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

Проектирование структуры проектных данных (модели трассировки требований)

Для того, чтобы разработать модель трассировки проектных данных, которая решала бы обозначенные проблемы процесса проектирования, необходимо было ответить на ряд вопросов, таких как:

  1. Как избежать дублирования одних и тех же функций?
  2. Как сократить время на поиск мест, затрагиваемых изменением требований?
  3. Как увидеть связанные элементы:
    • Требований и элементов базы данных;
    • Требований и блоками программной реализации;
    • Требований и элементов интерфейса;
    • Элементами интерфейса и программной реализацией;
    • Элементов интерфейса и элементов базы данных.
  4. Какая функция (требование) в каком блоке задействована?
  5. Как сформировать нужную документацию (описание БД и руководство пользователя) по имеющимся данным.

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

Разработанная структура проектных данных (модель трассировки) состоит из семи блоков:

1. Требования (requirements to the project обозначу аббревиатурой RP). Требования включают требования к вводимым данным и описание функций каждой подсистемы. При вводе требований к функциям по новому проекту уже на этом этапе выявились дублирующиеся функции в различных подсистемах. Для устранения дублирования (а значит излишних трудозатрат) я решила каждую повторяющуюся функцию, вынести один раз в отдельный элемент типа RP,  и  связать его с каждым узлом в дереве требований, относящемся к подсистеме имеющей такую функцию. Одно требование, будет соответствовать одному элементу типа RP.

2-4. База данных. База данных проекта представлена тремя типами элементов BD – база данных (от data base),Table — таблица, Field — поле. По аналогии с проектированием базы данных системы,  каждому элементу базы данных выделяю свой тип элемента в системе Cradle. Такая детализация описания более трудоемка, но позволит связать отдельно с другими элементами модели поля таблиц, что затем существенно упростит трассировку и поиск.

5. Пользовательский интерфейс (от англ. user interface — UI). Один элемент типа UI, описывает одну экранную форму. Иерархия элементов UI, отображает иерархию связей между формами.

6. Варианты использования (от англ. Use Case — UC) – применяю для описания работы экранных форм. Данный тип будет применяться для формирования документации «Руководство пользователя». Один вариант использования описывает работу одной экранной формы.

7. Программное обеспечение (software, запишу как Soft) – отображает иерархию дерева каталогов файлов с программной реализацией системы. Одному файлу соответствует один элемент типа Soft.

Для более точного понимания и использования в запросах связей элементов модели я ввела свои типы связей:

  1. Связь (RELATED TO) – служит для связывания элементов одного типа;
  2. Часть (BE PART) – предназначена для связывания элементов одного типа, являющимися частью элемента другого типа. Применяется для связи элементов BD -> Table, Table -> Field, BD -> Soft, Soft -> UI. Используя данный тип связи можно настроить запросы или матрицы трассировки для анализа связей между элементами Базы данных, элементами программного обеспечения и элементами пользовательского интерфейса. Это обеспечит быстрый поиск, решает поставленные вопросы 2 и 3.
  3. Реализует (REALIZED TO) – предназначена для связи требований с проектными решениями. Эта связь позволит решить вопросы 2 и 4.
  4. Описывает (PRESENT TO) – предназначена для связи каждого элемента типа UI с каждым элементом типа UC. Таким образом, каждой экранной форме пользовательского интерфейса будет соответствовать свой вариант использования. Связь данных элементов этим типом связи решает вопрос 5.

Сформированная модель трассировки процесса проектирования представлена на рисунке 1.

traceabilitymodel

Рис.1 Модель трассировки процесса проектирования

Новый процесс проектирования

Новый процесс проектирования имеет следующие этапы:

Фазы Что выполняется Отличие от прежнего процесса
1. Введение и  связывание требований 1. Подготовка требований к трассировке:- требования полученные от заказчика:а) формализуются;б) проектирование архитектуры системыв) выделяются подсистемы и связей между ними, описываются функционал для каждой подсистемы отдельно;г) структурируются;2. Трассировка требований:- выполняется захват требований из документации;- трассируются. 1. Трудоемкость этапа возросла.2. Уменьшилась избыточность требований на этапе подготовке к трассировке и при трассировке. Это уменьшит трудозатраты при реализации.3. Все требования зафиксированы и структурированы
2. Проектирование базы данных системы. 1. Формируется ответственным за данный этап специалистом, согласовывается со всеми разработчиками на основании требований.2. Каждый элемент базы данных вносится в соответствующие типы элементов базы данных Cradle.3. Связывание каждого элемента типа Поле с элементом типа Таблица. Связывания элементов типа Поле друг с другом, в соответствии со схемой БД.4. Связывание элементов БД и элементов требований 1. При выполнении 2 и 3 пункта (2-го столбца), возрастают трудозатраты.2. Все элементы БД зафиксированы и связаны с требованиями.3. При изменении требования можно быстро проанализировать затрагиваемые места в БД4. Быстрое формирование документации «Описание базы данных»
3. Проектирование пользовательского интерфейса. 1. Формируется согласовано со всеми разработчиками на основании требований.2. Каждая экранная форма вносится в БД Cradle3. Связываются элементы требований с элементами пользовательского интерфейса.4. Если разработаны описания работы экранных форм, то вводятся и связываются с элементами интерфейса один к одному. 1. При выполнении 2, 3 и 4 (2-го столбца) пункта, возрастают трудозатраты.2. Все элементы пользовательского интерфейса зафиксированы и связаны с требованиями3. При изменении требования можно быстро проанализировать затрагиваемые места в интерфейсах пользователя4. Быстрое формирование документации «Руководство пользователя» (если введены описания)
4. Распределение рабочих ресурсов – какой разработчик, какую часть реализует. Распределяются в зависимости от компетентности и загруженности разработчиков Начинают работать предыдущие стадии. Меньше нужно реализовывать (требования оптимизированы), описание БД есть, описание форм есть. Взаимосвязи есть. Уменьшается время на поиск информации
5. Реализация – формирование базы данных (БД), написание программной реализации (ПО). 1. Внесение изменений в базу Cradle при изменении БД во время реализации2. Написание кода3. Внесение названий файлов и связывание их с элементами типа требования, элементами типа экранные формы 1. Увеличение трудоемкости при выполнении пункта 3 (2-го столбца).2. Значительно уменьшается время на поиск мест в коде при внесении изменений в требованиях (автоматический поиск).3. Легче проводить оценку трудозатрат.4. Не будет пропущенных мест при коректировке
6. Поддержка актуальности данных Внесение изменений при их появлении в соответствии с каждым элементом Достоверность проектных данных на протяжении всего процесса проектирования
7. Формирование документации Настройка инструментов Cradle для формирования документации Значительное уменьшение времени и особенно трудоёмкости.

 

Основными особенностями нового процесса являются:

  1. Размещение в одном месте всех  проектных данных.
  2. Возможность автоматизировано проследить связи между требованиями и проектными решениями — трассируемость проектных решений.
  3. Возможность поиска проектных данных по различным типам связей и атрибутам.
  4. Быстрое формирование документации.
  5. Меньшие затраты на оценку и проведение изменений.
  6. Более точная оценка трудозатрат, при внесении изменений в требования.

Выводы

В ходе решения поставленной задачи:

  1. Удалось выявить причины, определяющие недостатки текущего процесса проектирования. Причинами являются отсутствие общей базы данных требований и проектных решений, связанных с ней.
  2. Структурировать процесс проектирования, используя модель трассировки, дополнив прежние фазы проектирования, задачами по фиксации проектных данных каждой фазы и связыванию этих данных с другими элементами модели.
  3. Оценить трудоемкость перехода от прежнего процесса проектирования к автоматизированному управлению требованиями проекта. Применение данных методов к разработке новых систем не столь трудоёмко, поскольку все данные должны вводиться последовательно. При поддержке разработанной системы трудоёмкость по вводу данных будет зависеть от разработанной модели трассировки процесса проектирования.
  4. Стало очевидно, что данный инструмент (3SL Cradle) имеет преимущества не только для компаний с большим коллективом, но и для одного человека, поскольку заставляет задуматься о процессе проектирования в целом, увидеть достоинства и недостатки. А также выбрать новые методы структуризации требований и успешно использовать их в работе, повысив эффективности технологического процесса и качество разрабатываемого продукта .

Пример реализации созданной технологии на базе 3SL Cradle 6.8

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

1. Создание проекта.

Создаем проект с незаполненной схемой (Schema: empty), используя Project Manager

cradle-example-pic1

Вводим название проекта, код, ID, тип схемы, путь к записи проекта

cradle-example-pic2

2. Настройка структуры проектных данных (модели трассировки) в базе данных Cradle.

Открываем созданный проект в WorkBench

cradle-example-pic3

Далее в меню Project Setup проводятся настройки схемы проекта

cradle-example-pic4

2.1. Установка типов элементов в соответствии с моделью трассировки.

Настраиваем используемые типы элементов в форме Project Setup

Добавляем тип элемента (BD, Table, Field, RP, SOFT, UC, UI), выбрав в ниспадающем списке  Options значение Item Definitions

cradle-example-pic5

Для элементов описываемых не только текстом настраиваем дополнительные типы в фреймах. Это необходимо, например, для сохранения скриншотов экранных форм. Выделите для этого нужный тип элемента и нажмите Frames… Добавляем новое поле и для него устанавливаем тип

cradle-example-pic6

2.2. Установка типов связей в соответствии с моделью трассировки.

Для этого в настройках Cross Reference Parameters создадим типы связей, описанные в модели трассировки BE PART, REALIZED TO, RELATED TO, PRESENT TO

cradle-example-pic7

Настроим правила связывания элементов в вкладке Link Rules. Этот диалог позволяет задать какая связь предназначена для связывания каких типов элементов. Для этого сначала добавим правило, нажав кнопку Add, затем выделенную строку (правило) можно редактировать. Форма установок правила вызывается нажатием кнопки Edit в боковом меню или двойным щелчком мыши по строке правила

cradle-example-pic8

Из выпадающего списка выбирается, от какого типа элемента к какому осуществляется связь. Кто может назначать данный вид связи (подробнее можно посмотреть в справочнике Cradle Manipulating and Viewing your Project InformationSetting up Projects and Users > Project Setup > Cross Reference Parameters )

После проведения настроек, сохраняем изменения установок проекта. Нажатием OK внизу формы Project Setup

cradle-example-pic9

3. Захват требований в базу данных Cradle.

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

cradle-example-pic10

Выполняем захват требований в БД Cradle

  1. Открываем программу Document Loader
  2. Выбираем в меню формы File -> Open New Document. Загружаем файл и настраиваем какими типами элементов будут захваченные Cradle требования. Это будет RP (требования в моей модели трассировки)

cradle-example-pic11

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

cradle-example-pic12

4. Трассировка требований.

Можно приступать к связыванию требований. Перетаскиваем элементы требований в дереве RP и назначаем тип связи. Выделить нужный элемент (будет дочерним) или группы элементов (используя клавишу Ctrl) и перемещать к узлу родителю

cradle-example-pic15

5.      Введение проектных решений

Проектные решения  вводятся  в базу Cradle, при помощи добавления нового  элемента (Item). Для ввода базы данных разработанной системы, данные типов элементов BD, TABLE, FIELD можно загрузить используя программу Document Loader, предварительно выгрузив данные о базе в файл (в моем случае, используя средства MySQL). Время на введение данных колоссально сократится.

cradle-example-pic14

Удобнее проводить последовательный ввод элементов одного типа

6. Связывание проектных решений

В соответствии с моделью трассировки начинаем связывать элементы различных типов.

cradle-example-pic15

Для этого проверяем тип связи.

7. Введенные проектные данные структурированы и трассированы в соответствии с моделью трассировки в БД Cradle.

cradle-example-pic16

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

8.  Пример настройки представления для анализа данных

Откроем форму для настройки представления View Details, это можно сделать или из главного меню Window -> View Details, или Ctrl + 9, или используя иконку в панели навигации. В открытом представлении выбираем тип элемента для анализа, выбираем поле которое будем анализировать. Выбираем тип связанности, с каким полем связанно, тип навигации (обхода), вариант представления данных. Для редактирования видимости выводимых полей используются элементы управления в области Column Properties и Row Properties. После настройки сохраняем полученное представление

cradle-example-pic17

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

cradle-example-pic18

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