Технологии программирования (Software Engineering)
Основные стадии технологических подходов
Мы уже отмечали, что технологические стадии выделяются исходя из соображений разумного
и рационального планирования и организации работ. Существует два основных варианта
формирования временных рамок.
В этом случае названия фаз отражают крупные временные рамки. Пример такого деления
присутствует в рациональном унифицированном процессе [Буч, Рамбо, Джекобсон 2000].
Начало - определение бизнес-целей проекта.
Исследование - разработка плана и архитектуры проекта.
Построение - постепенное создание системы.
Внедрение - поставка системы конечным пользователям.
4.2. Стадии как отражение классических процессов
Во втором варианте - названия стадий отражают названия классических процессов (или
их подмножества или надмножества), большая часть времени которых проходит в данной
стадии. Следующие девять стадий присутствуют практически во всех технологических подходах.
Несколько упрощая суть, можно считать, что их содержание совпадает с рядом процессов
и действий процесса разработки. По крайней мере, большая часть времени выполнения
процесса или действия (действий) процесса будет приходиться на одноименную стадию:
возникновение и исследование идеи;
планирование;
анализ требований;
проектирование;
программирование (реализация);
тестирование и отладка;
ввод в действие;
эксплуатация и сопровождение;
завершение эксплуатации.
4.3. Вариант подробного разбиения на стадии
Предложим руководителю проекта один из возможных вариантов подробного деления разработки
на стадии. Он демонстрирует важность контрольных точек (см. разд. 3.4.4). Этот вариант
берет за основу стадии, отражающие классические процессы:
стадия возникновения и исследования идеи;
стадия планирования проекта;
стадия анализа и проектирования;
стадия реализации;
стадия версии разработчика;
стадия оценки жизнеспособности продукта;
стадия альфа-версии;
стадия бета-версии;
стадия версии первой поставки пользователю.
Каждая стадия может быть разбита на этапы, отражающие основные события ее существования.
Стадия возникновения и исследования идеи.
Этап-1 - Исследование идеи.
Этап-2 - Концентрация идеи в виде одностраничного описания.
Этап-3 - Принятие решения о начале работы над проектом.
Стадия планирования проекта.
Этап-1 - Подготовка плана проекта.
Этап-2 - Техническое рецензирование проекта.
Этап-3 - Начало формирования команды разработчиков.
Этап-4 - Обзор планов инженеров.
Этап-5 - Исследование и поиск необходимых ресурсов.
Этап-6 - Достижение соглашения о выделении ресурсов.
Этап-7 - Утверждение проекта.
Стадия анализа и проектирования.
Этап-1 - Анализ и проектирование продукта.
Этап-2 - Планирование разработки тестов и документации.
Стадия реализации.
Этап-1 - Кодирование, разработка тестов и документации.
Этап-2 - Интеграция кода, тестов и документации.
Стадия версии разработчика.
Этап-1 - Объединение кодов нескольких компонентов, составляющих проект.
Этап-2 - Стабилизация версии.
Этап-3 - Тестирование.
Этап-4 - Распространение версии.
Стадия оценки жизнеспособности продукта.
Этап-1 - Оценка жизнеспособности продукта.
Стадия альфа-версии.
Этап-1 - Объединение кодов нескольких компонентов, составляющих проект.
Этап-2 - Стабилизация версии.
Этап-3 - Формальное начало выпуска версии.
Этап-4 - Распространение версии.
Этап-5 - Продолжающаяся разработка.
Этап-6 - Формальное тестирование.
Этап-7 - Начало сопротивления изменениям.
Стадия бета-версии.
Этап-1 - Объединение кодов нескольких компонентов, составляющих проект.
Этап-2 - Стабилизация версии.
Этап-3 - Создание электронного образа версии поставки.
Этап-4 - Формальное тестирование версии.
Этап-5 - Начало процесса помещения версии продукта на страницы в Интернете или
на компакт-диски, дискеты или другие носители.
Стадия версии первой поставки пользователю.
Этап-1 - Принятие решения о возможном переименовании бета-версии в версию первой
поставки пользователю в случае отсутствия ошибок и переходе к этапу 6.
Этап-2 - Объединение кодов нескольких компонентов, составляющих проект.
Этап-3 - Стабилизация версии.
Этап-4 - Создание электронного образа версии поставки.
Этап-5 - Формальное тестирование версии.
Этап-6 - Начало процесса помещения версии продукта на страницы в Интернете или
на компакт-диски, дискеты или другие носители.
Этап-7 - Завершающий анализ работы над версией ("разбор полетов").
К моменту завершения проекта
Статистики от стоматологии вывели закон "3 к 11". Они обнаружили, что пациенты распространяют
информацию о зубных врачах следующим образом. Если зуб вылечен хорошо, то человек
рассказывает об этом в среднем трем своим знакомым. Если плохо - тогда одиннадцати.
Именно такова психология людей и заказчиков в том числе. Именно это надо учитывать
и добиваться полного удовлетворения заказчиков и пользователей, создавая о себе хорошую
славу.
4.4. Контрольные точки
Важность контрольных точек заключается в том, что именно в них мы должны четко
оценить - в какой мере достигнуты намеченные цели и критерии и не следует ли внести
в процесс изменения прежде, чем двигаться дальше.
Уточним лишь, что традиционно понимается под различными типами версий и критериями,
к ним предъявляемыми.
Версия разработчика является ранней версией для внутреннего использования и тестирования
(с учетом инсталлирования и лицензирования).
На этапе альфа-версии продукт должен быть функционально полным, все фрагменты
должны быть правильно интегрированы в систему. Обычно формулируется список специальных
"альфа-критериев", которым продукт должен удовлетворять (например, должны быть исправлены
все высокоприоритетные ошибки). Запрещается внесение новых свойств и изменение интерфейса.
Готовы тестовые сюиты для генерального тестирования и документация. Как правило, программное
обеспечение на этом этапе не передается для внешнего тестирования.
На этапе бета-версии продукт должен удовлетворять специальным "бета-критериям"
(например, должны быть исправлены все ошибки высокого и среднего приоритетов) и быть
готовым к внешнему тестированию. Бета-версия содержит инсталляционную программу. Может
быть полезным предоставление бета-тестерам информации об обнаруженных ошибках, в некоторых
случаях это может помочь найти причину ошибки.
На этапе версии первой поставки пользователю продукт должен удовлетворять специальным
"критериям первой поставки пользователю" (например, полное отсутствие существенных
ошибок) и быть готовым к поставке пользователям.
Знаете ли Вы, что Polymorphism, полиморфизм в объектно-ориентированном программировании - это способность объекта выбирать правильный метод в зависимости от типа данных, полученных в сообщении.
