Лекции ПИС / Книги / RSA Архитектура программной системы
.pdf
Общий план технологического процесса разработки ПО
ЧТО ДОЛЖНА ДЕЛАТЬ |
КАК БУДЕТ РАБОТАТЬ |
|
ПРОГРАММНАЯ СИСТЕМА |
ПРОГРАММНАЯ СИСТЕМА |
|
Модель |
Модель |
Исходный |
требований |
архитектуры |
код |
|
IBM Rational |
IBM Rational |
|
Software Architect |
Application Developer |
Каркас цепочки моделей при разработке ПО в RSA
1
Модель
предметной
области
диаграмма деловых вариантов использования
диаграмма деловых классов
диаграмма |
деловой активности |
2
Модель
вариантов
использования
системы
диаграмма
вариантов
использования
3
Модель анализа реализации вариантов использования системы
диаграмма
последовательности этапа анализа
диаграмма классов этапа анализа
4
Модель проекта системы
диаграмма последовательности этапа проектирования
диаграмма классов этапа проектирования
5
Исходный
код
листинг
исходного
кода
22 |
© 2010 IBM Corporation |
Методологии ведения программных проектов
Каскадная модель
Предложена У.У. Ройсом в 1970 г.
Предусматривает строгую последовательность этапов разработки, при которой переход к следующему этапу осуществляется только после того, как будут завершены
все задачи предыдущего.
Планирование
Требования Анализ и проектирование
Программирование
Тестирование Передача в эксплуатацию
Спиральная модель
Предложена Б. Боэмом в 1988 г. Модель сочетает в себе возможности каскадной модели разработки и постадийного прототипирования. Каждый виток спирали предполагает выпуск очередной версии системы, уточнение задач проекта. Переход к следующей стадии проекта осуществляется в соответствии с планом работ, даже, если не вся работа на предыдущей стадии завершена.
IBM Rational Unified Process |
Microsoft Solutions Framework |
Итеративный процесс разработки программного |
Методология разработки программного обеспечения, |
обеспечения, созданный компанией Rational Software |
предложенная Microsoft в 1994 г. |
в 1996 г. |
|
Agile
Концептуальный каркас гибкой методологии разработки ПО. Нацелен на раннюю минимизацию проектных рисков путём сведения всего проекта разработки к серии повторяемых циклов, называемых итерациями. Каждая итерация — это мини-проект, результатом которого является новая версия продукта. Большое внимание уделяется непосредственному общению с заказчиком.
Манифест Agile-методов был принять в 2001 г.
XP |
Scrum |
Методология «экстремального |
Методология ведения agile- |
программирования». |
разработки. Позволяет в жёстко |
Предполагает короткий цикл обратной |
фиксированные и по времени |
связи и непрерывный процесс |
итерации предоставлять конечному |
разработки |
пользователю работающее ПО с |
|
новыми возможностями, для которых |
|
определён наибольший приоритет |
Rapid Application Development
OpenUP
Итеративно-инкрементальный метод разработки ПО, рассматриваемый как легкий и гибкий вариант RUP
V-Model
Концепция создания средств разработки программных |
Вариация каскадной модели, в которой задачи разработки |
продуктов, уделяющая внимание быстроте и удобству |
идут сверху вниз по левой стороне буквы V, |
программирования |
а задачи тестирования — вверх по правой стороне буквы V |
IBM Rational Unified Process
Дисциплины:
Бизнес моделирование
Требования
Анализ и проектирование
Реализация
Тестирование
Развёртывание Управление конфигурацией и
изменениями Управление проектом
Управление средой
время
Справка о методе OpenUP
Версия OpenUp 1.0 была опубликована в 2007 году
Метод развивается в рамках проекта Eclipse Process Framework Project
Проект с открытым исходным кодом, фокусирующийся на методологиях создания ПО Цели проекта:
Предоставить расширяемую платформу и образцовые инструменты для разработки 1.программного обеспечения
Предоставить образцовый и расширяемый контент для различных процессов 2. разработки, поддерживающих итеративную, гибкую и инкрементальную разработку,
применимый к широкому набору программных платформ и приложений
Образцовый инструмент: EPF Composer |
Образцовый процесс: OpenUP |
OpenUP: Фазы и вехи
НАЧАЛО
Веха назначения системы
Получено согласие заинтересованных лиц по следующим вопросам:
Границы системы
График проекта и его начальная стоимость
Начальный набор требований и их приоритетность
Риски в проекте и методы борьбы с ними
РАЗРАБОТКА
Веха архитектуры
Концепция системы, требования и архитектура стабильны
Главные риски сняты через тестирование и оценку исполняемых прототипов
Итерации фазы реализации спланированы с достаточной степенью детализации
Фактический расход ресурсов сравним с плановым и возможное отклонение приемлимо
РЕАЛИЗАЦИЯ
Веха начальной работоспособности
Программный продукт стабилен и достаточно готов для развёртывания в среде пользователя:
Готова бета-версия продукта
Вся функциональность реализована и протестирована
Подготовлено руководство пользователя и описание текущей версии продукта
Фактический расход ресурсов сравним с плановым и возможное отклонение приемлимо
ПЕРЕДАЧА
Веха готового продукта
Продукт принят заказчиком и пользователи удовлетворены его функциями
Заинтересованные лица согласны принять фактический расход ресурсов
Продукт в эксплуатации - следовательно, вы можете начать новый цикл работ по его усовершенствованию и/или его сопровождению.
Источник: Eclipse Process Framework 1.5.1.3 Release
OpenUP: Дисциплины и артефакты
Требования
Архитектура
Разработка
Тестирование
Управление
проектом
Управление
конфигурацией и изменениями
Концепция системы Словарь предметной области
Модель вариантов использования системы Спецификация потоков событий Вспомогательные требования Модель архитектуры системы Проект системы
Реализация системы (исходный код) Тесты компонент системы
Текстовые сценарии тестирования системы Журнал испытаний системы Программные сценарии тестирования План проекта План итерации Список задач Список рисков
Рабочая сборка
Источник: Eclipse Process Framework 1.5.1.3 Release
OpenUP: Роли
Требования
Архитектура
Разработка
Тестирование
Управление
проектом
Управление
конфигурацией и изменениями
Аналитик |
Заинтересованные лица |
Архитектор
Разработчик
Тестировщик
Руководитель проекта
Разработчик
Источник: Eclipse Process Framework 1.5.1.3 Release
OpenUP: Потоки работ и итерации
|
НАЧАЛО |
|
|
РАЗРАБОТКА |
|
|
РЕАЛИЗАЦИЯ |
|
||||
Инициирование проекта |
Планирование и управление итерацией |
Идентификация и уточнение требований |
Согласование технического подхода |
Планирование и управление итерацией |
Идентификация и уточнение требований |
Разработка архитектуры |
Разработка решения |
Тестирование решения |
Планирование и управление итерацией |
Идентификация и уточнение требований |
Разработка решения |
Тестирование решения |
Требования
Архитектура
Разработка
Тестирование
Управление
проектом
Управление
конфигурацией и изменениями
итерация 1 |
итерация 2 |
итерация 3 |
Источник: Eclipse Process Framework 1.5.1.3 Release |
|
итерация 4 * |
|
|
ПЕРЕДАЧА
Планирование и управление итерацией |
Разработка решения |
Тестирование решения |
итерация 5
OpenUP: Задачи дисциплины «Требования»
|
|
НАЧАЛО |
|
|
РАЗРАБОТКА |
|
|
РЕАЛИЗАЦИЯ |
|
||||
|
Инициирование проекта |
Планирование и управление итерацией |
Идентификация и уточнение требований |
Согласование технического подхода |
Планирование и управление итерацией |
Идентификация и уточнение требований |
Разработка архитектуры |
Разработка решения |
Тестирование решения |
Планирование и управление итерацией |
Идентификация и уточнение требований |
Разработка решения |
Тестирование решения |
Требования |
Определить |
|
Найти |
|
|
Найти |
|
|
|
|
Найти |
|
|
|
требования |
|
|
требования |
|
|
|
|
требования |
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|||
|
концепцию |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Детализировать |
|
|
Детализировать |
|
|
|
|
Детализировать |
|
|
|
|
|
требования |
|
|
требования |
|
|
|
|
требования |
|
|
Архитектура
Разработка
Тестирование
Управление
проектом
Управление
конфигурацией и изменениями
итерация 1 Источник: Eclipse Process Framework 1.5.1.3 Release
Обработка |
Обработка |
запроса на |
запроса на |
изменение |
изменение |
итерация 2 |
итерация 3 |
|
итерация 4 * |
ПЕРЕДАЧА
Планирование и управление итерацией |
Разработка решения |
Тестирование решения |
итерация 5