Введение
Зоопарки воодушевляют тем, что в одном месте мы можем наблюдать огромное разнообразие направлений эволюции. Зоопарк Гановера примечателен тем, что для всех животных создана среда, приближенная к их естественной среде обитания, это не только обеспечивает комфортные условия животным, но и позволяет лучше понять приспособительное значение особенностей каждого вида.
Понятие трассировки (прокладывание пути, трассы) широко используется во многих отраслях, в том числе при наблюдении за животными.
В области разработки программно-технических систем модели трассировки можно рассматривать как компактное представление различных направлений эволюции технологий проектирования. Более формально, модель трассировки требований — это структура, отражающая типы требований (проектных данных, артефактов) и отношения между ними, используемые для описания системы.
Ниже приведены несколько диаграмм, иллюстрирующих понятие «модель трассировки» и контекст ее применения.
Альбом моделей трассировки требований
Далее вам предлагается погрузиться в удивительный мир технологий проектирования, взглянув на них через фильтр моделей трассировки. Активное созерцание часто приносит конструктивные идеи…
Обсуждение
Многообразие предлагаемых моделей трассировки обусловлено разнообразием технологий проектирования, чью структуру они отражают и которые основаны на различных:
- парадигмах проектирования;
- методах анализа и проектирования — UML, IDEF, DataFlow, ARIS, EPC, BMPN, SDL, LePUS, SysML…;
- архитектурных каркасах (Architecture Framework) — 4+1 View, The Open Group Architecture Framework, (TOGAF), Federal Enterprise Architecture Framework (FEAF), Open Distributed Processing — Reference Model (RM-ODP), Department of Defence Architecture Framework (DoDAF), Zachman Architecture Framework,…;
- методологиях разработки программного обеспечения — RUP, Agile, MSF, ГОСТ 34,…;
- онтологиях — TOVE, Enterprise Ontology, SUPER,….
Существенные вариации моделей трассировки требований появляются также за счет использования разных семантических оттенков, придаваемых понятиям конкретным коллективом.
Так много усилий направлено в сторону разработки моделей трассировки требований так как установлено, что их применение позволяет сэкономить до 80% стоимости разработки. Это легко объяснить — разработчики не тратят время на проработку такой модели в начале каждого проекта, применение эталонной модели структурирует работу над проектом, позволяет заранее увидеть пропущенные связи между требованиями, а также другие ошибки в требованиях. На этапе сопровождения системы, эта технология позволяет значительно экономить отвечая на постоянные запросы заказчиков.
Необходимо ответить, что в исследовательских лабораториях активно прорабатываются не только подходы, при которых разработчики сразу структурируют проектные данные в соответствии с выбранной моделью трассировки, но и методы автоматизированного извлечения связей между артефактами проектирования, которые используют модели трассировки в неявном виде.
Одной из популярных задач, которой посвящено много работ, является разработка модели трассировки, определяющей связи между элементами UML диаграмм, с целью полной автоматизации процесса оценки распространения изменений при использовании данного метода моделирования.
Процесс разработки модели трассировки помогает по-новому взглянуть на процесс создания и эволюционного сопровождения ПО, найти значительные резервы для увеличения производительности, обеспечить более предсказуемый процесс проектирования, разработки, сопровождения, а значит внести значительный вклад в успех каждого проекта.
Не столько высота прыжка, сколько скорость реакции обеспечивает спасительное преимущество:
Использование моделей трассировки позволяет увеличить скорость реакции на изменяющиеся потребности заказчиков.
Первые шаги к направленной эволюции
- Попробуйте сделать зарисовку типов проектных данных и понятий, которые ваш коллектив использует при проектировании и разработке программно-технических систем. Не ограничивайте свой полет мысли и выписывайте все, приходящие в голову понятия.
- Определите связи между выделенным набором понятий. Дайте каждой связи наименование.
- Оцените полученную схему:
- какого типа получилась модель трассировки требований? — Методологическая, технологическая, смешанная?
- насколько она визуально сбалансирована,
- нет ли дублирующихся (семантически близких) понятий и связей, если такие есть, попробуйте определить к какому общему классу они принадлежат и чем отличаются друг от друга — может быть разница не существенна и две категории можно свести к одной?
- какого типа получилась модель трассировки требований? — Методологическая, технологическая, смешанная?
- Выпишите вопросы, на которые вам часто приходится отвечать, используя проектные данные — например:
- какие спецификации и тесты подлежат изменению при реализации пожелания заказчика?
- все ли требования заказчика учтены в спецификации?
- на что влияет эта ошибка и сколько трудозатрат необходимо для ее устранения?
- конфликтует ли проектное решение с отраслевым законом?
- возможно ли реализовать этот запрос заказчика?
- Оцените, возможно ли с помощью вашей модели ответить на эти вопросы. Посмотрите, где необходимы прямые, а не косвенные связи, чтобы на сформулированные вопросы можно было ответить быстрее.
- Возьмите данные одного из ваших проектов и разложите их по выделенным категориям, проставив трассировочные связи.
- Определите какие ошибки возможно контроллировать с помощью вашей модели и какие ошибки хотелось бы контроллировать. Ответ на этот вопрос покажет вам направления развития вашей модели.
- Организуйте внешнее тестирование вашей модели трассировки требований — попросите коллегу (без вашей помощи) разложить его проектные данные по разработанной вами модели трассировки. Если коллега затрудняется при классификации — дайте понятиям четкие определения и снабдите их критериями соотнесения данных.
- Итеративно уточняйте модель, с целью повышения ее однозначности — если специалисты не смогут быстро определять к какой категории относится те или иные проектные данные, они не будут поддерживать актуальной модель системы, построенную на базе модели трассировки требований и тогда ответы на сформулированные вами вопросы будут не актуальны.
- Попробуйте спрогнозировать направления методологического и технологического развития вашего коллектива и оцените, возможно ли будет адаптировать разработанную вами модель под новые подходы.
Технологические замечания
Для проектирования модели трассировки возможно использовать любой редактор, позволяющий соединять овалы (прямоугольники, элипсы — что нравится) стрелками и делать соответствующие надписи, например:
- графические редакторы (Visio, SmartDraw, ….)
- редакторы семантических сетей (СMapTools — бесплатный)
- редакторы, позволяющие рисовать диаграммы классов UML (VisualUML, 3SL Cradle, ….)
Для применения модели трассировки в технологическом процессе и решения поставленных аналитических задач и задач управления требованиями используются CASE-системы класса «Управление требованиями», со свободной моделью трассировки (т.е. позволяющие настроить любую модель трассировки). К таким системам относятся:
- Requisite pro — любые типы элементов, один тип связи.
- 3SL Cradle , Telelogic DOORs — любые типы элементов, любые типы связей.
Хотите сослаться на эту статью? Используйте правильную ссылку:
Источники моделей трассировки
- [Зезин 2011] Зезин В. Онтологический взгляд на инженерию требований// REQ LABS, 2011.
- [Мадорская 2012]Мадорская Ю.М. Подготовка спецификаций требований Заказчика к трассировке [электронный ресурс]/Ю.М. Мадорская, 2012. — Режим доступа: http://www.reqcenter.pro, свободный. — Загл. с экрана.
- [Химонин 2009] Химонин Ю. Сбор и анализ требований к программному продукту //электронный ресурс, 2009.
- [Gills 2005 ] Martins Gills. Survey of Traceability Models in IT projects //ECMDA-Traceability Workshop, 2005.
- [Kelleher 2006] Justin Kelleher Traceability Patterns //ECMDA-Traceability Workshop, 2006.
- [Rummler et al. 2007] Andreas Rummler, Birgit Grammel and Christoph Pohl. Improving Traceability in Model-Driven Development of Business Applications //ECMDA-Traceability Workshop, 2007.
- [Goknil et al. 2008] Arda Goknil, Ivan Kurtev, Klaas van den Berg Change Impact Analysis based on Formalization of Trace Relations for Requirements //ECMDA-Traceability Workshop, 2008.
- [Ramesh 2001] Balasubramaniam Ramesh and Matthias Jarke. Toward Reference Models for Requirements Traceability. // IEEE Trans. Softw. Eng. 27, 1 (January 2001), 58-93
- [Sowa et al. 1992] J. F. Sowa and J. A. Zachman. 1992. Extending and formalizing the framework for information systems architecture. //IBM Syst. J. 31, 3 (June 1992), 590-616.