Что такое findslide.org?

FindSlide.org - это сайт презентаций, докладов, шаблонов в формате PowerPoint.


Для правообладателей

Обратная связь

Email: Нажмите что бы посмотреть 

Яндекс.Метрика

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

Содержание

Технологическиеподходы1. Подходы со слабой формализацией2 Строгие (классические, жесткие, предсказуемые) подходы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. Рациональный
ПМ3  МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ ПО    Лекция 3. Технологическиеподходы1. Подходы со слабой формализацией2 Строгие (классические, жесткие, предсказуемые) подходы2.1. Каскадные технологические Рациональный унифицированный процесс   Rational Unified Process   RUP Проблемы разработки ПОПроекты по разработке ПО почти никогда не укладываются в запланированные 2.2. Каркасные технологические подходы Каркасные подходы представляют собой каркас для процессов и 2.2.1. Рациональный унифицированный процессОсновные особенности подхода: итеративность с присущей ей гибкостью; контроль 2.2.1. Рациональный унифицированный процесс 2.2.1. Рациональный унифицированный процессОсновные особенности подхода: итеративность с присущей ей гибкостью; контроль 2.2.1. Rational Unified ProcessАвторы RUP:Филипп Крачтен (Philippe Kruchten), Грейди Буч (Grady Booch), Рабочие процессы RUP(Disciplines):Бизнес-моделирование (Business Modeling) Управление требованиями (Requirements Management) Анализ и проектирование Основные характеристики процесса RUP Разработка требований в RUP  Для описания требований в RUP используются прецеденты Итеративная разработка в RUP Проект в RUP состоит из последовательности итераций с Архитектура в RUP RUP – ориентированная на архитектуру методология. Считается, что реализация Жизненный цикл проекта в RUPСостоит из четырех фаз. Последовательность этих фаз фиксирована, Рабочий процесс RUPВ RUP определены шесть инженерных дисциплин. В них входят:Бизнес-моделирование (Business Практика RUPЧасто RUP считают тяжеловесным процессом с высоким уровнем формализма. Это не 2.2.1. Rational Unified ProcessМетодология разработки программного обеспечения, созданная компанией Rational Software. В основе RUPВ терминах RUP участники проектной команды создают так называемые артефакты (work products), Примеры артефактов RUPсловари, план разработки ПО, разные аспекты, связанные с рисками (например, Рабочий процесс RUPВ RUP определены шесть ИНЖЕНЕРНЫХ ДИСЦИПЛИН. В них входят:Бизнес-моделирование (Business Вспомогательные дисциплины RUPУправление конфигурациями и изменениями (Configuration and Change Management) – управление RUP. Начальная стадия (Inception)Назначение 	Запуск проектаЦелиОпределение области примененияОпределение элементов Use Case, критических RUP. Начальная стадия. Действия Формулировка области применения проектаВыявление требований (функциональных требований) и RUP. Начальная стадия. Артефакты Спецификация основных проектных требованийНачальная модель Use Case (20%)Начальный RUP. Уточнение (Elaboration).Назначение Создать архитектурный базисЦелиОпределяются оставшиеся требованияФункциональные требования выражаются с помощью RUP. Уточнение. ДействияРазвитие спецификацииФормирование критических элементов Use Case, задающих дальнейшие решениеРазвитие архитектуры, выделение её компонентов RUP. Уточнение. Артефакты Модель Use Case (80%)Дополнительные (в том числе нефункциональные) требованияОписание RUP. Построение (Construction).НазначениеСоздание ПП с начальной функциональностьюЦелиМинимальная стоимость разработкиБыстрое получение требуемого качестваБыстрое получение версий RUP. Построение. ДействияУправление ресурсами, контроль ресурсов (люди, используемое ПО, аппаратура)Оптимизация процессов разработкиПолная RUP. Построение. АртефактыПП, пригодный для отчуждения от разработчиков (альфа-, бета-версии и т.п.)Описание текущей реализацииРуководство пользователя RUP. Внедрение (Transition)НазначениеОтдать ПП пользователюЗавершить цикл выпуска ППДействия в каждой итерацииВыпуск версии RUP. ВыводыНаиболее продуманная методологияПодходит для больших и очень больших проетов (реже средних)Требует высокой квалификации участников 2 Строгие (классические, жесткие, предсказуемые) подходы2.1. Каскадные технологические подходы. 2.1.1. Классический каскадный 2.3. Генетические технологические подходыНазвание этой группы подходов дано Поттосином, в которой термин 2.3.1. Синтезирующее программированиеСинтезирующее программирование предполагает синтез программы по ее спецификации. В отличие 2.3.2. Сборочное (расширяемое) программированиеСборочное программирование предполагает, что программа собирается путем переиспользования уже известных фрагментов 2.3.2. Сборочное (расширяемое) программированиеСборка может осуществляться вручную или быть задана на некотором 2.3.2. Сборочное (расширяемое) программированиеСборочное программирование тесно связано с методом повторного использования кода, 2.3.2. Сборочное (расширяемое) программированиеМОДУЛЬНОЕ сборочное программирование. Этот подход был исторически первым и 2.3.3. Конкретизирующее программированиеПредполагает, что частные, специальные программы извлекаются из универсальной. Наиболее известная 2.3.3. Конкретизирующее программированиеПаттерн состоит из четырех основных элементов: имени - однозначно описывающего 2.4. Подходы на основе формальных преобразованийЭта группа подходов содержит максимально формальные требования 2.4.1. Технология стерильного цеха Основные идеи технологии стерильного цеха (cleanroom process model) 2.4.1. Технология стерильного цеха 2.4.1. Технология стерильного цехаПроцесс проектирования связан с представлением программы как функции, в 2.4.1. Технология стерильного цехаИспользование ящиков определяют следующие три принципа: все определенные при 2.4.1. Технология стерильного цехаЧерный ящик представляет собой точную спецификацию внешнего, видимого с 2.4.1. Технология стерильного цехаНа основании одних и тех же стимулов мы можем 2.4.1. Технология стерильного цехаЯщик с состояниями получаем из черного ящика выделением элементов 2.4.1. Технология стерильного цехаПрозрачный ящик получаем из ящика с состояниями, определяя процедуру, 2.4.1. Технология стерильного цехаВ данной технологии отсутствует ОТЛАДКА. Его заменяет процесс формальной 2.4.2. Формальные генетические подходыСложились методы программирования, обладающие свойством доказательности и не теряющие 2.4.2. Формальные генетические подходыФормальное СИНТЕЗИРУЮЩЕЕ программирование использует математическую спецификацию - совокупность логических 2.4.2. Формальные генетические подходыОдной из наиболее интересных современных работ в области формальных
Слайды презентации

Слайд 2 Технологическиеподходы
1. Подходы со слабой формализацией
2 Строгие (классические, жесткие,

Технологическиеподходы1. Подходы со слабой формализацией2 Строгие (классические, жесткие, предсказуемые) подходы2.1. Каскадные

предсказуемые) подходы
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. Компьютерный дарвинизм


Слайд 3 Рациональный унифицированный процесс Rational Unified Process RUP

Рациональный унифицированный процесс  Rational Unified Process  RUP

Слайд 4 Проблемы разработки ПО
Проекты по разработке ПО почти никогда

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

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

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

Слайд 5 2.2. Каркасные технологические подходы
Каркасные подходы представляют собой

2.2. Каркасные технологические подходы Каркасные подходы представляют собой каркас для процессов

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

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

Слайд 6 2.2.1. Рациональный унифицированный процесс

Основные особенности подхода:

итеративность с

2.2.1. Рациональный унифицированный процессОсновные особенности подхода: итеративность с присущей ей гибкостью;

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

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

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

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

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

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

Слайд 7 2.2.1. Рациональный унифицированный процесс

2.2.1. Рациональный унифицированный процесс

Слайд 8 2.2.1. Рациональный унифицированный процесс

Основные особенности подхода:

итеративность с

2.2.1. Рациональный унифицированный процессОсновные особенности подхода: итеративность с присущей ей гибкостью;

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

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

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

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

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

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

Слайд 9 2.2.1. Rational Unified Process
Авторы RUP:
Филипп Крачтен (Philippe Kruchten),

2.2.1. Rational Unified ProcessАвторы RUP:Филипп Крачтен (Philippe Kruchten), Грейди Буч (Grady


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

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

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


Слайд 10
Рабочие процессы RUP
(Disciplines):

Бизнес-моделирование
(Business Modeling)
Управление требованиями (Requirements

Рабочие процессы RUP(Disciplines):Бизнес-моделирование (Business Modeling) Управление требованиями (Requirements Management) Анализ и

Management)

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

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

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


Фазы RUP


Слайд 11 Основные характеристики процесса RUP

Основные характеристики процесса RUP

Слайд 12 Разработка требований в RUP
Для описания требований в

Разработка требований в RUP Для описания требований в RUP используются прецеденты

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

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

Слайд 13 Итеративная разработка в RUP
Проект в RUP состоит

Итеративная разработка в RUP Проект в RUP состоит из последовательности итераций

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

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

Слайд 14 Архитектура в RUP
RUP – ориентированная на архитектуру

Архитектура в RUP RUP – ориентированная на архитектуру методология. Считается, что

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

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

Слайд 15 Жизненный цикл проекта в RUP
Состоит из четырех фаз.

Жизненный цикл проекта в RUPСостоит из четырех фаз. Последовательность этих фаз

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

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

Слайд 16 Рабочий процесс RUP
В RUP определены шесть инженерных дисциплин.

Рабочий процесс RUPВ RUP определены шесть инженерных дисциплин. В них входят:Бизнес-моделирование

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

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

Слайд 17 Практика RUP
Часто RUP считают тяжеловесным процессом с высоким

Практика RUPЧасто RUP считают тяжеловесным процессом с высоким уровнем формализма. Это

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

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

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

Слайд 18 2.2.1. Rational Unified Process
Методология разработки программного обеспечения, созданная

2.2.1. Rational Unified ProcessМетодология разработки программного обеспечения, созданная компанией Rational Software. В

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

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

Слайд 19 RUP
В терминах RUP участники проектной команды создают так

RUPВ терминах RUP участники проектной команды создают так называемые артефакты (work

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

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

Слайд 20 Примеры артефактов RUP
словари,
план разработки ПО,
разные аспекты,

Примеры артефактов RUPсловари, план разработки ПО, разные аспекты, связанные с рисками

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

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

Слайд 21 Рабочий процесс RUP
В RUP определены шесть ИНЖЕНЕРНЫХ ДИСЦИПЛИН.

Рабочий процесс RUPВ RUP определены шесть ИНЖЕНЕРНЫХ ДИСЦИПЛИН. В них входят:Бизнес-моделирование

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

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

Слайд 22 Вспомогательные дисциплины RUP
Управление конфигурациями и изменениями (Configuration and

Вспомогательные дисциплины RUPУправление конфигурациями и изменениями (Configuration and Change Management) –

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

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


Слайд 23 RUP. Начальная стадия (Inception)
Назначение
Запуск проекта
Цели
Определение области

RUP. Начальная стадия (Inception)Назначение 	Запуск проектаЦелиОпределение области примененияОпределение элементов Use Case,

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

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

Слайд 24 RUP. Начальная стадия. Действия
Формулировка области применения проекта
Выявление

RUP. Начальная стадия. Действия Формулировка области применения проектаВыявление требований (функциональных требований)

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

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

Слайд 25 RUP. Начальная стадия. Артефакты
Спецификация основных проектных требований
Начальная

RUP. Начальная стадия. Артефакты Спецификация основных проектных требованийНачальная модель Use Case

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

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

Слайд 26 RUP. Уточнение (Elaboration).
Назначение
Создать архитектурный базис
Цели
Определяются оставшиеся требования
Функциональные

RUP. Уточнение (Elaboration).Назначение Создать архитектурный базисЦелиОпределяются оставшиеся требованияФункциональные требования выражаются с

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

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

Слайд 27 RUP. Уточнение. Действия
Развитие спецификации
Формирование критических элементов Use Case,

RUP. Уточнение. ДействияРазвитие спецификацииФормирование критических элементов Use Case, задающих дальнейшие решениеРазвитие архитектуры, выделение её компонентов

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


Слайд 28 RUP. Уточнение. Артефакты
Модель Use Case (80%)
Дополнительные (в

RUP. Уточнение. Артефакты Модель Use Case (80%)Дополнительные (в том числе нефункциональные)

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

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


Слайд 29 RUP. Построение (Construction).
Назначение
Создание ПП с начальной функциональностью
Цели
Минимальная стоимость

RUP. Построение (Construction).НазначениеСоздание ПП с начальной функциональностьюЦелиМинимальная стоимость разработкиБыстрое получение требуемого качестваБыстрое получение версий

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


Слайд 30 RUP. Построение. Действия
Управление ресурсами, контроль ресурсов (люди, используемое

RUP. Построение. ДействияУправление ресурсами, контроль ресурсов (люди, используемое ПО, аппаратура)Оптимизация процессов

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

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

Слайд 31 RUP. Построение. Артефакты
ПП, пригодный для отчуждения от разработчиков

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

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


Слайд 32 RUP. Внедрение (Transition)
Назначение
Отдать ПП пользователю
Завершить цикл выпуска ПП
Действия

RUP. Внедрение (Transition)НазначениеОтдать ПП пользователюЗавершить цикл выпуска ППДействия в каждой итерацииВыпуск

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

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


Слайд 33 RUP. Выводы
Наиболее продуманная методология
Подходит для больших и очень

RUP. ВыводыНаиболее продуманная методологияПодходит для больших и очень больших проетов (реже средних)Требует высокой квалификации участников

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


Слайд 34 2 Строгие (классические, жесткие, предсказуемые) подходы
2.1. Каскадные технологические

2 Строгие (классические, жесткие, предсказуемые) подходы2.1. Каскадные технологические подходы. 2.1.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. Компьютерный дарвинизм

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

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


Слайд 35 2.3. Генетические технологические подходы
Название этой группы подходов дано

2.3. Генетические технологические подходыНазвание этой группы подходов дано Поттосином, в которой

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

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

Слайд 36 2.3.1. Синтезирующее программирование
Синтезирующее программирование предполагает синтез программы по

2.3.1. Синтезирующее программированиеСинтезирующее программирование предполагает синтез программы по ее спецификации. В

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

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

Слайд 37 2.3.2. Сборочное (расширяемое) программирование
Сборочное программирование предполагает, что программа

2.3.2. Сборочное (расширяемое) программированиеСборочное программирование предполагает, что программа собирается путем переиспользования уже известных фрагментов

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


Слайд 38 2.3.2. Сборочное (расширяемое) программирование
Сборка может осуществляться вручную или

2.3.2. Сборочное (расширяемое) программированиеСборка может осуществляться вручную или быть задана на

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

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

Слайд 39 2.3.2. Сборочное (расширяемое) программирование
Сборочное программирование тесно связано с

2.3.2. Сборочное (расширяемое) программированиеСборочное программирование тесно связано с методом повторного использования

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

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

Слайд 40 2.3.2. Сборочное (расширяемое) программирование
МОДУЛЬНОЕ сборочное программирование. Этот подход

2.3.2. Сборочное (расширяемое) программированиеМОДУЛЬНОЕ сборочное программирование. Этот подход был исторически первым

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

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

Слайд 41 2.3.3. Конкретизирующее программирование
Предполагает, что частные, специальные программы извлекаются

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

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

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

Слайд 42 2.3.3. Конкретизирующее программирование
Паттерн состоит из четырех основных элементов:

2.3.3. Конкретизирующее программированиеПаттерн состоит из четырех основных элементов: имени - однозначно


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

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

Слайд 43 2.4. Подходы на основе формальных преобразований



Эта группа подходов

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

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



Слайд 44 2.4.1. Технология стерильного цеха
Основные идеи технологии стерильного цеха

2.4.1. Технология стерильного цеха Основные идеи технологии стерильного цеха (cleanroom process

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

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

Слайд 45 2.4.1. Технология стерильного цеха

2.4.1. Технология стерильного цеха

Слайд 46 2.4.1. Технология стерильного цеха
Процесс проектирования связан с представлением

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

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

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

Слайд 47 2.4.1. Технология стерильного цеха
Использование ящиков определяют следующие три

2.4.1. Технология стерильного цехаИспользование ящиков определяют следующие три принципа: все определенные

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

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

Слайд 48 2.4.1. Технология стерильного цеха
Черный ящик представляет собой точную

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

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

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

Слайд 49 2.4.1. Технология стерильного цеха
На основании одних и тех

2.4.1. Технология стерильного цехаНа основании одних и тех же стимулов мы

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

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

Слайд 50 2.4.1. Технология стерильного цеха
Ящик с состояниями получаем из

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

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

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

Слайд 51 2.4.1. Технология стерильного цеха
Прозрачный ящик получаем из ящика

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

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

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

Слайд 52 2.4.1. Технология стерильного цеха
В данной технологии отсутствует ОТЛАДКА.

2.4.1. Технология стерильного цехаВ данной технологии отсутствует ОТЛАДКА. Его заменяет процесс

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

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

Слайд 53 2.4.2. Формальные генетические подходы
Сложились методы программирования, обладающие свойством

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

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

Три

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

Слайд 54 2.4.2. Формальные генетические подходы
Формальное СИНТЕЗИРУЮЩЕЕ программирование использует математическую

2.4.2. Формальные генетические подходыФормальное СИНТЕЗИРУЮЩЕЕ программирование использует математическую спецификацию - совокупность

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

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

  • Имя файла: klassifikatsiya-tehnologicheskih-podhodov-strogie-karkasnye-geneticheskie-i-na-osnove-formalnyh-preobrazovaniy.pptx
  • Количество просмотров: 127
  • Количество скачиваний: 0