Проектирование программного обеспечения
Если бы мы запланировали статью, которая не будет никому интересна, то наверное написали про важность проектирования зданий перед их постройкой. Но, к счастью, любой человек понимает, почему не стоит строить дома на глазок, добавляя фичи прямо в процессе строительства. При разработке же программного обеспечения по-прежнему полезно напоминать о том, что начинать её следует с проектирования — т.е. с полного планирования того, что непосредственно нам придётся разрабтывать, в какие сроки, с какими исходными данными и ожидаемым результатом.
За 13 лет опыта компании «Эдисон» в аутсорс-разработке для средних и крупных компаний из России, США, Европы и Австралии мы выработали собственную схему проектирования ПО, о которой в этом посте и расскажем.
Зачем нужно проектирование программного обеспечения
Определив требования к программному обеспечению, разработчик получает согласованный четкий план действий, график оплат и сроков, сокращает время разработки и повышает её качество, а также позволяет предусмотреть любые другие нюансы разработки, например, юридические (в частности по передаче авторских прав на программное обеспечение).
Проектируя ПО заранее, разработчик получает возможность:
- оценить стоимость и время разработки программного продукта,
- исключить потери времени и денег на ненужные действия, вынужденные доработки, длительное согласование,
- избежать разногласий и неудовлетворённости клиента и исполнителя.
Подготовительный этап
В зависимости от особенностей проекта порядок разработки программного обеспечения может отличаться, но в общем виде он такой:
При подготовке к проектированию решаются организационные вопросы:
- что клиент может предоставить (ТЗ, макеты, дизайн), насколько достаточны исходники и какие этапы закрывают — таким образом определяется состав работ,
- бюджет и сроки: на основе имеющихся материалов утверждается примерная стоимость, срок всего проекта, а также срок и точная стоимость ближайшего этапа.
Теперь можно подписывать контракт, получать предоплату и все необходимые для работы материалы.
Этапы и результаты проектирования
- Описание: совместная работа заказчика (говорит о пользе продукта, требованиях к работоспособности и внешнему виду) и EDISON (предлагает технические и алгоритмические решения).
- Архитектура: утверждается язык программирования, база данных, серверы и фреймворки.
- Техническое задание: составляется архитектором на основании описания и ответов заказчика на вопросы, согласовывается с менеджером проекта, затем передается клиенту, производятся правки.
- Макеты (добавляются к техзаданию): интерфейсов, принципиальные схемы устройства, диаграммы структуры базы данных, схемы взаимодействия компонентов.
- Контроль: архитектор устраняет замечания менеджера проектов.
- Утверждение: заказчик проверяет и меняет ТЗ самостоятельно или сообщает список правок проект-менеджеру, замечания устраняются, ТЗ утверждается и прилагается к контракту.
Как результат проектирования, мы получаем техническое задание с понятной и однозначной для заказчика и исполнителя (руководителя проекта, программистов, тестировщиков, дизайнеров и других участников процесса разработки) иллюстрацией ответов на вопросы:
- Что делаем (описание продукта, функционала, пользователей)?
- Как делаем (архитектура)?
- Как проверить, что цель достигнута (тестирование, критерии оценки)?
Теоретически, если на подготовительном этапе клиент может сразу предоставить результат проектирования в соответствии с этими требованиями, этап проектирования можно опустить и сразу перейти к бесплатной оценке проекта. Однако пока таких случаев в нашей практике не было.
Требования к техническому заданию на разработку программного обеспечения
Минимально достаточное ТЗ должно:
- полностью, чётко (инструкционно, без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
- исключать противоречивые сведения,
- быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.
Техническое задание должно содержать:
- общие данные о проекте (название продукта, кем и для чего будет использоваться);
- общие требования к ПО (к структуре, функциям, в частности приложить схему архитектуры и описать связь подсистем, виды интерфейсов всех составляющих для каждой из ролей пользователей — готовый дизайн или его концепцию);
- подробный план работ (перечень этапов, сроки по ним);
- порядок тестирования и приемки (виды и состав испытаний продукта в целом и отдельных частей);
- перечень действий для запуска продукта;
- требования к документированию процесса и результата разработки.
В составе ТЗ необходимо уделить внимание описанию:
- детaлей:
- пользователи программного продукта: роли, права и функции,
- описание алгоритмов обработки данных,
- перечень открытых и закрытых протоколов,
- требования к безопасности данных на всем жизненном цикле,
- список компонентов (платных, свободных), которые будут использоваться в разработке,
- примеров:
- при наличии аналогов, интегрируемых систем указываются ссылки на них,
- в описании работы системы приводится описание типичных сценариев взаимодействия с ней пользователей,
- примеры входящих данных и формат данных взаимодействия подсистем (таблицы, базы, страницы и др.),
- примеры исходящих данных (виды отчетов и экспортируемых файлов),
- производительности и надежности:
- указание уровней нагрузки системы (день, месяц, максимальный),
- требования к производительности, сохранности,
- обоснование выбора оборудования запуска программного обеспечения,
- указание хостинга серверной части.
Примеры техзаданий на разработку ПО
Естественно, чем сложнее проект, тем дольше и дороже подготовка к нему. Проектирование небольших проектов занимает от недели до месяца. Чтобы процесс шёл быстрее и стоил меньше, мы предоставляем заказчикам по запросу инструкцию по составлению ТЗ и примеры готовых технических заданий. Приведем примеры и тут.
ТЗ на программное обеспечение Protector
Объект ТЗ: разработка и интеграция с существующей системой модульного ПО для мониторинга удаленных устройств охраны
Заказчик: ООО «ВТИМБ»
Техническое задание на платформу безопасности Protector from EDISON Software Development Centre
Вариант в pdf
Сценарии использования образовательной системы
Объект ТЗ: создание образовательной системы
Cценарии использования from EDISON Software Development Centre
Вариант в pdf
ТЗ на разработку ПО SMPP-шлюз
Объект ТЗ: разработка программного обеспечения SMPP-шлюза
Заказчик: IMT
ТЗ на SMPP шлюз from EDISON Software Development Centre
Вариант в pdf
В ходе разработки ТЗ, как в последнем кейсе, мы обязательно визуализируем основные моменты в виде схем, диаграмм, моделируем бизнес-процессы, создаем макеты интерфейсов, по желанию клиента выполняем ТЗ на русском или английском языках.
Проектирование — для больших парней
За годы работы нами написаны сотни техзаданий на разработку программного обеспечения различной степени сложности, и мы понимаем, что роль разработки подробного ТЗ сложно переоценить. Бывало, работали с ТЗ на более чем 1000 страниц, и для крупных проектов — это оправдано и необходимо. Тем не менее не стоит забывать о принципе целесообразности — нет смысла писать ТЗ на 20 страниц для двухдневной разработки продукта.
Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях или на нашей странице в Фейсбуке.
