Проектирование программного обеспечения

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



За 13 лет опыта компании «Эдисон» в аутсорс-разработке для средних и крупных компаний из России, США, Европы и Австралии мы выработали собственную схему проектирования ПО, о которой в этом посте и расскажем.

Зачем нужно проектирование программного обеспечения

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

Проектируя ПО заранее, разработчик получает возможность:

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

Подготовительный этап

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



При подготовке к проектированию решаются организационные вопросы:

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

Теперь можно подписывать контракт, получать предоплату и все необходимые для работы материалы.

Этапы и результаты проектирования

1. Описание: совместная работа заказчика (говорит о пользе продукта, требованиях к работоспособности и внешнему виду) и EDISON (предлагает технические и алгоритмические решения).
2. Архитектура: утверждается язык программирования, база данных, серверы и фреймворки.
3. Техническое задание: составляется архитектором на основании описания и ответов заказчика на вопросы, согласовывается с менеджером проекта, затем передается клиенту, производятся правки.
4. Макеты (добавляются к техзаданию): интерфейсов, принципиальные схемы устройства, диаграммы структуры базы данных, схемы взаимодействия компонентов.
5. Контроль: архитектор устраняет замечания менеджера проектов.
6. Утверждение: заказчик проверяет и меняет ТЗ самостоятельно или сообщает список правок проект-менеджеру, замечания устраняются, ТЗ утверждается и прилагается к контракту.

Как результат проектирования, мы получаем техническое задание с понятной и однозначной для заказчика и исполнителя (руководителя проекта, программистов, тестировщиков, дизайнеров и других участников процесса разработки) иллюстрацией ответов на вопросы:

1. Что делаем (описание продукта, функционала, пользователей)?
2. Как делаем (архитектура)?
3. Как проверить, что цель достигнута (тестирование, критерии оценки)?

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

Требования к техническому заданию на разработку программного обеспечения

Минимально достаточное ТЗ должно:

• полностью, чётко (инструкционно, без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
• исключать противоречивые сведения,
• быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.

Техническое задание должно содержать:

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

В составе ТЗ необходимо уделить внимание описанию:

1. детaлей:
   
   • пользователи программного продукта: роли, права и функции,
   • описание алгоритмов обработки данных,
   • перечень открытых и закрытых протоколов,
   • требования к безопасности данных на всем жизненном цикле,
   • список компонентов (платных, свободных), которые будут использоваться в разработке,
2. примеров:
   
   • при наличии аналогов, интегрируемых систем указываются ссылки на них,
   • в описании работы системы приводится описание типичных сценариев взаимодействия с ней пользователей,
   • примеры входящих данных и формат данных взаимодействия подсистем (таблицы, базы, страницы и др.),
   • примеры исходящих данных (виды отчетов и экспортируемых файлов),
3. производительности и надежности:
   
   • указание уровней нагрузки системы (день, месяц, максимальный),
   • требования к производительности, сохранности,
   • обоснование выбора оборудования запуска программного обеспечения,
   • указание хостинга серверной части.

Примеры техзаданий на разработку ПО

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

ТЗ на программное обеспечение 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 страниц для двухдневной разработки продукта.

Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях, в нашей группе в Фейсбуке или во Вконтакте.



О компании:
Проектирование программного обеспечения
Разработка программного обеспечения: этапы и принципы
Тестировщик в ответе за всё
Поддержка программного обеспечения
Как йога кодить и жить помогает: личный опыт
Обучаем сотрудников английскому: опыт Edison
Умственный труд и физическая культура