У любой компании, занимающейся разработкой ПО, рано или поздно просыпается интерес к различным методологиям разработки. Это связано с расширением команды, возрастающей сложностью проектов, желанием улучшить качество продуктов и сделать их выпуск более предсказуемым. Когда над проектом трудится хотя бы 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)
Комментарии
Страницы
Вообще, MBA - штука неплохая. Главное, она позволяет подняться на высоту птичьего такназываемого полета и взглянуть на все глазами отрешенными от операционной деятельности. ЭмБиЭй - это в первую очердь стратегия и стратегическое мышление.
Однако, проблема не в MBA, а в детях. Всякие там дети (люди с детским мышлением) получают MBA и лезуць в бусинес, не имею нихрена никакого опыта. Вот эти всякие дети ишчуць механизмы(RUP, CMM, ISO9000), чтобы заставить все работать, как в книжке написано.
Эти люди не поварились в каше повседневного дерьма, им кажется, что все можно превратить в машины с кнопочками... Они пытаются все и всех проклассифицировать: ты - дизйнер баз данных, ты арнхитектор, ты - дед момор, ты - май
Они бяруць книжки и наперад!!! И што? Конь в пальто!
Зрелось, зрелость!!!
Что такое зрелось, как половые органы обросли, так мы и созрели...
Все пытаются всех проверить, кто созрел, а кто нет. да у каждого все по-своему. Я не могу понять, почему ИТ всегда отделяют от других видов бизнеса. Возьмите производство компрессорного оборудования. Разве у всех контор единая методология менеджмента? Нет.
А создание дизайна автомобилей? Тоже нет. Вон чуваки из BMW всех воих дизайнеров оправляют на пол года далеко, чтобы глаза их не видели, лишь хоть че нового придумали...
Мы всегда пытаемся все понять с теоретической точки зрения, а нужно руководствоваться и здравым смылом тоже.
Менеджер может "использовать" методологию или юзать жестокий прессинг, может ваще ходить с безбольной битой. Это его дело, главное, чтобы люди работали, чтобы дело двигалось вперед. А если все будут рисовать диаграммы и писать спецификации, компилировать код по 25 раз за день, это не приведет ни к чему хорошему.
>Но с другой чем дальше дело заходит тем неповоротливей становится вся машина.
Нужно помнить, что машины всегда неповоротливы. На то они и машины, они создаются для автоматизации процессов. Именно тех процессов, которые всегда обычно постоянно повторяются. Вот их, черт побери, и нужно автоматизировать!
Когда создется машина, и кто-то пытается ее изменить, нужно помнить, что чаще проще создать еще одну новую машину или же задачу перестроить под старую машину.
При создании машины нужно помнить, что она должна быть гибкая и легко изменяемая.
P.S. Под "машиной" я понимаю контору, где более 1 человека.
И еще, мне думается, что нужно помнить о разделении труда. Разделение труда эффективно с определенного момента и до определенной точки! В других случаях это разделение только вредит.
Именно разделение труда создет машины. Когда мы делим лшюдей на тех, кто встречается с заказчиком, кто рисует рисуночки, кто пишет код, кто рассказывает заказчику как и что работает мы УЖЕ создаем машины.
>Да еще сколько очков вы получили бы по тесту Джоела?
Ну может пару очков бы и получил. Ваще дядька мне нравится, он очень простой и понятный, таких мало... Эднако его взгляд принадлежит только ему одному, поэтому, господа, ФИЛЬТРУЕМ БАЗАР ВСЯКИХ ТАКМ УМНЫХ ДЯДЗЕК!!! АЕ, КАМ ОН!!!
Можно подписаться. На мой взгляд, проблема в объеме знаний. Чтобы стать хорошим PM в IT, надо знать дисципилны управления проектом (работа с людьми, планирование, контроли и т.п), методики создания ПО (контроль конфигурации, тестирование и т.п), а еще лучше уметь создавать ПО. Получается, что без большого опыта хорошим PM не стать, просто времени не хватит. Если подметать улицы можно научиться за полчаса и за неделю-другую достич высот в этой сфере, то отлично управлять проектом создания ПО в идеале может опытный разработчик, знакомый с большим количеством методик и знающий дисциплины PM. Таких мало.
Хорошим разработчиком можно стать года за три. На опробирование методик еще пару лет минимум. Научиться менеджменту еще года два. Получается, что надо лет семь практики. Минимум.
Кроме того, сложно найти человека, у которого есть таланты программиста и менеджера одновременно. Вот и получается, что классных PM в IT очень мало.
Хрен его знает. Рецептов нет. Должны быть и личностные качества и опыт. На моей практике была контора, где был очень сильный директор. Он был монстром в проектировании и кодинге. Таких объектных моделей, которые делал он, я больше нигде не видел. Но он совершенно нифига не понимал во заимоотношениях между людьми, не имел четкой направленности действий. В результате слил весь бизнес, ща немного держится на плаву, а мог же ведь достичь космических высот. В чем проблема - он не умел говорить с людьми и не обладал стратегическим мышлением.
>Хорошим разработчиком можно стать года за три. На опробирование методик еще пару лет минимум. Научиться менеджменту еще года два. Получается, что надо лет семь практики. Минимум.
Можно так, а можно забить на все и равться в бой. Мне думается, это происходит даже чаще. Если менеджер 0 в разработке, но он умеет обращаться с людьми, координировать их работу, понимает, что от него хочет высшее руководство, он справится. Главное, чтобы было желание и злость!!!
Anger, anger, anger!!!
Get out of my way!!!
Gonna kill you!!!
Will not ever stop myself!
Gonna get you!!!
>Кроме того, сложно найти человека, у которого есть таланты программиста и менеджера одновременно. Вот и получается, что классных PM в IT очень мало.
Есть такие люди, они среди нас. Просто люди эти иногда очень стеснительные, забитые, замучанные бюрократией. Мы должны освободить их крылья, отправить в свободный полет.
Ну и последнее. Довольно часто слышу, как очередной замороченый товарищь пытается впихнуть процессы проектирования и программирования в производственный процесс, утверждая, что это то же самое, что и шайбы точить на заводе. Что тут сказать? Не буду я работать на такой фабрике. И не хочу, что бы у меня такие программеры в подчинении оказались...
Для использования бумаги не нужна мышка и клавиатура, компьютер ваще. Очень классно рисовать! Я ваще люблю рисовать, особенно в детстве любил танчики и космические корабли, вот!
За это я больше всего люблю бумагу!
Всякия там ErWin, BpWin-ы и Rational-ы лучше использовать, когда приходится иметь дело с большим числом квадратиков. За ними следить проще, легче найти ошибки.
Но признаюсь, не очень люблю Rose. Эта сволочь не дает работать без мышки в некоторых очень ответственных ситуациях, а это ох как выводит, злит...
А ваще я думаю, что самый классный проектировщик должен представлять в голове систему, как набор как-нить мух или муравьев, или еще каких-нить тварей морских. Квадратики со стрелочками и симантическими надписями нужны для самих систем, чтобы поблюсти правила. С мухами же проще, когда о них думаешь - зашибательски абстрагируешься.
А на счет всяких там логических моделей БД - помойму это хрень, причем дибильная хрень, причем неудобная хрень. Нас заставляют мышкой по несколько раз перетаскивать названия полей, как это неудобно, ненавижу!!!
Круто конечно и весьма. Только это реальный мир и рвать жопу на британский флаг за чей-то левый продукт не стоит. Другое дело если у тебя есть идея и сколько-то денег на первое время, если ты собрал нормальную команду под этот проект.
А так как есть это просто работа. Можно делать ее спокойно и профессионально. Именно так это делали лучшие из известных мне менеджеров.
Я считаю что это два разных типа менеджеров. Для того что бы основать проект и в решающий момент захватить свою долю рынка и для того что бы потом удержать позиции и выпускать надежный софт и обеспечивать поддержку пользователей.
Поэтому я нахожу зрелость проекта решающим фактором в разработке програмного обеспечения. Чем старше проект и чем больше у него пользователей, тем больше внимания уделяется их поддержке.
У меня такое чувство что ты думаешь только про самый первый выпуск когда определение требований очень критично.
Я же довольно далеко ушел от этого и скорее думаю о том какие инструменты и насколько могли бы облегчить построение дествительно большой системы с большим количеством связей между компонентами
Звучит занудно, не так ли?
Впрочем лучше всего проектируется на бумаге где-то между 12 и часом ночи. Так что неприятие тяжеловесных инструментов готов с вами разделить
>Интересно как это ты собираешься спроектировать сколько нибудь большую систему без логического анализа структуры БД. Так чтобы то что получится можно было отлаживать и поддерживать?
Нууу лана, немного расскажу, хотя в прочем, оно всегда само собой получается, вот.
Не знаю, как это называется (может и логическое проектирование - не люблю ипользовать эти термины, т.к. они очень быстро начинают держать верх и преращают работу в бюрократию), но ночну с рисования больших квадратиков. Разделю все на независимые квадратики. Оценю эти квадратики с различных точек зрения. Нарисую стрелочки между ними.
Соберу людей, расскажу им про квадратики. Устрою этот, как его, брэйн-шторм, во, вспомнил.
Перерисую все квадратики! Потом напишу спецификацию. Потом отдам ее почитать людям. Потом начну рисовать БД. Отдам ее людям.
Устрою шторм, все перефигячу ваще или чуть-чуть. И буду это делать до тех пор, пока есть время и силы. Нууу в общем-то, там уже постепенно отдам всю работу программерам, но постоянно буду отслеживать, что происходит.
Главное следить за тем, чтобы квадратики как можно меньше касались друг друга. И вот, чтобы поприкосновения квадратиков менялись как можно меньше. То что внутри - отследить очень тяжело, просто жуть. Иногда мне кажется, что лучше про это не думать, а то можно испортить себе нервы.
Ну когда схема БД будет более менее устойчива, нарисую ее в ErWin-е или кто-нить другой нарисует.
Хотя, как бы я не старался в процессе работы, все меняется, приходится перефигячивать абсолютно все. Эволюция товарищи, эволюция, в т.ч. и в головах наших клиентов!!!
Тут главное общение, все схемы и спецификации - это хорошо, НО все равно, блин, все думают по-своему. Чтобы все одинаково думали - должен произойти процесс индоктринации (хы, словечко означающее воспитание), а это очень длительный процесс. Да и эти схемы и документы, блин, жрут время, очень много времени...
Прошу прощения за простоту своего текста, не люблю эти армиканские термины, хочу быть простым и понятным всем, вот.
Страницы