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

предсказуемые) подходы
2.1. Каскадные технологические подходы.
2.1.1. Классический каскадный подход
2.1.2.

Каскадно-возвратный подход
2.1.3. Каскадно-итерационный подход
2.1.4. Каскадный подход с перекрывающимися процессами
2.1.5. Каскадный подход с подпроцессами
2.1.6. Спиральная модель
2.2. Каркасные подходы.
2.2.1. Рациональный унифицированный процесс (RUP)
2.3. Генетические подходы.
2.3.1. Синтезирующее программирование
2.3.2. Сборочное (расширяемое) программирование
2.3.3. Конкретизирующее программирование
2.4. Подходы на основе формальных преобразований.
2.4.1. Технология стерильного цеха
2.4.2. Формальные генетические подходы

3 Гибкие (адаптивные, легкие) подходы
3.1. Ранние технологические подходы быстрой разработки (RAD)
3.1.1. Эволюционное прототипирование
3.1.2.Итеративная разработка
3.1.3. Постадийная разработка
3.2. Адаптивные подходы.
3.2.1. Экстремальное программирование (XP)
3.2.2. Адаптивная разработка
3.3. Подходы исследовательского программирования.
3.3.1. Компьютерный дарвинизм

не укладываются в запланированные сроки и бюджет
Созданные в результате

этого процесса программы почти никогда не оправдывают возлагавшихся на них надежд
Только 26% проектов создания ИС заканчиваются успешно (Standish Group CHAOS Report)
Источники и причины проблем:
Потребности клиентов почти всегда опережают возможности разработчиков
Разработчики пренебрегают присущими другим индустриям системным принципам: массовое производств, повторяемость процессов и компонентов, надежность, следование методологическим и технологическим принципам
Узкая специализация затрудняет взаимопонимание между участниками проекта

каркас для процессов и включают их огромное количество.
2.2.1.

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

присущей ей гибкостью;

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

риски как можно раньше;

предпочтение в первую очередь отдается моделям, а не бумажным документам;

основное внимание уделяется раннему определению архитектуры;

возможность конфигурирования, настройки и масштабирования.

присущей ей гибкостью;

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

риски как можно раньше;

предпочтение в первую очередь отдается моделям, а не бумажным документам;

основное внимание уделяется раннему определению архитектуры;

возможность конфигурирования, настройки и масштабирования.

Грейди Буч (Grady Booch),
Джеймс Рамбо (James Rumbaugh)
Айвар Якобсон

(Ivar Jacobson)
Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее – Rational) для управления процессами разработки. Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда создает специализированный процесс, ориентированный на ее потребности
Начало разработки 1995 г.
Первая версия 1998г.
Наиболее глубоко проработана
Объединяет инкрементную и эволюционную итеративные методологии
Базируется на UML
На всех стадиях используются программные метрики

Создатели нотации UML
Грейди Буч,
Джеймс Рамбо,
Айвар Якобсон

Management)

Анализ и проектирование (Analysis and Design)

Реализация (Implementation)

Тестирование (Test)
Развертывание (Deployment)
Вспомогательные процессы:
Управление конфигурациями и изменениями (Configuration and ChangeManagement)
Управление проектом (Project Management)
Среда (Environment)

Фазы RUP

RUP используются прецеденты использования (use cases). Айвар Якобсон (один

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

из последовательности итераций с рекомендованной продолжительностью от 2 до

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

методология. Считается, что реализация и тестирование архитектуры системы должны

начинаться на самых ранних стадиях проекта. RUP использует понятие исполняемой архитектуры (executable architecture) – основы приложения, позволяющей реализовать архитектурно значимые прецеденты использования. Основы исполняемой архитектуры должны быть реализованы как можно раньше. Это позволяет оценить адекватность принятых архитектурных решений и внести необходимые коррективы еще в начале проекта. Таким образом, для первых нескольких итераций необходимо выбирать прецеденты, которые требуют реализации большей части архитектурных компонентов.
RUP поощряет использование визуальных средств для анализа и проектирования. Как правило, используется нотация и, соответственно, средства моделирования UML (такие как Rational Rose). Модель предметной области документируется в виде диаграммы классов, модель прецедентов использования – при помощи диаграммы прецедентов, взаимодействие компонентов системы между собой описывается диаграммой последовательности и т д.

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

завершения каждой фазы, определяется индивидуально для каждого конкретного проекта. Фазы RUP нельзя отождествлять с фазами водопадной модели – их назначение и содержание принципиально различны.
Начало (Inception). Фаза Начало обычно состоит из одной итерации. В ходе выполнения этой фазы необходимо:
Определить видение и границы проекта.
Создать экономическое обоснование (business case).
Идентифицировать большую часть прецедентов использования и подробно описать несколько ключевых прецедентов.
Найти хотя бы одно возможное архитектурное решение.
Оценить бюджет, график и риски проекта.
Если после завершения первой итерации заинтересованные лица приходят к выводу о целесообразности выполнения проекта, проект переходит в следующую фазу. В противном случае проект может быть отменен или проведена еще одна итерация фазы Начало.
Проектирование (Elaboration). В результате выполнения этой фазы на основе требований и рисков проекта создается основа архитектуры системы. Проектирование может занимать до двух-трех итераций или быть полностью пропущенным (если в проекте используется архитектура существующей системы без изменений). Целями этой фазы являются:
Детальное описание большей части прецедентов использования.
Создание оттестированной (при помощи архитектурно значимых прецедентов использования) базовой архитектуры.
Снижение основных рисков и уточнение бюджета и графика проекта.
В отличие от модели водопада, основным результатом этой фазы является не множество документов со спецификациями, а действующая система с 20-30% реализованных прецедентов использования.
Построение (Construction). В этой фазе (длящейся от двух до четырех итераций) происходит разработка окончательного продукта. Во время ее выполнения создается основная часть исходного кода системы и выпускаются промежуточные демонстрационные прототипы.
Внедрение (Transition)
Целями фазы Внедрения являются проведение бета-тестирования и тренингов пользователей, исправление обнаруженных дефектов, развертывание системы на рабочей площадке, при необходимости – миграция данных. Кроме того, на этой фазе выполняются задачи, необходимые для проведения маркетинга и продаж.
Фаза внедрения занимает от одной до трех итераций. После ее завершения проводится анализ результатов выполнения всего проекта: что можно изменить для улучшения эффективности в будущих проектах?

В них входят:
Бизнес-моделирование (Business Modeling) – исследование и описание

существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.
Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.
Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.
Создание статического и динамического представления системы
Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.
Создание программного кода
Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.
Проверка система в целом
Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.

уровнем формализма. Это не совсем так, поскольку процесс RUP

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

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

компанией Rational Software. В основе методологии лежат 6 основных принципов:−
компонентная

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

называемые артефакты (work products), выполняя задачи (tasks) в рамках

определенных ролей (roles). К артефактам, создаваемым на разных этапах, предъявляются жесткие требования.
Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline). В RUP определены шесть инженерных и три вспомогательные дисциплины.

связанные с рисками (например, список рисков текущего этапа),
описание

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

В них входят:
Бизнес-моделирование (Business Modeling) – исследование и описание

существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.
Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.
Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.
Создание статического и динамического представления системы
Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.
Создание программного кода
Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.
Проверка система в целом
Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.

Change Management) – управление версиями исходного кода и документации,

процесс обработки запросов на изменение (change requests).
Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.
Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки.

применения
Определение элементов Use Case, критических для системы
Определение общих черт

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

требований (функциональных требований) и ограничений (нефункциональных требований)
Планирование
Подготовка бизнес-варианта

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

модель Use Case (20%)
Начальный словарь проекта (для больших проектов

из специфической предметной области важно!) на разделяемом ресурсе (файле, викихранилище)
Начальный бизнес-вариант (развития проекта с точки зрения бизнеса, если риски не сработают)
Начальная оценка риска (в виде списка и он приоритизируется)
Укрупненный проектный план с этапами и итерациями

требования выражаются с помощью Use Case
Определение архитектурный платформы системы

(клиент-сервер, трехзвенную и др.)
Отслеживание рисков, устранение наибольших рисков
Разработка плана итераций этапа «Конструирование»

задающих дальнейшие решение
Развитие архитектуры, выделение её компонентов

том числе нефункциональные) требования
Описание программной архитектуры
Действующий архитектурный макет (прототип

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

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

ПО, аппаратура)
Оптимизация процессов разработки
Полная разработка компонентов и их тестирование
Оценивание

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

(альфа-, бета-версии и т.п.)
Описание текущей реализации
Руководство пользователя

в каждой итерации
Выпуск версии или релизов
Исправление найденных в процессе

бета-тестирования ошибок
Результат
Законченный ПП

больших проетов (реже средних)
Требует высокой квалификации участников

подходы.
2.1.1. Классический каскадный подход
2.1.2. Каскадно-возвратный подход
2.1.3. Каскадно-итерационный подход
2.1.4.

Каскадный подход с перекрывающимися процессами
2.1.5. Каскадный подход с подпроцессами
2.1.6. Спиральная модель
2.2. Каркасные подходы.
2.2.1. Рациональный унифицированный процесс (RUP)
2.3. Генетические подходы.
2.3.1. Синтезирующее программирование
2.3.2. Сборочное (расширяемое) программирование
2.3.3. Конкретизирующее программирование
2.4. Подходы на основе формальных преобразований.
2.4.1. Технология стерильного цеха
2.4.2. Формальные генетические подходы

3 Гибкие (адаптивные, легкие) подходы
3.1. Ранние технологические подходы быстрой разработки (RAD)
3.1.1. Эволюционное прототипирование
3.1.2.Итеративная разработка
3.1.3. Постадийная разработка
3.2. Адаптивные подходы.
3.2.1. Экстремальное программирование (XP)
3.2.2. Адаптивная разработка
3.3. Подходы исследовательского программирования.
3.3.1. Компьютерный дарвинизм

Технологическиеподходы

1. Подходы со слабой формализацией

Поттосином, в которой термин "генетический" связывается:
с происхождением программы
и

дисциплиной ее создания.

ее спецификации. В отличие от программы, которая написана на

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

собирается путем переиспользования уже известных фрагментов

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

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

методом повторного использования кода, причем как исходного, так и

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

был исторически первым и базировался на процедурах и функциях

методологии структурного императивного программирования.
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ сборочное программирование. Подход базируется на методологии объектно-ориентированного программирования и предполагает распространение библиотек классов в виде исходного кода или упаковку классов в динамически компонуемую библиотеку.
КОМПОНЕНТНОЕ сборочное программирование. Основные идеи подхода - распространение классов в бинарном виде и предоставление доступа к методам класса через строго определенные интерфейсы, что позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий классов без перекомпиляции использующих их приложений..
АСПЕКТНО-ОРИЕНТИРОВАННОЕ сборочное программирование. Концепция компонента в этом случае дополняется концепцией аспекта - варианта реализации критичных по эффективности процедур. Аспектно-ориентированное сборочное программирование заключается в сборке полнофункциональных приложений из многоаспектных компонентов, инкапсулирующих различные варианты реализации.

из универсальной.
Наиболее известная технология конкретизирующего программирования - это

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

имени - однозначно описывающего проблему проектирования;
задачи - описания

того, когда следует применять паттерн для конкретизации;
решения - абстрактного описания элементов дизайна и отношений между ними;
результатов - следствий применения паттерна.
Дополнительно к паттернам существуют каркасы (framework) - наборы взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ. Каркас диктует определенную архитектуру приложения, в нем аккумулированы проектные решения, общие для проектной области. Например, существуют каркасы, которые используются для разработки компиляторов.

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

(cleanroom process model) были предложены Харланом Миллзом в середине

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

программы как функции, в виде так называемых "ящиков":
черного

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

принципа:
все определенные при проектировании данные скрыты (инкапсулированы) в

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

спецификацию внешнего, видимого с пользовательской точки зрения поведения. Ящик

получает стимулы S от пользователя и выдает ответ R. Каждый ответ черного ящика определяется его текущей историей стимулов SH как функция:
(S, SH) -> (R)

же стимулов мы можем получить разные ответы, базирующиеся на

истории использования.
Рассмотрим калькулятор с двумя историями стимулов:
Clear 3 1 4
Clear 3 1 4 +
Если следующим стимулом будет число 1, то
на основании первой истории калькулятор выдаст ответ 3141,
а на основании второй - 315.
Определять поведение черных ящиков очень удобно с помощью табличных спецификаций.

черного ящика выделением элементов истории стимулов, которые сохраняют состояние

(инварианты состояний) в процессе выполнения действий в черном ящике. Функция преобразования ящика с состояниями выглядит так:
(S, OS) -> (R, NS)
Здесь OS - старое состояние, a NS - новое. Хотя с пользовательской точки зрения поведение черного ящика и ящика с состоянием выглядит одинаково, истории стимулов заменяются ссылками на старое состояние и новое состояние, требуемое преобразованием.

с состояниями, определяя процедуру, выполняющую требуемое преобразование. Таким образом,

прозрачный ящик - это просто программа, реализующая соответствующий ящик с состоянием.
(S, OS) -> (R, NS) by procedure
Проектирование процедуры прозрачного ящика выглядит как последовательное определение функций назначения и преобразование их в структуру управления и новые функции назначения.

Его заменяет процесс формальной верификации. Для каждой управляющей структуры

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

доказательности и
не теряющие это точное, накопленное знание.

Три

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

спецификацию - совокупность логических формул. Существуют две разновидности синтезирующего

программирования:
ЛОГИЧЕСКОЕ, в котором программа извлекается как конструктивное доказательство из спецификации, понимаемой как теорема;
ТРАНСФОРМАЦИОННОЕ, в котором спецификация рассматривается как уравнение относительно программы и символическими преобразованиями превращается в программу.
Формальное СБОРОЧНОЕ программирование использует спецификацию как композицию уже известных фрагментов.
Формальное КОНКРЕТИЗИРУЮЩЕЕ программирование использует такие подходы, как смешанные вычисления и конкретизацию по аннотациям.