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

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

7117c8dd2d7b4dfd99cb5227bd660073.jpg

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

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


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

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

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


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


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

8bb796b1d7a04181acd86e02be16f8f1.jpg

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

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


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

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


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


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

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


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

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


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

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


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

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


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

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


972c08a61103455ea8d2f9d6892f4e12.jpg

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


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

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

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

0d29f5c4eb324393af460af6a50bc5d1.jpg

© Habrahabr.ru