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

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



За 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
Умственный труд и физическая культура
Edison
95,00
Изобретаем успех: софт и стартапы
Поделиться публикацией

Комментарии 21

    +2
    Честно говоря не особо заметил в чем отличие от этого
      +24
      Минимально достаточное ТЗ должно: полностью, чётко… описывать будущий программный продукт


      Интересно, где тот шкаф через который можно попасть в то измерение, в котором существуют такие ТЗ. Там наверное, ещё единороги водятся и есть работа для ведьмака…
        +2
        Теоретически бывают такие bread-and-butter / getting-things-done области разработки, где программа просто-таки ложится в переданное описание функционала. В области mission-critical / line-of-business приложений таких ситуаций значительно меньше. В современном мире, мне кажется, неизвестных столько, что проще начать разработку по минимальному черновику и корректировать ход в процессе, нежели потратить сотни страниц, которые потом всё равно придётся корректировать, т.к. они были построены из слегка не тех предположений.
        +2
        Как вы проверяете полноту ТЗ?
          +23
          Большое спасибо за статью! Отличный и подробный пример того, как не надо делать, если вы планируете получить на выходе конкурентноспособный и актуальный продукт.
            –1
            А можете пояснить почему «не надо» делать?
            И как делаете вы в случае работы по fixed price и требованиям ДИТ заказчика сдавать документы по госту?
              +12
              Так делать не надо, поскольку, ТЗ на систему сложнее калькулятора:
              1) НЕ позволяет объективно оценить стоимость и время разработки программного продукта
              2) НЕ исключает потери времени и денег на ненужные действия, вынужденные доработки, длительное согласование
              3) НЕ позволяет избежать разногласий и неудоволетворенности клиента и исполнителя

              Однако прекрасно позволяет:
              1) Потратить неведомую кучу времени на проработку документа, который превратится в устаревшую макулатуру, как только вы нажмете на кнопку «Печать»
              2) Связать заказчику руки, который, на момент написания ТЗ, имеет только набор гипотез и догадок, которые вы, любезно, поможете ему упаковать в артефакт, отражающий ваши совместные галлюцинации относительно продукта, пользователей и сценариев использования и, тем более, касательно нагрузки и производительности
              3) Получить иллюзию понимания сроков и стоимости проекта
              4) Сделать, в итоге, совсем не то, что реально было нужно заказчику, при этом узнать об этом в самом конце.
              5) Посчитать заказчика мудаком и дать ему все основания считать мудаком вас.
              5) Понять, наконец, что современная разработка ПО не имеет ничего общего с постройкой зданий, и что единственной постоянным элементом требований будет только одно — их непрерывное изменение в процессе реализации.
                –3
                Простите, но причём тут ТЗ?
                По вашим НЕ:
                1. ТЗ не является документов оценивающим стоимость и время проекта.
                2. не исключает, а что исключает? Например, сменился стекхолдер, который отвечает на письма команды раз в месяц, а проект\этап нужно сдавать?
                3. Это всегда может быть. Вообще не представляю, как этого можно избежать в условиях fixed price.
                Как вы эти вопросы решаете?

                По остальным пунктам:
                1. Если ТЗ пишут люди далёкие от сути дел, или заказчик сам не знает, что хочет, то ок. но тут ничего поможет.
                2. Для этого делается предпроектное исследование. Чтобы при проектировании решения учесть максим факторов.
                3. Ок, а как получить не иллюзию?
                4. Ну это уже кто как проектам управляет.
                5. — 5. непрерывное изменение путь к большому количеству говнокода, потому что мы бежим на поводу у заказчика и допиливаем фичи, которые изначально не была заложены, в итоге любой чих выливается в недели тестирования.
                Также это ведёт к отсутствию понимания заказчиком сроков выхода его продукта, не пониманием бюджета.

                Давайте, чтобы не спорить, расскажите, сколько проектов вы сделали выиграв тендер на конкурентном рынке с таким подходом?

                По-моему опыту я видел десятки проектов стоимостью от сотен тысяч до десятков миллионов, которые разваливались и клались в коробку, как раз по причине это гибкости и готовности команды делать изменения идя на поводу заказчика.
            +5
            По-моему вы что-то недоговариваете.

            www.edsd.ru/ru/proekty/razrabotka_po
            Заказчик: Крупнейшая Российская библиотека.
            Период: С сентября 2007.

            8 лет продолжаете работать по одной и той же спеке? Крупнейшая российская библиотека решила отправить книги на Марс?
              0
              Занятно, нас так в университете учат проектировать информационные системы. После фразы «свою схему проектирования» хотелось увидеть что-то действительно новое.
              Но все равно спасибо за статью и, особенно, за пример ТЗ.
                0
                CMM использовать не пробовали?
                  +2
                  Бюрократия.
                    0
                    Жалко РГБ в Vivaldi так и не работает :-( Bad Gateway на Нгинксе.
                      +3
                      Прошлый век ;))
                      госкорпорациям понравится ;)
                        +6
                        Ребят, вас десять лет назад заморозили в криогене, что-ли? Откуда водопад в разработке ПО в 2015-ом году? Так и напишите: мы делаем большие, неповоротливые продукты, с циклом развития в несколько лет, а потом их выкидываем и делаем заново, потому что таким способом нашим заказчикам более удобно пилить корпоративные бюджеты.

                        По крайней мере, будет честно.
                          0
                          Водопад имеет право на жизнь. К аджайлу должен быть готов прежде всего сам заказчик, а если не готов, то какие варианты?
                          –1
                          Здесь излагается как написать программу. А вот этого как раз никогда и не требуется. Требуется нечто иное. Надергать разных библиотек, всяких там баз данных и собрать из них то, что нужно. Или напротив, написать движок для игрушек, банков, бухгалтерий. А этот движок кому то понравится? Ну, сперва написать простенький. Или на движке нарисовать свою дизайнерскую реализацию. А в процессе выяснится, что использованные средства никуда не годятся, и их нужно поменять на подходящие. Результат таков: нам удалось на платформе такой-то добиться вот такой крутизны. Если я рисую квадратики на экране, то я никогда не использую эти квадратики, а если я использую эти квадратики, то я их всяко не рисую, и не умею. Если я домо-строитель, то я уж никак не машино-строитель.
                            0
                            Было бы неплохо увидеть примеры ТЗ от других компаний или команд ( из комментариев), по которым были завершены проекты, с цифрами. Или ссылку на ресурс, где такое собирают для расширения кругозора и анализа желающим. Как по успешным кейсам, так и провальным. С комментариями и пояснениями.
                              0
                              Двадцать лет назад меня в институте учили именно так подходить к проектированию программного обеспечения. Однако времена изменились, «водопад» в большинстве случаев не подходит для современных условий. Пора обновить методику, пора…
                                +1
                                По доброй традиции хаба «Клиентская оптимизация» поинтересуюсь:
                                — автор, вам известно значение термина, давшего название упомянутому хабу?
                                — какое отношение этот топик имеет к предметной области, описываемой этим термином?
                                  0

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

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

                                  Самое читаемое