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

В последние годы появилось такое понятие как аутсорсинг разработки ПО, что преподносится как новое и выгодное явление. На самом деле аутсорсинг разработки ПО – понятие довольно глупое, и есть ни что иное, как наем подрядчика на выполнение работ по разработке ПО.

Если вам не приходилось сталкиваться с заказной разработкой программного обеспечения, вы можете не подозревать, какие подводные камни могут помешать реализации ваших замыслов в ходе проекта. Мы считаем полезным разъяснить, как происходит взаимодействие между заказчиком и исполнителем, с чего начать, из каких этапов состоит типовой проект разработки, чего требовать от исполнителя.

Сценарий взаимодействия заказчика и исполнителя

Размещение заказа

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

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

Оценка заказа и согласование объема работ и стоимости

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

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

Результатом оценки является коммерческое предложение на разработку системы или продукта. Коммерческое предложение включает:

• Объем проекта – краткое описание реализуемой функциональности
• Риски и предложения по их профилактике
• Сделанные допущения
• Длительность работ
• Стоимость работ
• Порядок оплаты (как правило, предлагается использовать поэтапную оплату).
• Трудозатраты в часах по ролям специалистов
• Погрешность оценки (в процентах)
• Календарный план

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

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

Старт проекта

Для начала работ по проекту стороны подписывают контракт.

Разработка и согласование ТЗ

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

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

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

Если в процессе согласования ТЗ появляются новые требования или изменяются существующие, и становится понятным, что это влияет на сроки или стоимость работ, то ставится вопрос о пересогласовании сроков и/или стоимости проекта.

Если запланированный срок согласования ТЗ сорван, принимается решение об изменении сроков, объемов или стоимости работ.

Для уменьшения времени согласования ТЗ может согласовываться поэтапно (например, команда проекта может согласовывать только один какой-либо уже подготовленный раздел ТЗ), если это возможно.

В план проекта могут быть заложена активность по очному обсуждению ТЗ с заказчиком. Этот подход более эффективен, чем e-mail переписка и серьезно экономит время согласования.

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

Разработка ПО

Специалисты Instream подготавливают среду разработки и выполняют программирование продукта на основании согласованного технического задания.

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

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

Модульное тестирование

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

Демонстрационные версии

В процессе разработки ПО желательно, чтобы исполнитель предоставлял заказчику для ознакомление готовые модули. Это позволяет заказчику на ранних этапах проекта «пощупать» ПО, если необходимо, изменить внешний вид или функциональность в небольших объемах. Такой подход требует немного больше усилий, но может снять риск получения в итоге неудобного продукта. Приемочное тестирование в таких случаях проходит также гораздо быстрее.

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

После завершения разработки инженеры качества исполнителя проверяют программное обеспечение на соответствие требованиям.

Для тестирования систем инженеры качества должны использовать только специально выделенную аппаратную среду - среду тестирования. Перед установкой релиза тестовая среда приводится в состояние, максимально похожее на продуктивную среду заказчика. Инженер качества устанавливает релиз на тестовую среду, имитируя действия специалистов Заказчика, тем самым проверяя сам процесс установки.

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

В объем тестирования входят следующие работы:

• Комплексное тестирование. Проверяется весь новый разработанный функционал на соответствие требованиям, проверяется работоспособность самого критичного функционала.
• Регрессионное тестирование. Проверяется отсутствие ранее найденных ошибок, самой критичной функциональности и в некоторых случаях полная проверка всех функций системы.
• Интеграционное тестирование. Программное обеспечение проверяется на возможность правильной работы с внешними системами. Если Instream не имеет тестовые среды внешних систем, тестирование проходит с использованием тестовых сред Заказчика.
• Нагрузочное тестирование. Программное обеспечение проверяется на соответствие требованиям по нагрузке, в некоторых случаях проводится стресс-тестирование, выявляющее верхний «потолок» возможностей системы.

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

Документирование

В зависимости от масштабов системы исполнитель и заказчик согласовывают заранее объем сопроводительной документации к системе. Как правило, в состав эксплуатационной документации входит:

• Спецификация требований
• Описание системы
• Базу знаний по системе, например в виде wiki-портала (для крупных и сложных систем)
• Руководства пользователя
• Руководство администратора
• Сценарии тестирования

Передача и приемка продукта

Исполнитель передает Заказчику разработанное программное обеспечение на твердом носителе (CD диск) или по электронной почте.

Релиз системы устанавливается Заказчиком в тестовую среду самостоятельно или при помощи специалистов исполнителя.

Заказчик проводит приемочное тестирование системы на основе подготовленных ранее тестовых сценариев и принимает решение о соответствии требованиям. Специалисты Instream оказывают помощь в тестировании.

Запуск системы

В согласованное время с Исполнителем, Заказчик устанавливает программное обеспечение в продуктивную среду самостоятельно или с привлечением специалистов исполнителя. Сразу после установки проводится sanity-тестирование – набор кратких тестов, проверяющих работоспособность системы.

Патронажный период

В течение 2 недель после установки (точный срок оговаривается в плане каждого отдельного проекта). Исполнитель производит мониторинг системы и анализ ее работы на основании данных, полученных от администраторов Заказчика или самостоятельно, при наличии доступа «на чтение» к продуктивной среде.

Подведение итогов проекта

После не менее двух недель работы новой/обновленной системы в продуктивной среде команда подводит итоги проекта - Post Implementation Review (PIR).

Цель PIR - подведение итогов, анализ возникших проблем и выработка их профилактики на будущее.

На PIR обязательно приглашаются ключевые сотрудники Заказчика, участвующие в проекте.

Контроль рисков проекта

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

Менеджер проекта со стороны Исполнителя в еженедельно информирует Заказчика о рисках проекта и предлагает пути их снижения.

При планировании проекта разработки Исполнитель закладывает в план и бюджет проекта резервы:

• Резерв времени специалистов Исполнителя на непредвиденные риски.
• Резерв календарного времени

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

После окончания проекта Исполнитель подготавливает отчет об их использовании заложенных резервов на риски.

Контроль изменения объема проекта

Изменение объема работ и угроза сдвига сроков проекта может происходить в нескольких случаях:

• При срабатывании рисков по независящим от команды проекта причинам
• При добавлении новых или изменении существующих требований Заказчиком
• При увеличении трудозатрат по не зависящим от Исполнителя причинам

В любом из этих случаев команда проекта должна определить, как действовать в данной ситуации:

• Использование ранее заложенного резерва на риски
• Проведение дескоупинга (уменьшение объема реализуемой функциональности)
• Увеличение стоимости и/или сроков сдачи проекта

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

Оплата работ

Instream предлагает поэтапную оплату производимых работ:

№	Этап	% от общей суммы проекта
Этап 1	Анализ требований и разработка ТЗ	30 %
Этап 2	Разработка и тестирование системы	50 %
Этап 3	Установка в продуктив	20 %

Словарь терминов

Термин/сокращение	Описание
БТ	Бизнес требования. Высокоуровневые бизнес требования к продукту
БФТ, ФТ	Бизнес-функциональные требования. Функциональные требования. Более проработанный документ, нежели БТ. Требования к функциональности, сценарии использования продукта. Как правило, включают и нефункциональные требования (требования к нагрузке, доступности, безопасности).
Инспекция кода, Сode review	Систематическая проверка исходного кода программы с целью обнаружения и исправления ошибок, которые остались незамеченными в начальной фазе разработки. В результате улучшается качество программного продукта и навыки разработчика.
Команда проекта	Специалисты Заказчика и Исполнителя, работающие над одним проектом
Релиз	Новая версия системы, как правило, разрабатываемая в рамках одного проекта
ТЗ	Техническое Задание
Post Implementation Review, PIR	Подведение итогов проекта