ToT /

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

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

Этап 1. Постановочный
Этап 2. Уточняющий
Этап 3. Стабилизирующий
Этап 4. Внедрение

Назначение методики и границы ееприменимости

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

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

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

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

Этап 1. Постановочный

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 2. Уточняющий

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

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

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

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

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

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

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

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

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

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

Этап 3. Стабилизирующий

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

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

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

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

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

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

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

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

Этап 4. Внедрение

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

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

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

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

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

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

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

Владимир Иванов