У любой компании, занимающейся разработкой ПО, рано или поздно просыпается интерес к различным методологиям разработки. Это связано с расширением команды, возрастающей сложностью проектов, желанием улучшить качество продуктов и сделать их выпуск более предсказуемым. Когда над проектом трудится хотя бы 5 человек, нужно каким-то образом организовать слаженную работу, разделить обязанности и вообще сделать так, чтобы хаоса было поменьше. Вот тогда управляющий проектом и задумывается над тем, что поставленный процесс разработки поможет решить многие из возникающих проблем. Встает совершенно логичный вопрос: какие методологии существуют в природе и какая именно подойдет для его команды и для его проекта?
Очевидно, что выбор методологии - дело непростое, особенно когда нет опыта использования. Для начала неплохо бы познакомиться с ними поближе.
Rational Unified Process
На сегодняшний день это одна из самых известных методологий. Разработана она компанией Rational Software для поддержки своих продуктов, которых насчитывается более десятка (среди самых знаменитых - Rational Rose и Requisite Pro). RUP создан тремя небезызвестными личностями - это Гради Буч, Ивар Якобсон и Джеймс Рамбо (как только не переводят на русский его фамилию Rumbaugh). Все они имеют огромный опыт разработки сложного программного обеспечения, что и нашло свое отражение в RUP.
Итеративность
RUP, как и любой современный продвинутый процесс, является итеративным. Это значит, что создание продукта происходит за несколько итераций. В конце каждой итерации получается работающая версия продукта, но с неполным функционалом. В последующих итерациях функционал дорабатывается и в конце последней получается полностью готовый продукт. Идею итеративного процесса можно показать следующим образом (см. рис.1).
![]() |
Рис. 1. Каждый виток спирали является итерацией. Таким образом, система постепенно обрастает функционалом. |
У итеративной разработки много плюсов. Большое количество релизов сильно влияет на качество конечного продукта, который тестируется в каждой итерации. Также уже на ранних стадиях можно проверить ожидания пользователей и внести изменения в продукт, если требуется. Кроме того, планировать проект гораздо проще, потому что уже после первой итерации все становится более предсказуемым, и управляющий проектом сможет с большей достоверностью прогнозировать реальные сроки окончания следующих итераций.
Надо сказать, что в RUP прямо не сказано о корректной итеративности процесса. Так что RUP можно успешно использовать и для водопадного процесса, где все стадии следуют строго друг за другом и готовый продукт выходит в самом конце. Поэтому при настройке RUP надо обязательно обратить внимание на итеративность и внедрить ее корректно.
Сценарии пользователей
Сценарий пользователя (Use Case) - это описание последовательности действий пользователя при выполнении определенной операции. Например, можно написать сценарий пользователя для открытия нового документа и т.п.
Кроме того, RUP управляется сценариями пользователей (или прецедентами). Сценарии пользователей позволяют более точно представить разработчикам, что же должна делать система и как именно она должна это делать. Сценарии пользователя являются частью функциональной спецификации системы. Вообще такие сценарии крайне полезны при разработке программы, потому что они:
- понятны заказчику и служат как бы общим языком и главным связующим звеном между заказчиком и разработчиком;
- помогают на ранней стадии выявить многие ошибки в логике работы программы;
- помогают более четко определить требования заказчика к программе;
- служат базой для разработки интерфейса и для написания тестовых сценариев.
В RUP сценариям пользователей отведено почетное место, процесс является use-case driven, то есть управляемый сценариями пользователей.
Структура RUP
Процесс имеет четыре фазы:
- Исследование (Inception)
- Уточнение плана (Elaboration)
- Построение (Construction)
- Развертывание (Transition)
На каждой из фаз основное внимание уделяется разным процессам. На фазе исследования идет сбор и анализ требований, на фазе уточнения плана - анализ требований и проектирование системы, на фазе построения - разработка и кодирование, на фазе развертывания - тестирование и распространение.
Методология RUP основана на 9 основных потоках:
- Бизнес-анализ (анализ потребностей)
- Сбор требований и управление требованиями (перевод требований в функциональные спецификации)
- Анализ и моделирование (перевод требований в программную модель)
- Кодирование
- Тестирование (проверка того, что программа соответствует требованиям)
- Управление конфигурацией и изменениями (отслеживание изменений в разных версиях продукта)
- Управление проектом
- Создание и поддержка среды разработки
- Развертывание (все что нужно для продажи или передачи продукта).
Все эти девять потоков и четыре фазы изображают в виде затасканной картинки, которую аккуратно вставляют в любую статью о RUP, но объяснение дают не часто. Повторять ее вновь нет особого смысла, лучше все объяснить словами.
Любой проект в RUP проходит четыре фазы. Через эти фазы проходят и все девять потоков. Каждая фаза, в свою очередь, разбивается на итерации. Если взять, например, первую итерацию на фазе "Исследования", то основное внимание на этой итерации уделяется бизнес-анализу, сбору требований и моделированию, но кодирование тоже есть. Если взять одну из последних итераций на фазе "Построения", то основное внимание уделяется кодированию, тестированию и управлению конфигурацией. Иными словами, по мере развития проекта в каждой итерации смещаются акценты. Это и правильно, ближе к концу особо анализировать нечего, а требования собирать как-то поздно.
Артефактом (Artefact) называется продукт, который создается и используется в процессе разработки ПО. Например, артефактами являются документы, модели, исходный код. Примеры артефактов: руководство пользователя, диаграмма классов в UML и т.п.
Неотъемлемую часть RUP составляют артефакты и роли. При разработке программы создаются разные артефакты, и за создание того или иного артефакта отвечает определенная роль. Например, диаграмму классов создает "Архитектор", а сценарии тестирования пишет "Дизайнер тестов".
Все визуальное моделирование осуществляется с помощью CASE-средств. Основой для него служит язык UML (Unified Modeling Language), что не удивительно, потому что UML разрабатывался авторами RUP.
Лучшие практики
Сама RUP основывается на шести лучших практиках (best practices):
- Итеративная разработка
- Управление требованиями
- Использование модульных архитектур
- Визуальное моделирование
- Проверка качества
- Отслеживание изменений
Они не являются непосредственной частью RUP, но их рекомендуется соблюдать при настройке процесса.
Итеративная разработка позволяет на ранней стадии получить работающую версию продукта и выявить критичные недостатки, кроме того, в итоге продукт получается более качественным, потому что база тестируется столько раз, сколько итераций проходит продукт.
Управление требованиями - один из важнейших процессов при разработке более-менее серьезных продуктов. Благодаря ему продукт более точно соответствует ожиданиям заказчика. Инструментальная поддержка обеспечивается Requisite Pro.
В теории модульная архитектура позволяет повторно использовать код, и система получается более гибкой. На практике это практически невозможно реализовать.
Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Модели помогают понять, как на самом работает система, что она делает и как она это делает. Кроме того, модели являются средствами коммуникаций между разработчиками, но для этого они должны быть понятны каждому. Вот для этого в RUP используется UML, который позволяет разработчикам говорить на одном языке. Инструментальная поддержка обеспечивается Rational Rose.
Качество продукта - одна из важнейших его характеристик. Заявляется, что RUP ориентирован на достижение приемлемого уровня качества, однако в процессе адаптации этой методологии с качеством могут возникать проблемы, если адаптация будет не совсем удачной. Инструментальная поддержка обеспечивается целым рядом программ: Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot.
Отслеживание изменений позволяет оперативно реагировать на изменение требований заказчика либо на изменяющиеся условия внешней среды. RUP имеет процессы, которые позволяют эффективно отслеживать изменения. Инструментальная поддержка обеспечивается Rational ClearCase и Rational ClearQuest.
Настройка RUP
RUP является адаптируемым процессом, то есть его можно настраивать под нужды конкретной команды и под конкретный проект. Более того, это делать совершенно необходимо, поскольку в противном случае эффективность использования RUP будет стремиться к нулю.
В RUP 2000, например, насчитывается более 30 ролей и более 50 артефактов. Естественно, что если команда состоит из 5 человек, то просто нет смысла вводить все эти роли и создавать все артефакты. Вообще чем меньше команда, тем легче должен быть процесс. То есть надо создавать минимум артефактов и вводить минимум ролей.
Так вот RUP позволяет настроить процесс. Из общего описания RUP можно взять только те процессы, роли и артефакты, которые действительно нужны команде для разработки качественного продукта в срок и в пределах бюджета.
Например, возьмем управление требованиями. В общем описании RUP присутствуют следующие артефакты: план управления требованиями, модель сценариев пользователей, спецификация требований системы, видение, репозиторий требований. Для маленького проекта вполне достаточно спецификации требований и набора отдельных сценариев. Но для крупного проекта совершенно необходим репозиторий, потому что без него отслеживание и изменение требований превратится в головную боль системного аналитика.
Однако настройка RUP под конкретный проект - нетривиальная задача. Если решать ее будет тот, кто до этого внедрением RUP не занимался, есть риск получить на выходе совершенно неподходящий процесс, состоящий из бестолкового нагромождения артефактов, потоков и ролей, на которые тяжелым грузом лягут продукты Rational Software.
Вообще считается, что RUP достаточно тяжелая методология, которая лучше подходит для больших команд. Одной из попыток облегчить RUP является методология dX. Она объединяет в себе RUP и XP, о которой мы поговорим в следующий раз.
Михаил ДУБАКОВ,
wa.artel.by
![Версия для печати Версия для печати](https://www.kv.by/sites/all/modules/print/icons/print_icon.png)
Комментарии
Страницы
"Правильно делать наоборот. Надо эти абстракции под реальность подстраивать."
Делать это очень сложно и редко оправдано. Для введения методологий нужен сурьезна подковынный менеджмент, такого у нас нет.
Обычно все получается наоборот: в результате убитое время, низкая мотивация людей, ненавись к методологиям. (Вот почему я такой злой)
""Какие итерации? Нифига такого не знаем. Какие сценарии? Какие требования? Нахрена все это? "
Думаете, легко объяснить, зачем это надо? "
Программерам этого объяснять не надо, это должны знать манагеры. Программеры должны кодировать - струячить код.
Рассуждения о методологиях извращают их мышление, снижают производительность.
"О! Наконец-то наши взгляды соприкоснулись. Я тоже так считаю и наконец-то мне удалось выудить эту информацию от вас в явной форемы ;)"
Я рад, выуживайте!!!
"К сожалению, я не super PM и даже не рядом."
Ну зачем себя так веслом по голове!
Мы все не идеальны...
"А многие не знают, к сожалению. Это вам понятно, у вас опыт большой, а сколько блин есть народу, которые вообще не знают ни о юз-кейсах, ни об итерациях и т.п. Особенно это касается веб-программеров. Ну, знают хорошо PHP и MySQL. Ну, еще CVS может пользуются. И часто это все!"
Почти всегда этого вполне достаточно. Простая работа она ж такая - сама себя делает, главное - это желание что-то определенное в конце-концов получить, вот!
А еще проектировать базы данных, создавать архитектуру системы, уметь нормально объяснить друг другу все это. Хотя бы. Вы считаете, что юз-кейсы должны PM писать? И требования тоже они должны собирать? Иногда, конечно, это бывает и может даже правильно, но очень редко.
>Почти всегда этого вполне достаточно. Простая работа она ж такая - сама себя делает, главное - это желание что-то определенное в конце-концов получить, вот!
Я очень быстро столкнулся с ситуацией, когда этого крайне мало. В результате было потеряно немало времени и многое пришлось переписывать с нуля.
Да в общем-то зачем им всякие кейзы писать, они на словах договоряться.
Зачем им требования собирать у них все прекрасно в голове уместиться. Заказчик все по телефону или на пальцах покажет.
Сколько раз я сценарии писал, столько раз их никто не использовал. Мне сценарии нравятся, потому как это немного помогает разобраться в том, что должно получиться. А программерам проще на словах проблему показать. Нууу...может еще дать спецификацию почитать!
Ваще заметил, что спецификация более юзабельная для программеров, чем эти всякие юсе-кейзы.
"Я очень быстро столкнулся с ситуацией, когда этого крайне мало. В результате было потеряно немало времени и многое пришлось переписывать с нуля. "
Раз пришлось все переписывать с нуля, значит товарищ менеджер про#бал проект с самого начала, как говориться - не держал руку на пульсе. Юсе кейзы и прочая методологическая хрень тут не причем.
Гы. Типа неправильно спроектировали систему. Причем здесь менеджер?
Да притом, что менеджер виноват - в функции менеджера входит планрование, организация, руководство, координация, контроль, оценка. Раз он хреново контролирует, значит он плохой менеджер! За яйца и на мыло такого менеджера!
http://russian.joelonsoftware.com/Articles/BigMacsvs.TheNakedChef.html
13 марта 2003 года, 15:56
>Гы. Типа неправильно спроектировали систему. Причем здесь менеджер?
Правильно, у нас же считается, что менеджер не должен разбираться в технологиях и методологиях. Вот и системы такие получаются, когда необразованные манагеры принимают решения. :)
========== cut'n'paste=======
In my experience, MBA programs teach some very dangerous things. The bigest of these is that you do not have understand the process that you are managing.
If management is the process of making decisions about a project and allocating resources to complete that project, then you have to have some rational understanding of what is involved in that project. (Otherwise you can be replaced by a random number generator. Probably with better results.)
What happens with managers who do not have that requisite clue is that they make decisions based on "other criteria". (Things like "how good of an ad does the vendor have", "The product the airline magazine recommended", or "which one had the prettier marketing rep".)
Harvard MBAs are the worst of the lot. They are the ones who seem to have started the trend that clueless managers are a good thing.
And heaven forbid that you actually work for a company run by someone who taught in the MBA program! (*cough*NCD*cough*) It is guarenteed that they will drive your company into the ground.
Dilbert (это такие популярные комиксы из жизни корпоративной америки) exists because this style of "management" has become the accepted norm. Management has been used as a place to put all of those oxygen-robbing morons who had the fortune to be born to a good family, but not the brains to go into a trade that would really require actual thought. (Like criminal lawyer (redundant, I know), oilwell salesman, or brothel owner.)
And it seems the less you know about the business and what it does, the higher you will rise in the company.
Makes you wonder just how American businesses survive at all. (And judging by the dot-coms, we have our answer...)
==================================
Присоединяюсь к мнению, что всегда нужно думать прежде чем замутить какую нибудь хрень.
Но у меня есть вопрос к вам. Как выдумаете где место Модели зрелости програмного обеспечения с нашей работе?
С одной стороны действительно формализация процессов приносит свои плоды... Но с другой чем дальше дело заходит тем неповоротливей становится вся машина.
Да еще сколько очков вы получили бы по тесту Джоела?
-------
Тест Джоэла
Пользуетесь ли вы системой контроля версий?
Можете ли вы собрать продукт за один шаг?
Выполняете ли вы ежедневные билды?
Используете ли вы базу данных ошибок?
Исправляете ли вы ошибки перед написанием нового кода?
Есть ли у вас актуальный план работ?
Есть ли у вас спецификация?
Предоставлены ли вашим программистам спокойные условия для работы?
Используете ли вы новейшее дорогое оборудование?
Есть ли у вас тестеры?
Пишут ли кандидаты на работу код во время собеседования?
Проводите ли вы коридорное тестирование удобства использования программ?
-----
http://russian.joelonsoftware.com/Articles/TheJoelTest.html
PS Я перевел новую статью Джоела
Лорд Палмерстон в программировании (Декабрь 11, 2002)
Если кому-нибудь интересно напишите мне
Страницы