Теория

Практика

Этапы жизненного цикла программного обеспечения

Стратегия

Основная задача данного этапа — оценка реального объема проекта, его целей и задач. Заказчик должен получить документ, позволяющий решить, стоит ли продолжать данный проект, какие требования могут быть удовлетворены (и при каких условиях), а какие не должны присутствовать в задании вообще (неограниченный по функциям проект не реализуем в принципе!). Должны быть также зафиксированы границы по времени и по финансированию.

Объем проекта не оценивался. Функциональные требования не формулировались. Ограничения во времени (и стоимости) отсутствуют. Решение принималось на уровне «ребята хорошие, они нам все сделают». Оплата выполняемых частных заданий не связана с фактическим выполнением этих заданий.

Анализ

На этом этапе исследуются бизнес-процессы (функции) и информация, необходимая для их выполнения (сущности, их атрибуты и связи). Важно здесь систематически отделять общезначимые (стандартные) функции и сущности от специфических.

Системный анализ не проводился. Значительная часть разработки обращена на уникальные функции и несуществующие «сущности». В то же время, ряд стандартных функций реализуется некорректно.

Проектирование

Из множества задач этапа проектирования выделим три ключевые:

•          Проверка полноты результатов анализа
•          Использование продуктов третьих разработчиков и взаимодействие с ними
•          Отображение функций системы на ее модули

На выходе этапа проектирования должна быть получена модель функций и модель данных. На самом деле, этап проектирования — это этап синтеза системы.

•          Анализа не было, поэтому и синтезировать нечего.
•          Искусственно усложнено использование разработок фирмы 1С.
•          Поскольку четкое определение (и понимание) функций системы отсутствует, модули создавались беспорядочно.

Реализация

Основная задача разработчиков состоит в том, чтобы уяснить спецификацию: проектировщик написал, что надо сделать, разработчик определяет, как это сделать.

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

Тестирование

По меньшей мере (согласно ГОСТу), в Программе и методике испытаний создаваемой системы должен быть описан приемосдаточный (комплексный) тест.

Не всегда проводится даже автономное тестирование разрабатываемых модулей, не говоря уже о тестах связей компонентов.

Внедрение

Этап внедрения — это главный тест: тест одобрения пользователем (customer acceptance tests). Если этого не было сделано на этапе тестирования, то на этапе внедрения это непременно произойдет: тестировщиком будет заказчик, что не всегда приемлемо для разработчика.

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

Эксплуатация и техническая поддержка

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

Регламент технической поддержки — единственный документ в проекте, который подробно разрабатывался. Однако сроки отработки функциональных требований к системе, определяемых нормативной базой, в этом документе не фигурируют. Мало этого, к системе вообще не предъявлялось требования соответствия реализуемых функций нормативной базе.

Резюме

Проект не может стать успешным без выполнения элементарных правил разработки.

Он и не стал