Методика мягкого внедрения

Мягкое внедрение - внедрение в условиях взаимного доверия Заказчика и Исполнителя, при котором проблемы и ошибки Заказчика берет на себя большей частью Исполнитель.

Данная технология разработки и внедрения имеет следующие проверенные границы применимости:

• Рассчитано на взаимное доверие Заказчика и Исполнителя в пределах не менее одного этапа работ, имеется в виду, что Заказчик или Исполнитель могут блокировать проект, но не более чем в рамках этапа.
• Оптимально для проектов сроком до 3х месяцев и трудоемкостью до 1 чел/года. Для изготовления более сложной системы, необходимо, чтобы ее отдельные модули внедрялись не дольше 3х месяцев, в противном случае методика не применима.
• Учет модели ценообразования. Данная методика разработана с учетом рискованного для Исполнителя и выгодного для Заказчика "ценообразования за весь проект". Это не исключает возможность применения более простой расчетной схемы повременного типа.
• Заказчик готов заплатить больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени Исполнителя позволяет Заказчику снять с себя значительную часть ответственности за свои проблемы и ошибки.
• Ключевые пользователи Заказчика не является специалистами в информационных системах. Заказчик предпочитает работать не с формальной спецификацией, а с документацией пользователя и моделями системы.
• Методика применима для небольших заказных и серийных систем.

Замечания для использующих Rational Unified Process:

- в отличие от RUP, даются рекомендации как оформить спецификацию и документацию единым документом, это важно для малых разработок
- данная методика в основном повторяет этапы RUP, но является ее упрощением для малой группы или разработки (до 1 чел. года, до 5 разработчиков). RUP будет более эффективен для команды от 7-12 человек;
- помимо RUP использовались элементы методики спиральной разработки BSM (Boehm Spiral Methodology);
- в отличие от RUP, требуется (а не просто рекомендуется) прототипирование на первом этапе (Inception Phase), это связано с тем, что малые группы корпоративных разработчиков обычно не имеют необходимой статистики для хорошего планирования проектов;
- уточнена статистика трудоемкости этапов для малых разработок.

Данный этап проводится по договору о консалтинге, т.е. оплата этапа  повременная. В виду неопределенности задачи спланировать заранее ее стоимость невозможно. Себестоимость этапа примерно равна 10% себестоимости всех работ.

Основной продукт этапа - документ "Постановка Задачи" (Product Vision).

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

На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование".

Данный документ должен содержать статистическую оценку трудоемкости (себестоимости) работ. С другой стороны, должен быть сделан анализ экономического эффекта от внедрения.

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

Для оценки рисков требуется разработать как минимум 2 простейших прототипа (они могут быть выполнены как один).

"Интерфейсный прототип" - это прототип, имитирующий 1-2 важнейших диалоговых окна программы. Необходимо проанализировать реакцию пользователей с целью  изучения рисков связанных с модификацией их требований.

"Архитектурный прототип" - это прототип, проверяющий самые критические места будущей архитектуры. Данный прототип служит для оценки технологических рисков.

Данные прототипы  не должны далее использоваться при разработке системы, требуется начать разработку заново. Это связано с тем, что прототипы служат для нахождения оптимальных решений, но таковыми не являются.

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

В результате мы имеем нечетко сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может играть роль ТЗ, но с указанием в договоре на то, что более приоритетный документ "Документация пользователя" (см. ниже) и система будет приниматься по "Приемочным испытаниям" (см. также ниже)

Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".

На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с  ключевыми пользователями.  Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.

Одновременно в виде пошаговых сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как  неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.

Возможны два варианта взаимодействия "прототип-документация":

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

2) При отсутствии представления о лучшем варианте реализации по краткому заданию на основе "Постановки Задачи" сначала создается прототип . После одобрения Заказчиком документируется желаемое поведение системы.

Пользователь оценивает прототип и документацию одновременно. Если, осмотрев прототип, пользователь согласен с описанием поведения конечной системы в "Документации Пользователя",  осуществляется переход к созданию прототипа следующего функционального модуля.

Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:

1. Описание программы делается на языке, понятном пользователю.
2. Уже на первых этапах разработки программы пользователь включается в анализ своей рабочей документации.
3. Нет необходимости править ТЗ и Документацию одновременно.
4. Как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.

Условие завершения этапа: этап завершается письменным соглашением Заказчика и Исполнителя о том, что конечная система будет принята, если соответствует последней согласованной версии "Документации Пользователя"; архитектура и требования стабильны, не предвидится изменений более чем на 20% в ходе следующего этапа.

Важное замечание о юридической стороне. Вполне возможно, что не удается достигнуть согласия ключевых пользователей с прототипом или описанием в Документации. В данном случае Заказчик должен принять волевое решение на уровне топ-менеджера и определиться с требованиями. Если этого не происходит, или если требования выходят за рамки "Постановки задачи" с учетом надбавок на риск, рекомендуется пересмотреть трудоемкость/цену проекта или прекратить его. Указанная возможность прекращения проекта должна быть предусмотрена в договоре.

На данном этапе удаляются дефекты реализации и выпускается "Релиз Системы". Себестоимость этапа - примерно 50% разработки.

В начале этапа составляется и согласовывается документ "Приемочные испытания". Данный документ содержит описание тестов, успешное выполнение которых является необходимым и достаточным условием приемки. Иными словами, документ описывает минимально гарантированное качество реализации.

Данный документ составляется следующим образом:

1. Производится описание тестовых данных в виде набора конкретных значений.
2. Составляется описание тестовых процедур, при этом манипуляции пользователя не описываются, тестовые сценарии берутся из "Документации пользователя". Обычно тестовая процедура описывает последовательность проверки разделов "Документации" (сквозной пример).

На данном этапе "Документация Пользователя" может быть изменена по инициативе тестера и по согласию Заказчика.

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

С этого момента система проходит регулярное тестирование по "Приемочным испытаниям". Примерно через 3-5 версий приемочные тесты должны выполниться успешно, и система объявляется готовой к сдаче в опытную эксплуатацию.

Условие завершения этапа: Успешное прохождение приемочных тестов у Заказчика, передача Системы и Документации в бета-тестирование.

На данном этапе Заказчик выявляет дефекты программы в опытной эксплуатации (бета-тестировании), Исполнитель их устраняет. Является ли это ошибкой или доработкой решается согласно "Документации пользователя". Себестоимость этапа примерно составляет 10% от разработки.

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

1. Общее описание системы. Формируется на основе общих сценариев функционирования системы.
2. Быстрое введение. Тут описывается как запустить программу и сразу начать работу.
3. Основные операции. В данном разделе описывается как использовать основную функциональность не вдаваясь в детали. Стиль описательный и сценарный.
4. Справочник пользователя ("Как сделать?"). Формируется на основе пошаговых сценариев выполнения конкретных задач.
5. Дополнительные главы. В данный раздел переносятся части "Документации пользователя" носящие системный характер и обычно не требующиеся пользователям.

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

Исполнитель устанавливает систему на рабочем оборудовании Заказчика и проводит обучение пользователей. Пользователи должны получить свои должностные инструкции и подтвердить, что они могут по ним использовать систему.

К оговоренному заранее сроку окончания опытной эксплуатации Заказчик должен представить список выявленных проблем. Если имеющиеся проблемы не означают, что программа не соответствует "Документации", то принимается решение об окончательной приемке Системы.

Условие завершения этапа: Заказчик может эксплуатировать Систему согласно "Документации".