Методологии разработки ПО

У любой компании, занимающейся разработкой ПО, рано или поздно просыпается интерес к различным методологиям разработки. Это связано с расширением команды, возрастающей сложностью проектов, желанием улучшить качество продуктов и сделать их выпуск более предсказуемым. Когда над проектом трудится хотя бы 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

Процесс имеет четыре фазы:

  1. Исследование (Inception)
  2. Уточнение плана (Elaboration)
  3. Построение (Construction)
  4. Развертывание (Transition)

На каждой из фаз основное внимание уделяется разным процессам. На фазе исследования идет сбор и анализ требований, на фазе уточнения плана - анализ требований и проектирование системы, на фазе построения - разработка и кодирование, на фазе развертывания - тестирование и распространение.

Методология RUP основана на 9 основных потоках:

  1. Бизнес-анализ (анализ потребностей)
  2. Сбор требований и управление требованиями (перевод требований в функциональные спецификации)
  3. Анализ и моделирование (перевод требований в программную модель)
  4. Кодирование
  5. Тестирование (проверка того, что программа соответствует требованиям)
  6. Управление конфигурацией и изменениями (отслеживание изменений в разных версиях продукта)
  7. Управление проектом
  8. Создание и поддержка среды разработки
  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

Версия для печатиВерсия для печати

Номер: 

09 за 2003 год

Рубрика: 

Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!
 

Комментарии

Страницы

Аватар пользователя Groover
2Dionique:

Интересненькая перепалка получилась. А все же, хотелось бы узнать: каким же образом организуется процесс разработки в Вашей организации. Кстати, Вы вроде как являетесь прожект манагером. Кому как не Вам рассказать об этом. Я не прошу указывать те вещи, которые являются секретными для общего пользования.

должна же таки быть какая то методика. Или же как сказал FireFalcon (PM): приходят утром девелоперы и давай клепать код?

Аватар пользователя Андрюха
2 Dionique

Супер!!! :)))) Сразу видно человека утомленного маркетолагами и прочими "oxygen drive moron'ами". Из выдержек можно делать пособие:

>>"...проект нуждается в своем процессе" - эта хрень выглядит как "каждому кабинету по бюрократу" в вашем понимании

>>Захочется тим-лидеру потом сделать так, чтобы UML пользовались." - если ему захочется, надо его по голове палкой ударить, чтобы он больше не хотел, а то че-то хочет, а сам не знает, чего

>>роботы - это дибилы из космоса, они медленно двигаются, не обладают гибкостью мышления. Роботы нужны на войне, а не в творческой работе.

>>Как у микрософта и всех других умных контор - поделить на маленькие функциональные команды 5-6 чел

>>да, в прочем, программера можно научишь Вашему емелю за 30 минут, зато проектировать придется учить несколько лет. так что не надо подменять опыт всякими там емелями.

5,5,5,4,5 :)

>>В любом случае, все самое юзабельное - как сценарии (Use Case), UML, MS Project, MS Word не принадлежат ни одной из методологий, слава богу

+ CVS (VSS, etc) и остаток мсофиса (outlook, visio, excel, powerpoint)

Action Item: Все перевести на аглицкий, отправить в комиксы Dilbert'а

;)

Аватар пользователя FireFalcon
Карашо. Lets move.

>Они появились гораздо раньше, даже раньше UML-я. Не удивлюсь, если их переняли из каких-нить ролевых игр или еще у чего-нить.

Правильно. Но к сожалению многие разработчики о них не знают. Откуда-то узнавать надо? Надо. Откуда? Вот статейка в газете попалась, может пошарятся по инету и откопают полезного на будущее.

>Как у микрософта и всех других умных контор - поделить на маленькие функциональные команды 5-6 чел.

Тогда возникают проблемы коммуникаций между командами. И я сильно сомневаюсь, что будет достаточно личного общения.

>>Кто-то должен знать, какая хрень из какой методологии или вообще понадобится в начинающемся проекте."

>Перевожу на русский: "Кто-то должен знать, как кому голову заморочить с начала проекта, чтобы его постоянно боялись".

Неправильно на русский переводите. Есть набор методик. Например, управление конфигурацией, планирование, итерационность. Каждая методология содержит свой набор методик. Так что общее знакомство с методологиями позволит знать эти методики и затем попробовать некоторые из них на практике.

Аватар пользователя Dionique
2Groover и всем, всем, всем...

Скажу честно, я разочарован в менеджменте, как науке, а также во всяких там методологиях...

Все это - результаты работы консультантов. Консультанты - это люди, которые абстрагируют реальность, придумывают солюшаны и умные фразы, типа: customer-oriented, use case-driven, platform-independent...

Они вешают ярлыки на любые проблемы, как делают доктора в больницах. У вас - гейморит, у вас - простотит, а у вас - душа болит!

Нам, людям, которые имеют дело с реальными проектами приходится эту абстрагированную реальность использовать. И что получается, мы подстраиваем свою реальность под ихния там абстракции. В результате мы добиваемся того, что наша реальность изменяется под напором абстракций - мы обслуживаем чужие абстракции.

Что это дает нам, маленьким компаниям? Ничего полезного. Вместо ориентации на свои ежедневные проблемы мы ориентируемся на синтаксис UML диаграмм, бесконечный поток сценариев, стараемся все согласовать и красиво оформить... Но зачем, смысла нет!!! мы теряем время, не получая никакой ценности от этих процессов. Задачи наших клиентов очень динамичны, т.к. и сами клиенты очень динамичны. Мир меняется очень быстро, нам, маленьким компаниям, приходится к нему приспосабливаться, чтобы выжить.

Решение тут одно - делать только то, что действительно может помочь разобраться в требованиях, объяснить задания, обеспечить четкое понимание, согласование действий, постоянное обучение, доверие между людьми...

Для каждого проекта эти процессы очень индивидуальны, т.к. зависят от конкретных людей: от их опыта, культуры, привычек и настроения.

Однако, всякия там методологии полезны. Теория позволяет разложить реальность на абстракции и лучшее понять эту реальность. Именно понять, но, бл#, не переделать в абстракцию абстракции.

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

В заключение добавлю, что громкие методологии аля RUP могут быть полезны для больших корпораций. Почему? Потому, что такие корпорации могут приспосабливать окружающую среду под себя. Эти конторки могут воздействовать на своих клиентов, т.к. имеют силу. И все же, большая часть таких компаний разрбатывает методолгии под себя, учитывая свою специфику.

Пока мы небольшие, мы должны сторониться бюрократизма, присущего многим методологиям, мы должны стремиться быть гибкими, быстрыми, умными, постоянно развиваться и главное - думать, бл#, ДУМАТЬ!!!

Аватар пользователя Groover
согласен. Добавлю: в любом случае методология должна существовать и не важно кто ее создал, пусть даже тот самый Рэшинал. В конечном итоге методология выбирается и используется не в чистом виде. Да проще и правильнее использовать то, что уже создано, над чем люди уже ломали головы. Зачем изобретать велосипед. Он уже есть и не один

Ну а если не нравится - пожалуйста, разработайте свою методику. Но я уверен - нового вы придумать врятли сможете. В любом случае это будет микс из уже существующих, и направленных именно на конкретный проект.

Итак, конклюжин: теорию надо знать. Надо знать и разбираться в разных методологиях, а уж затем выбирать каким образом это можно применить на практике.

Аватар пользователя Groover
2 Dionique

ну вот, сам загнал себя в угол. всетаки используети вы методику XP, что действительно хорошо для небольших (1-6 чел.) проектов. А как быть когда разработка идет 30-ю, 50, 100 людьми. И проект ведется не месяц, и даже не год. О каком экстрим программинге может идти речь?

Аватар пользователя Dionique
2Groover и FireFalcon (super-PM)

Вы, господа, мыслите немного не моими категориями, очевидно, из-за этого у нас недопонимание, недопонимание того, чего я хочу до Вас донести.

Вот статья неглупого чувака:

http://www.maxkir.com/sd/people_as_nonlinearRUS.htm

Надеюсь она немного приблизит Вас к моему mindset-у.

И еще:

"Ну а если не нравится - пожалуйста, разработайте свою методику. Но я уверен - нового вы придумать врятли сможете. В любом случае это будет микс из уже существующих, и направленных именно на конкретный проект."

Мы всегда разрабатываем свои собственные методологии. Микс методологий невозможен. Возможен микс практик, как использование сценариев, тестирование до кодинга, объединение в функциональные команды. Эти практики существуют отдельно от методологий.

"Итак, конклюжин: теорию надо знать. Надо знать и разбираться в разных методологиях, а уж затем выбирать каким образом это можно применить на практике."

Мы должы изучать практики а не метоологии, мы должны тренироваться объединять самые лучшие практики!

Аватар пользователя Dionique
2 Groover

"ну вот, сам загнал себя в угол. всетаки используети вы методику XP, что действительно хорошо для небольших (1-6 чел.) проектов. А как быть когда разработка идет 30-ю, 50, 100 людьми. И проект ведется не месяц, и даже не год. О каком экстрим программинге может идти речь?"

Да не использую я никакого экстрим программинга. Ваще ничего не использую, хватит на меня ярлыки вешать. Не сметана я и не молоко.

А на счет 100 человек, быть надо проще и все получится. Главное, не думать про методологии. Про них думать нужно во время учебы, во время работы нужно исходить из конкретной ситуации.

Аватар пользователя FireFalcon
>Мегафак, столько можно писать про RUP, рисуя всякие там спирали и прочие пупурышки, как на презервативах. Это и так понятно, любой творческий процесс проходит через несколько итераций...

А многие не знают, к сожалению. Это вам понятно, у вас опыт большой, а сколько блин есть народу, которые вообще не знают ни о юз-кейсах, ни об итерациях и т.п. Особенно это касается веб-программеров. Ну, знают хорошо PHP и MySQL. Ну, еще CVS может пользуются. И часто это все!

"Какие итерации? Нифига такого не знаем. Какие сценарии? Какие требования? Нахрена все это? "

Думаете, легко объяснить, зачем это надо?

>что получается, мы подстраиваем свою реальность под ихния там абстракции.

Правильно делать наоборот. Надо эти абстракции под реальность подстраивать.

>Пока мы небольшие, мы должны сторониться бюрократизма, присущего многим методологиям, мы должны стремиться быть гибкими, быстрыми, умными, постоянно развиваться и главное - думать, бл#, ДУМАТЬ!!!

Ну, а я что говорил? ;)

Аватар пользователя FireFalcon
К сожалению, я не super PM и даже не рядом. Статью http://www.maxkir.com/sd/people_as_nonlinearRUS.htm я, естественно, читал. На том сайте вообще много интересного.

>Мы должы изучать практики а не метоологии, мы должны тренироваться

объединять самые лучшие практики!

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

Страницы