- •Введение
- •Содержание
- •1.1 Анализ и характеристика областей знаний swebok
- •1.1.1. Требования к по (Software Requirements)
- •1.1.2. Проектирование по (Software design)
- •1.1.3. Конструирование по (Software Construction)
- •1.1.4. Тестирование по (Software Testing)
- •1.1.5. Сопровождение по (Software maintenance)
- •1.1.6. Управление конфигурацией по
- •1.1.7. Управление инженерией по
- •1.1.8. Процесс инженерии по (Software Engineering Process)
- •1.1.9. Методы и инструменты инженерии по
- •1.1.10. Качество по (Software Quality)
- •1.2. Жизненный цикл пс, связь с ядром знаний swebok
- •Контрольные вопросы и задания
- •Лекция 2: Модели жизненного цикла для разработки программных систем Содержание
- •2.1. Процессы жц стандарта iso/iec 12207
- •2.2. Типы моделей жц
- •2.2.1. Каскадная модель жц
- •2.2.2. Инкрементная модель жц
- •2.2.3. Спиральная модель
- •2.2.5. Стандартизация модели жц
- •2.3. Сопоставление жц стандарта iso/iec 12207 и областей swebok
- •2.3.1. Характеристика процессов стандарта iso/iec 12207
- •2.3.2. Характеристика областей знаний swebok
- •Контрольные вопросы и задания
- •Лекция 3: Методы определения требований в программной инженерии Содержание
- •3.1. Общие подходы к определению требований
- •3.1.1. Классификация требований
- •3.1.2. Анализ и сбор требований
- •3.1.3. Инженерия требований
- •3.1.4. Фиксация требований
- •3.1.5. Трассировка требований
- •Сложность программного обеспечения
- •1.8.1. Каскадная (водопадная) модель
- •1.8.2. Итеративная и инкрементальная модель
- •1.8.3. Спиральная модель Боэма
- •1.9.1. Методология Rational Unified Process (rup)
- •2. Проектирование (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •1.9.2. Экстремальное программирование
- •Живое планирование (planning game)
- •Программирование парами (pair programming)
- •Включение заказчика в команду (on-site customer)
- •Использование кода как средства коммуникации
- •Открытое рабочее пространство (open workspace)
- •Изменение правил по необходимости (just rules)
1.9.1. Методология Rational Unified Process (rup)
RUP - методология разработки программного обеспечения, созданная компанией Rational Software. Она является ведущей методологией разработки ПО. Это пример «тяжелого» процесса.
RUP использует итеративную и инкрементальную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
В основе RUP лежат следующие основные принципы:
Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Структуру жизненного цикла проекта, выполняемого по технологии RUP удобно рассматривать на координатной плоскости. При этом по горизонтальной оси отложено время, а по вертикальной — основные деятельности, которые обычно выполняются в ходе любого проекта, претендующего на статус успешного (рис. 1.4).
Время отражает динамический аспект жизненного цикла проекта, выраженный в терминах циклов, фаз, итераций и контрольных точек, которые разделяют две отдельные фазы. Вертикальная ось отражает статический аспект проекта. Он описывается в терминах процессов, артефактов (единица информации, создаваемая или модифицируемая в ходе любого процесса) и ролей (ответственность за адекватное выполнение той или иной деятельности в процессе).
Рисунок 1.4. - Процессы (дисциплины) и фазы жизненного цикла проекта в RUP
RUP организует выполнение проекта по фазам, каждая из которых состоит из одной или нескольких итераций. При итеративном подходе объем работ по каждому процессу варьируется в течение всего жизненного цикла. Контрольные точки в конце фаз позволяют оценить, насколько успешной была предыдущая фаза и насколько успешен весь проект в целом.
Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций:
1. Начало (Inception)
На этом этапе:
Формируются видение и границы проекта.
Создается экономическое обоснование (business case).
Определяются основные требования, ограничения и ключевая функциональность продукта.
Создается базовая версия диаграммы вариантов использования.
Оцениваются риски.
2. Проектирование (Elaboration)
На этапе Проектирование производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
Документирование требований (включая детальное описание большинства вариантов использования).
Спроектированную, реализованную и оттестированную исполняемую архитектуру.
Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
Сниженные основные риски.
