Завершение проекта

Завершение проекта в меньшей части относится к самому процессу разработки ПО. Этот этап включает в себя:

• Формальное завершение работ по проекту

• Передача заказчику продуктов проекта

• Заключительная оценка затрат по проекту

• Заключительный отчет по проекту и проектная документация;

• Список открытых вопросов и заключительных работ;

• Анализ опыта выполнения данного проекта.

Существует риск, что заказчик может отказаться от проекта по какой-либо причине. В таких случаях уже выполненный проект можно продать другому заказчику. Но в процессе разработки проекта, в его стоимость включают риски потери проекта по вине заказчика. При правильном составлении плана проекта и последующего согласования с заказчиком ситуаций, в которых заказчика не удовлетворит готовый проект чаще всего не возникает.

Последняя заключительная стадия разработки проекта – ключевая. Т.к. именно на заключительной стадии идет внедрение проекта и сопровождение его функционирования. Здесь же происходит и обучение новому проекту персонала, который будет на нем работать. Если опустить заключительный этап, можно получить абсолютно никому ненужную систему, или проект, который некому будет обслуживать, следовательно потерявший свою ценность.

Стандарты жизненного цикла

Стандарт жизненного цикла является достаточно условным понятием при разработке ПО, так как каждый проект является уникальным и требует своих подходов к реализации. Но существуют международные стандарты описывающие технологические процессы жизненного цикла ПО. Они предложены такими организациями, как

• IEEE — Institute of Electrical and Electronic Engineers, Институтинженеровпоэлектротехникеиэлектронике;

• ISO — International Standards Organization, Международная организация по стандартизации;

• IEC — International Electrotechnical Commission, Международная комиссия по электротехнике, а также некоторыми национальными и региональными институтами и организациями

• ANSI — American National Standards Institute, Американский национальный институт стандартов;

• ECMA — European Computer Manufactures Association, Европейская ассоциация производителей компьютерного оборудования;

Выбор методологии

Процесс разработки ПО — структура, согласно которой построена разработка ПО.

Существует несколько моделей такого процесса (методологий разработки ПО), каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса. Методологию выбирает менеджер проекта. Изменять методологию не рекомендуется, так как это приведёт к глобальным изменениям в процессе разработки, включая смену плана проекта и состава разработчиков.

При выборе методологии учитываются следующие факторы:

• масштаб

• критичность

• распределение участников

• новизна

• требования заказчика

• ожидаемая долговечность

Методологии можно разделить на 2 группы: жесткие и гибкие.

Жесткие и гибкие методологии Модель водопада

Модель водопада (waterfall model или последовательная разработка) – наверное, самый известный, исторически появившийся одним из первых процесс разработки. Он был описан в статье Ройса (W.W.Royce) в 1970 году (на самом деле, Ройс критиковал этот процесс, предлагая в качестве альтернативы итеративную разработку). Основная идея заключается в том, что процесс разработки делится на четко определенные фазы, выполняемые строго последовательно. Название «водопад» появилось из-за внешнего вида диаграммы, изображающей процесс.

Отдельные задачи, из которых состоит любой проект (не обязательно выполняемый по модели водопада), можно разделить между несколькими процессными областями.

Классическая водопадная модель включает следующие области:

• Разработка требований: сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.

• Анализ и дизайн: разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т.п.

• Реализация: создание продукта по спецификациям, разработанным на предыдущем этапе.

• Тестирование: включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации.

• Развертывание: обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.

В модели водопада каждая из процессных областей представляет собой отдельную фазу проекта. Фазы выполняются строго последовательно.