RUP (Рациональный Унифицированный Процесс)
Я решил использовать метод разработки RUP (Rational Unified Process) в моем проекте. Это метод, который я никогда не использовал раньше. Я также включил некоторые элементы из Scrum в процесс разработки. Вопрос в том, что спецификации требований должны содержать в RUP-модели? Это функциональные и нефункциональные требования? А что должно быть включено в технический анализ и требования безопасности для RUP? Не могу найти никакой информации. Заметки об этом были бы полезны. Надеюсь, что люди с опытом работы в RUP могут поделиться полезным опытом.
2 ответа
РУП состоит из 3 основных частей:
- Роли
- мероприятия
- Рабочие продукты
Каждая РОЛЬ выполняет ДЕЯТЕЛЬНОСТЬ и, как результат, производит РАБОТУ ПРОДУКТОВ...
Например, Аналитик [Роль] Разработать Vision [Деятельность], в результате у нас будет Vision [Рабочий продукт]...
Кроме того, этот RUP дает нам РУКОВОДЯЩИЕ ПРИНЦИПЫ и ПРОВЕРКУ, чтобы исправить нашу ДЕЯТЕЛЬНОСТЬ и РАБОЧУЮ ПРОДУКТУ
RUP предоставляет нам шаблоны для РАБОЧИХ ПРОДУКТОВ, но они просто дают представление о том, как они могут выглядеть...
Предположим, для зрения вы можете использовать шаблон RUP, но вы можете просто использовать заметки после публикации и просто написать "заявление elavator", например:
Для [целевого клиента] Кто [заявление о необходимости или возможности] The (название продукта) является [категорией продукта] Это [заявление о ключевой выгоде; то есть убедительная причина для покупки] В отличие от [первичной конкурентной альтернативы] Наш продукт [заявление о первичной дифференциации]
Даже продукты Work могут быть простыми утверждениями, которые вы пишете в своей WIKI... Они могут быть в любой форме...
Они не должны быть "статически написанными" документами... Они могут даже быть "видео". Предположим, вместо того, чтобы писать документы Softaware Architecture [ Архитектурный блокнот в OpenUP], вы можете просто создать видео, в котором ваша команда объясняет основную архитектуру на белой доске....
**** ПРЕДУПРЕЖДЕНИЕ ДЛЯ ШАБЛОНОВ РАБОТЫ RUP:**
НЕ СТАТЬ ШАБЛОНОМ ZOMBIE.YO НЕ СЛЕДУЕТ ЗАПОЛНЯТЬ ЕГО ЧАСТЕЙ... ВЫ ДОЛЖНЫ ЗАПРОСИТЬ СЕБЯ, ЧЕМ ВИД ПРЕИМУЩЕСТВА Я ПОЛУЧУ, НАПИСАВАЯ ЭТОТ... ЕСЛИ У ВАС НЕТ ДЕЙСТВИТЕЛЬНОГО ОТВЕТА, НЕ ПИШИТЕ... ДОКУМЕНТАЦИЯ ДОЛЖНЫ ИМЕТЬ РЕАЛЬНЫЕ ПРИЧИНЫ, НЕ СДЕЛАТЬ ДОКУМЕНТАЦИЮ ТОЛЬКО ДЛЯ "ДОКУМЕНТАЦИИ"... **
RUP имеет богатый набор РАБОЧИХ ПРОДУКТОВ... Так что выбирайте минимальное количество из них, которые вы получите наибольшую выгоду...
Для типичных проектов, как правило, у вас будут следующие рабочие требования:
Видение: что мы делаем и почему мы делаем? Соглашение о StakeHolders...
Дополнительная спецификация [Общесистемные требования в OpenUP]: обычно фиксирует нефункциональные [которые мне не нравятся] или "качественные" [которые мне нравятся ") системные требования.
Модель варианта использования: требования к функции захвата как сценарии использования
Глоссарий: чтобы прояснить концепцию...
RUP является коммерческим, а OpenUP - нет... Таким образом, вы можете посмотреть шаблоны OpenUP WORK PRODUCTS, чтобы понять, какая информация в них записана...
Загрузите его с веб- сайта Eclipse Process Framework Project http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php и начните чтение со страницы индекса:
...-->
...---> 
---> 
-----> 
---> 
....>.........................................
---->.......................................
Наконец, вы можете найти гибкое использование этих РАБОЧИХ ПРОДУКТОВ в книге Лармана "Применение UML и паттернов..."
И снова: НЕ СТАТЬ ШАБЛОНОМ ЗОМБИ!!!
Попробуйте страницу Rational Unified Process в Википедии для обзора.
Основные требования должны быть задокументированы в описании проекта. RUP, как правило, уделяет большое внимание "вариантам использования", однако очень важно не упускать из виду исходные требования на всех уровнях детализации, поскольку они ответят "Почему?" вопросы. Если разработчики видят только варианты использования, они будут знать, что они должны построить (фактически, функциональные требования), но не знают, почему это требуется. Если разработчики не имеют легкого доступа к оригинальным аналитикам, это может вызвать очень серьезные проблемы.