Теория |
Практика |
Этапы жизненного цикла программного обеспечения |
|
Стратегия |
|
Основная задача данного этапа - оценка реального объема проекта, его целей и задач. Заказчик должен получить документ, позволяющий решить, стоит ли продолжать данный проект, какие требования могут быть удовлетворены (и при каких условиях), а какие не должны присутствовать в задании вообще (неограниченный по функциям проект не реализуем в принципе!). Должны быть также зафиксированы границы по времени и по финансированию. |
Объем проекта не оценивался. Функциональные требования не формулировались. Ограничения во времени (и стоимости) отсутствуют. Решение принималось на уровне «ребята хорошие, они нам все сделают». Оплата выполняемых частных заданий не связана с фактическим выполнением этих заданий. |
Анализ |
|
На этом этапе исследуются бизнес-процессы (функции) и информация, необходимая для их выполнения (сущности, их атрибуты и связи). Важно здесь систематически отделять общезначимые (стандартные) функции и сущности от специфических. |
Системный анализ не проводился. Значительная часть разработки обращена на уникальные функции и несуществующие «сущности». В то же время, ряд стандартных функций реализуется некорректно. |
Проектирование |
|
Из множества задач этапа проектирования выделим три ключевые:
На выходе этапа проектирования должна быть получена модель функций и модель данных. На самом деле, этап проектирования - это этап синтеза системы. |
|
Реализация |
|
Основная задача разработчиков состоит в том, чтобы уяснить спецификацию: проектировщик написал, что надо сделать, разработчик определяет, как это сделать. |
Фактически, проект не создавался. Приложенный к Стандарту себестоимости план счетов предопределил многие из последующих трудностей именно потому, что на начальном периоде разработки он предписывал как делать, а не что. |
Тестирование |
|
По меньшей мере (согласно ГОСТу), в Программе и методике испытаний создаваемой системы должен быть описан приемосдаточный (комплексный) тест. |
Не всегда проводится даже автономное тестирование разрабатываемых модулей, не говоря уже о тестах связей компонентов. |
Внедрение |
|
Этап внедрения - это главный тест: тест одобрения пользователем (customer acceptance tests). Если этого не было сделано на этапе тестирования, то на этапе внедрения это непременно произойдет: тестировщиком будет заказчик, что не всегда приемлемо для разработчика. |
Так и происходило, но с одним нюансом: заказчик, не будучи пользователем, просто проигнорировал замеченные (и незамеченные) недостатки, чем существенно облегчил жизнь разработчикам в ущерб проекту в целом. |
Эксплуатация и техническая поддержка |
|
Вообще говоря, при согласовании технической поддержки заказчик должен стремиться к обеспечению функциональной работоспособности системы в течение разумного промежутка времени с разумным интервалом отклика на изменение условий функционирования системы. В данной конкретной интерпретации - система должна работать не менее года с обеспечением выполнения изменившихся нормативных требований не позже начала следующего месяца. |
Регламент технической поддержки - единственный документ в проекте, который подробно разрабатывался. Однако сроки отработки функциональных требований к системе, определяемых нормативной базой, в этом документе не фигурируют. Мало этого, к системе вообще не предъявлялось требования соответствия реализуемых функций нормативной базе. |
Резюме |
|
Проект не может стать успешным без выполнения элементарных правил разработки. |
Он и не стал |