RUP (Rational Unified Process)

Question

В моем проекте я выбрал метод разработки RUP (Rational Unified Process). Это метод, который я никогда раньше не использовал. Я также включил некоторые элементы Scrum в процесс разработки. Вопрос в том, какие спецификации требований должны содержать в RUP-модели? Это функциональные и нефункциональные требования? И что должно быть включено в технический анализ и требования безопасности для RUP? Невозможно найти информацию. Заметки об этом были бы полезны. Надеемся, что люди с опытом RUP могут поделиться некоторыми полезными событиями

Answer 1

Проанализируйте страницу Rational Unified Process на странице Wikipedia.

Основные требования должны быть задокументированы в описании проекта. RUP имеет тенденцию уделять большое внимание «случаям использования», однако очень важно не упускать из виду первоначальные требования на всех уровнях детализации, потому что они ответят «Почему?». вопросов. Если разработчики только видят случаи использования, они будут знать Что они должны строить (эффективно функциональные требования), но не Почему требуется. Если разработчики не имеют легкий доступ к оригинальным аналитикам, это может вызвать очень серьезные проблемы.

Answer 2

RUP имеет 3 основных частей:

• Роли
• Деятельность
• работы Продукция

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

Например Analyst [Role] Develop Vision [Activit у] в результате мы будем иметь видение [Работа продукт] ...

Кроме этого RUP дает нам некоторые рекомендации и контрольный список, чтобы сделать правильную нашу деятельность и рабочими продукты ...

RUP дает нам шаблоны для работы ПРОДУКТЫ, но они просто для того, чтобы дать представление о том, как они могут выглядеть ...

Предположим, для видения вы можете использовать шаблон RUP, но вы можете просто использовать заметки, сделанные после этого, и просто написать инструкцию «elavator», например:

Для [целевой клиент] Кто [заявка о необходимости или возможности] (название продукта) является [категорией продукта] Это [выписка по ключу пособие; то есть веская причина, чтобы купить] В отличии от [первичной конкурентоспособной альтернативы] Наш продукт [постановка первичного дифференциации]

Даже работы продуктов может быть простыми заявлениями, которые вы пишете на свой WIKI ... они могут быть в любой форме ...

Они не должны быть «статическими» документами ... Они могут быть даже «видео». Предположим, что вместо написания Softaware Architecture docs [Архитектура Notebook в OpenUP] вы можете просто создать видео, в котором ваша команда объяснит основную архитектуру на белой доске ....

**** ПРЕДУПРЕЖДЕНИЕ ДЛЯ RUP WORKPRODUCTS ШАБЛОНЫ: **

НЕ СТАЛ ШАБЛОН ZOMBIE.YOU НЕ ДОЛЖНЫ ЗАПОЛНИТЬ EVER ЧАСТИ ЕГО ... вы должны спросить себя, КАКУЮ ПОЛЬЗУ WILL I ПОЛУЧИТЬ написав это ... ЕСЛИ У ВАС нЕТ ОТВЕТ ДЕЙСТВИТЕЛЬНОГО, нЕ ПИШИТЕ ... ДОКУМЕНТАЦИИ должна иметь реальные причины, нЕ ДЕЛАЙТЕ ДОКУМЕНТАЦИЮ ТОЛЬКО ДЛЯ «ДОКУМЕНТАЦИИ» ... **

RUP имеет богатый набор РАБОЧИХ ПРОДУКТОВ ... Так что выбрали минимальную сумму, из которой вы получите наибольшую пользу ...

Для типичных проектов обычно вы будете иметь эти требования к работе Продукция:

• Видение: То, что мы делаем и почему мы делаем? Agrément заинтересованных сторон ...

• Suplemantary Спецификация [ОБЩЕСИСТЕМНОЕ требование в OpenUP]: Вообще захватить нефункциональный [который термин я не люблю] или «качество» [который я люблю "] требования системы

• Use-Case Model:. требования к функции захвата, как примеры использования

• Глоссарий: Для того, чтобы сделать понятия ясно ...

RUP является коммерческим, но OpenUP нет ... Так что вы можете смотреть OpenUP рабочие продукты шаблоны только, чтобы получить представление о том, какая информация записана в них ...

Загрузить его можно и Затмения Process Framework Project http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php и начать чтение с индексной страницы:

...-->

...--->

--->

----->

--->

....>. ........................................

---->. ......................................

Наконец вы можете найти использование этих рабочих продуктов в гибкой манере в Larman книге Применение UML и шаблонов ...

И снова: НЕ СТАЛ ШАБЛОН ЗОМБИ !!!