Каталог Рефератов - Модели проектных групп - скачать рефераты, бесплатно рефераты

	Информационно-образоательный портал
	Рефераты, курсовые, дипломы, научные работы,



МЕНЮ\|

поиск

Модели проектных групп

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

Модель жизненного цикла RUP является довольно сложной, детально проработанной итеративно - инкрементной моделью с элементами каскадной модели. В модели RUP выделяются 4 основные фазы, 9 видов деятельности (процессов). Кроме того, в модели описывается ряд практик, которые следует применять или руководствоваться для успешного выполнения проекта. RUP ориентирован на поэтапное моделирование создаваемого продукта с помощью языка UML (Рис.5).

Рис.5. Жизненный цикл RUP

Основными фазами RUP являются:

1. Фаза начала проекта (Inception). Определяются основные цели проекта, бюджет проекта, основные средства его выполнения - технологии, инструменты, ключевой персонал, составляются предварительные планы проекта. Основная цель этой фазы - достичь компромисса между всеми заинтересованными лицами относительно задач проекта.

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

3. Фаза построения (Construction). Основная цель этой фазы - детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.

4. Фаза передачи (Transition). Цель фазы - сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.

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

Деятельности (основные процессы) RUP делятся на 5 рабочих и 4 поддерживающие. К рабочим деятельностям относятся:

1. Моделирование предметной области (бизнес - моделирование, Business Modeling). Цели этой деятельности - понять бизнес - контекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают их одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система.

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

3. Анализ и проектирование (Analysis and Design). Выработка архитектуры системы на основе ключевых требований, создание проектной модели, представленной в виде диаграмм UML, описывающих продукт с различных точек зрения.

4. Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент.

5. Тестирование (Test). Общая оценка дефектов продукта, его качество в целом; оценка степени соответствия исходным требованиям.

Поддерживающими деятельностями являются:

1. Развертывание (Deployment). Цели - развернуть систему в ее рабочем окружении и оценить ее работоспособность.

2. Управление конфигурациями (Configuration and Change Management). Определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений.

3. Управление проектом (Project Management). Включает планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта.

4. Управление средой проекта (Environment). Настройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте.

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

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

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

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

1. «Вброс» архитектуры - начальный этап проекта, на котором создается видение продукта, принимаются основные решения по архитектуре и применяемым технологиям. Результатом начального этапа является метафора (metaphor) системы, которая в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.

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

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

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

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

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

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

Особенности модели жизненного цикла XP проясняют следующие принципы этого метода. Прежде всего, это принципы «живой» разработки ПО, зафиксированные в манифесте «живой» разработки:

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

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

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

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

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

Страницы: 1, 2, 3, 4

© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.