Кумар Мани, старший IT-архитектор, IBM
http://www.ibm.com/developerworks/ru/library/ar-reqframe1/index.html
11.07.2007
В данной серии статей Кумара Мани предлагаются новые приемы, помогающие выявить и проследить архитектурные требования, а также управлять ими. Введение В этой статье описываются новые архитектурные методы и приемы, направленные на проектирование требований, на умение их собирать, анализировать и управлять ими в течение всего жизненного цикла проекта. Хотя в данной статье для иллюстрации этих приемов используется набор инструментов Rational, она не является учебным пособием по использованию этих продуктов. Ваша цель - использовать основные архитектурные методы и применять их в своих проектах. Конечно же, IT-архитекторы, знакомые с Rational, смогут без труда воспроизвести эти методы в своих проектах. Требования важны, поскольку они образуют основу для разработки архитектур. На Рисунке 1 показан метод разработки архитектуры Open Group Architecture Framework Architecture Development Method (TOGAF ADM) и его восемь фаз.
Рисунок 1. Метод разработки архитектуры TOGAF
Эта статья призвана устранить брешь между литературой о продуктах и литературой о процессах. Документация по инструментальным средствам Rational прекрасно описывает их функции и возможности; литература о процессах содержит описание разнообразных методов и передовой практики. Однако IT-архитекторы все же не представляют себе до конца, как можно извлечь максимальную пользу из этого инструмента. В этой статье вы узнаете о бизнес-требованиях, вариантах использования и базовой трассируемости, а затем о требованиях системного уровня, компонентизации и трассируемости во время тестирования.
Корпорация Empire Systems
Чтобы продемонстрировать, как наилучшим образом использовать методы управления архитектурными требованиями, в этой серии статей я буду приводить гипотетические примеры из практики Empire Systems Corporation (ESC), вымышленного производителя и поставщика ПК, ноутбуков, компьютерных компонентов и сопутствующего оборудования, например, Web-камер и микрофонов. ESC уже представлена в Web, и многие из её приложений доступны через Интернет. Теперь руководству компании нужно перевести предприятие на следующий уровень путем рационализации процессов, автоматизации деловой активности, внедрения корпоративной архитектуры, и, в конечном счете, повышения доходов и рентабельности.
Бизнес-требования
Удачные IT-проекты начинаются с хороших бизнес-требований. В технической литературе содержится описание многочисленных методов, приемов и передовой практики в области проектирования требований. Однако информация о требованиях, особенно о бизнес-требованиях, зачастую бывает малопонятна, беспорядочна, и, в общем, трудна для восприятия. Недостаточная ясность влияет на интерпретацию бизнес-требований, и, как следствие, на их преобразование в технические требования. Перечислим некоторые основные принципы выработки требований.
У ESC есть несколько Web-приложений. Поскольку каждое приложение разрабатывалось самостоятельно, клиенты сталкиваются с такими проблемами, как необходимость регистрироваться отдельно в каждом приложении и работать с различными представлениями для каждой бизнес-функции, что вызывает недовольство. В ответ на это бизнес-группа ESC сформулировала следующее требование:
В этом приеме для записи требования в RequisitePro главное - сохранить тот порядок, который был использован при сборе данных и уточнении требования. Этот прием включает три шага:
Прием 2 (Связь вариантов использования с требованиями) касается следующей фазы проекта. Как только бизнес-требования будут определены, бизнес-архитектор или аналитик разрабатывает варианты использования для большей ясности. Бизнес-аналитики часто сталкиваются с двумя проблемами, в особенности в больших или сложных проектах:
Существует большое количество материала по моделированию вариантов использования. Статьи в разделе Ресурсы - хорошая отправная точка. Обзор вариантов использования выходит за рамки этой статьи, однако мы представим соглашение об именах, которое применяется в реализации приема.
Принцип именования для вариантов использования
Почему имеет значение имя варианта использования? Вспомните, для определения требований мы ввели структуру подлежащее-глагол. Это понятие здесь расширено. В модели варианта использования подлежащее представлено исполнителями (actors). Наш принцип именования вариантов использования заключается в том, что варианты использования должны быть названы при помощи настоящего времени или герундия (ing-формы) глагола. В некоторых случаях это помогает включить имя объекта, модифицированного глаголом.
Прием 2. Соединение вариантов использования с требованиями
Теперь пора определить варианты использования и соединить их с требованиями. Цели этого приема - поддерживать ясность в определении вариантов использования и обеспечить их связь с требованиями (трассируемость), выполняя следующие шаги.
Трассируемость
Почему важна трассируемость? Трассируемость - это способность отслеживать жизнь требования, начиная с происхождения, через различные воплощения, как вперед, так и в обратном направлении. По мере развития предприятий развиваются и системы (и их требования), которые их поддерживают. Трассируемость - это необходимое звено, которое связывает прошлое, настоящее и будущее требований. Отчеты о трассируемости содержат данные, на основании которых можно выполнять различные виды анализа проекта, например анализ затрат, охвата и воздействия.
Трассируемость трудно достижима на практике. Главная проблема - в том, что трассируемость рассматривается как дополнительный аспект выработки требований. Требования определены в документах, а модели создаются в Rose. Трассируемость записывается, часто вручную, в электронные таблицы, после
Наш следующий прием решает эту проблему. Первая часть приема - ввести дисциплину прослеживания требований при их создании. (Мы показывали это в предыдущем приеме с вариантами использования.) Идея в том, чтобы поддерживать дисциплину во время всего рабочего цикла требования вплоть до теста. Вторая часть - cгенерировать отчеты об охвате (coverage) и "свисаниях" (danglers). Отчет о "свисании"(dangler) - первый уровень анализа воздействия. Основная идея - в том, что эти отчеты, генерируемые автоматически, запрашивают тщательную проверку во время анализа.
Охват, судя по названию, предполагает, что каждое требование на одном уровне охватывается (или в дальнейшем определяется) на следующем уровне. Каждый вариант использования, например, должен быть охвачен набором тестовых данных. "Свисания"(danglers) - это требования, которые непреднамеренно "вползли" на один уровень, не имея прецедента на предшествующем уровне. Важно перехватить и то, и другое в начале цикла, поскольку гораздо легче обработать предупреждение на этой стадии, чем работать с отчетом об ошибках после реализации системы. Не менее важно автоматизировать эти функции.
Прием 3. Трассировка охвата и "свисаний"(danglers)
Этот прием показывает, как построить представления Coverage и Dangler, чтобы найти пробелы между бизнес-требованиями и вариантами использования. Эти представления соответствуют стандартной инфраструктуре представления RequisitePro. Выполните следующие шаги.
Выводы
В этой статье рассмотрены основы выработки требований и представлены три новых приема для управления архитектурными требованиями. В ней дан обзор основных принципов требований и описаны три приема для управления бизнес-требованиями, вариантами использования и трассируемостью.
Тем не менее, мы всё ещё находимся на этапе задачи. Настройтесь на работу с частью 2, которая познакомит вас с этапом решения и различными стадиями разработки решений (в плане архитектуры), и рассмотрит новые приемы по управлению созданием решений.
http://www.ibm.com/developerworks/ru/library/ar-reqframe1/index.html
11.07.2007
Рисунок 1. Метод разработки архитектуры TOGAF
- "Я использую продукты Rational для моделирования и разработки, но как связать их с требованиями?"
- "У нас уже есть инструмент XYZ с подобными возможностями, так чем же это решение лучше?"
IT-специалисты хотели бы, чтобы их технические требования были четко выражены, чтобы им можно было начать кодирование. Менеджеры проектов и клиенты не совсем представляют себе преимущества таких инструментов, как Rational RequisitePro® и возможность их использования с инструментами управления проектами, например, Rational Portfolio Manager. (В некоторых проектах используется весь набор инструментов Rational, кроме RequisitePro!) Ответам на эти вопросы и посвящена данная статья.
Такие инструменты, как Rational, при правильном использовании могут дать значительные преимущества. Некоторые менеджеры проектов используют такие инструменты (например, RequisitePro) как репозитории для требований; то есть требования импортируются в инструмент как есть, и из него публикуются отчеты. Менеджерам проектов остаётся удивляться, почему они не видят никаких ощутимых преимуществ.Эта статья призвана устранить брешь между литературой о продуктах и литературой о процессах. Документация по инструментальным средствам Rational прекрасно описывает их функции и возможности; литература о процессах содержит описание разнообразных методов и передовой практики. Однако IT-архитекторы все же не представляют себе до конца, как можно извлечь максимальную пользу из этого инструмента. В этой статье вы узнаете о бизнес-требованиях, вариантах использования и базовой трассируемости, а затем о требованиях системного уровня, компонентизации и трассируемости во время тестирования.
Корпорация Empire Systems
Чтобы продемонстрировать, как наилучшим образом использовать методы управления архитектурными требованиями, в этой серии статей я буду приводить гипотетические примеры из практики Empire Systems Corporation (ESC), вымышленного производителя и поставщика ПК, ноутбуков, компьютерных компонентов и сопутствующего оборудования, например, Web-камер и микрофонов. ESC уже представлена в Web, и многие из её приложений доступны через Интернет. Теперь руководству компании нужно перевести предприятие на следующий уровень путем рационализации процессов, автоматизации деловой активности, внедрения корпоративной архитектуры, и, в конечном счете, повышения доходов и рентабельности.
Бизнес-требования
Удачные IT-проекты начинаются с хороших бизнес-требований. В технической литературе содержится описание многочисленных методов, приемов и передовой практики в области проектирования требований. Однако информация о требованиях, особенно о бизнес-требованиях, зачастую бывает малопонятна, беспорядочна, и, в общем, трудна для восприятия. Недостаточная ясность влияет на интерпретацию бизнес-требований, и, как следствие, на их преобразование в технические требования. Перечислим некоторые основные принципы выработки требований.
В центре внимания должен быть бизнес
Бизнес-требования должны базироваться на реальных требованиях бизнеса, их следует отличать от других понятий бизнеса (таких, как видение, программа, цели и задачи). Распространенная ошибка - формулировать бизнес-цель (например, "достичь 20% снижения издержек") как бизнес-требование.
Будьте разумны
Требования должны быть Specific (конкретными), Measurable (измеримыми), Actionable (действенными), Realistic (реалистичными) и Timebound (ограниченными во времени). Это сложнее, чем кажется. Однако этого легко сделать добиться, задавая следующие вопросы:
* Почему это должно быть сделано таким образом?
* Какой результат вы получите или сможете достичь, если эта проблема решится?
* Какой именно процесс страдает от этого недостатка?
* Какая выгода (измеримая количественно, насколько это возможно), достигается внесением поправок в процесс?
* Что можно сделать, чтобы изменить ситуацию?
Ответить обычно бывает трудно, и заинтересованные стороны часто возвращаются к постановке задачи. Специалист по требованиям может начать с нескольких предположений типа "а что если", чтобы выявить некоторые возможности. Однако важно от них отступить, как только заинтересованные стороны вернутся к вопросам.
* Когда, в соответствии с временными рамками, этого необходимо достичь, принимая во внимание ситуацию и бизнес-среду?
Предполагается, что это не стартовая площадка для своевременного осуществления проектов, а скорее отправная точка для размышлений о бизнес-контексте. Например, коммерсант, работающий онлайн с кредитными картами, возможно захочет наметить на время праздников (их бизнес-контекст) дебют их нового Web-сайта.
Определите и уточните область действия
Что на входе и что на выходе? Что следует выполнить или осуществить, и к какому времени?
Определите "подлежащее" и "глагол"
Это очень часто упускается из виду и является основной причиной смещения области действия. Если глагол не один, а несколько, подумайте, не сформулировать ли его как отдельное требование. Это делает ситуацию более понятной и способствует её лучшему пониманию заинтересованными сторонами.
Важно что, а не как
Бизнес-требования всегда выражают, что должно быть сделано, и следует избегать указаний на то, как это можно сделать. Например, предприятию могут понадобиться субъективные, целостные представления их деловой информации. Тогда в центре внимания должно быть то, что нужно сделать, а не то, что необходимо получить (например, хранилище данных).
Пример требованийУ ESC есть несколько Web-приложений. Поскольку каждое приложение разрабатывалось самостоятельно, клиенты сталкиваются с такими проблемами, как необходимость регистрироваться отдельно в каждом приложении и работать с различными представлениями для каждой бизнес-функции, что вызывает недовольство. В ответ на это бизнес-группа ESC сформулировала следующее требование:
BR264: клиенты должны иметь доступ ко всем приложениям ESC через единый интерфейс и регистрироваться только один раз. ESCWeb (основной коммерческий Web-сайт) должен иметь одинаковый вид и функции для всех клиентов. В результате должно сократится количество ошибок пользователей, а удобство работы с сайтом - повыситься. ESCWeb также должен поддерживать мобильных и удаленных клиентов.
Очевидно, это требование может быть улучшено. Применяя принципы, мы можем переформулировать его следующим образом.
BR264: В ESC5.0 клиенты смогут однократно зарегистрироваться для всех приложений ESC, в том числе ESCWeb, ESCOrderStatus, ESCVendor и ESCSupport.
BR265: В ESC5.0 во всех приложениях ESC реализуются ESC Web Standard 273-1 и 273-2, что приведет к уменьшению количества ошибок пользователей на 10%.
Прием 1. Определение бизнес-требований в RequisiteProBR265: В ESC5.0 во всех приложениях ESC реализуются ESC Web Standard 273-1 и 273-2, что приведет к уменьшению количества ошибок пользователей на 10%.
В этом приеме для записи требования в RequisitePro главное - сохранить тот порядок, который был использован при сборе данных и уточнении требования. Этот прием включает три шага:
- Определите Requirement Type (Тип требования) для бизнес-требований. Все бизнес-требования получат этот тип. BUS - это обычный префикс.
- Определяя тип требований, используйте опцию Requirement Must Contain (Требование должно содержать) для указания разделителя (например "|"). Подлежащее и глагол могут помещаться по любую сторону от разделителя. Это не обязательно для соблюдения; в руководстве RequisitePro имеется более подробное описание. Идея в том, чтобы осторожно ввести порядок при определении подлежащего-глагола для требований.
- Создайте пакет для бизнес-требований на высшем уровне. Вы сразу же увидите, как это улучшает послеживаемость.
Прием 1 завершен. Вы записали понятное и точное бизнес-требование, и готовы перейти к следующей фазе. Этот приём показан на Рисунке 2.
Рисунок 2. Использование приема 1 для записи бизнес-требования
Рисунок 2. Использование приема 1 для записи бизнес-требования
Прием 2 (Связь вариантов использования с требованиями) касается следующей фазы проекта. Как только бизнес-требования будут определены, бизнес-архитектор или аналитик разрабатывает варианты использования для большей ясности. Бизнес-аналитики часто сталкиваются с двумя проблемами, в особенности в больших или сложных проектах:
- Требования размещаются в документах (если не использовать Прием 1), а варианты использования "живут" в моделях, например Rational Rose® Enterprise (Rose).
- Таким разобщенным набором объектов становится трудно управлять при увеличении количества требований (и вариантов использования).
Существует большое количество материала по моделированию вариантов использования. Статьи в разделе Ресурсы - хорошая отправная точка. Обзор вариантов использования выходит за рамки этой статьи, однако мы представим соглашение об именах, которое применяется в реализации приема.
Принцип именования для вариантов использования
Почему имеет значение имя варианта использования? Вспомните, для определения требований мы ввели структуру подлежащее-глагол. Это понятие здесь расширено. В модели варианта использования подлежащее представлено исполнителями (actors). Наш принцип именования вариантов использования заключается в том, что варианты использования должны быть названы при помощи настоящего времени или герундия (ing-формы) глагола. В некоторых случаях это помогает включить имя объекта, модифицированного глаголом.
Прием 2. Соединение вариантов использования с требованиями
Теперь пора определить варианты использования и соединить их с требованиями. Цели этого приема - поддерживать ясность в определении вариантов использования и обеспечить их связь с требованиями (трассируемость), выполняя следующие шаги.
- Если ваш проект RequisitePro не содержит пакета для вариантов использования или типа требований для вариантов использования, создайте их.
- Свяжите модель Rose с проектом RequisitePro, используя диалоговое окно Associate Model to RequisitePro project (Связать модель с проектом RequisitePro). Убедитесь, что в качестве Default Requirement Type (Типа требования по умолчанию) установлено Use Case (Вариант использования).
- Теперь можете начинать создавать модели в Rose. Для каждого варианта использования вначале создайте требование RequisitePro типа Use Case с именем, соответствующим принципу именования, как показано на Рисунке 3. Введите имя в Requirement Text (Текст требования).
Рисунок 3. Принцип именования варианта использования
- Создайте вариант использования в Rose. Нажмите правой кнопкой на вариант использования, чтобы вызвать диалог Associate Requirement to Use Case (Связать требование с вариантом использования). Выберите Use Case in RequisitePro и нажмите OK. В результате появится диалог Resolve Use Case Name, который важен тем, что он связывает варианты использования с требованиями с помощью глагола, как показано на Рисунке 4.
Рисунок 4. Соединение варианта использования с требованиями
- Теперь вы увидите диалог Requirement Properties (Свойства требования). Выберите вкладку Traceability (Трассируемость), и трассируйте вариант использования до требования BUS.
Трассируемость
Почему важна трассируемость? Трассируемость - это способность отслеживать жизнь требования, начиная с происхождения, через различные воплощения, как вперед, так и в обратном направлении. По мере развития предприятий развиваются и системы (и их требования), которые их поддерживают. Трассируемость - это необходимое звено, которое связывает прошлое, настоящее и будущее требований. Отчеты о трассируемости содержат данные, на основании которых можно выполнять различные виды анализа проекта, например анализ затрат, охвата и воздействия.
Трассируемость трудно достижима на практике. Главная проблема - в том, что трассируемость рассматривается как дополнительный аспект выработки требований. Требования определены в документах, а модели создаются в Rose. Трассируемость записывается, часто вручную, в электронные таблицы, после
Наш следующий прием решает эту проблему. Первая часть приема - ввести дисциплину прослеживания требований при их создании. (Мы показывали это в предыдущем приеме с вариантами использования.) Идея в том, чтобы поддерживать дисциплину во время всего рабочего цикла требования вплоть до теста. Вторая часть - cгенерировать отчеты об охвате (coverage) и "свисаниях" (danglers). Отчет о "свисании"(dangler) - первый уровень анализа воздействия. Основная идея - в том, что эти отчеты, генерируемые автоматически, запрашивают тщательную проверку во время анализа.
Охват, судя по названию, предполагает, что каждое требование на одном уровне охватывается (или в дальнейшем определяется) на следующем уровне. Каждый вариант использования, например, должен быть охвачен набором тестовых данных. "Свисания"(danglers) - это требования, которые непреднамеренно "вползли" на один уровень, не имея прецедента на предшествующем уровне. Важно перехватить и то, и другое в начале цикла, поскольку гораздо легче обработать предупреждение на этой стадии, чем работать с отчетом об ошибках после реализации системы. Не менее важно автоматизировать эти функции.
Прием 3. Трассировка охвата и "свисаний"(danglers)
Этот прием показывает, как построить представления Coverage и Dangler, чтобы найти пробелы между бизнес-требованиями и вариантами использования. Эти представления соответствуют стандартной инфраструктуре представления RequisitePro. Выполните следующие шаги.
- Из Coverage в пакете бизнес-требований выберите новое View (представление), где View Type (Тип представления) - это матрица трассируемости, Row Requirement Type (тип требований в ряду) - BUS, а Column Requirement Type (тип требований в колонке) - UC. Обратите внимание, что мы повторно используем пакет BUS из Приема 1.
- В окне View Properties (Свойства представления) создайте Query (Запрос) под названием
Business Requirements Coverage (Охват бизнес-требований)в требованиях ряда. Теперь Add (добавьте) атрибут Traced-from в Query. - В результате появится диалог Query Requirements (Требования к запросу). Как показано на Рисунке 5, выберите Not Traced и поставьте галочку на Direct links only (Только прямые ссылки).
Рисунок 5. Охват трассируемости
- Теперь обновите View. Вы увидите бизнес-требования, которые не имеют связанных с ними вариантов использования. Вы можете создать полный отчет View, пропустив шаги 2 и 3.
- Представления Dangler создаются путем инверсии критериев Query в этом приеме. Мы начинаем с требований типа в колонке (варианты использования) и выбираем требование Traced-to BUS. Это представление отражает все ссылающиеся на несуществующий объект варианты использования.
Выводы
В этой статье рассмотрены основы выработки требований и представлены три новых приема для управления архитектурными требованиями. В ней дан обзор основных принципов требований и описаны три приема для управления бизнес-требованиями, вариантами использования и трассируемостью.
Тем не менее, мы всё ещё находимся на этапе задачи. Настройтесь на работу с частью 2, которая познакомит вас с этапом решения и различными стадиями разработки решений (в плане архитектуры), и рассмотрит новые приемы по управлению созданием решений.
Комментариев нет:
Отправить комментарий