Немного критики в адрес RUP

- В чем разница между методологом и террористом?
- С террористом можно вести переговоры.

Тема родилась отсюда: Зачем нужен тест-план?, происки подлых бюрократов?

В одном из своих постов я покусился на святое:

RUP чудовищно устарел. Это прекрасно разработанная система. Без дураков. Одна из самых, а, скорее, самая подробная. Но как раз ввиду этого - застывшая, неповоротливая и во многом ошибочная.
Так, например, их модель прецедентов “действующие лица и цели” устарела на дюжину лет. Взаимосвязь артефактов также нуждается в “капитальном ремонте”.

И Вячеслав попросил осветиь этот вопрос поподробнее.

Сергей, тема очень интересная - я пользуюсь РУП-ом ибо нет ничего подробнее и ничего обширнее. Беру РУП и отсекаю ненужное… то бишь адаптирую.

А вот в остальном - “давайте разбираться” :)

1. В чём ошибочен РУП?
2. В чем устаревшесть модели прецендентов РУПа? Что сейчас не работает или работает совсем не так или не может работать как описано?
3. Какие именно связи между артефактами нарушены или требуется их переадресация?
4. Что с инструментами?

Мне в самом деле интересна тема, я далеко не адепт РУПа, во многом он меня устраивает как структурированная Библиотека проектных практик, во многом не устраивает, но лучше я пока не видел и с тем что ты говоришь не согласен.

Кто б спорил. Действительно нет ничего подробнее и ничего обширнее RUP-а. И если бы теория разработки ПО стояла на месте последние сорок лет, то унифицированный процесс от Rational был бы самым передовым и самым правильным.

Давайте рассмотрим модель прецедентов. Как я уже говорил выше, в RUP используется модель «действующие лица и цели» (Actors and Goals). Неколько лет назад Алистер Коберн создал современную модель «Участники и интересы» (Stakeholders and Interests). Разница в результатах при использовании этих двух моделей прекрасно показана в статье «Варианты использования, десять лет спустя»:

Один консультант рассказывал, как он и его рабочая группа решили перечислить все участвующие в проекте стороны и их интересы. Неожиданно они обнаружили, что этот список практически совпадает со списком изменений, которые им пришлось сделать в недавно сданной заказчику системе в течение первого года ее работы! Другими словами, проделай они эту работу на год раньше, они избежали бы целой массы ошибок, которые не вышли на поверхность до того момента, как системой стали пользоваться реальные люди. Я слышал подобные рассказы и от других. Некоторые говорили, что перечислять взаимодействующие стороны и их интересы полезно всегда, даже если это делается очень кратко и неформально.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.