Сравнение технологии rup и технологии экстремального программирования реферат

Обновлено: 05.07.2024

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

Методология разработки – подход к созданию и сопровождению информационных систем в виде жизненного цикла ИС, представляющий его в виде последовательности стадий, каждая из которых разбита на этапы, и выполняемых на них процессов.

Методология RUP

Разрабатывайте программное обеспечение итеративно;
Управляйте требованиями;
Используйте компонентную архитектуру;
Визуализируйте модель программы;
Проверяйте качество программы;
Контролируйте изменения программы.

Рис 1. Рабочие процессы RUP

Ядро RUP составляют следующие рабочие процессы, пересечение которых показано на рисунке 1., среди которых 6 процессов инжиниринга и 3 вспомогательных процесса:

бизнес моделирование;
управление требованиями;
проектирование;
реализация;
тестирование;

развертывание.

конфигурационное управление и управление изменениями;
управление проектом;
поддержка среды разработки.

+ Сравнительная легкость описания и наглядность моделей

+ Возможность адаптирования методологии UML собственным элементам и видам диаграмм

+ Возможность автоматической генерации кода на основе построенных моделей при проектировании с использованием case средств, поддерживающих методологию

– Невозможность проведения детального анализа процессов

– Неполнота и незавершенность некоторых видов диаграмм, возможность их неверной интерпретации

Методология MSF

Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.
MSF включает четыре фазы: анализ, проектирование, разработку, стабилизацию. Она является итерационной, предполагает использование объектно - ориентированного моделирования. MSF по сравнению с RUP в большей степени ориентирована на разработку бизнес - приложений.

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

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

+ снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

+ непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

+ раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

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

- при итерациях приходится отбрасывать часть сделанной ранее работы.

Сравнительный анализ методологии RUP и MSF

Сравним две крупные методологии, предназначенные специально для создания корпоративных систем - Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF).

Технология	Оптимальная команда	Соответствие стандартам	Допустимые технологии и инструменты	Удобство модификации и сопровождения
RUP	10-40 чел	Стандарты Rational	UML и продукты Rational	Удобно
MSF	3-20 чел	Адаптируемая	Любые	Удобно

RUP. В основе методологии RUP лежат процессы, причем следует отметить такие особенности методологии, такие особенности подхода, как архитектурную центричность, а также основу на Use Cases – сценариях использования, и итеративность.

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

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

Поскольку RUP – методология строгая, существуют вполне определенные критерии выхода, как из каждой фазы, так и из каждой итерации. Существуют вполне определенные артефакты и вполне определенные метрики, которые описывают степень их готовности. На первой стадии — это основные высокоуровневые требования к системе. На втором этапе – архитектурный проект и, соответственно, диаграммы, которые описывают программный продукт, если на первом этапе это были Use-Сase. На третьем этапе – программное решение в виде кода и документации. И на четвертом этапе – полный релиз, готовый к передаче заказчику.

MSF. Методология MSF основана на гибкой процессной модели и включает в себя командную разработку. Масштабирование, команды команд – это достаточно важные составляющие MSF. Нужно сказать, что MSF поддерживает полный жизненный цикл разработки, т.е. он включает в себя как MSF (Microsoft Solutions Framework), так и MOF (Microsoft Operations Framework), которые объединяют процессы концептуализации, создания, внедрения, сопровождения, расширения, развития программных продуктов.

Прежде всего, важнейшим фокусом этой методологии является ориентация именно на бизнес, требования заказчика. Поэтому первое, что требуется – это партнерство с клиентом. При этом клиент понимается достаточно широко. Это может быть не обязательно конечный заказчик, но это может быть целый ряд людей, которые называются стейкхолдерами, или людей, которые вносят свой капитал в создание и развитие программного продукта. Одной из ценностей методологии является открытая коммуникация. Суть её состоит в том, что на самом деле представление о продукте, особенно на уровне первоначальной идеи, первоначальной концепции с точки зрения разработчика и с точки зрения заказчика, могут весьма существенно отличаться. При этом на стороне разработчика существует порядка 15 и даже более ролей, каждая из которых на самом деле имеет свое видение и свой взгляд на продукт и на программный проект.

Заключение

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

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

Приведен обзор предсказуемых методологий на примере Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF). Были обсуждены характерные черты этих методологий. Наряду с общими деталями были выявлены также и некоторые сложные моменты процесса разработки, связанные с управлением командой, планированием, стратегией менеджмента, взаимодействием с заказчиком, жизненным циклом программного продукта, внедрением и реализацией выбранной методологии.

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

Список источников

1. Fazar W., Program Evaluation and Review Technique // The American Statistician, Vol. 13 (№ 2), 1959, С. 10.

2. A.A. Ермолаев, В. М. Дёмкин. Управление проектами по разработке программных продуктов.

4. Уокер Ройс. Управление проектами по созданию программного обеспечения. Издательство "Лори", 2002 г. 424 с.

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

Как получится…

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

А как обстоит дело с применением итеративного подхода? Увы, как правило, он в таких проектах не используется. Прежде всего потому, что он бы позволил еще на первых итерациях оценить проект как крайне сомнительный и требующий срочного вмешательства более высокого руководства для наведения порядка. Ведь в итеративном проекте традиционный ответ программиста, что у него уже все на 90% готово, проходит только до момента завершения первой итерации…

Структурные методологии

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

Тем не менее основу этих методологий составляют последовательный переход от работы к работе и передача результатов (документов) очередного этапа участникам последующего.

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

Гибкие методологии

Гибкие методологии базируются на десяти принципах, из которых мы назовем лишь те, которые определяют оценку этих методологий по выбранным параметрам:

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

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

eXtreme Programming, или XP (экстремальное программирование)

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

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

Crystal Clear

Crystal — семейство методологий, определяющих необходимую степень формализации процесса разработки в зависимости от количества участников и критичности задач.

Методология Crystal Clear уступает XP по производительности, зато максимально проста в использовании. Она требует минимальных усилий для внедрения, поскольку ориентирована на человеческие привычки. Считается, что эта методология описывает тот естественный порядок разработки ПО, который устанавливается в достаточно квалифицированных коллективах, если в них не занимаются целенаправленным внедрением другой методологии.

Основные характеристики Crystal Clear:

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

Помимо Crystal Clear, в семейство Crystal входит еще несколько методологий, предназначенных для выполнения более крупных или более критических проектов. Они отличаются несколько более жесткими требованиями к объему документации и вспомогательным процедурам, таким как управление изменениями и версиями.

Feature Driven Development

FDD включает пять процессов, причем последние два повторяются для каждой функции:

разработка общей модели;
составление списка необходимых функций системы;
планирование работы над каждой функцией;
проектирование функции;
конструирование функции.

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

Общие черты

Список гибких методологий в настоящее время достаточно широк. Тем не менее описанные нами методологии дают весьма полное представление обо всем семействе.

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

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

ГОСТы

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

В настоящее время в России действуют старые ГОСТы 19-й и 34-й серий и более новый ГОСТ Р ИСО МЭК 122207. ГОСТы 19-й и 34-й серий жестко ориентированы на каскадный подход к разработке ПО. Разработка в соответствии с этими ГОСТами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Таким образом, сразу строгое следование этим стандартам не только приводит к каскадному подходу, но и обеспечивает очень высокую степень формализованности разработки.

ГОСТ 12207, в отличие от стандартов 19-й и 34-й серий, описывает разработку ПО как набор основных и вспомогательных процессов, которые могут действовать от начала и до завершения проекта. Модель жизненного цикла может выбираться исходя из особенностей проекта. Таким образом, этот ГОСТ явно не запрещает применение итеративного подхода, но и явно не рекомендует его использование. ГОСТ 12207 также более гибок в части требований к формальности процесса разработки. В нем содержатся только указания на необходимость документирования основных результатов всех процессов, но нет перечней требуемых документов и указаний относительно их содержания.

Таким образом, ГОСТ 12207 допускает итеративную и менее формализованную разработку ПО.

Модели зрелости процесса разработки (CMM, CMMI)

Помимо государственных и международных стандартов, существует несколько подходов к сертификации процесса разработки. Наиболее известными из них в России являются, по-видимому, CMM и CMMI.

Требования CMM и CMMI

После появления CMM стали разрабатываться специализированные модели зрелости для создания информационных систем, для процесса выбора поставщиков и некоторые другие. На их основе была разработана интегрированная модель CMMI (Capability Maturity Model Integration). Кроме того, в CMMI была предпринята попытка преодолеть проявившиеся к тому времени недостатки CMM — преувеличение роли формальных описаний процессов, когда наличие определенной документации оценивалось значительно выше, чем просто хорошо налаженный, но не описанный процесс. Тем не менее CMMI также ориентирован на использование весьма формализованного процесса.

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

Связь CMM и CMMI с итеративной разработкой более опосредованная. Формально ни та ни другая не выдвигают конкретных требований к тому, чтобы придерживаться каскадного или итеративного подхода. Однако, по мнению ряда специалистов, CMM в большей степени совместима с каскадным подходом, в то время как CMMI допускает также и применение итеративного подхода.

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

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

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

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

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

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

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

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

3.3 Жизненный цикл XP

Модель жизненного цикла XP является итерационно-инкрементной моделью быстрого создания (и модификации) протопопов продукта, удовлетворяющих очередному требованию (user story). Жизненный цикл XP представлен на рис.6.

Рис.6. Жизненный цикл XP

Особенности этой модели представлены на схеме. Основными фазами модели можно считать:

Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. User Story являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.

Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования - получение оценок того, что и как можно сделать за 1-3 недели создания следующей версии продукта.

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

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

Выпуск релиза – разработанная версия передается заказчику для использования или бета-тестирования.

По завершению цикла делается переход на следующую итерацию разработки.

Люди и их общение более важны, чем процессы и инструменты

Работающая программа более важна, чем исчерпывающая документация

Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта

Отработка изменений более важна, чем следование планам

Кроме того, как было выше сказано, в XP есть несколько правил (техник), характеризующих особенности модели его жизненного цикла:

Живое планирование (planning game) - как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в первую очередь, бизнес-приоритетов заказчика и, во-вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.

Частая смена версий (small releases) - первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.

Простые проектные решения (simple design) – в каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Новые функции добавляются только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

Разработка на основе тестирования (test-driven development) – сначала пишутся тесты, потом реализуются модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.

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

Программирование парами (pair programming) - весь код пишется двумя программистами на одном компьютере, что повышает его качество (отсутствие ошибок, понятность, читаемость,…).

Постоянная интеграция (continuous integration) - система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции.

40-часоваярабочаянеделя – сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.

4. Сравнение технологий MSF, RUP и XP

Основные особенности MSF, RUP и XP можно свести в небольшую таблицу (Таблица 2) [9]. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется самой методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.

Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP – сопровождаемость. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации.

Таблица 2. Технологии MSF, RUP и XP

Допустимые технологии и инструменты

Удобство модификации и сопровождения

Rational Unified Process

UML и продукты Rational

Microsoft Solutions Framework

Сложно (зависимость от конкретных участников коллектива)

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

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

Преимуществами XP являются:

простота в использовании, адаптации, обучении;

устойчивость к внешним факторам, таким как текучесть кадров, нехватка денег, внезапное завершение финансирования;

учёт изменчивости требований и кардинального пересмотра всей системы;

равномерная загруженность всех членов коллектива;

быстрое включение в работу новичков с минимальным уровнем риска;

эффективный контроль работоспособности разрабатываемых систем;

увеличение производительности разработчиков;

предоставление дополнительных благ членам коллектива;

естественный профотбор членов команды;

низкая степень бюрократизма;

широкая известность и популярность.

От других известных методологий разработки его также отличает простота, низкая стоимость внедрения и общедоступность. По сравнению с известным процессом разработки Rational Unified Process (RUP), время интенсивного внедрения его в несколько раз меньше. Если внедрение RUP может занять от полугода до двух лет, то внедрение XP может быть выполнено в течение одного-двух месяцев. При этом сама технология RUP стоит около 600$. И это не считая сопутствующих программ, обучающего материала и повышенного требования к персоналу.

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

Заказчик должен подготовить документы, необходимые для внесения изменения и предоставить руководителю группы разработчиков на рассмотрение. При этом язык изложения требования должен быть строго формализованным, например Диаграмма прецедентов (Use-case diagram). После первоначального рассмотрения передать запрос менеджерам, которые в свою очередь передадут его аналитикам.

Аналитики построят высокоуровневые модели, проведут подсчёт сложности, количество человеко-часов, необходимых на доработку, и предоставят информацию менеджерам.

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

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

Отдел тестирования должен внести соответствующие изменения в тест-план. После подготовки всех необходимых документов, программисты приступают к кодированию, при этом отсутствие любого члена команды грозит срывом сроков сдачи. Этот этап является самым непродолжительным, примерно 10% от всего времени на изменение.

Уточнение моделей. Тестирование изменившейся части. Тестирование системы в целом

Заказчик тесно общается с разработчиками и знает, что изменения могут быть внесены достаточно просто. Поэтому он не боится предлагать внести изменения, когда это действительно необходимо. Он формирует запрос на изменение в виде истории пользователя (User story), на понятном человеческом языке.

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

Вместе с заказчиком корректируется список историй для выполнения в рамках текущей итерации.

Один из программистов (или пара) берёт на себя ответственность за выполнение данной истории и приступает к работе. Это может быть не тот человек, который разрабатывал эту область ранее, за счёт коллективного владения кодом.

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

Программист разбивает историю на задачи и пишет для каждой модульные тесты (Unit test).

Программист кодирует каждую задачу и добивается выполнения всех тестов. Далее идёт проверка работоспособности истории с помощью приёмочных тестов. При этом работоспособность всей системы контролируется автоматически посредством ранее написанных тестов [10].

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

Ролей в XP также не так много, и здесь нет ограничений на совместимость их в рамках одного человека. Так, если следовать учению Microsoft Solution Framework (MSF), то программист не может быть одновременно менеджером, тестировщиком или техническим писателем. Хотя опыт показывает обратное, что, в свою очередь, является оправданной и довольно успешной практикой. В экстремальном программировании это даже приветствуется. Так, например, опытный программист может достойно совмещать, помимо своих основных обязанностей, роль тренера, наблюдателя и менеджера. Да, действительно, в Microsoft произвели ряд дорогостоящих исследований, которые показали определённую несовместимость ролей. Разработчики же экстремального программирования, глядя глубоко в корень, постарались устранить причину этой несовместимости. Это стало возможным за счёт усиления обратных связей, неявного автоматизированного и мануального контроля.

Есть также определённые условия, при которых достигается максимальная эффективность использования XP. Они включают следующие: группа разработчиков от двух до десяти человек, проект на срок до полугода и присутствие заказчика на месте разработки. Но это не является требованием. Большинством методик и принципов XP могут пользоваться и единичные программисты.

Заключение

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

Таким образом, в данной курсовой работе были рассмотрены вопросы управления проектами по разработке программного обеспечения на основе анализа современных методологий управления проектами.

Проанализировано состояние отрасли информационных технологий и тенденции в индустрии разработки ПО. Выявлена и обоснована острая необходимость в эффективных методологиях управления программными проектами.

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

На примере эволюции моделей процесса разработки ПО: водопада, водоворота и спиральной – прослежено начало пути, пройденного программной инженерией. К настоящему времени сформировались два альтернативных подхода к процессу разработки ПО (предсказуемый и адаптивный) и множество методологий, реализующих эти подходы. Приведен обзор предсказуемых методологий на примере Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF), и гибких – на примере Extreme Programming (XP). Были обсуждены характерные черты этих методологий. Наряду с общими деталями были выявлены также и некоторые сложные моменты процесса разработки, связанные с управлением командой, планированием, стратегией менеджмента, взаимодействием с заказчиком, жизненным циклом программного продукта, внедрением и реализацией выбранной методологии.

Выполнен сравнительный анализ методологий RUP, XP и MSF. Были представлены преимущества использования методологий RUP, XP и MFS, а также критерии выбора методологии в зависимости от сложности проекта и размера команды разработчиков.

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

Список использованной литературы

1. A.A. Ермолаев, В. М. Дёмкин. Управление проектами по разработке программных продуктов.

Уокер Ройс. Управление проектами по созданию программного обеспечения. Издательство "Лори", 2002 г. 424 с.

БекК. Экстремальное программирование. С - Пб.: Питер, 2002, 224 с.

Источник: А.Гаврилов. Технологии разработки программного обеспечения – MSF

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

Содержание

Прикрепленные файлы: 1 файл

реферат RUP.docx

Министерство образования и науки РФ

САРАТОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИМЕНИ Н.Г. ЧЕРНЫШЕВСКОГО

РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ

ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Реферат на тему: Модель разработки RUP

студент механико-математического факультета 442 группы

Котикова Дарья

Введение………………………………………………………… …………3
Понятие RUP……………………………………………………………….4
Структура RUP……………………………………………………………..6

3.1 Жизненный цикл…………………………………………8

3.2 Основные характеристики RUP…………………………9
3.3 Основные этапы разработки, согласно RUP…………………………………………………………..11
3.4 Продукты, поддерживающие RUP, внедрение системы……………………………………………………. 15

Заключение…………………………………………………… …………..17

Список литературы…………………………………………………… ….18
Приложения…………………………………………………… ………….19

В своем реферате мне бы хотелось более подробно рассмотреть модель RUP – Rational Unified Process, структурированная база знаний, которая была выпущена корпорацией Rational Software - ведущий производитель продуктов для создания сложных программных систем.

Унифицированный процесс является достаточно устоявшимся, т.к. это результат не одного десятилетия разработки и практического использования. Его разработка шла от Objectory Process (1987 год) через Rational Objectory Process (1997 год) к Rational Unified Process (1998 год). Изменение названия говорит о том, что произошла унификация процесса по многим параметрам: унификация подходов к разработке, использование унифицировано языка моделирования¹ и т.д.

Так что же такое RUP?

RUP это: - процесс разработки программного обеспечения;

- итеративная методология с очень широким диапазоном возможных решений в части формализации процесса разработки²;

- процесс с перестраиваемой конфигурацией, никакой одиночный процесс не подходит для всех случаев разработки программного обеспечения³;

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

RUP считается одной из самых лучших методологий. Одним из основных

¹Якобсон. А, Унифицированный процесс разработки ПО, стр.27

³ Крачтен Ф., Введение в Rational Unified Process, стр.14

пунктов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).

Целью RUP является гарантия высокого качества программного продукта, которое удовлетворяло бы потребностям конечного пользователя в пределах установленного (ожидаемого) временного графика и бюджета. RUP достаточно четко определяет: кто и что должен делать в проекте.

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

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

¹ Крачтен Ф., Введение в Rational Unified Process, стр.13

И еще, т.к. RUP поддерживает объектно-ориентированную технологию, то разработка ПО рассматривается как процесс создания артефактов (технические искусственные объекты).

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

RUP поддерживает и объективно осуществляемое управление качеством. Оценка качества всех работ, выполняемых любыми участниками проекта, использует объективные метрики и критерии. Методология RUP создавалась с прицелом на поддержку управления качеством в рамках требований SEI CMM/CMMI.

В основе методологии RUP лежит "пошаговый подход", который определяет этапы жизненного цикла, контрольные точки, правила работ для каждого этапа, а так же упорядочивает проектирование и разработку ПО. Для каждого этапа жизненного цикла методология задает:

- состав и последовательность работ, а также правила их выполнения;

- распределение полномочий среди участников проекта (роли);

- состав и шаблоны формируемых промежуточных и итоговых документов;

- порядок контроля и проверки качества.

RUP- процесс разработки в двух измерениях: по основным потокам работы и по стадиям жизненного цикла системы (см. приложение 1).

Основные потоки работы - это статистическое измерение (исполнители, действия и др.). Динамическое измерение-это соответственно, стадии жизненного цикла (этапы, итерации и др.).

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

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

Статическая структура RUP состоит из 6 дисциплин, основных процессов, в которые группируются работы, задачи, артефакты и роли:

— Бизнес-моделирование (Business modeling) – описание существующих бизнес процессов заказчика, исследование его требований, поиск решения;

— Управление требованиями (Requirements) – определяются рамки проекта, согласовывается интерфейс, дизайн с заказчиком;

— Анализ и Проектирование (Analysis and Design) – непосредственно проектирование системы на основе имеющихся данных;

— Реализация (Implementation) – разработка и интеграция компонентов системы;

— Тестирование (Test) – проверка системы на правильность, корректность работы, поиск ошибок;

— Развертывание (Deployment) – установка системы, обучение пользователей.

И три вспомогательные:

— Управление проектом (Project management) – контроль за бюджетом и рисками, создание проектной команды;

— Управление изменениями (Change management) – рассмотрение возможностей изменения системы;

— Среда (Environment) – внедрение проекта в конкретную инфраструктуру.

Все эти дисциплины выполняются во всех фазах жизненного цикла системы.

3.1 Жизненный цикл RUP

Включает в себя четыре фазы:

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

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

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

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

Читайте также: