Форум программистов, компьютерный форум, киберфорум
Наши страницы

О составлении технического задания для заказа программ во фрилансе

Войти
Регистрация
Восстановить пароль
Темы блога относятся к программированию на языке С++

В основном для C++Qt (Qt5.1) и C++ Builder (RAD 2009 и RAD XE3)
Рейтинг: 4.43. Голосов: 7.

О составлении технического задания для заказа программ во фрилансе

Запись от Avazart размещена 14.12.2013 в 02:56
Обновил(-а) Avazart 06.11.2016 в 21:48

Часто заказчики спрашивают как правильно они должны оформить техническое задание.

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

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


И так вот мой вариант того что хотелось бы видеть в тех. задании :

1. Назначение и область применения программы:
  1. Вид задачи: учебная (лабораторная, курсовая, диплом) либо прикладная (парсер сайта, бот, клиентское приложение для работы с БД итд.)
  2. Если программа прикладная, то место применение: для собственных нужд, для продажи, для компании.
    (Как следствие требования: необходимо ли предоставление авторских прав, передачи исходных файлов, документации к программе, сопровождению программы итд)

2. Описание задачи.
Цитата:
Сообщение от Kastaneda Посмотреть сообщение

Задача (подзадача и т.д.) должна иметь настолько полное описание, насколько это необходимо для понимания сути задачи. Формулировка задачи не должна иметь двоякого чтения во избежания разного представления конечного продукта у заказчика и исполнителя.

Любой функционал должен быть описан явно, а не подразумеваться в расплывчатых формулировках.
Как пример не должно быть субъективных формулировок типа: хорошо","качественно","красиво","эстетично" итп

Если вы что-то не указали или указали расплывчато, то скорее всего исполнитель сделает по своему усмотрению и как ему легче, и тут как повезет ведь его понимание того как должна выглядеть программа может сильно отличаться от вашего и когда вы это поймете может быть уже поздно.
Порой некоторые упущенные детали, которые возможно покажутся заказчику пустяковыми приводят к тому что программу фактически придется переписывать чуть ли не с нуля. И не каждый программист согласится проделывать одну и ту же работу дважды без дополнительной оплаты.

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

В большинстве случаев представить программу легче описав весь цикл её работы с момента её запуска до завершения.

Если программа принимает в процессе работы какие-то решения, то стоит описать так же на какие данные она должна опираться, и какой логике следовать при их принятии.

Стоит описать сразу весть функционал программы и при этом сразу обозначить что из функционала является обязательным (критичным), а что является желаемым (и к примеру может быть доработано позже)

Если вы хотите что бы программа имела нестандартный вид или интерфейс, то это тоже сразу стоит указать.

При описании для наглядности можно использовать скриншоты, рисунки, схемы, и даже видео.

Если программа взаимодействует с каким-нибудь сайтом (например, парсер или бот) то следует привести ссылки на конкретные (или возможные) страницы сайта с которым программа должна работать, а также данные, которые должна брать с этих страниц, указать необходимо ли прохождение авторизации на сайте (при необходимости предоставить тестовый логин пароль)

Если программа должна будет работать сайтом (например через FTP, или удаленно с его БД) то желательно сразу предоставить, параметры для подключения (логин, пароль, хост, порт итп.)
3. Технические требование к программе:
  1. Требование к задаче как в общем, так и каждой ее части.
    (например, если задание подразумевает использование комплекса программ, БД, скриптов итп.)
  2. Требования к необходимой функциональности программы (как, в общем, так конкретно, тут же возможно стоит указать связь функциональности с интерфейсом, например, какой пункт меню будет реализовывать/вызывать те или иные действия).
  3. Требования интерфейсу и внешнему виду программы.(тут особо пригодятся примеры, скриншоты, рисунки, схемы).
  4. Системные требования программы (к компьютеру на котором она будет работать).
  5. Другие дополнительные требования (например, к размеру исполняемого файла программы, наличие инсталятора или наоборот портабельность итд).

Пункты 2 и 3 влияют на выбор технических средств для решение поставленной задачи.

4. Средства, которые может/должен использовать программист при разработке:
  1. Язык программирования (Delphi, C++, C#, Java итд)
  2. Платформа (или платформы в случае кроссплатформенного приложения) под которую будет писаться программа.
    (Windows, Linux, Mac OS а также разрядность x32/x64 )
  3. Среда разработки (например, для языка С++: MSVC++/С++Builder/QtCreator).
  4. Стандартные, а также сторонние библиотеки и компоненты, которые может (или которые нельзя) использовать программист (например, в среде MSVC++ можно использовать WinApi/MFC/CLR ну и сторонний Qt).
  5. Необходимость применение конкретных методов (подходов, технологий и способов) решения вашей задачи (применение ООП, паттернов проектирования, алгоритмов итп)


5. Дополнительная информация, которая будет необходима программисту для выполнения задачи.
Для учебных задач это может быть требования к выполнению курсовой работы, методическое указание, готовый пример выполненной работы.
Для прикладной программы информация может быть самой различной, например ссылки на документацию, описание API-сервера.
Темы на форуме:
  1. О ТЗ и фрилансе
Размещено в Фриланс
Просмотров 4786 Комментарии 4
Всего комментариев 4

Комментарии

  1. Старый комментарий
    Аватар для Pingvinoff
    Я с недавнего времени стал работать только по ГОСТ. Все неполноценные заказчики отпадают сразу. А с понимающими людьми очень приятно работать.
    Запись от Pingvinoff размещена 04.08.2015 в 07:30 Pingvinoff вне форума
  2. Старый комментарий
    Аватар для Avazart
    Да думаю там в ГОСТе http://www.rugost.com/index.php?opti...d=19&Itemid=50 слишком много необязательного и возможно непонятного для заказчика.
    Запись от Avazart размещена 07.08.2015 в 13:10 Avazart на форуме
    Обновил(-а) Avazart 07.08.2015 в 13:16
  3. Старый комментарий
    Цитата:
    Сообщение от Pingvinoff Просмотреть комментарий
    Я с недавнего времени стал работать только по ГОСТ. Все неполноценные заказчики отпадают сразу. А с понимающими людьми очень приятно работать.
    Это очень хорошо. Таким образом вы дадите дорогу для более гибких в общении с заказчиком разработчиков.
    Запись от ppbwpg размещена 09.08.2015 в 06:58 ppbwpg вне форума
  4. Старый комментарий
    Хорошая тема. И, в целом, хороший подбор факторов для описания ТЗ. Могу предложить вам составить такой вопросник для составления ТЗ в помощь заказчику, и многие спорные моменты могут быть решены до их возникновения, а само ТЗ будет более ясным и точным. Например, я был бы рад иметь такой вопросник при обсуждении заказа с потенциальным разработчиком.

    Из дополнений к собственно вопроснику я бы добавил - если есть какие то отчеты или выводы данных на экран - приводить их пример (составленный напр. в Excel/Word и т.д.), т.к. представление о том, что должно быть показано, как результат, дает отличное представление разработчику о том, что должно быть для этого сделано. А заказчик часто может хорошо представлять как раз результат, а не детали того, как его достичь.

    Работа "точно по ГОСТу" - смешно и слышать. Для этого мне нужно будет на каждых троих разработчиков нанимать отдельного аналитика только для составления ТЗ, которое, к тому же, может меняться по желанию конечного клиента.
    Запись от ppbwpg размещена 09.08.2015 в 07:12 ppbwpg вне форума
 
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru