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

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

Комментарии

Страницы

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

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

Однако, проблема не в MBA, а в детях. Всякие там дети (люди с детским мышлением) получают MBA и лезуць в бусинес, не имею нихрена никакого опыта. Вот эти всякие дети ишчуць механизмы(RUP, CMM, ISO9000), чтобы заставить все работать, как в книжке написано.

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

Они бяруць книжки и наперад!!! И што? Конь в пальто!

Аватар пользователя Allis
Full oblivion isn't my name!
Аватар пользователя Dionique
2Allis

Зрелось, зрелость!!!

Что такое зрелось, как половые органы обросли, так мы и созрели...

Все пытаются всех проверить, кто созрел, а кто нет. да у каждого все по-своему. Я не могу понять, почему ИТ всегда отделяют от других видов бизнеса. Возьмите производство компрессорного оборудования. Разве у всех контор единая методология менеджмента? Нет.

А создание дизайна автомобилей? Тоже нет. Вон чуваки из BMW всех воих дизайнеров оправляют на пол года далеко, чтобы глаза их не видели, лишь хоть че нового придумали...

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

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

>Но с другой чем дальше дело заходит тем неповоротливей становится вся машина.

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

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

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

P.S. Под "машиной" я понимаю контору, где более 1 человека.

И еще, мне думается, что нужно помнить о разделении труда. Разделение труда эффективно с определенного момента и до определенной точки! В других случаях это разделение только вредит.

Именно разделение труда создет машины. Когда мы делим лшюдей на тех, кто встречается с заказчиком, кто рисует рисуночки, кто пишет код, кто рассказывает заказчику как и что работает мы УЖЕ создаем машины.

>Да еще сколько очков вы получили бы по тесту Джоела?

Ну может пару очков бы и получил. Ваще дядька мне нравится, он очень простой и понятный, таких мало... Эднако его взгляд принадлежит только ему одному, поэтому, господа, ФИЛЬТРУЕМ БАЗАР ВСЯКИХ ТАКМ УМНЫХ ДЯДЗЕК!!! АЕ, КАМ ОН!!!

Аватар пользователя FireFalcon
>The bigest of these is that you do not have understand the process that you are managing.

Можно подписаться. На мой взгляд, проблема в объеме знаний. Чтобы стать хорошим PM в IT, надо знать дисципилны управления проектом (работа с людьми, планирование, контроли и т.п), методики создания ПО (контроль конфигурации, тестирование и т.п), а еще лучше уметь создавать ПО. Получается, что без большого опыта хорошим PM не стать, просто времени не хватит. Если подметать улицы можно научиться за полчаса и за неделю-другую достич высот в этой сфере, то отлично управлять проектом создания ПО в идеале может опытный разработчик, знакомый с большим количеством методик и знающий дисциплины PM. Таких мало.

Хорошим разработчиком можно стать года за три. На опробирование методик еще пару лет минимум. Научиться менеджменту еще года два. Получается, что надо лет семь практики. Минимум.

Кроме того, сложно найти человека, у которого есть таланты программиста и менеджера одновременно. Вот и получается, что классных PM в IT очень мало.

Аватар пользователя Dionique
>...отлично управлять проектом создания ПО в идеале может опытный разработчик, знакомый с большим количеством методик и знающий дисциплины PM. Таких мало.

Хрен его знает. Рецептов нет. Должны быть и личностные качества и опыт. На моей практике была контора, где был очень сильный директор. Он был монстром в проектировании и кодинге. Таких объектных моделей, которые делал он, я больше нигде не видел. Но он совершенно нифига не понимал во заимоотношениях между людьми, не имел четкой направленности действий. В результате слил весь бизнес, ща немного держится на плаву, а мог же ведь достичь космических высот. В чем проблема - он не умел говорить с людьми и не обладал стратегическим мышлением.

>Хорошим разработчиком можно стать года за три. На опробирование методик еще пару лет минимум. Научиться менеджменту еще года два. Получается, что надо лет семь практики. Минимум.

Можно так, а можно забить на все и равться в бой. Мне думается, это происходит даже чаще. Если менеджер 0 в разработке, но он умеет обращаться с людьми, координировать их работу, понимает, что от него хочет высшее руководство, он справится. Главное, чтобы было желание и злость!!!

Anger, anger, anger!!!

Get out of my way!!!

Gonna kill you!!!

Will not ever stop myself!

Gonna get you!!!

>Кроме того, сложно найти человека, у которого есть таланты программиста и менеджера одновременно. Вот и получается, что классных PM в IT очень мало.

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

Аватар пользователя Piligrim
Ну наконец то КВ разродилась щепетильной темой! Господи! Наконец - то я услышал (то биш - прочитал) умных людей. Аж не по себе стало... Однако хочу добавить и свой писк в это хор. По воле случая я работаю сам себе всем. И постановщиком, и 5 -10 программерами, и всеми прочими составляющими сурьёзной программерской фирмы. В отличии от таких фирм, которым: продал продукт и в сторону, мне деваться некуда. С ним я живу, получая и удовольствие и шишки от эксплуатации моего софта. Удовольствие бешенное. Шишки пихают на совершенствование. Так как фирма моя спецефична, то и база и софт то же спецефичны. Для того, что бы спроектировать базу для такого предприятия нужно досконально изучить всё о нём. И вот здесь сторонние программерские фирмы для меня давно потеряли авторитет. Хотя им ещё удаётся навешать лапшу нашим высоким чиновникам. Начало последней эпопеи по рзработке "офигенно универсального и всеобъемлешего" ПО вот тут у меня на столе лежит и относится к 1996 году. С тех пор и идёт эта песня... Кстати, тот проект про который зам. министра связи в телевизоре освещал (это о всебелорусской справке) вот это он и есть. Главный проектировщик - Компоненты и системы. Проект всё больше мертвеет. К чему это я? Да вот тот случай где на лицо проект без руля и без ветрил. Но вот поможет ли ему какая - либо методика сомневаюсь. С одной стороны: недостаточная компетенция, "маниловщина" и безответственность заказчика, с другой - не желаниие КиСы влазить, по её мению, не в своё дело и породили этот заранее обречённый продукт. Но вот мне - то и пришлось с этого самого 1996 года заниматься тем, чем по сей день занимаются ТАМ. Пока всё начиналось и я сам ещё ни фига не представлял, всё казалось просто. Но когда я в третий раз начал проектировать систему, тут уже и захотелось всё делать по науке. Тогда и проштудировал и Гарди, и UML, и много ещё чего. Бо трудно стало крутится более чем в 200 таблицах, в трёх сотнях ХП и всей прочей требухе. Не одни сутки побеждал Retional Rouse(прости Господи!Може не правильно написал). И всё это пытался как-то применить на деле. Но мало по малу пыл потерял. Я не могу назвать свой проект маленьким. Он не меньше, чем у КиСы. Но вот вышеуказанные технологии в чистом виде для меня оказались просто не приемлемы. Они может хороши для моделирования каких нибудь производственных процессов, автоматики и т.д. Но тут же дают сбой при пректировании баз данных. Кстати это чувствовал и сам Гарди Буч. В своей книге про ООП он очень не внятно пишет о базах данных и у меня полное впечатление, что это не его тема. В общем-то дело именно в ООП. Ну не заточено большинство современных серверов баз данных под эту технологию! Есть, правда, несколько, но они мало отработаны и имеют недостаточную информационную базу и програмное окружение. Наприер СУБД Cashe. А вот остальные имеют класичесское лицо. Проектируя по описываемой технологии базу, можно увязнуть уже на уровне подготовки самой методики. На мой взгляд, для использования всей этой системы в любой компании необходимо подключать к штату ещё группу спецов именно по этой методике, чтобы как-то оживлять её. Но нельзя отрицать, что в ней имеются всё же великолепные средства анализа. Да и визуализация, и документирование - всё же это сильная сторона такого ПО как Rational или ERWin. Так что? Отказаться от них? Ну нет.Совсем не обязательно. Я проектирую в своих средах, конретно заточенных под нужный мне сервер. А уже в процессе и по окончанию "затягиваю" базу в Rational или(чаще) в ERWin. Теперь: можешь сам любоваться, а можешь и руководить кем-то(если есть кем:o)). И вот ещё: - на мой взгляд для проектирования базы ни в коем случае нельзя привлекать большой коллектив. Если она уж очень велика (не по количеству записей, а по количеству классов), то лучше разделить её по задачам. Иначе она потеряет управляемость и, как бы это сказать? - Единоначалие, что-ли... А вот потом, всё "навесное" окружение и интерфесы вполне можно раздать.

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

Аватар пользователя Dionique
Нууу...если говорить о проектировании, то можно смело заметить - лучше бумаги ничего нет.

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

За это я больше всего люблю бумагу!

Всякия там ErWin, BpWin-ы и Rational-ы лучше использовать, когда приходится иметь дело с большим числом квадратиков. За ними следить проще, легче найти ошибки.

Но признаюсь, не очень люблю Rose. Эта сволочь не дает работать без мышки в некоторых очень ответственных ситуациях, а это ох как выводит, злит...

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

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

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

Круто конечно и весьма. Только это реальный мир и рвать жопу на британский флаг за чей-то левый продукт не стоит. Другое дело если у тебя есть идея и сколько-то денег на первое время, если ты собрал нормальную команду под этот проект.

А так как есть это просто работа. Можно делать ее спокойно и профессионально. Именно так это делали лучшие из известных мне менеджеров.

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

Поэтому я нахожу зрелость проекта решающим фактором в разработке програмного обеспечения. Чем старше проект и чем больше у него пользователей, тем больше внимания уделяется их поддержке.

У меня такое чувство что ты думаешь только про самый первый выпуск когда определение требований очень критично.

Я же довольно далеко ушел от этого и скорее думаю о том какие инструменты и насколько могли бы облегчить построение дествительно большой системы с большим количеством связей между компонентами

Звучит занудно, не так ли?

Аватар пользователя Allis
2Dionique Интересно как это ты собираешься спроектировать сколько нибудь большую систему без логического анализа структуры БД. Так что бы то что получится можно было отлаживать и поддерживать?

Впрочем лучше всего проектируется на бумаге где-то между 12 и часом ночи. Так что неприятие тяжеловесных инструментов готов с вами разделить

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

>Интересно как это ты собираешься спроектировать сколько нибудь большую систему без логического анализа структуры БД. Так чтобы то что получится можно было отлаживать и поддерживать?

Нууу лана, немного расскажу, хотя в прочем, оно всегда само собой получается, вот.

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

Соберу людей, расскажу им про квадратики. Устрою этот, как его, брэйн-шторм, во, вспомнил.

Перерисую все квадратики! Потом напишу спецификацию. Потом отдам ее почитать людям. Потом начну рисовать БД. Отдам ее людям.

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

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

Ну когда схема БД будет более менее устойчива, нарисую ее в ErWin-е или кто-нить другой нарисует.

Хотя, как бы я не старался в процессе работы, все меняется, приходится перефигячивать абсолютно все. Эволюция товарищи, эволюция, в т.ч. и в головах наших клиентов!!!

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

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

Страницы