- •Введение
- •Практическая работа №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.6. Занятость исполнителей
Модель процесса предполагает параллельное выполнение нескольких проектов. Для динамического формирования команд исполнителей и составления индивидуальных планов-графиков необходимо учитывать схему занятости исполнителей, которая определяется моделью процесса.
В случае выполнения сверх легких проектов, в которых на каждый проект задействован один исполнитель, играющий все роли и являющийся руководителем проекта, особых проблем с занятостью исполнителей нет. После окончания одного проекта исполнитель начинает следующий, чем обеспечивается 100% занятости при равномерной нагрузке.
Замечание. Индивидуальный характер работы над сверх легкими проектами позволяет просто планировать отвлечение исполнителей (отпуск, обучение) на периоды между проектами. В случае выполнения только легких проектов может быть обеспечена равномерная полная занятость без смены ролевых функций при следующем соотношении численности групп: Аналитики : Программисты : Эксплуатационники = 2 : 2 : 1.
На рис. 18 показана плотная укладка четырех проектов. Фазы первого проекта обведены сплошной линией, фазы второго проекта заштрихованы горизонтально, фазы третьего проекта заштрихованы вертикально, фазы четвертого проекта обведены волнистой линией. Буква А обозначает фазу анализа, П - планирование, Р - реализация, С - стабилизация, О - опытная эксплуатация, В - внедрение.
Замечание по конструированию. Схему укладки реализовать значительно проще, если исполнители владеют смежными специализациями и могут играть различные роли.
В случае наличия тяжелых и сверх тяжелых проектов плотной укладки без смены ролевых функций не существует. Для проектов этих типов неизбежно динамическое переназначение ролей, и даже в этом случае не всегда возможно распределить роли так, чтобы обеспечить полную занятость и равномерную нагрузку.
Замечание по конструированию. В предлагаемой модели процесса нет абсолютной жесткой схемы назначения ответственности за достижение вехи на определенную роль. Конкретное назначение ответственности за веху определяется планом фазы, и может быть различным для разных типов проектов.
Абсолютные величины трудозатрат по ролям для проектов разных типов (в условных человеко-месяцах):
|
Сверх легкий |
Легкий |
Тяжелый |
Сверх тяжелый |
Аналитик |
0,5 |
4 |
4 |
6 |
Программист |
1 |
4 |
3 |
4 |
Эксплуатационник |
0,5 |
2 |
3 |
3 |
Всего |
2 |
10 |
10 |
13 |
На рис. 20 показано относительное соотношение между трудозатратами для проектов разных типов.
Замечание по конструированию. Следует обратить внимание на то, что чем тяжелее проект, тем большую долю составляет работа аналитиков и тем меньшую долю составляет работа аналитиков.
3.4.4. Порядок проведения типового проекта
Замечание по конструированию. Сконструированная в соответствии с потребностями программирующей организации абстрактная модель процесса должна быть переведена в конкретную форму, допускающую ее практическое применение. Такой формой в настоящее время чаще всего является документированная процедура. Документированные процедуры описывают различными средствами, в соответствии с корпоративной культурой и иными особенностями организации. В качестве примера приведем описание документированной процедуры «порядок проведения типового проекта» с использованием унифицированного языка моделирования UML и естественного языка.
В качестве типового проекта, на примере которого описывается порядок проведения, выбран легкий проект, содержащий разработку вертикального приложения по внешнему заказу.
Вопросы появления проектов (маркетинг, формирование портфеля заказов, работа с потенциальными заказчиками) находятся вне рамок основной процедуры. Далее считается, что рассматриваемый проект имеет место, т. е. известен потенциальный заказчик, известна предметная область и тип потенциального проекта.
Выполнение проекта другого типа может отличаться в деталях выполняемых действий и в составе документов проекта, но основная процедура является неизменной и состоит в последовательном выполнении трех этапов:
подготовка к проекту;
работа над проектом;
3. завершение проекта.
Далее рассматриваются основные действия и документы, специфические для каждого из этапов. Выполнение каждого этапа подразумевает выполнение соответствующей процедуры этапа. Общая процедура прохождения проекта представлена на рис. 20.