За 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 страниц для двухдневной разработки продукта.
Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях, в нашей группе в Фейсбуке или во Вконтакте.
Комментарии (20)
musuk
30.09.2015 18:39+24Минимально достаточное ТЗ должно: полностью, чётко… описывать будущий программный продукт
Интересно, где тот шкаф через который можно попасть в то измерение, в котором существуют такие ТЗ. Там наверное, ещё единороги водятся и есть работа для ведьмака…
excoder
01.10.2015 11:50+2Теоретически бывают такие bread-and-butter / getting-things-done области разработки, где программа просто-таки ложится в переданное описание функционала. В области mission-critical / line-of-business приложений таких ситуаций значительно меньше. В современном мире, мне кажется, неизвестных столько, что проще начать разработку по минимальному черновику и корректировать ход в процессе, нежели потратить сотни страниц, которые потом всё равно придётся корректировать, т.к. они были построены из слегка не тех предположений.
AndreyShelehin
30.09.2015 19:31+23Большое спасибо за статью! Отличный и подробный пример того, как не надо делать, если вы планируете получить на выходе конкурентноспособный и актуальный продукт.
u_story
30.09.2015 23:24-1А можете пояснить почему «не надо» делать?
И как делаете вы в случае работы по fixed price и требованиям ДИТ заказчика сдавать документы по госту?AndreyShelehin
01.10.2015 00:31+12Так делать не надо, поскольку, ТЗ на систему сложнее калькулятора:
1) НЕ позволяет объективно оценить стоимость и время разработки программного продукта
2) НЕ исключает потери времени и денег на ненужные действия, вынужденные доработки, длительное согласование
3) НЕ позволяет избежать разногласий и неудоволетворенности клиента и исполнителя
Однако прекрасно позволяет:
1) Потратить неведомую кучу времени на проработку документа, который превратится в устаревшую макулатуру, как только вы нажмете на кнопку «Печать»
2) Связать заказчику руки, который, на момент написания ТЗ, имеет только набор гипотез и догадок, которые вы, любезно, поможете ему упаковать в артефакт, отражающий ваши совместные галлюцинации относительно продукта, пользователей и сценариев использования и, тем более, касательно нагрузки и производительности
3) Получить иллюзию понимания сроков и стоимости проекта
4) Сделать, в итоге, совсем не то, что реально было нужно заказчику, при этом узнать об этом в самом конце.
5) Посчитать заказчика мудаком и дать ему все основания считать мудаком вас.
5) Понять, наконец, что современная разработка ПО не имеет ничего общего с постройкой зданий, и что единственной постоянным элементом требований будет только одно — их непрерывное изменение в процессе реализации.u_story
01.10.2015 08:03-3Простите, но причём тут ТЗ?
По вашим НЕ:
1. ТЗ не является документов оценивающим стоимость и время проекта.
2. не исключает, а что исключает? Например, сменился стекхолдер, который отвечает на письма команды раз в месяц, а проект\этап нужно сдавать?
3. Это всегда может быть. Вообще не представляю, как этого можно избежать в условиях fixed price.
Как вы эти вопросы решаете?
По остальным пунктам:
1. Если ТЗ пишут люди далёкие от сути дел, или заказчик сам не знает, что хочет, то ок. но тут ничего поможет.
2. Для этого делается предпроектное исследование. Чтобы при проектировании решения учесть максим факторов.
3. Ок, а как получить не иллюзию?
4. Ну это уже кто как проектам управляет.
5. — 5. непрерывное изменение путь к большому количеству говнокода, потому что мы бежим на поводу у заказчика и допиливаем фичи, которые изначально не была заложены, в итоге любой чих выливается в недели тестирования.
Также это ведёт к отсутствию понимания заказчиком сроков выхода его продукта, не пониманием бюджета.
Давайте, чтобы не спорить, расскажите, сколько проектов вы сделали выиграв тендер на конкурентном рынке с таким подходом?
По-моему опыту я видел десятки проектов стоимостью от сотен тысяч до десятков миллионов, которые разваливались и клались в коробку, как раз по причине это гибкости и готовности команды делать изменения идя на поводу заказчика.
js605451
30.09.2015 22:19+5По-моему вы что-то недоговариваете.
www.edsd.ru/ru/proekty/razrabotka_po
Заказчик: Крупнейшая Российская библиотека.
Период: С сентября 2007.
8 лет продолжаете работать по одной и той же спеке? Крупнейшая российская библиотека решила отправить книги на Марс?
ArtemE
30.09.2015 22:28Занятно, нас так в университете учат проектировать информационные системы. После фразы «свою схему проектирования» хотелось увидеть что-то действительно новое.
Но все равно спасибо за статью и, особенно, за пример ТЗ.
dgstudio
01.10.2015 14:02+6Ребят, вас десять лет назад заморозили в криогене, что-ли? Откуда водопад в разработке ПО в 2015-ом году? Так и напишите: мы делаем большие, неповоротливые продукты, с циклом развития в несколько лет, а потом их выкидываем и делаем заново, потому что таким способом нашим заказчикам более удобно пилить корпоративные бюджеты.
По крайней мере, будет честно.VolCh
01.10.2015 19:33Водопад имеет право на жизнь. К аджайлу должен быть готов прежде всего сам заказчик, а если не готов, то какие варианты?
whitepen
01.10.2015 14:15-1Здесь излагается как написать программу. А вот этого как раз никогда и не требуется. Требуется нечто иное. Надергать разных библиотек, всяких там баз данных и собрать из них то, что нужно. Или напротив, написать движок для игрушек, банков, бухгалтерий. А этот движок кому то понравится? Ну, сперва написать простенький. Или на движке нарисовать свою дизайнерскую реализацию. А в процессе выяснится, что использованные средства никуда не годятся, и их нужно поменять на подходящие. Результат таков: нам удалось на платформе такой-то добиться вот такой крутизны. Если я рисую квадратики на экране, то я никогда не использую эти квадратики, а если я использую эти квадратики, то я их всяко не рисую, и не умею. Если я домо-строитель, то я уж никак не машино-строитель.
byria
01.10.2015 17:32Было бы неплохо увидеть примеры ТЗ от других компаний или команд ( из комментариев), по которым были завершены проекты, с цифрами. Или ссылку на ресурс, где такое собирают для расширения кругозора и анализа желающим. Как по успешным кейсам, так и провальным. С комментариями и пояснениями.
hoack
01.10.2015 18:51Двадцать лет назад меня в институте учили именно так подходить к проектированию программного обеспечения. Однако времена изменились, «водопад» в большинстве случаев не подходит для современных условий. Пора обновить методику, пора…
onthefly
09.10.2015 13:23+1По доброй традиции хаба «Клиентская оптимизация» поинтересуюсь:
— автор, вам известно значение термина, давшего название упомянутому хабу?
— какое отношение этот топик имеет к предметной области, описываемой этим термином?
wheercool
Честно говоря не особо заметил в чем отличие от этого