Вы говорите на самом деле о так называемом "цикле разработки ПО".
A>1. Водопадные (каскадные) [Устаревшие. Кто-нибудь сейчас ими пользуется?]
Это, например, PSP/TSP. Используется. Они, конечно, что-то лепечут про итеративную разработку. Но это ерунда.
Почему так? Основная проблема и отличительное свойство Waterfall — строгая привязка фазы цикла к виду деятельности. Что налицо в PSP.
A>2. Водоворотные (возвратные) [SADT очень похожа на именно такую методологию, я прав? Какие еще есть?]
Чистого водопада в реальной жизни не бывает, на деле они все "возвратные". Так мозги человеческие устроены.
Насчет SADT. Это не методология разработки софта. Это методология разработки документации, а именно, диаграм SADT (IDEF0). Она глубоко итеративна, и там нет привязки фазы к виду активности. Основной формальный цикл в ней — это цикл "автор" — "читатель" с нелимитированным количеством итераций.
A>3. Спиральные [RUP, MSF...?]
MSF — это вроде как спиральная. Которая на деле не далеко уходит от waterfall, основное отличие, что спиральку красивую нарисовать придумали.
Цикл разработки, используемый в RUP называется "контроллируемая итерация" (controlled iteration). Обратите также внимание на критерии входа-выхода в их фазы, и график разных активностей по фазам. Разительное отличие от Waterfall-подобных систем. Вместо фраз в духе "фаза дизайна окончена, когда готов документ такой-то и диаграммы такие-то" вы увидите что-то вроде "когда вся команда имеет одинаковое представление о том, как будет реализовано 90% сценариев использования".
A>4. Адаптивные [XP, все семейство Agille]
Ага. Это можно выделить в отдельный класс.
Господа проджект менеджеры и остальные уважаемые люди!
Возникло горячее желание упорядочить знания о методологиях разработки ПО, что требует, для начала, ознакомления с ними и четкой классификации по каким-либо критериям.
После прочтения ряда статей, из которых хочется выделить Устаревшие методологии – на пенсию!
, Каждому проекту своя методология, Процесс разработки или…разрабатываем процесс!
Так вот, соответственно, возникло естественное желание разделить методологии по
схеме управления процессом разработки:
1. Водопадные (каскадные) [Устаревшие. Кто-нибудь сейчас ими пользуется?]
2. Водоворотные (возвратные) [SADT очень похожа на именно такую методологию, я прав? Какие еще есть?]
3. Спиральные [RUP, MSF...?]
4. Адаптивные [XP, все семейство Agille]
Но это слегка однобокая классификация, поэтому очень уместным кажется такой критерий, как "объем", описанный Коуберном как произведение Project Lifecycle * Roles * Activities,
где, насколько я понял
1. Project Lifecycle – набор видов деятельности, выполняемых в рамках разработки системы.
2. Roles – набор ролей участников проекта.
3. Activities – набор видов деятельности, выполняемых в рамках управления проектом.
Тут мы можем прямо получить численный эквивалент тяжести. Но число нам конечно не нужно, а лучше выделить
"легкие", "средние" и "тяжелые".
Очень бы хотелось узнать Ваше мнение на тему какие методологии имеют какую "весовую категорию".
В идеале, для каждой существующей методологии разработки ПО можно дать такое описание: Методология такая-то, процесс управление такой-то, весовая категория такая-то.
Самому мне не приходилось, к сожалению, работать в проектах, где применялись тяжелые методологии, да еще строго применялись, поэтому прошу Вас высказывать свое мнение по всем известным Вам методологиям
Спасибо!
Я весьма доверчив, когда речь идет о моих словах. Я верю всему, что
говорю, хотя и знаю, что я лжец.
Мне кажется, что RUP и XP относятся как к спиральным, так и к адаптивным технологиям. По той простой причине — что имеют как ярко выраженный спиральный (итеративный) процесс и одновременно — наличествует обратная связь с заказчиком (в виде изменения требований) в процессе разработки — т.е. адаптация.
Что до оценки "тяжести" процесса разработки — я предложил бы несколько другой подход. Нужно просто суммировать общий объём работ (в человеко-часах) по всем видам деятельности (включая собрания, написание и чтение внутренних документов, проектирование, написание кода и т.д.) и поделил бы это на общий объём работ (в тех же единицах) на написание итоговых артефактов (кода, пользовательской документации и т.д.) — т.е. на результат, видимый и нужный заказчику. Чем это соотношение меньше — тем легче процесс, чем больше — тем процесс тяжелее.
Хотя возможно, что полезно будет делить не на написание итоговых артефактов, а объём самих артефактов или их функционал. Правда тут же возникает вопрос об оценке объёма артефактов или их функционала (полезности).
Сразу хочу сказать, что хорошо знаком только с RUP и XP.
Но сравнивать их, на мой взгляд, очень сложно. Если XP – это всего лишь набор советов как организовать разработку, при это последовательность действий, документация и прочее остается, не описано. Т.е. даются буквально общие советы.
RUP же в противоположность, наоборот описывает все процессы, дает шаблоны документов, советы по проектированию и анализу. И мало того, весь процесс имеет мощную поддержку со стороны программ компании Rational.
Мало того, RUP – адаптируется под проект. Т.е. можно на RUP организовать процесс как в малой, так и в большой фирме.
Если необходимо организовать крупную фирму, то сама методология RUP и инструментальные средства это с легкостью позволят, для этого необходимо будет содержать администраторов по продуктам Rational, специалистов по инструментам и провести обучение сотрудников.
Но сама идея RUP заключается в том, что вам необязательно брать его как есть, т.е. даже наоборот Rational советует каждый раз составлять свой «адаптированный процесс», на базе RUP. Там даже документ такой есть, так и называется «адаптированный процесс».
Мало того XP и RUP это подход к разработке с разной стороны.
При желании, в сети можно найти информацию о том как организовать группу разработчиков на основе XP и RUP вместе. Т.е. именно из-за того, что методологии рассматривают разработку с разной стороны они не противоречат друг другу. Ну и к тому же они имеют много схожих моментов. Например, истории (в XP), и прецеденты(UseCase в RUP)…
Вообще, обзор получился какой-то сумбурный, как-то мало времени…
Можно эту тему пообсуждать еще.
Конкретно RUP я знаю очень неплохо, перерыл его основательно, да еще на курсы для укрепления знаний недавно ездил, так, что будут вопросы спрашивайте.
. Но число нам конечно не нужно, а лучше выделить
