- •Введение
- •Практическая работа №1. Тема: технология программирования. Основные понятия и подходы.
- •1.1. Назначение технологии программирования
- •1.2. История развития технологии программирования
- •1.2.1. Дореволюционный период
- •1.2.2. «Революция в программировании»
- •1.2.3. Послереволюционный период
- •1.3. Типы программных проектов
- •1.4. Составные части технологии программирования
- •1.5. Проект, продукт, процесс и персонал
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме.
- •Практическая работа №2. Тема: приемы обеспечения технологичности программных продуктов.
- •2.1. Циклический характер разработки
- •2.2. Основные понятия технологии программирования
- •2.2.1. Процессы и модели
- •2.2.2. Фазы и витки
- •2.2.3. Вехи и артефакты
- •2.2.4. Заинтересованные лица и работники
- •2.3. Выявление и анализ требований
- •2.3.1. Требования к программному обеспечению
- •2.3.2. Схема разработки требований
- •2.3.3. Управление требованиями
- •2.4. Архитектурное и детальное проектирование
- •2.4.1. Архитектурное проектирование
- •2.4.2. Детальное проектирование
- •2.5. Реализация и кодирование
- •2.6. Тестирование и верификация
- •2.6.1. Процесс контроля качества
- •2.6.2. Методы «белого ящика» и «черного ящика»
- •2.6.3. Инспектирование и обзоры
- •2.6.4. Цели тестирования
- •2.6.5. Верификация, валидация и системное тестирование
- •2.7. Сопровождение и продолжающаяся разработка
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме.
- •Практическая работа №3. Тема: определение требований к программному обеспечению и исходных данных для его проектирования. Модели процесса разработки.
- •3.1. Водопадные и конвейерные модели
- •3.2. Спиральные и инкрементные модели
- •3.4. Конструирование модели процесса
- •3.4.1. Выявление требований к процессу
- •3.4.2. Используемые фазы, вехи и артефакты
- •3.4.2.1. Фаза «Анализ»
- •3.4.2.2. Фаза «Проектирование»
- •3.4.2.3. Фаза «Реализация»
- •3.4.2.4. Фаза «Стабилизация»
- •3.4.2.5. Фаза «Внедрение»
- •3.4.3. Выбор архитектуры процесса.
- •3.4.3.1. Типы проектов
- •3.4.3.2. Модель процесса сверх легкого проекта
- •3.4.3.3. Модель процесса легкого проекта
- •3.4.3.4. Модель процесса тяжелого проекта
- •3.4.3.5. Модель процесса сверх тяжелого проекта
- •3.4.3.6. Занятость исполнителей
- •3.4.4. Порядок проведения типового проекта
- •3.4.4.1. Этап 1. Подготовка к проекту
- •3.4.4.2. Сбор и анализ предварительной информации
- •3.4.4.3. Формирование бригады проекта
- •3.4.4.4. Подготовка исходных документов
- •3.4.4.5. Этап 2. Работа над проектом
- •3.4.4.6. Процедура выполнения фазы проекта
- •3.4.4.7. Подготовка результирующих материалов вех
- •3.4.4.8. Этап 3. Завершение проекта
- •3.4.4.9. Архивирование результатов работы
- •3.4.4.10. Подведение итогов проекта
- •3.4.5. Документированные процедуры
- •3.4.5.3. Проверка качества материалов
- •3.4.6. Выводы
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме
- •Практическая работа №4. Тема: анализ требований и определение спецификаций программного обеспечения при структурном подходе.
- •4.1. Спецификации программного обеспечения при структурном подходе
- •4.2. Определение понятий и видов требований
- •Виды требований
- •4.1.2. Анализ и сбор требований
- •4.1.3. Инженерия требований по
- •4.2. Трассирование требований
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме
3.4.3.4. Модель процесса тяжелого проекта
В спиральной структуре тяжелого проекта (рис. 16) второй виток начинается в тот момент, когда достигнута главная веха фазы реализации первого витка и, тем самым, доказана принципиальная возможность реализации при выбранной концепции. Для тяжелого проекта расчет общей продолжительности проводится по формуле 7,5+1,5. В типичном случае, считая продолжительность фаз проектирования и внедрения равной полутора месяцам, а продолжительность остальных фаз равной месяцу, заказчик получает результат через 9 месяцев.
Замечание по конструированию. В тяжелом проекте фазы проектирования (и повторного анализа), а также внедрения следует немного удлинить.
Замечание по конструированию. На схемах спиральной структуры первый выпуск заканчивается выпуском прототипа19, который является законченным приложением (решением), но не является тем экземпляром приложения, который будет реально эксплуатироваться заказчиком после окончания проекта. Это не означает, что результаты пилотного проекта полностью выбрасываются. Напротив, они в максимальной степени используются при построении второго "боевого" варианта приложения (решения).
Схематический план-график модели процесса тяжелого проекта:
П. |
Фаза |
Веха |
Роль |
Примечания |
1 |
Анализ |
Концепция |
Аналитик |
|
2 |
Планирование |
Спецификации |
Аналитик |
|
3 |
Реализация |
Код готов |
Программист |
|
4 |
Анализ |
Концепция |
Аналитик |
|
Стабилизация |
Выпуск |
Программист / Тес-тировщик |
|
5 |
Планирование |
Спецификация |
Аналитик |
Переработка предыдущей спецификации |
Опытная эксплуатация |
|
Тестировщик / Эксплуатационник |
| |
6 |
Реализация |
Код готов |
Программист |
|
7 |
Стабилизация |
Выпуск |
Программист / Тес-тировщик |
|
8 |
Внедрение |
Проект закончен |
Эксплуатационник |
|
19 Иногда употребляется термин "пилотный проект". Не следует путать "прототип" на этих схемах с "прототипом", о котором речь шла при перечислении вех фазы планирования.
3.4.3.5. Модель процесса сверх тяжелого проекта
Если фаза реализации тяжелого проекта заканчивается неудачей, т.е. вехи "код готов" на первом витке не удается достичь, то проект переходит из категории тяжелых в категорию сверх тяжелых. Такая ситуация означает необходимость увеличить срок выполнения проекта на время, затраченное до момента получения видимой неудачи первоначальной концепции. Если увеличить сроки выполнения проекта невозможно, то проект следует прекратить, чтобы уменьшить неизбежные убытки. В противном случае, т.е. при попытке выполнить проект в намеченные сроки за счет вложения дополнительных ресурсов, возникает очень большой финансовый риск. Если же проект можно удлинить, то он возвращается в категорию тяжелых и проходит согласно модели процесса тяжелого проекта. Таким образом, в типичном случае, считая продолжительность одной фазы равной месяцу, заказчик получает результат сверх тяжелого проекта через 12 месяцев (рис. 17).
Замечание по конструированию. Согласно авторитетным зарубежным источникам, сокращение сроков требует не менее чем квадратичного увеличения ресурсов. Например, чтобы сократить сроки вдвое, потребуется вложить вчетверо больше ресурсов.
Замечание по конструированию. Формально в процессе сверх тяжелого проекта имеется 11 периодов, но продолжительность фаз анализа, повторного анализа и окончательного внедрения следует положить равной 1,5 месяца.