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

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

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

Модель ЖЦ для УП отражает объём работ дисциплин во всех фазах (рис.9.5).

В УП выделены 4 фазы: 1. Начало; 2. Уточнение; 3. Построение; 4. Внедрение. Каждая из фаз включает ряд итераций (с учётом фазы и проекта). На протяжении этих фаз по проекту выполняются работы, сгруппированные в следующие дисциплины (рис.9.5): 1. Бизнес-моделирование; 2. Определение требований; 3. Анализ и проектирование; 4. Реализация; 5. Тестирование; 6. Развёртывание.



Рис.9.5. Модель ЖЦ для подхода UP

Конец каждой фазы является некоторой вехой. Всего выделено 4 вехи:

1. Цели ЖЦ (LCO). Веха определяется достижением договорённости о жизнеспособности проекта и формированием базового плана.

2. Архитектура ЖЦ (LCA). Веха определяется подтверждением выбора подхода на основе архитектуры в простейшей форме.

3. Начальный операционный вариант (IOC). Веха определяется доступностью решения, годного к употреблению.

4. Выпуск продукта (PR). Веха определяется завершением разработки и передачей продукта в эксплуатацию.

Как следует из названий, дисциплины УП являются подмножеством действий стандартного процесса «Разработка», кроме того используется пофазное формирование стадий. В отличие от процессов каскадного подхода все дисциплины УП выполняются практически во всех фазах ЖЦ. Для дисциплин в зависимости от фазы применяется соответствующая целевая установка проекта и определяется соответствующий объём работ (рис.9.5).

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

Контрольные вопросы

1. Охарактеризуйте каскадные технологические подходы. Перечислите виды каскадных подходов и примеры подходов каждого вида.

2. В чём суть классического и модифицированного каскадных подходов?

3. В чём суть каскадно-возвратного подхода? Приведите графическое представление модели для этого подхода.

4. В чём суть каскадно-итерационного подхода? Приведите графическое представление модели для этого подхода.

5. В чём суть каскадно-перекрывающегося подхода? Приведите графическое представление модели для этого подхода.

6. В чём суть каскадно-декомпозиционного подхода? Приведите графическое представление модели для этого подхода.

7. Охарактеризуйте каркасные технологические подходы. Перечислите виды каркасных подходов и примеры подходов каждого вида.

8. Что представляет собой подход УП? Перечислите и поясните особенности УП.

9. Приведите графическое представление модели ЖЦ для УП. Перечислите фазы, дисциплины и вехи ЖЦ проекта для УП.

Лекция 10

Тема лекции: Подходы разработки ПО (продолжение)

Основное содержание

Рациональный унифицированный процесс (РУП, RUP - Rational Unified Process) - унифицированный каркасный подход, предлагаемый фирмой Rational Software Corporation (с 2003 г. - подразделение IBM Corporation); поэтому возможен и другой перевод названия: Унифицированный процесс [от] Rational Software.

Исторически РУП является развитием подхода Objectory Process, созданный А. Якобсоном как развитие его методики Объектно-ориентированная инженерия ПО. В 1987 г. автор основал компанию Objectory AB. После вливания Objectory AB в Rational в 1995 г. подход Якобсона был объединён с Rational Approach. Этот подход основан на работах У. Ройса, Ф. Крухтена и Г. Буча. Объединённый подход вначале получил название Rational Objectory Process, лишь затем, после включения поддержки бизнес-моделирования, был переименован в РУП. Кроме этого в подход был включён развивавшаяся в это время сотрудниками Rational объектно-ориентированная методика анализа и проектирования, получившая название языка UML.

РУП является сложным, детально проработанным итеративным подходом разработки. Он представляет собой адаптируемый каркас процессов, который может быть специализирован для конкретных организаций или определённых проектов путём выбора наиболее подходящих элементов из предлагаемого каркаса.

Rational Unified Process является также продуктом, предоставляемым IBM Rational. В этом качестве он представляет собой структурированную интерактивную базу знаний с шаблонами артефактов и подробным описанием различных типов действий, которое включает в себя общие принципы, конкретные рекомендации и примеры по эффективной разработке систем. База знаний регулярно обновляется и совершенствуется с учётом передового опыта.

Этот продукт входит как составная часть в набор инструментальных средств IBM Rational для поддержки РУП. Некоторые из этих средств благодаря возможности их расширения оказываются применимыми в качестве инструментария для других подходов. В частности, подход MSF долгое время основывался на этом наборе до разработки собственного набора средств.

Исследование различных неудачных проектов привело авторов РУП к выявлению признаков и первопричин их провала. Провал проекта обычно связан с некоторой комбинацией признаков, вызванных рядом первопричин, хотя такие проекты заканчиваются неудачей каждый по_своему.

Результатом исследований стало выделение лучших практик, позволяющих устранить первопричины провала проектов. Лучшая практика - практика разработки, проверенная на многих проектах и позволяющая вместе с другими практиками повысить эффективность проекта и обеспечить успех организации. Лучшими считаются следующие практики, используемые в РУП: 1. Итеративная разработка; 2. Управление требованиями; 3. Использование компонентной архитектуры; 4. Визуальное моделирование; 5. Проверка качества; 6. Контроль изменений.

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

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

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

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

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

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

Лучшие практики послужили основой для создания подхода РУП.

РУП основан на наборе из 6 ключевых принципов бизнес-управляемой разработки, сокращённо называемый ABCDEF: 1. Адаптация процесса; 2. Баланс приоритетов заинтересованных лиц; 3. Сотрудничество между командами; 4. Демонстрация результата итерационно; 5. Эволюция (рост) уровня абстракции; 6. Фокусировка непрерывно на качестве. Эти принципы были определены Пером Кроллом и Уолкером Ройсом.

Модель ЖЦ для РУП отражает объём работ дисциплин в фазах (рис.10.1).

В РУП, как и в УП, также выделены 4 фазы, состоящие из ряда итераций.

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

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

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

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



Рис.10.1. Модель ЖЦ для подхода RUP

Конец каждой фазы является некоторой вехой. Всего выделено 4 вехи, совпадающие с вехами УП, кроме того указаны критерии прохождения этих вех.

На протяжении этих фаз по проекту выполняются дисциплины. РУП выделяет 6 основных и 3 вспомогательные дисциплины (рис.10.1). Основные дисциплины: 1. Бизнес-моделирование; 2. Определение требований; 3. Анализ и проектирование; 4. Реализация; 5. Тестирование; 6. Развёртывание. Вспомогательные дисциплины, связанные с управлением разработкой: 1. Управление конфигурацией и изменениями; 2. Управление проектом. 3. Управление средой.

Бизнес-моделирование (в общем случае - моделирование ПрО) применяется, чтобы изучить ПрО, обеспечить единство понимания среди всех участников проекта и определить высокоуровневые требования, которые должны быть реализованы в ходе проекта при создании системы.

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

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

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

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

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

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

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

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

По трудоёмкости и затратам времени (на один цикл) фазы ЖЦ распределяются следующим образом (рис.10.2): Построение, Уточнение, Внедрение и Начало.

Рис.10.2. Трудоёмкость и затраты времени на фазы

Нагрузка основных дисциплин РУП распределяется по фазам следующим образом: в фазе Начала - Бизнес-моделирование и Определение требований, в фазе Уточнения - Анализ и проектирование и Реализация, в фазе Построения - Реализация и Тестирование, в фазе Внедрения - Развёртывание.

Рис.10.3. Итеративность разработки

В каждой итерации выполняются все дисциплины РУП, но с разной интенсивностью, зависящей от фазы, и в определённой взаимосвязи (рис.10.3).

Контрольные вопросы

1. Что представляет собой подход РУП?

2. Что представляет собой RUP как продукт?

3. Дайте определение понятию «лучшая практика».

4. Перечислите и поясните лучшие практики, используемые в РУП.

5. Перечислите ключевые принципы бизнес-управляемой разработки.

6. Приведите графическое представление модели ЖЦ для РУП.

7. Перечислите и поясните фазы ЖЦ проекта для РУП.

8. Перечислите вехи ЖЦ проекта для РУП.

9. Перечислите и поясните дисциплины ЖЦ проекта для РУП.

10. Как распределяются фазы ЖЦ для РУП по трудоёмкости и затратам времени?

11. Приведите графическое представление итеративности разработки для РУП.

Лекция 11

Тема лекции: Подходы разработки ПО (продолжение)

Основное содержание

Каркас решений Microsoft или Фреймворк для создания решений от Microsoft (МСФ, MSF - Microsoft Solutions Framework) - каркасный подход, предлагаемый фирмой Microsoft Corporation. MSF 1.0 был представлен в 1993 г. MSF 4.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 выполняются следующие действия. Формируются описания прецедентов: основной ход событий прецедента («главный поток») и альтернативные ходы событий (редко используемые варианты и ошибочные ситуации). Выполняется анализ робастности. Для каждого прецедента: определяется набор объектов, которые участвуют в выбранном сценарии, строится диаграмма робастности с использованием стереотипов из UML Objectory, обновляются диаграммы классов (добавляются новые объекты, а также новые атрибуты и ассоциации). Завершается обновление диаграмм классов. Это действие свидетельствует о завершении стадии анализа для проекта. Выбирается техническая архитектура - технологические инструментарий и платформа (в частности, язык программирования и средство построения распределённых программных компонентов).

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

На этапе 3 выполняются следующее действия. «Размещается» поведение системы. Для каждого прецедента: определяются сообщения, передаваемые объектами, сами объекты и соответствующие вызываемые методы, строится диаграмма последовательности: слева указывается текст выполняемого сценария, справа - соответствующий дизайн (сама диаграмма), обновляется диаграмма классов (добавляются новые атрибуты и операции). Если необходимо, строятся дополнительные диаграммы: диаграмма кооперации для основных взаимодействий между объектами, диаграмма состояний для поведения системы реального времени. Завершается построение статической модели добавлением информации о детальном дизайне (например, области видимости значений и паттерны). Командой осуществляется проверка дизайна на соответствие все предъявляемым к системе требованиям. Это действие свидетельствует о завершении стадии проектирования.

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

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

Веха 4 позволяет установить, что: модульные тесты соответствуют описанию прецедентов и диаграммам последовательности; созданный программный код соответствует диаграммам классов и последовательности, рассматриваемых как руководство к написанию кода. Таким образом, осуществляется проверка того, что определено соответствие программного кода и тестов разработанным статической и динамической моделям - структуре и поведению системы исходя из предъявленных требований.

Одним из преимуществ подхода является то, что для каждого этапа указано 10 наиболее распространённых ошибок разработки и их разбор.

Контрольные вопросы

1. Что представляет собой подход МСФ? Что представляет собой MSF как продукт? Охарактеризуйте пакет руководств МСФ 4.0.

2. Перечислите основополагающие принципы и ключевые концепции МСФ.

3. Перечислите особенности модели руководства МСФ.

4. Приведите графическое представление модели ЖЦ для МСФ. Перечислите и поясните фазы и вехи ЖЦ проекта для МСФ.

5. Охарактеризуйте фазу «Представление» подхода МСФ.

6. Охарактеризуйте фазу «Планирование» подхода МСФ.

7. Охарактеризуйте фазу «Разработка» подхода МСФ.

8. Охарактеризуйте фазу «Стабилизация» подхода МСФ.

9. Охарактеризуйте фазу «Развёртывание» подхода МСФ.

10. Что представляет собой Процесс ICONIX? Как связан Процесс ICONIX с подходами RUP и XP? Перечислите основные особенности ICONIX.

11. Перечислите условия построения хороших моделей объектов в ICONIX. Перечислите и поясните ключевые принципы ICONIX.

12. Приведите графическое представление модели ЖЦ для ICONIX. Перечислите и поясните этапы и вехи ЖЦ проекта для ICONIX.

13. Охарактеризуйте этап «Анализ требований» ICONIX.

14. Охарактеризуйте этап «Предварительное проектирование» ICONIX.

15. Охарактеризуйте этап «Детализированное проектирование» ICONIX.

16. Охарактеризуйте этап «Реализация» ICONIX.

Лекция 12

Тема лекции: Подходы разработки ПО (продолжение)

Основное содержание

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

Особенностями эволюционных подходов являются: 1. Использование прототипирования и 2. Тесное взаимодействие с заказчиком.

Выделяют эволюционные подходы следующих двух видов:

1. Подходы прототипирования.

2. Подходы быстрой разработки: Итеративная инкрементная разработка (IID), Быстрая разработка приложений (RAD), Эволюционная быстрая разработка (ERD), Метод разработки динамичных систем (DSDM).

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

Непланируемый подход («кодирование - исправление») основан на одноимённой модели. Фактически это всего лишь способ написания кода программы, простой проверки полученной программы и его модификации, он не предполагает серьёзного проектирования. Многие разработчики не считают его подходом, называя этот способ кустарной разработкой. Непланируемый подход используется при разработке небольших свободно распространяемых программ. Он рекомендуется в случае разработки простого демонстрационного прототипа или проверки некоторой программной концепции. Идея непланируемого подхода оказалась полезной и получила своё развитие в прототипировании.

Прототипируемые подходы, или подходы прототипирования, являются одновременно развитием и альтернативой каскадных подходов и основаны, как следует из названия, на прототипировании. Выделяют следующие основные подходы прототипирования: 1. Эволюционная доставка; 2. Итеративная доставка; 3. Постадийная доставка. Модели ЖЦ для прототипируемых подходов являются вариантами прототипируемой модели с учётом каскадной и других моделей.

Эволюционная доставка - эволюционный подход, ориентированный в первую очередь на создание пользовательского интерфейса. Основой модели ЖЦ служит эволюционная модель, так как в начале разработки нет чётко сформулированных требований. Принцип модели (рис.12.1) заключается в том, что первый прототип обычно уже включает развитый пользовательский интерфейс. Далее, пока заказчик не сочтёт продукт законченным, в него вносится необходимая функциональность; при этом возможно небольшое изменения интерфейса.

Рис.12.1. Модель ЖЦ для подхода Эволюционная доставка

Подход применяется в проектах с ярко выраженным преобладанием разработки пользовательского интерфейса. Существенным недостатком подхода является невозможность определить стоимость и продолжительность проекта.

Итеративная доставка - эволюционный подход, ориентированный в первую очередь на создание необходимого ядра функциональности. Основой модели ЖЦ для подхода служит итеративная инкрементная модель, так как в начале разработки известны чётко сформулированные требования. Принцип модели (рис.12.2) заключается в том, что первый прототип обычно уже включает большую часть необходимой функциональности. Далее, пока заказчик не сочтёт продукт законченным, для него разрабатывается необходимый пользовательский интерфейс; при этом возможно небольшое изменение функциональности.

Рис.12.2. Модель ЖЦ для подхода Итеративная доставка

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

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

Рис.12.3. Модель ЖЦ для подхода Постадийная доставка

Итеративная инкрементная разработка (ИИР, IID - Iterative and Incremental Development) - подход разработки, являющийся альтернативой (классическому) каскадному подходу и использующий прототипы.

Идея повышения качества путём организации производства в виде коротких циклов «Планирование - Выполнение - Проверка - Действие» была предложена в 1939 г. в работе У. Шуарта, эксперта по качеству Bell Labs. Эта идея получила развитие в области разработки ПО и привела к созданию в середине 1950_х гг. подхода ИИР. ИИР использовался в ряде исследовательских проектов, выполненных подразделением FSD (Отделение федеральных систем) фирмы IBM по заказу Министерства обороны США. ИИР стал одним из основных компонентов ряда современных строгих и гибких подходов, в том числе RAD, DSDM, RUP и многих живых подходов. Подход основан на одноимённой модели.

Быстрая разработка приложений (БРП, RAD - Rapid Application Development) - эволюционный подход, сформулированный Дж. Мартином в 1991 г.

В 1980_х гг. Дж. Мартин, сотрудник фирмы IBM, разработал подход БРП. В 1991 г. он опубликовал книгу под названием «Быстрая разработка приложений». В дальнейшем подход БРП включил в себя другие методики, нацеленные на ускорение разработки приложений.

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

БРП обладает следующими особенностями. Команда разработчиков: малочисленная проектная команда (от 2 до 10 человек) из опытных, разносторонне подготовленных специалистов, способных заменять друг друга. Подход к управлению командой: максимальная интеграция управленческого аппарата с командой разработчиков с коротким, но тщательно проработанным графиком проекта (от 2 до 6 месяцев). Использование техники прототипирования: повторяющийся цикл разработки и быстрая разработка прототипа перед каждой итерации для демонстрирования пользователям и уточнения требований для этой итерации.

На основе БРП созданы и другие подходы: Адаптивная разработка ПО (ASD), Метод разработки динамичных систем (DSDM) и т.д.

К основным принципам БРП следует отнести следующие:

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

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

3. Обязательное вовлечение пользователей в процесс разработки системы.

4. Ведение разработки немногочисленной хорошо управляемой командой профессионалов.

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

6. Необязательность полного завершения работ на каждой из фаз ЖЦ.

7. Необходимое применение CASE-средств, обеспечивающих целостность проекта на всём протяжении ЖЦ.

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

9. Непременное использование генераторов кода.

10. Тестирование и развитие проекта одновременно с разработкой.

Для выполнения разработки согласно перечисленным принципам используется метрика - оценка размера приложения. Эта метрика вычисляется на основе так называемых функциональных элементов (экранных форм, документов, отчётов и т.п.). Размер приложения, разрабатываемое с помощью БРП, для хорошо отлаженной среды разработки с максимальным повторным использованием компонентов определяется следующим образом: Один человек - при числе функциональных элементов менее 1000, одна команда - при 1000 - 4000, 4000 функциональных элементов на одну команду разработчиков - при более 4000.

Основой модели ЖЦ для подхода служит итеративная инкрементная модель, ориентированная на разработку работающих прототипов (рис.12.4).



Рис.12.4. Схема модели ЖЦ для подхода RAD

В БРП выделены следующие 4 фазы: 1. Планирование и Анализ требований; 2. Проектирование; 3. Построение; 4. Внедрение.

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

На фазе 2 часть пользователей принимает участие в логическом проектировании системы под руководством разработчиков. Для быстрого получения работающих прототипов приложений используется CASE-средство. Пользователи уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создаётся частичный прототип, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов системы и принимается решение о разделении её на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средства проект распределяется между различными командами. Результатами фазы должны быть: общая информационная модель системы, функциональные модели системы в целом и подсистем, точно определённые с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами, построенные прототипы экранов, отчётов, диалогов. Все модели и прототипы должны быть получены с применением того CASE-средства, которое будут использоваться в дальнейшем при построении системы. Применение единой среды хранения информации о проекте позволяет избежать опасности искажения данных.

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

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

Приведённая схема разработки не является абсолютной. Возможны различные её варианты в зависимости от целей проекта.

Контрольные вопросы

1. Охарактеризуйте эволюционные технологические подходы. Перечислите виды эволюционных подходов и примеры подходов каждого вида.

2. Что представляет собой непланируемый подход? Охарактеризуйте подход.

3. Что представляют собой подходы прототипирования? Перечислите основные подходы прототипирования.

4. Охарактеризуйте подход Эволюционная доставка. В чём суть модели ЖЦ для этого подхода. Приведите графическое представление данной модели.

5. Охарактеризуйте подход Итеративная доставка. В чём суть модели ЖЦ для этого подхода. Приведите графическое представление данной модели.

6. Охарактеризуйте подход Постадийная доставка. В чём суть модели ЖЦ для этого подхода. Приведите графическое представление данной модели.

7. Что представляет собой подход ИИР? В каких подходах ИИР является одним из основных компонентов?

8. Что представляет собой подход БРП? Перечислите особенности БРП.

9. Перечислите и поясните основные принципы БРП.

10. Приведите графическое представление модели ЖЦ для БРП.

11. Перечислите фазы ЖЦ проекта для БРП.

12. Охарактеризуйте фазу «Планирование и Анализ требований» подхода БРП.

13. Охарактеризуйте фазу «Проектирование» подхода БРП.

14. Охарактеризуйте фазу «Построение» подхода БРП.

15. Охарактеризуйте фазу «Внедрение» подхода БРП.

Лекция 13

Тема лекции: Подходы разработки ПО (продолжение)

Основное содержание

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

Выделяют адаптивные подходы следующих видов:

1. Игровые адаптивные подходы: Адаптивная разработка ПО (ASD), Экстремальное программирование (XP), Скрам (Scrum).

2. Управляемые адаптивные подходы: Управляемая тестами разработка (TDD), Управляемая возможностями разработка (FDD), Управляемая поведением разработка (BDD), Управляемая дизайном разработка (D3).

3. Унифицированные адаптивные подходы: Гибкие варианты UP.

4. Облегчённые адаптивные подходы: Облегчённая разработка ПО (LSD).

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

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

В 2001 г. 17 известных сторонников гибких подходов встретились в местечке Сноубёрд (штат Юта, США), для обсуждения вопросов создания ПО более лёгким, быстрым и «человеко-центрированным» способом. Кроме того они предложили общее название для подходов с указанными выше способами разработки: Живая разработка ПО. Результат - «Манифест Живой разработки ПО», известный как «Живой манифест». Живой манифест включает в себя уведомление с основными положениями и сам документ с принципами живой разработки ПО.

Основные положения при разработке ПО связаны с правильной оценкой:

1. Люди и их взаимодействие важнее процессов и средств.

2. Работающее ПО важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее обсуждения контракта.

4. Реагирование на изменения важнее следования плану.

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

Адаптивная разработка ПО (АРП, ASD - Adaptive Software Development) - живой подход, предложенный Дж. Хайсмитом.

Идея представления процесса разработки как адаптивной системы была высказана Э.А. Эдмондсом в его статье ещё в 1974 г. Изложение этого подхода приведено в книге «Адаптивная разработка ПО: Подход сотрудничества при управлении сложными системами» (2000 г.) автора подхода Дж. Хайсмита. Она закладывает теоретическую основу адаптивных разработок. Это позволяет использовать АРП совместно с другими гибкими подходами (Crystal, FDD, XP). Подходы АРП и Crystal Family объединены их авторами в единый подход.

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

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

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

В АРП предлагается динамический ЖЦ «Обдумывание - Сотрудничество - Обучение». Цикл (рис.13.1) связан с постоянными изменениями, повторными оценками, попытками предугадать неизвестное на текущий момент будущее проекта и требует тесного взаимодействия между разработчиками, тестировщиками и заказчиками. При этом цикл не всегда представляет собой круг, так как можно иногда отклоняться в сторону, чтобы изучить неисследованные области.



Рис.13.1. Схема модели ЖЦ для подхода ASD

Цикл обладает следующими свойствами: 1. Целенаправленность; 2. Компонентный подход; 3. Итеративность; 4. Ограниченность по времени; 5. Управляемость рисками; 6. Допущение изменений.

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

...