Sergey 12345
Member
Откуда:
Сообщений: 4
|
Добрый день, коллеги. Существует система управления требованиями DOORS компании Telelogic, которая может решать проблемы, обсуждаемые здесь. Я отвечу на вопросы Юрия.
| Юрий Волков | 1. По поводу "внешних документов" предлагаю ещё более радикальную формулировку требования к системе управления требованиями:
Система управления требованиями должна ориентироваться на то,
что документы-требования хранятся во внешнем хранилище документов.
При этом внутри самого "репозитория требований" хранятся, в основном, метаданные требований и информация, специфичная именно для процессов управления требованиями. |
DOORS имеет возможность включать любое количество файлов в текст требования. При этом файл будет храниться внутри базы данных DOORS. Кроме того, в текст требования возможно включить ссылку на файл в файловой системе. В этом случае файл будет храниться в файловой системе, а в требовании будет храниться только ссылка на этот файл. Как видно, имеется поддержка любых вариантов.
Лично я сторонник хранения всей информации в одном месте (т.е. в системе управления требованиями). Однако жизнь есть жизнь и может возникнуть ситуация, когда требуется сослаться на внешний файл. Например, исторически информация ведется в определенном месте в документе Word и никакими силами нет возможности изменить это.В любом случае DOORS поддержит любой процесс.
| Юрий Волков | | В настоящее время наиболее удобное хранилище требования, формулировка которого превышает несколько предложений, - это файловая система. Для документов, хранящихся в файловой системе, легко организовать и доступ, и контроль этого доступа, и полнотекстовый поиск, и многое что ещё. "Репозитории требований" современных инструментов убоги и неудобны по сравнению с файловой системой и её расширениями. И гнаться за файловой системой, по-моему, нет смысла. В этой связи начинаешь с новой стороны смотреть на инициативы, подобные WinFS, ориентированные на расширение возможностей файловой системы. |
Здесь я, скорее, соглашусь. Для файловых систем существует ограмное кол-во примочек, которые существенно расширяют их возможности (например программа поиска по содержимому документов Word) и т.д. В DOORS, используя стандартную функциональность, нельзя организовать поиск внутри прикрепленных к требованиям документам. Однако, система управления правами доступа в DOORS достаточно гибкая и может потягаться с файловой системой. Например, права доступа можно установить на любом уровне: проект, папка, модуль с требованиями, конкретное требование. Более того, права доступа можно установить на отдельные атрибуты требования. Права доступа могут быть даны на чтение, создание, модификацию, удаление, администрирование (т.е. изменение прав доступа для других)
| Юрий Волков | 2. По поводу вопроса "Что такое требование". На уровне бизнес-процессов (на уровне предприятия) возникают требования как в виде текстовых описаний (сценариев, вариантов использования, см. Новый взгляд на описание бизнес-процессов), так и в виде графических моделей/диаграмм (см., например, статью Architecture and Architecture Modeling Techniques).
Эти документы организованы сложным образом, предназначены для различных аудиторий, и на их основе создаются различные артефакты проекта (отчётные документы).
Если "система управления требованиями" будет требовать куда-то _повторно_ "заносить" эти модели/описания и т.п., искусственным образом разбивать их на части, а потом самому отслеживать их актуальность..., то этой системой управления требованиями никто и не будет пользоваться: архитекторы и аналитики следуют прагматичному принципу: "не повторяй себя" (DRY). Кроме того, нужно иметь ввиду, что на уровне предприятия одно описание бизнес-процесса может содержать требование к нескольким "Системам" (приложениям, проектам автоматизации и т.п.). |
В этом высказывании очень много мыслей, поэтому я напишу несколько тезисов.
1. Существует 2 подхода к разработке: MDD Model driven devalopment и RDD requirements driven development. При разработке можно использовать любой из них или комбинацию. Здесь существует масса подходов. Например, на уровне бизнеса можно использовать MDD, используя продукт System Architect компании Телелоджик. Далее, отдельные артифакты выгружать в DOORS, как требования высокого уровня. И далее в DOORS на основании этих требований вводить требования более низкого уровня. Т.к. это продукты одной компании, то они тесно интегрированы между собой.
2. Если нет цели построить целостную модель, а есть задача лишь снабжать требования отдельными разрозненными диаграмами, то можно ограничиться только DOORS. Можно использовать расширение DOORS\Analyst. Это расширение позволяет внедрять в требования диаграммы на UML 2.0.
3. По-поводу повторного ввода информации соглашусь. Дублированный ввод никогда долго не живет. Мне кажется, что важно правильно построить процесс. Если процесс будет правильно построен, то дублирования быть не должно.
4. Если на высоком уровне есть требование к нескольким системам - это хорошо. Это соответствует идее управления требованиями. Значит для этого требования возникнет множество требований для разных систем (требований более низкого уровня) и все они будут ссылаться на это высокоуровневое требование.
| Юрий Волков | | 3. По поводу "атомарности" требований. Возможно, "описание бизнес-процесса" действительно будет "атомарным требованием", которое кратко можно сформулировать так: "Система должна делать то, что указано в данном описании". В то же время, документ, который с точки зрения управления требованиями есть "атомарное требование", с точки зрения архитектора есть сложная, структурированная сущность, модель, с точки зрения владельца бизнеса - это рассказ о его бизнесе. Здесь нет противоречия. |
Здесь я бы сначала обратился к теории, которая гласит, что требования должны быть: точными, краткими, непротиворечивыми, проверяемыми. На мой взгляд, лучше всего в этом случае ввести в DOORS вложенный документ в виде отдельных требований. Преимущества: появляется более детальный контроль над этими требованиями. Если в ходе тестов не выполнен один пункт из документа, то в системе управления требованиями можно будет отметить какой именно пункт не выполнен и разработчик будет знать что именно ему делать. Это же касается изменений отдельных пунктов документа. Если документ прикреплен к требованию, то описаные выше задачи вы берете под свой контроль (т.е. вы отказываетесь от функционала системы управления требованиями в пользу ручного контроля).
Хотя, в отдельных случаях можно ограничиться присоединением документа. Но, чтобы понять как лучше, нужно уже смотреть конкретно каждый случай.
| Юрий Волков | | 4. Система управления требованиями должна максимально использовать атрибуты документов - требований, например, атрибуты документов MS Word, содержащих сценарии, артибуты графической модели в файле хранения этой модели и т.п. Тогда не потребуется повторный ввод информации и не будет проблем с её обновлением. |
Здесь я не очень понимаю о чем идет речь. Возможно, речь идет о том, что система управления требованиями должна "разбирать" любые форматы файлов и вытаскивать оттуда информацию для обработки (Из Word автора, кол-во абзацев, учреждение и т.д.; из Photoshop слои, фильтры, названия объектов; из JPG кол-во цветов, степень сжатия и т.д.). Думаю, что это невозможно.
| Юрий Волков | | 5. По поводу стилей MS Word, см. статью Документ MS Word - всем миром. Содержание данной статьи сильно пересекается с процессами управления требованиями, в которых требования создаются разными людьми ("всем миром"), а потом на основе этих требований создаётся множество различных документов: как тех, которые нужны для самого процесса разработки (участникам команды), так и те, которые необходимы для формального выполнения проекта в соответствии в условиями контракта (например, Клиент (Заказчик) может требовать оформления документации по неким стандартам). |
В DOORS существует выгрузка в Word и это является одним из возможных вариантов создания отчетов. При выгрузке требований в Word можно использовать шаблон Word, содержащий стили. Для каждого требования можно указать свой стиль, который оно будет иметь в Word. Обычно стиль устанавливается не для отдельных требований, а для уровней требований. Тогда документ смотрится более строго и структурировано. |
Система управления требованиями [new]
Re: Система управления требованиями [new]
Re: Система управления требованиями [new]