Контрольные вопросы
1. Что представляет собой подход РУП?
2. Что представляет собойRUPкак продукт?
3. Дайте определение понятию «лучшая практика».
4. Перечислите и поясните лучшие практики, используемые в РУП.
5. Перечислите ключевые принципы бизнес-управляемой разработки.
6. Приведите графическое представление модели ЖЦ для РУП.
7. Перечислите и поясните фазы ЖЦ проекта для РУП.
8. Перечислите вехи ЖЦ проекта для РУП.
9. Перечислите и поясните дисциплины ЖЦ проекта для РУП.
10. Как распределяются фазы ЖЦ для РУП по трудоёмкости и затратам времени?
11. Приведите графическое представление итеративности разработки для РУП.
Лекция 11 Тема лекции
Подходы разработки ПО (продолжение).
План лекции
1. Каркасные технологические подходы:
– Каркас решений Microsoft(MSF).
– Процесс ICONIX(ICONIX Process).
Основное содержание
Каркас решений MicrosoftилиФреймворк для создания решений от Microsoft(МСФ,MSF – Microsoft Solutions Framework) – каркасный подход, предлагаемый фирмойMicrosoft Corporation.MSF 1.0 был представлен в 1993 г.MSF4.0 выпущена в 2005 г. МСФ представляет собой каркас процессов, основанных на принципах и использующих опробованные практики.
Microsoft Solutions Frameworkявляется также продуктом, предоставляемымMicrosoft. В этом качестве он представляет собой базу знаний в виде пакета руководств, разделённого на несколькобелых книг– документов, каждый из которых охватывает определённую модель или дисциплину. Он входит в набор инструментальных средствMicrosoft Visual Studio Team Systemдля поддержки МСФ.
МСФ 4.0 состоит из 5 белых книг: Модель руководства МСФ, Модель проектной группы МСФ, Дисциплина управления проектами МСФ, Дисциплина управления рисками МСФ, Дисциплина управления подготовкой МСФ.
МСФ основан на наборе из 9 основополагающих принципов: 1. Работа в рамках единого видения;2. Проявление живости, ожидание изменений;3. Сотрудничество с заказчиками;4. Поощрение свободного общения;5. Обучение на любом опыте;6. Вкладывание [денег] в качество;7. Поставка инкрементного результата;8. Установление ясной подотчётности;9. Наделение полномочиями членов команды. Принципы формируют общую суть моделей и дисциплин МСФ.
МСФ предлагает набор из 9 ключевых концепций: 1. Фокусировка на конечном результате;2. Поддержка своей клиентуры;3. Чувство гордости за мастерство;4. Просмотр всей картины;5. Поставка на своих обязательствах;6. Практика хорошего гражданства;7. Поощрение команды равных;8. Непрерывное обучение;9. Усвоение качеств обслуживания. В МСФ 4.0 они названы мыслеукладами из-за стремлениемMicrosoftк созданию и внедрению своей культуры разработки.
Модель руководства МСФ обладает следующими тремя особенностями: 1. Итеративный подход;2. Подход, основанный на фазах и вехах;3. Целостный подход к созданию и внедрению решений.
Модель ЖЦ для МСФ отражает один цикл разработки (рис.11.1).
В МСФ выделено всего 5 фаз: 1. Представление;2. Планирование;3. Разработка;4. Стабилизация;5. Развёртывание. Все фазы разграничены главными вехами. Для повышенного управления проектом внутри фаз выделяют ряд промежуточных вех, показывающих достижение результата в некоторой деятельности.
Рис.11.1. Модель ЖЦ для подходаMSF
На фазе 1выполняется создание и сплочение команды на основе выработки единого видения. Основными задачами являются создание ядра команды и подготовка документа с описанием концепции проекта, включающего видение и содержание проекта. Главная веха1считается достигнутой, если команда и заказчик пришли к соглашению об общих задачах и сроках проекта, включаемой и не включаемой в решение функциональности. Результатами являются: Описание видения и содержания, Документ оценки рисков, Описание структуры проекта.
На фазе 2производится основная работа по составлению планов проекта. Она включает в себя подготовку командой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Главная веха2считается достигнутой, если заказчик и команда пришли к соглашению о составе решения и сроках поставок. Утверждённые спецификации, планы и календарные графики образуютбазовый план проекта. Результатами являются: Функциональная спецификация, План управления рисками, Сводный план и сводный календарный график проекта.
На фазе 3команда фокусируется на создании компонентов решения. Некоторая часть этой работы может продолжаться на следующей фазе, если такая необходимость выявлена при тестировании. Эта фаза также включает в себя разработку инфраструктуры. Главная веха3считается достигнутой, если создание всех компонентов решения завершено и решение готово к тестированию и стабилизации. Результатами являются: Исходный и исполнимый код приложений, Скрипты установки и конфигурирования, Окончательная функциональная спецификация, Материалы поддержки решения, Спецификации и сценарии тестов.
На фазе 4производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Главная веха4считается достигнутой, если команда завершила разрешение всех существенных проблем и производится выпуск или внедрение решения. Результатами являются: «Золотой» выпуск, Документация выпуска, Материалы поддержки решения, Результаты и инструментарий тестирования, Исходный и исполнимый код приложений, Проектная документация, Обзор вехи.
На фазе 5команда внедряет технологии и компоненты решения, стабилизирует внедрённое решение, передаёт работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершении внедрения команда производит анализ работы и удовлетворённости заказчика. Главная веха5считается достигнутой, если решение начало давать заказчику результат, а команда может свернуть свою деятельность. Результатами являются: Информационные системы эксплуатации и поддержки, Процедуры и процессы, Базы знаний, отчёты, журналы протоколов, Версии проектных документов, массивы нагрузки и код, разработанные во время проекта, Отчёт о завершении проекта, Окончательные версии всех проектных документов, Показатели удовлетворённости заказчика и пользователей, Описание последующих шагов.
Следует сделать следующие замечания по этой модели ЖЦ. Длительность фаз не одинакова. Деятельность может выходить за рамки одной фазы. Наличие / отсутствие некоторых фаз определяется выполняемым проектом.
Таким образом, МСФ предлагает модель ЖЦ, основанную на распределении работ в команде проекта по фазам, а не на выделении процессов.
Процесс ICONIX(ICONIX Process) – каркасный подход, предлагаемый фирмойICONIX Software Engineering, Inc. Название этого подхода официально не является аббревиатурой, хотя и пишется прописными буквами. В 1992 г. Д. Розенберг разработал подход ПроцессICONIX. В него были включены отобранные им приемлемые методы из методик Г. Буча, Дж. Рамбо и А. Якобсона.
Общая идея подхода состоит в минимизации времени, требуемого для преобразования требований к системе в работающий код этой системы. Это достигается отбором только основных моделей UML, с помощью которых за 4 этапа выполняется необходимое преобразование. Таким образом, ПроцессICONIXявляется упрощённым подходом, ориентированным на моделирование при анализе и проектировании. При этом упрощённость не приводит к снижению строгости разработки, а связана с облегчением разработки при применении этого подхода.
В качестве средств поддержки подхода используется инструментальное средство Enterprise Architectсамой фирмы.
Основные особенности: 1. Упрощённое использованиеUML;2. Высокая степень отслеживаемости;3. Итеративность и инкрементность моделей.
Сутью Процесса ICONIXявляется понимание того, что построение хороших моделей объектов является простым, если сосредоточиться на нахождении ответа на фундаментально важные вопросы о разрабатываемой системе и отказаться от рассмотрения излишних, ненужных проблем моделирования. Этого можно достигнуть, если придерживаться направления разработки от требований пользователя и модели ПрО к работающему коду.
Разработка в рамках подхода выражается в виде трёх ключевых принципов: Снаружи внутрь, Изнутри наружу, Сверху вниз. Принцип «снаружи внутрь» определяет движение внутрь, исходя из требований пользователя, формализуемых в виде сценариев и прецедентов. Принцип «изнутри наружу» задаёт движение вовне, исходя из основных абстракций ПрО, образующих соответствующую модель. Принцип «сверху вниз» обозначает движение вниз – от высокоуровневых моделей к детализированному дизайну.
Модель ЖЦ для Процесса ICONIXотражает построение моделей во всех этапах ЖЦ, связанных с анализом и проектированием (рис.11.2).
Рис.11.2. Модель ЖЦ для ПроцессаICONIX
В подходе выделено 4 этапа: 1. Анализ требований;2. Предварительное проектирование;3. Детализированное проектирование;4. Реализация. Все этапы разграничены вехами, служащими для обзора работы, выполненной командой на соответствующих этапах.
На этапе 1выполняются следующие действия. Определяются объекты ПрО и выясняются связи обобщения и агрегации между ними. На основе этого начинается создание высокоуровневых диаграмм классов – модели (сущностей) ПрО. Если возможно, строится прототип предполагаемой системы (модель пользовательского интерфейса). Или собирается вся необходимая информация об унаследованной системе, которую нужно реорганизовать. Определяются прецеденты в виде диаграмм прецедентов. Организуется группировка прецедентов в виде диаграммы пакетов. Размещаются функциональные требования к системе – в прецеденты и объекты ПрО.
Веха 1позволяет установить, что: диаграммы прецедентов и модель ПрО совместно отражают все функциональные требования; заказчик понимает идею системы и понятно отражает её в требованиях; команда способна создать дизайн системы по выделенным требованиям. Таким образом, осуществляется проверка того, что созданы все диаграммы прецедентов и модель ПрО, необходимые для создания системы.
На этапе 2выполняются следующие действия. Формируются описания прецедентов: основной ход событий прецедента («главный поток») и альтернативные ходы событий (редко используемые варианты и ошибочные ситуации). Выполняется анализ робастности. Для каждого прецедента: определяется набор объектов, которые участвуют в выбранном сценарии, строится диаграмма робастности с использованием стереотипов изUMLObjectory, обновляются диаграммы классов (добавляются новые объекты, а также новые атрибуты и ассоциации). Завершается обновление диаграмм классов. Это действие свидетельствует о завершении стадии анализа для проекта. Выбираетсятехническая архитектура– технологические инструментарий и платформа (в частности, язык программирования и средство построения распределённых программных компонентов).
Веха 2позволяет установить, что: описание прецедентов и диаграммы робастности соответствуют друг другу и оба представляют правильно и полностью поведение создаваемой системы; модель ПрО соответствует диаграммам робастности (в частности, все объекты-сущности на диаграммах робастности представлены и в модели ПрО); классы-сущности включают в себя необходимые атрибуты; можно проследить потоки данных между именованными экранными формами системы через классы-сущности и, возможно, к лежащему в основе системы хранилищу данных. дизайн, разработка которого начинается, выглядит правдоподобным в контексте выбранной технической архитектуры системы. Таким образом, осуществляется проверка того, что заданы все ключевые абстракции проблемной области, необходимые для реализации поведения системы.
На этапе 3выполняются следующее действия. «Размещается» поведение системы. Для каждого прецедента: определяются сообщения, передаваемые объектами, сами объекты и соответствующие вызываемые методы, строится диаграмма последовательности: слева указывается текст выполняемого сценария, справа – соответствующий дизайн (сама диаграмма), обновляется диаграмма классов (добавляются новые атрибуты и операции). Если необходимо, строятся дополнительные диаграммы: диаграмма кооперации для основных взаимодействий между объектами, диаграмма состояний для поведения системы реального времени. Завершается построение статической модели добавлением информации о детальном дизайне (например, области видимости значений и паттерны). Командой осуществляется проверка дизайна на соответствие все предъявляемым к системе требованиям. Это действие свидетельствует о завершении стадии проектирования.
Веха 3позволяет установить, что: детальный дизайн в виде диаграмм последовательности и связанных с ними диаграмм классов соответствует прецедентам; детальный дизайн обладает достаточной глубиной (т.е. достаточно подробен), чтобы облегчить относительно небольшой и плавный переход к коду. дизайн удовлетворяет заданным критериям качества, позволяющим сделать оценку с различных точек зрения. дизайн должен удовлетворять внутренним стандартам, определённым в организации (например, использование паттернов, механизмов доступа к базам данных), что позволяет диаграммам последовательности и детальным диаграммам классов (детальной модели) отразить реальный дизайн системы; стабилизированы и утверждены все требования и техническая архитектура; решены все оставшиеся проблемы дизайна. Таким образом, осуществляется проверка того, что определено соответствие детального дизайна требованиям, представленным в виде прецедентов.
На этапе 4выполняются следующие действия. Если необходимо, строятся диаграммы развёртывания и диаграммы компонентов, которые могут оказаться полезными в стадии реализации. Пишется или генерируется программный код. Осуществляется модульное и интеграционное тестирование. Совершается системное тестирование и тестирование приемлемости для пользователей. Это действие свидетельствует о завершении стадий реализации и тестирования для проекта.
Веха 4позволяет установить, что: модульные тесты соответствуют описанию прецедентов и диаграммам последовательности; созданный программный код соответствует диаграммам классов и последовательности, рассматриваемых как руководство к написанию кода. Таким образом, осуществляется проверка того, что определено соответствие программного кода и тестов разработанным статической и динамической моделям – структуре и поведению системы исходя из предъявленных требований.
Одним из преимуществ подхода является то, что для каждого этапа указано 10 наиболее распространённых ошибок разработки и их разбор.