Этапы разработки и тестирования

Альтернативой последовательной модели является модель итеративной и инкрементальной разработки [2]. Она предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектов в целом.
У каждой итерации целью является получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результатом финальной итерации является вся требуемая функциональность продукта. То есть, в основе такой модели лежит эволюционность.
В этом случае, шансы на успешное создание сложного программного продукта будут максимальны, ведь изначально каждый такой шаг заключает в себе четко определенный успех, а также возможность вернуться к предыдущему успешному этапу в случае неудачи. Именно так разработчик может получить из окружающего мира обратную связь и исправить возможные ошибки в проекте. Но все же у такого подхода будут и свои минусы:
Очень долгое время отсутствует целостное понимание возможностей и ограничений проекта;
При итерациях приходится отбрасывать часть сделанной ранее работы.
Снижается добросовестность специалистов при выполнении работ.
center192024000И все же, в современном мире варианты итерационного подхода реализованы в большинстве современных методологий разработки. Рассмотрим еще одну возможную модель жизненного цикла – спиральная модель [2]. Эта модель была разработана в середине 1980-х годов Барри Боэмом. Основывается она на классическом цикле Деминга PDCA (plan-do-check-act) – это повторяющийся процесс принятия решения, представляющий собой
Рисунок 3 – Спиральная модель.
простейший алгоритм действий руководителя по управлению процессом и достижению его целей. Начинается такой цикл с планирования – установления целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворение возможного пользователя, а также планирование выделения и распределения необходимых ресурсов. Следующий этап – выполнение запланированных работ. После него идет проверка – сбор информации и контроль результата на основе ключевых показателей эффективности, получившегося в ходе выполнения работы, выявление и анализ отклонений, установление причин отклонений. Завершающий этап такого цикла – воздействие, то есть принятие мер по устранению причин отклонений от запланированного результата, изменение в планировании и распределении ресурсов. При использовании такой модели жизненного цикла программного продукта создается несколько итераций, в данном случае это витки спирали, методом прототипирования [6]. Каждая такая итерация соответствует созданию фрагмента или версии программного продукта. Далее уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируется работа следующей итерации.
Во время работы с каждой итерацией проводится оценка следующего:
Риск превышения сроков и стоимости программного продукта;
Необходимость выполнения еще одной итерации;
Степень полноты и точности понимания требований к системе;
Целесообразность прекращения проекта.
Отличительной особенностью спиральной модели жизненного цикла программного продукта является особое внимание, уделяемое рискам, влияющим на организацию, и контрольным точкам [3]. Наиболее распространенные риски по формулировке Боэма:
Дефицит специалистов;
Нереалистичные сроки и бюджет;
Реализация несоответствующей функциональности;
Разработка неправильного пользовательского интерфейса;
Ненужная оптимизация и оттачивание деталей;
Непрекращающийся поток изменений;
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию;
Недостатки в работах, выполняемых внешними ресурсами (по отношению к программному продукту);
Недостаточная производительность итоговой системы;
Разрыв в квалификации специалистов разных областей.
Каждая из стратегий имеет множество реализаций на конкретных моделях. Все эти стратегии и модели будут эффективны только при применении к конкретному типу проектов, именно поэтому существуют классификаторы проектов по разработке, позволяющие обоснованно выбирать модель жизненного цикла разработки программного продукта для каждого конкретного случая.