2.3 Методология rup

Безусловно, RUP - итеративная методология. Хотя выполнение всех фаз или какого-то минимального числа итераций нигде в RUP не оговаривается, весь подход ориентирован на то, что их достаточно много. Только при этом можно настроить процесс для последующих итераций, основываясь на результатах начальных. Ограниченное количество итераций не позволяет использовать в полной мере все преимущества RUP. Вместе с тем, RUP можно использовать и в "практически каскадных" проектах, включающих реально всего пару итераций: одну в фазе Построение и одну в фазе Передача. Именно такое количество итераций, как правило, реально используется в каскадных проектах. Ведь проведение испытаний и опытной эксплуатации системы предполагает внесение исправлений, которые могут предполагать определенные действия, связанные с анализом, проектированием и разработкой, то есть фактически являются еще одним проходом через все фазы разработки.

Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (то есть с официальным назначением рецензента, с предоставлением рецензентом достаточно полной рецензии в виде электронного или бумажного документа и т.д.) проводить все рецензирования, RUP представляет собой крайне формальную, тяжеловесную методологию. С другой стороны, RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности. Можно требовать детальной проработки и тщательного оформления каждого документа. Можно требовать предоставления столь же тщательно выполненной и оформленной рецензии. А можно ограничиться электронным письмом или наброском на бумаге. А, кроме того, всегда остается еще одна возможность - сформировать документ «в голове»: продумать соответствующий вопрос и принять соответствующее решение [6].

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

3. Модель Extreme Programming (xp)

3.1 Ориентация, принципы и практика xp

Экстремальное программирование является примером, так называемого метода «живой» разработки. Экстремальное программирование– сравнительно молодая методология разработки программных систем, основанная на постепенном улучшении системы и разработки ее очень короткими итерациями [7]. По своей сути экстремальное программирование (XP) – это одна из так называемых «гибких» методологий разработки ПО, представляющая собой небольшой набор конкретных правил, позволяющих максимально эффективно выполнять требования современной теории управления программными проектами.

XP ориентирована на:

• командную работу с тесными связями внутри команды и с заказчиком;

• разработку наиболее простых работающих решений;

• гибкое адаптивное планирование;

• оперативную обратную связь (путем модульного и функционального тестирования).

Основными принципами XP является разработка небольшими итерациями на основании порции требований заказчика (т.н. пользовательских историй), написание функциональных тестов до написания программного кода, постоянное общение и постоянный рефакторинг кода.

Основными практиками XP являются:

Планирование процесса; частые релизы; метафора системы; простая архитектура; тестирование; рефакторинг; парное программирование; коллективное владение кодом; частая интеграция; 40-часовая рабочая неделя; стандарты кодирования; тесное взаимодействие с заказчиком.3.2 Методология XP

Из всех гибких методологий XP – самая известная. XP стоит на четырех китах: Коммуникация, Обратная связь, Простота и Смелость. Из них следуют двенадцать практик, которым должны следовать проекты, использующие ХР. Многие из этих практик представляют собой старые проверенные техники, которые, тем не менее, уже забыты (включая большинство предсказуемых процессов). ХР не только воскрешает к жизни такие техники, но и соединяет их таким образом, что все они поддерживают и усиливают друг друга. В нем тестирование является той основой, на которой строится разработка. При этом каждый программист пишет тесты одновременно с кодом разрабатываемой системы. Эти тесты используются при постоянной интеграции и в процессе сборки системы, что дает стабильный фундамент для дальнейшей работы.

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

Экстремальное программирование, как процесс, даёт новое дыхание давно придуманным подходам к разработке программного обеспечения. Это такие подходы как Модульное тестирование (Unit testing), Переработка кода (Refactoring), Парное программирование (Pair programming), Нормированный рабочий день (40-hour week).

По результатам исследования, проведенного независимой компанией Spikes Cavell в Великобритании в финансовом секторе, основной причиной неудачи программных проектов является срыв сроков сдачи (75%). Так экстремальное программирование представляет возможности для гарантирования успеваемости и контроля сроков. Это достигается посредством эффективного планирования, автоматического контроля качества и формирования быстрых обратных связей, в том числе и с заказчиком [8].

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