1.Модель процессов MSF, версия 3.1. http://www.microsoft.com/Rus/Download.aspx?file=/Msdn/Msf/MSF_process_model_ru s.doc
2.Андрей Колесов. Введение в методологию Microsoft Solutions Framework. http://www.bytemag.ru/Article.asp?ID=2866
2.4.2. Модель Rational Unified Process
Модель жизненного цикла RUP является довольно сложной, детально проработанной итеративно-инкрементной моделью с элементами каскадной модели. В модели RUP выделяются 4 основные фазы, 9 видов деятельности (процессов). Кроме того, в модели описывается ряд практик, которые следует применять или руководствоваться для успешного выполнения проекта. RUP ориентирован на поэтапное моделирование создаваемого продукта с помощью языка UML.
Основными фазами RUP являются:
Фаза начала проекта (Inception). Определяются основные цели проекта, бюджет проекта, основные средства его выполнения — технологии, инструменты, ключевой персонал, составляются предварительные планы проекта. Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта.
Фаза проработки (Elaboration). Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы.
Фаза построения (Construction). Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.
Фаза передачи (Transition). Цель фазы — сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы
вее рабочей среде, подгонка мелких деталей под нужды пользователей.
Врамках каждой фазы возможно проведение нескольких итераций, количество которых определяется сложностью выполняемого проекта.
Деятельности (основные процессы) RUP делятся на пять рабочих и четыре поддерживающие. К рабочим деятельностям относятся:
Моделирование предметной области (бизнес-моделирование, Business Modeling). Цели этой деятельности — понять бизнес-контекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают его одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система.
Определение требований (Requirements). Цели — понять, что должна делать система, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем.
Анализ и проектирование (Analysis and Design). Выработка архитектуры системы на основе ключевых требований, создание проектной модели, представленной в виде диаграмм UML, описывающих продукт с различных точек зрения.
Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент.
Тестирование (Test). Общая оценка дефектов продукта, его качество в целом; оценка степени соответствия исходным требованиям.
Поддерживающими деятельностями являются:
Развертывание (Deployment). Цели — развернуть систему в ее рабочем окружении и оценить ее работоспособность.
16
Управление конфигурациями и изменениями (Configuration and Change Management). Определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений.
Управление проектом (Project Management). Включает планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта.
Управление средой проекта (Environment). Настройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте.
2.4.3. Модель Extreme Programming
Экстремальное программирование является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» входят, помимо экстремального программирования, входит еще ряд методов, о чем подробнее можно прочитать: Мартин Фаулер. Новые методологии программирования. http://www.maxkir.com/sd/newmethRUS.html.
2.4.3.1.Схема модели XP
Модель жизненного цикла XP является итерационно-инкрементной моделью быстрого создания (и модификации) протопопов продукта, удовлетворяющих очередному требованию (user story). Особенности этой модели представлены на слайде. Основными фазами модели можно считать:
«Вброс» архитектуры – начальный этап проекта, на котором создается видение продукта, принимаются основные решения по архитектуре и применяемым технологиям. Результатом начального этапа является метафора (metaphor) системы, которая в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.
Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. Истории использования являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.
Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования - получение оценок того, что и как можно сделать за 1-3 недели создания следующей версии продукта.
Разработка проводится в соответствии с планом и включает только те функции, которые были отобраны на этапе планирования.
Тестирование проводится с участием заказчика, который участвует в составлении тестов.
Выпуск релиза – разработанная версия передается заказчику для использования или бета-тестирования.
По завершению цикла делается переход на следующую итерацию разработки
2.4.3.2.Extreme Programming. Принципы
Особенности модели жизненного цикла XP проясняют следующие принципы этого метода. Прежде всего, это принципы «живой» разработки ПО, зафиксированные в манифесте «живой» разработки:
Люди их общение более важны, чем процессы и инструменты
Работающая программа более важна, чем исчерпывающая документация
17
Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
Отработка изменений более важна, чем следование планам
Кроме того, в XP есть несколько правил (техник), характеризующих особенности
модели его жизненного цикла:
Живое планирование (planning game) - как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в первую очередь, бизнес-приоритетов заказчика и, во-вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.
Частая смена версий (small releases) - первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.
Простые проектные решения (simple design) - в каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Новые функции добавляются только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.
Разработка на основе тестирования (test-driven development) - сначала пишутся тесты, потом реализуются модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.
Постоянная переработка (refactoring) - системы для устранения излишней сложности, увеличения понятности кода, повышения его гибкости. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат.
Программирование парами (pair programming) - весь код пишется двумя программистами на одном компьютере, что повышает его качество (отсутствие ошибок, понятность, читаемость,…).
Постоянная интеграция (continuous integration) - система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции.
40-часовая рабочая неделя - сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд
— это истощает программистов и делает их работу значительно менее
продуктивной.
Более подробно об экстремальном программировании можно почитать здесь: http://www.xprogramming.ru/index.html.
Классификацию современных моделей жизненного цикла ПО по типам проектов можно найти в обзоре: Рассел Арчибальд. Модели жизненного цикла высокотехнологичных проектов. http://www.pmprofy.ru/content/rus/107/1073-article.asp
Вопросы для контроля
1.Что такое жизненный цикл программного продукта?
2.Что такое процесс, действие, задача?
3.Какие типы процессов и конкретные процессы вы запомнили?
4.Что такое модель жизненного цикла ПО?
5.Какие типы моделей вы знаете? В чем их преимущества, недостатки, область применимости?
6.Что вы можете сказать об особенностях моделей жизненного цикла MSF, RUP, XP?
18
Рекомендуемая литература
Основная
–Шафер Д, Фатрел Р, Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. - М.:
Вильямс., 2003. - 1136с. (стр.31; 135-175)
–ГОСТ Р ИСО/МЭК 12207-99. Процессы жизненного цикла программных средств. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO1220799/ISO12207.htm
–Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504) ISBN: 5-212-00884-0/ Изд: АйТи, Книга и бизнес. http://www.ntrlab.ru/rus/method/iso15504/ Глава 2. Раздел 5. Измерение
«процесс»
Дополнительная
–В.Липаев. Стандарты, регламентирующие жизненный цикл сложных программных комплексов http://www.pcweek.ru/year1998/N24/CP1251/Reviews/chapt1.htm
–В. В. Кулямин. Технологии программирования. Компонентный подход. Лекция 2. Жизненный цикл и процессы разработки ПО. МГУ. ВМК. Каф. Системного программирования. http://www.ispras.ru/~RedVerst/RedVerst/Lectures and training courses/Software Development Technologies/Lecture02.doc
Использованные источники
При разработке материалов лекции использовались следующие источники:
№ |
Источник |
Темы лекции |
Сла |
||
йды |
|||||
|
|
|
|
||
1 |
Шафер Д, Фатрел Р, Шафер Л. Управление программными |
|
|
|
|
|
проектами: достижение оптимального качества при минимуме |
|
|
|
|
|
затрат.: Пер. с англ. - М.: Вильямс., 2003. - 1136с |
|
|
|
|
1.1 |
Введение (стр.31) |
Немного истории |
3 |
||
1.2 |
Модели жизненного цикла разработки ПО (стр. 135-175) |
|
|
|
|
3 |
В.Липаев. Стандарты, регламентирующие жизненный цикл |
История… |
4 |
||
|
сложных программных комплексов |
|
|
|
|
|
http://www.pcweek.ru/year1998/N24/CP1251/Reviews/chapt1.htm |
|
|
|
|
4 |
ГОСТ Р ИСО/МЭК 12207-99. Процессы жизненного цикла |
ISO 12207. |
7 |
||
|
программных средств. |
Структура ЖЦ ПО |
|
||
|
http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207- |
|
|
|
|
|
99/ISO12207.htm |
|
|
|
|
5 |
Оценка и аттестация зрелости процессов создания и |
ISO 15504 … |
8-15 |
||
|
сопровождения программных средств и информационных систем |
|
|
|
|
|
(ISO/IEC TR 15504) ISBN: 5-212-00884-0/ Изд: АйТи, Книга и |
|
|
|
|
|
бизнес. http://www.ntrlab.ru/rus/method/iso15504/ Глава 2. Раздел |
|
|
|
|
|
5. Измерение «процесс» |
|
|
|
|
|
С.Н.Баранов. Управление программным проектом. |
Схемы |
моделей |
|
|
|
http://www.exams.icqinfo.ru/edu/tp-part2.rar |
ЖЦ спиральной, V- |
|
||
|
|
образной |
|
|
|
|
В. В. Кулямин. Технологии программирования. |
Модель |
ЖЦ RUP, |
|
|
|
Компонентный подход. Лекция 2. Жизненный цикл и |
XP |
|
|
|
|
процессы разработки ПО. |
|
|
|
|
|
http://www.ispras.ru/~RedVerst/RedVerst/Lectures and training |
|
|
|
|
19
courses/Software Development Technologies/Lecture02.doc
МГУ. ВМК. Каф. Системного программирования.
Андрей Колесов. Введение в методологию Microsoft Модель ЖЦ MSF
Solutions Framework. http://www.bytemag.ru/Article.asp?ID=2866
20