Как писать техническое задание на программу по ГОСТ 19.201-78?
Создан 15.02.2010 15:50:53
Примечание от 11.06.2014 г. - Уважаемые дамы и господа! Наверное, в каждом втором-третьем из ваших технических заданий на программы, тем или иным образом оказавшихся в руках автора, содержатся аутентичные тексты из настоящей статьи. Это здорово и чертовски приятно, но следует учитывать тот факт, что прошло почти десятилетие с момента первой статьи, а за это время многое изменилось, особенно в части. Из песни, конечно, слов не выкинешь, но настройтесь на креатив и выдумывайте какие-нибудь более современные ее аранжировки. И не забывайте о том, что это , а не «» документ.
Техническое задание в соответствии с на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения листа. Номера листов (страниц) проставляются в верхней части листа над [из п. 1.1 ГОСТ 19.201-78]
Лист утверждения и титульный лист
Лист и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (и), лист регистрации изменений допускается в документ не включать [из п. 1.2 ГОСТ 19.201-78]
Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.
Изменения и дополнения
Для внесения или дополнений в техническое задание на последующих или выпускают дополнение к нему. и дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания [из п. 1.3 ГОСТ 19.201-78]
Учесть все детали на начальных невозможно, поэтому на практике указанный подход применяется весьма часто. В «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с заказчиком».
Состав разделов технического задания
Техническое задание должно содержать следующие:
- введение;
- основания для;
- назначение разработки;
- к или;
- требования к;
- технико-экономические показатели;
- порядок и;
- в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. 1.4 ГОСТ 19.201-78]
Любые манипуляции с разделами - строго по с.
Отдельные подразделы технического задания могут подействовать на условного заказчика, как красная тряпка на быка. Заказчика, даже условного, раздражать не следует. В спорных подразделах будут рассмотрены пути поиска компромиссных решений. Ключевые позиции, в которых уступка заказчику равносильна затягиванию петли на шее исполнителя, будут также откомментированы с обоснованием жесткой позиции исполнителя.
Чтобы излишне не отягощать ход повествования, в качестве будем использовать реальную программу с, обеспечивающую возможность выполнения нескольких шаблонных функций. Пусть такой программой станет несложный.
Введение
В разделе «Введение» указывают, краткую характеристику области применения или и объекта, в котором используют программу или программное изделие [из п. 2.1 ГОСТ 19.201-78]
Основное правило работы с – детализация, дробление текста на структурные единицы, - разделы, подразделы, пункты и подпункты, см. статью «» документа будет иметь четкую структуру, способствующую легкому требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:
Наименование программы
Наименование программы – «Текстовый редактор для работы с файлами формата rtf».
Краткая характеристика области применения
Программа предназначена к применению в профильных подразделениях на объектах заказчика.
Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. документ можно будет в ходе технического задания с заказчиком.
Основания для разработки
В разделе «Основания для разработки» должны быть указаны:
- документ (документы), на основании которых ведется разработка;
- , этот документ, и дата его утверждения;
- и (или) условное обозначение темы разработки.
[из п. 2.2 ГОСТ 19.201-78]
Основание для проведения разработки
Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор утвержден Директором ФГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.
Удобно воспользоваться разделом «Общие сведения» , поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в договоре. Следует ли приводить их в техническом задании – зависит от конкретного случая.
Наименование и условное обозначение темы разработки
Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf». Условное обозначение темы разработки (шифр темы) – «РТФ-007»
Назначение разработки
В разделе «Назначение разработки» должно быть указано и эксплуатационное назначение или [из п. 2.3 ГОСТ 19.201-78]
Функциональное назначение
Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf.
В подразделе должно быть указано «укрупненное» функциональное назначение программы. Детали – перечень функций и т.д. – будут приведены ниже, в соответствующих разделах.
Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?
Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. По причине отсутствия. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.
Применим формальный подход:
Эксплуатационное назначение
Программа должна эксплуатироваться в профильных подразделениях на объектах заказчика. должны являться сотрудники профильных подразделений объектов заказчика.
Два крайних предложения - не в тему. При проведении переговоров с реальным заказчиком подраздел будет откорректирован.
Требования к программе или программному изделию
Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
- требования к функциональным характеристикам;
- требования к;
- требования к составу и параметрам;
- требования к и;
- требования к и;
- требования к и;
- специальные требования.
[из п. 2.4 ГОСТ 19.201-78]
Если существуют стандарты, содержащие общие (технические) требования к программе, или, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.
Требования к составу выполняемых функций
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
- функции создания нового (пустого) файла;
- функции открытия (загрузки) существующего файла;
- функции редактирования открытого (далее - текущего) файла путем ввода, содержимого файла с применением стандартных;
- функции редактирования текущего файла с применением;
- функции файла с исходным;
- функции сохранения файла с именем, отличным от исходного;
- функции отправки содержимого текущего файла электронной почтой с помощью внешней клиентской почтовой программы;
- функции вывода оперативных справок в (подсказок);
- функции;
- функции отображения названия программы, версии программы, копирайта и комментариев разработчика.
Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая. Применение клише - шаблонного построения фраз - детально расписано в статье «».
Требования к организации входных данных
программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих RFC... Файлы указанного формата должны размещаться () на локальных или съемных, согласно требованиям операционной системы.
Любой иного, но с расширением rtf, открываться не должен.
Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного, отформатированного, к примеру, в формате ext3, открываться не должны.
Требования к организации выходных данных
Требования те же, что и к организации выходных данных. Тот самый случай, когда следует объединить оба пункта технического задания.
Требования к временным характеристикам
Требования к временным характеристикам программы не предъявляются.
Следует уточнить, предъявляет ли заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам, см. формулировку выше.
Требования к надежности
В подразделе «Требования к надежности» должны быть указаны требования к обеспечению функционирования (обеспечения, контроль входной и выходной информации, после и т.п.) [из п. 2.4.2 ГОСТ 19.201-78]
– штука тонкая и очень опасная. Но перечень функций и видов их, согласно п. 1.3.2. , обязан составить заказчик и согласовать с исполнителем.
Скорее всего, дождаться от заказчика чего-либо вразумительного не удастся. Стоит разъяснить заказчику, что надежное функционирование программы зависит не столько от исполнителя, сколько от надежности технических средств и, а также предложить заказчику ряд жестких мер для повышения и.
Требования к обеспечению надежного (устойчивого) функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
- организацией бесперебойного питания технических средств;
- использованием программного обеспечения;
- регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
- регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие.
К списку можно добавить еще несколько десятков. В ходе первичного согласования технического задания заказчик, скорее всего, начнет проявлять склонность к компромиссу.
Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТу) можно считать выполнение некой i-той функции в течение конкретного интервала времени. Предложим заказчику считать критерием надежной работы программы следующий показатель: заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст, считаются выполненными.
Если заказчик, наконец, убедился, что надежность зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой – в разделе обязательно следует написать такую фразу:
Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.
Время восстановления после отказа
Вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать стольких-то минут при условии соблюдения технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение технических средств и переустановки программных средств.
Перечень аварийных ситуаций ситуаций также составляет заказчик и согласовывает с исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств.
Отказы из-за некорректных действий оператора
Отказы программы возможны вследствие при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу пользователя без предоставления ему административных.
Условия эксплуатации
В подразделе «Условия эксплуатации» должны быть указаны (, относительная влажность и т.п. для выбранных типов), при которых должны обеспечиваться заданные характеристики, а также, необходимое количество и персонала [из п. 2.4.3 ГОСТ 19.201-78]
Очень опасный подраздел для тех, кто делает первые шаги в разработке технического задания.
Климатические условия эксплуатации
Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести в полном объеме за счет исполнителя.
Много лет тому назад автор статьи, в силу молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал на климатику», причем «попал конкретно» (так, со слов Путина, выражается просвещенная интеллигенция), на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!
Примечание от 10.02.2011 г. - По иронии судьбы специалисты «Технической документации» не так давно снова «попали на климатику», а точнее - провели разработку программы и методики испытаний на воздействие внешних факторов , по и подготовили, открыв для себя еще одно. Не зря говорят, что история развивается по восходящей спирали...
Требования к видам обслуживания
Программа не требует проведения каких-либо видов.
Виды обслуживания следует позаимствовать из подраздела «Требования к обеспечению надежного (устойчивого) функционирования».
Если заказчик в ходе согласования технического задания сошлется на отсутствие или желание проводить все виды обслуживания собственными силами, имеет смысл предложить разработку технического задания на за отдельные деньги отдельным договором. Откажется – следует считать программу.
Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц – системный администратор и пользователь программы – оператор.
Системный администратор должен иметь высшее профильное образование и компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:
- задача поддержания технических средств;
- задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы;
- задача установки (инсталляции) программы.
Пользователь программы (оператор) должен обладать практическими навыками работы с операционной системы.
Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).
При отсутствии самой ключевой фразы в утвержденном техническом задании заказчик вправе затребовать от исполнителя разработку руководства по эксплуатации графического пользовательского интерфейса операционной системы, мотивируя тем, что оператор «не справляется» с программой.
Персонал, не имеющий II квалификационной группы по электробезопасности, не имеет права даже близко подходить к и конторскому оборудованию.
Требования к составу и параметрам технических средств
В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав с указанием их основных технических характеристик [из п. 2.4.4 ГОСТ 19.201-78]
Следует подбирать не хуже той, на которой будет производиться разработка. Логично затребовать, чтобы технику предоставил заказчик не позднее указанного срока. Речь идет, разумеется, о компьютере.
В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:
- процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее;
- материнскую плату с FSB, ГГц - 5, не менее;
- оперативную память объемом, Тб - 10, не менее;
- и так далее…
Требования к информационной и программной совместимости
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и решения, и, используемым программой.
При необходимости должна обеспечиваться и [из п. 2.4.5 ГОСТ 19.201-78]
Требования к информационным структурам и методам решения
Иформационная структура файла должна включать в себя текст, содержащий, предусмотренную спецификацией формата rtf.
Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.
Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на C++. В качестве интегрированной программы должна быть использована среда Borland C++ Buider.
Требования к программным средствам, используемым программой
Используемые программой, должны быть представлены лицензионной локализованной версией операционной системы такой-то. Допускается применение пакета обновления такого-то.
Требования к защите информации и программ
Требования к и программ не предъявляются.
Подобных требований следует избегать, если нет особого желания разработать что-то вроде концепции обеспечения информационной безопасности согласно Обеспечить некоторый уровень и программ возможно, обеспечить безопасность невозможно. Заказчик, скорее всего, это осознает и проявлять настойчивость не станет.
Требования к маркировке и упаковке
В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке, варианты и способы упаковки [из п. 2.4.6 ГОСТ 19.201-78]
Программа поставляется в виде программного изделия - на дистрибутивном (внешнем) носителе (компакт-диске). Речь идет, разумеется, о маркировке и упаковке дистрибутивного.
Требование к маркировке
Программное изделие должно иметь маркировку с обозначением компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.
Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача исполнителя - прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов).
Требования к упаковке
Упаковка программного изделия должна осуществляться в упаковочную тару ().
Именно предприятия-изготовителя (поставщика). Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель (поставщик) тары.
Условия упаковывания
Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.
Заказчик получит программное изделие надлежащего внешнего вида. В случае возврата программного изделия (по) в ненадлежащем виде (наличие царапин, трещин и прочих) исполнитель сможет предъявить претензии в части нарушения заказчиком условий упаковывания и не принять программное изделие.
Порядок упаковки
Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары.
Программное изделие упаковывается с применением чехлов из водонепроницаемой пленки с обязательным наличием химически неагрессивных влагопоглотителей (силикагеля).
Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.
должна быть уложены в потребительскую тару вместе с программным изделием.
На верхний слой прокладочного материала укладывается - упаковочный лист и ведомость упаковки.
Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.
Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.
В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.
Габариты грузового места должны быть не более 1250 820 1180 мм.
Масса НЕТТО - не более 200 кг.
Масса БРУТТО - не более 220 кг.
Приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком - полнейший стёб, но требования есть и остаются требованиями.
Требования к транспортированию и хранению
В подразделе «Требования к транспортированию и хранению» должны быть указаны для условия, места, условия хранения, условия складирования, в различных условиях [из п. 2.4.7 ГОСТ 19.201-78]
В подразделе приведены условия транспортирования и хранения из ранее разработанного документа на какие-то технические средства. Это касается и требований к порядку упаковки. Выглядит несколько необычно в контексте программного изделия.
Заказчик не вправе нарушать условий транспортирования и хранения. Исполнитель сможет отказать заказчику в возврате программного изделия, утверждая, что ненадлежащий внешний вид программного изделия является следствием несоблюдения условий транспортирования и хранения.
Условия транспортирования и хранения
Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный.
При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания и. Не допускается кантование программного изделия. Климатические условия транспортирование приведены ниже:
- температура окружающего воздуха, °С - от плюс 5 до плюс 50;
- , кПа - такое-то;
- относительная влажность воздуха при 25 °С - такая-то.
Специальные требования
Программа должна обеспечивать взаимодействие с пользователем () посредством, разработанного согласно рекомендациям компании-производителя операционной системы.
Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом.
Требования к программной документации
В разделе «Требования к программной документации» должен быть указан предварительный состав и, при необходимости, специальные требования к ней [из п. 2.5а ГОСТ 19.201-78]
Предварительный состав программной документации
В состав программной документации должны входить:
Программа и методика испытаний потребуется, чтобы показать заказчику, что разработанная исполнителем программа соответствует требованиям согласованного и утвержденного технического задания. После проведения совместных (приемо-сдаточных) испытаний заказчик и исполнитель подпишут. И, тем самым, работа будет закрыта, условия договора выполнены.
Допускается объединять отдельные виды эксплуатационных документов (за исключением и). Необходимость указывается в. Объединенному документу присваивают и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. 2.6 ГОСТ 19.101-77]
Но тем, кто впервые занялся разработкой программной документации, лучше придерживаться принципа «мухи отдельно, котлеты отдельно».
Технико-экономические показатели
В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами [из п. 2.5 ГОСТ 19.201-78]
Ориентировочная экономическая эффективность не рассчитываются. Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.
Положим, заказчик оснащает программой десяток рабочих мест. Исполнитель потребовал за разработку $1000. Заказчик мог бы установить на рабочие места программный продукт третьей фирмы, стоимостью $500 за дистрибутив и по $100 за лицензию на каждое рабочее место.
Экономические преимущества разработки
Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:
число рабочих мест | разработка | экономические преимущества |
|
Виды испытаний
должны проводиться на объекте заказчика в сроки…
Приемосдаточные испытания программы должны проводиться согласно разработанной (не позднее такого-то срока) исполнителем и согласованной заказчиком «Программы и методики испытаний».
Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в.
Общие требования к приемке работы
На основании протокола испытаний исполнитель совместно с заказчиком акт приемки-сдачи программы в эксплуатацию.
Приложения
В приложениях к техническому заданию, при необходимости, приводят:
- перечень и других работ, обосновывающих разработку;
- схемы, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
- другие источники разработки.
[из п. 2.8 ГОСТ 19.201-78]
Если есть, почему не привести. И обязательно выложить перечень ГОСТов, на основании которых должна проводиться разработка. Например:
- ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению;
- и так далее..
Выводы
Настоящий стандарт, несмотря на свой немалый возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Разработчики ГОСТ 19.201-78 смотрели в будущее и учли практически все аспекты, касающиеся разработки программных средств.
Что осталось неучтенным? Сроки, объемы и этапы финансирования? Техническое задание всегда разрабатывается на основании Договора, письма, и т.д. Указанные сведения должны быть отражены в Договоре.
Каковы спорные моменты? Отсутствие в стандарте конктретных требований, положим, к пользовательскому интерфейсу? Разработчиками стандарта предусмотрен раздел «Специальные требования», возможность добавления новых разделов, допустим, разделов «Дополнительные требования» или «Требования к интерфейсу».
- ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
| Техническое задание на разработку программы «______________» к Договору №___ 1. Введение 1. Введение 1.1. Наименование программы Наименование программы: «АСУ «______________»» 1.2. Назначение и область применения Программа предназначена для автоматизации обработки данных клиентов кафе/бара. Она оперирует следующими данными:
2.1. Требования к функциональным характеристикам Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
2.2.1 Требования к обеспечению надежного функционирования программы Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Отказы программы вследствие некорректных действий пользователя при взаимодействии с программой. 3.1. Требования к квалификации и численности персонала Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 1 штатной единицы - оператор ПК. В перечень задач, выполняемых оператором ПК, должны входить:
3.2. Требования к составу и параметрам технических средств
3.3.1. Требования к информационным структурам и методам решения Программное обеспечение представляет из себя самостоятельное исполняемое приложение. Формат базы данных совместим с ADO.Пользователи работают с базой данных через системный интерфейс. 3.3.3. Требования к исходным кодам и языкам программирования Дополнительные требования не предъявляются. Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows XP. Требования к защите информации и программ не предъявляются. 3.5. Специальные требования Специальные требования не предъявляются. 4.1. Предварительный состав программной документации Состав программной документации должен включать в себя:
5.1. Экономические преимущества разработки Программа является бесплатным продуктом, финансовые средства не затрачиваются, и преимуществом является ускорение автоматизации обработки данных клиентов кафе/бара 6.1. Стадии разработки Разработка должна быть проведена в три стадии:
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы. На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика. 7.1. Виды испытаний:
7.2. Требования к приемке работы При приёмке необходимо проверить соблюдение следующих условий:
|
| Техническое задание на разработку дизайн проекта помещения. Информация | Техническое задание на разработку проектной документации для строительства зоопарка Положения В границах земельного участка ул. Подлесная, шоссе Космонавтов, ул. Малкова, Дзержинского района г. Перми |
||
| Техническое задание на разработку интернет-сайта структура документа Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного… |
Техническое задание на разработку веб-сайта «Объединение Российских Художников Аэрографии» Основной html контейнер, в который вставляются информационные блоки, должен быть полностью доступен для редактирования. Желательно… |
||
| Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных» Гост 34. 602-89 Техническое задание на создание автоматизированной системы (пример) |
2. Техническое задание на разработку ис В данном курсовом проекте приведен процесс выдачи пенсионного страхового свидетельства. Разработанная система предназначена для упрощения… |
||
| Техническое задание на разработку сайта журнала Настоящее тз представляет… Сайт моделируется с учетом ограничений современных систем контент-менеджмента (открытых WordPress, Joomla, LiveStreet и им подобных… |
Программа демонстрации алгоритмов обхода графов Данное техническое задание регламентирует разработку учебного программного продукта предназначенного, для наглядного представления… |
||
| Техническое задание включает в себя: наименование разработки, основание… Технико-рабочий проект: описание предметной области (объектная модель), управление объектами (события, диаграмма взаимодействия),… |
Проектирование программных средств Этап проектирования подразумевает разработку архитектуры, разработку данных и процедурную разработку программных средств |
Технические требования к системе
Технический облик изделия
Теория решения изобретательских задач — это советская методика сильного мышления, получившая широкое как в России, так и в мире. Она позволяет глубоко проанализировать проблему и найти эффективное решение.
Работа над ТРИЗ была начата Генрихом Сауловичем Альшуллером и его соратниками в 1946 году.
Разработка программы: пример технического задания
В 1956 году вышла первая публикация про то, что техника развивается по определенным законам. Чтобы эффективно изобретать, нужно эти законы выявить и эффективно применять
Со временем ТРИЗ развился в большой набор инструментов, помогающие решать ряд актуальных задать:
— создавать новые прорывные продукты,
— повышать потребительские свойства имеющихся решений,
— снижать себестоимость,
— обходить патенты конкурентов.
Ведущие мировые компании, такие как Samsung, Intel, Procter&Gambel, General Electric и другие используют ТРИЗ в своих R&D центрах.
Термины
Для исключения спорных моментов и недопонимания важно пользоваться одинаковым понятийным аппаратом. Для этого мы составили перечень наиболее часто используемых терминов и сокращений.
Когда речь заходит о разработке технической документации для программного обеспечения, чаще всего мы думаем, пожалуй, о таком документе, как Техническое задание (ТЗ). Почему так происходит?
Назначение технического задания
Во-первых, техническое задание – это, как правило, основной документ в рамках проектной документации. Именно в ТЗ описываются все основные требования на разработку программного обеспечения, будь то создание либо простенькой программы или сайта, либо же разработка крупномасштабной информационной системы или программно-аппаратного комплекса. Причем, говоря языком ГОСТов, техническое задание может разрабатываться как в рамках эскизного проекта (это когда только описание функций и структуры системы без рассмотрения технологий реализации решения), так и в дальнейшем «перекочевать» в технический проект (более детальное описание с учетом выбранных технологий).
Во-вторых, техническое задание может быть как поверхностным (например, общеконцептуальное ТЗ, предназначенное для инвесторов проекта), так и более детальным (например, подробное ТЗ для программиста). Посмотрите раздел Проекты, там как раз приведены примеры различных ТЗ. Вы можете выбрать любой уровень детализации – мы подготовим для вас ТЗ любой сложности по доступным ценам.
В-третьих, в некоторых случаях можно обойтись только подготовкой одного технического задания для описания разрабатываемой системы. Разумеется, в этом случае качество разрабатываемого ТЗ играет ключевую роль, поэтому здесь явно не стоит экономить и лучше доверить разработку такого ТЗ профессионалам, имеющим большой опыт в этом деле. Скупой платит дважды, но в случае провала разработки ПО по причине некачественной документации – вдесятеро, а иногда и еще на несколько порядков выше.
Состав типового технического задания
Давайте рассмотрим, что же включает в себя типовое ТЗ.
Техническое задание программного обеспечения оказалось поверхностным?
Итак, техническое задание, вне зависимости от выбранного ГОСТа, всегда включает следующие основные сведения по разрабатываемому ПО:
1) наименование
– полное и краткое названия, условное обозначение разрабатываемого ПО;
2) назначение
– то, для чего, в какой области и с какой целью разрабатывается ПО;
3) основание для разработки
– документы, на основании которых производится разработка ПО;
4) функции
– перечень и описание функций разрабатываемого ПО;
5) структура
– описание архитектуры и компонентов разрабатываемого ПО;
6) пользовательский интерфейс
– в современном мире обязателен;
7) надежность, безопасность, условия эксплуатации
и проч. важные требования;
8) документация
– какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана;
9) стадии и этапы разработки
– что и в какой последовательности разрабатывается;
10) порядок контроля и приемка
– как именно будет происходить сдача разработанного ПО Заказчику.
Стандарты для технического задания
Существует несколько ГОСТов, регламентирующих разработку ТЗ в нашей области: это ГОСТ 34.602 (автоматизированные системы) и ГОСТ 19.201 (программное обеспечение). Документы, выполненные по этим стандартам, значительно отличаются как по наполнению, так и по содержанию. Оба стандарта представлены на нашем корпоративном портале в разделе Библиотека, вы можете самостоятельно ознакомиться с ними более подробно.
Стоимость разработки технического задания
В целом, составление ТЗ – это достаточно сложная и ответственная задача, но грамотно составленное техническое задание – это уже половина успеха разрабатываемого проекта. Поэтому в процессе разработки ТЗ на ПО вы должны проявить максимальную внимательность и осведомленность в технических и организационных вопросах. Либо можете заказать у нас разработку технического задания «под ключ» прямо сейчас.
Возможно, вас также заинтересует:
– разработка программы и методики испытаний;
– создание пояснительной записки к эскизному и техническому проекту;
– этапы разработки документации.
Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы. В техническом задании мы описываем предметную область, существующую инфраструктуру Заказчика, требования к создаваемому функционалу, а также нефункциональные требования. Получившийся документ необходим как бизнес-пользователю для того, чтобы он убедился в том, что все его пожелания к будущей системе учтены, так и нам, чтобы оценить стоимость разработки системы.
Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.
Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.
Приведем ниже принципы, которыми мы руководствуемся при написании технического задания, и проиллюстрируем их выдержками из разработанного нами технического задания на многокомпонентную систему баннерной рекламы для крупной Интернет-компании.
Структура технического задания
Каждое техническое задание содержит несколько обязательных разделов. В них определяется назначение документа, терминология, общий контекст проекта. Обычно первая часть документа выглядит так:
Class="fs-13">
Если в начале документа даётся общая, концептуальная информация о разрабатываемой системе, то во второй, основной части документа, детально прописываются бизнес-требования и существенные для оценки стоимости разработки функциональные требования к системе.
В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.
class="fs-13">
7. Система размещения баннеров
8.
Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine
class="fs-13">
Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.
Учитывая специфику данного проекта, мы посвятили отдельный раздел взаимодействию баннерки с биллинговой системой. Также в отдельный раздел мы выделили требования к достаточно независимой компоненте сбора и отображения статистической информации, которая является для заказчиков рекламных кампаний и менеджеров рекламных агентств едва ли не основным компонентом системы.
Отдельный раздел технического задания описывает требования к компоненту Banner Engine, отвечающему за показ баннеров, учёт статистики, её обработку и сохранение в виде, пригодном для дальнейшего анализа и построения отчетов.
Это – технически самый сложный и самый высоконагруженный компонент баннерной системы. В ТЗ мы включили раздел, содержащий некоторые технические и архитектурные детали, связанные с работой Banner Engine. Прежде всего, это позволяет минимизировать риски при оценке стоимости разработки системы, ведь в зависимости от выбранной архитектуры трудоемкость может отличаться в разы.
Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.
class="fs-13">
Бизнес vs Функциональные требования
В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта.
Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
Пример бизнес-требования:
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта
Роль: Администратор
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест).После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий, разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Основные принципы
При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста. В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е. представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.
У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.
Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.
По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
Прототипы, уже на стадии разработки, дают заказчику понять, как именно будет выглядеть интерфейс системы.
Требования должны быть написаны «живым человеческим» языком , понятным бизнес-пользователю в т.ч. руководителю высшего звена, не обладающему техническими навыками; в них должен содержаться минимум технической терминологии. Чем быстрее пользователь «вникнет» в содержания технического задания, тем более эффективно будет выстраиваться наше с ним общение.
Опыт в предметной области
Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными. Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.
Поиск Лекций
Техническое задание на объект
При проектировании технического объекта важное место занимает разработка технической и технологической документации: техническое задание (ТЗ) и технические условия (ТУ).
Техническое задание — это основной исходный документ для разработки продукции, содержащий технико-экономические требования к продукции, определяющие ее потребительские свойства и эффективность применения, перечень документов требующих совместного рассмотрения, порядок сдачи и приемки результатов разработки. Техническое задание на проектирование разрабатывается на основании ГОСТ 15.001-88 и оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-68.
В качестве технического задания допускается также использовать любой документ (контракт, протокол, эскиз, образец продукции и др.), содержащий необходимые и достаточные требования для разработки и признанный заказчиком и разработчиком.
Утвержденное техническое задание является документом, которым разработчики должны руководствоваться на всех этапах создания системы и проектирования задач. Изменения, вносимые в техническое задание, должны оформляться протоколом, являющимся частью технического задания. Протокол должен утверждаться заказчиком.
При разработке технического задания следует:
· установить общую цель создания технической системы;
· установить общие требования к проектируемой системе;
· определить этапы создания системы и сроки их выполнения;
· провести предварительный расчет затрат на создание системы.
Техническое задание должно содержать следующие разделы:
1) наименование и область применения;
2) код изделия;
3) основания для разработки;
4) цель и технико-экономическое обоснование;
5) источники для разработки;
6) этапы разработки и запуска производства;
7) технические требования.
В зависимости от назначения разрабатываемых средств измерений, условий их изготовления и эксплуатации допускается изменять структуру технического задания, объединяя отдельные разделы и вводя новые.
В разделе Основание для разработки указывают наименование документа (документов), которым предусмотрена данная разработка, организацию, утвердившую этот документ, и дату его утверждения, наименование и шифр темы разработки.
Основанием для разработки является маркетинговые исследования и выход нового стандарта.
В разделе «Цель и технико-экономическое обоснование разработки» указывают:
1. Конкретное функциональное назначение объекта – для снижения токсичности автомобиля.
Техническое задание на разработку программы
Наличие отечественных и зарубежных аналогов и возможность или целесообразность их применения по данному назначению – на рынке присутствуют зарубежные аналоги, но их стоимость и отечественные аналоги.
3. Предполагаемую потребность в данных объектах у потребителей – данный объект необходим потребителю для соблюдения норм стандарта и сохранения здоровья людей и окружающей среды.
В разделе «Источники разработки» приводят перечень научно-исследовательских и других работ, результаты которых используют в данной разработке, а также перечень образцов или макетов, на базе которых выполняют разработку.
В разделе «Этапы разработки» указывают необходимые этапы работ и ориентировочные сроки их выполнения, состав и ориентировочные сроки представления конструкторской технологической документации на метрологическую экспертизу и организацию, которая ее проводит.
Основываясь на этапы жизненного цикла продукции разрабатываем этапы разработки и запуска в производство.
Основные этапы разработки: маркетинговые исследование; разработка ТЗ; — проектирование объекта; испытание; подготовка производства; запуск в производство.
На первой стадии проектирования производится выбор (или разработка) принципиальной схемы объекта. С этой целью на основании справочных данных, рекомендаций и стандартов формируется ряд вариантов объектов – аналогов, в той или иной степени отвечающих требованиям ТЗ. Далее в случае необходимости производится доработка принципиальных схем объектов – аналогов. Если варианты объектов – аналогов не найдены, переходят к процедуре синтеза вариантов объектов, еще не встречавшиеся в практике машиностроения. При это, как уже отмечалось, максимально используются стандартные элементы и узлы.
Следующая стадия проектирования – конструктивное оформление основных элементов и построение математических моделей функционирования приспособления. Последняя стадия проектирования- окончательное конструкторское оформление принятых решений, выполнение чертежей и текстовой части в соответствии с требованиями ЕСКД .
После успешных испытаний, для заказчика проекта, на основе требований технического задания и стандартов, касающихся данного вида продукции, с учетом результатов испытаний разрабатывается техническое условие на приспособление, которое включает в себя:
1.Технические требования
2. Требования безопасности
3. Требования охраны окружающей среды
4. Правила приемки
5. Методы контроля
6. Транспортирование и хранение
7. Указание по эксплуатации
8. Гарантии изготовителя
9. Утилизация
На основе разработанных документов можно приступать к непосредственному проектированию объекта.
Привет, Хабр! Адресую эту статью себе более молодому и неопытному, а также всем, кто чувствует неуверенность в подходе к технической документации. Хотя если кому-то из зубров проектного дела она поможет, буду рад вдвойне.
Для составления ТЗ существует множество , но если молодые студии при разработке простенького интернет-магазина будут пытаться им соответствовать, то не успеют реализовать и пары проектов, как разорятся, закопавшись в кучу непонятных документов.
Что было раньше
Мы небольшая региональная компания, занимающаяся заказной веб-разработкой, которая, как и многие другие, в самом начале бралась за проекты, не особо представляя как их делать. Но подобный “вынужденный рост” крайне положительно сказался на членах команды, благодаря огромному желанию развиваться, и помог прокачать и скилы, и голову. Разработка становилась все качественнее, но техническое задание оставалось на самом низком уровне. Как и большинство начинающих студий, мы использовали обычный описательный подход к ТЗ: какие страницы, что должно отображаться, некоторые технические моменты, да и все, пожалуй.
На многих проектах это выливалось в следующие проблемы:
- Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
- Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
- ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.
Новый подход
Определившись с целями, мы разработали новую, довольно простую, но эффективную концепцию.ТЗ состоит из следующих разделов:
- Введение
- Статика
- Динамика
- Задачи
- Административная панель
- Общие технические требования
Введение и подготовка к реализации
- Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
- Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
- Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа - “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.
Статика
Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики - страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель - задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.
Если же страница содержит блок, который можно “вынести за скобки”, то в месте его интеграции мы пишем “Интегрируется функционал “NAME”, а сам функционал описываем в разделе “Динамика”.
Помимо страниц Статика включает в себя описание pop-up и письма. На мой взгляд их нет смысла выносить в отдельный большой раздел и раздувать структуру.
Динамика
Все, что относится к динамике мы называем функционалом. Возможно, позже появится еще какое-то разделение, т.к. уже сейчас сюда относятся различные типы задач:
- Блок. В динамику выносим:
- Блоки, используемые в разных частях сайта.
- Блоки, которые имеет смысл оценивать отдельно. Во-первых, это упрощает и сам процесс оценки, и понимание заказчиком сложности отдельного элемента. Во-вторых, в эту категорию часто попадают блоки, которые не являются жизненно необходимыми для проекта, и при таком подходе их проще исключить из сметы.
- Процессы, происходящие при определенном действии пользователя. В первую очередь сюда относятся действия, происходящие при оформлении заказа, оплате, добавлении в корзину и тд. Подобный функционал при развитии проекта часто дорабатывается, и так эти доработки намного удобнее описывать.
- Интеграции сторонних сервисов. В зависимости от сложности интеграции, она может описываться как один функционал, или наоборот разбиваться на много разных для описания отдельных запросов.
Этот раздел используется для работ, которые нельзя отнести ни к одному из других разделов: нарисовать баннер, установить счетчик метрики, спарсить товары и т.д.
Административная панель
Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.
Общие технические требования
Включает в себя довольно много подразделов, не все из которых действительно являются техническими требования, но опять же выносить их отдельно не имело смысла:
- SEO-требования к тегам и микроразметке
- Правила транслитерации
- Ручное и автоматическое тестирование
- Поддерживаемые браузеры
Новые версии
При описании новых версий необходимо вносить изменения в существующие элементы. Мы рассматривали следующие способы описания доработок: в начале каждого из разделов (Статика, Динамика, АП) писать “Доработка функционала “NAME”, либо сделать отдельный раздел “Доработки”, в котором в кучу будут свалены сразу все изменяющиеся задачи. Пока остановились на втором варианте, но это связано скорее удобством на конкретных проектах. В других условиях лучше подойдет первый способ.После написания ТЗ на новую версию, мы сливаем их в одну, чтобы следующее можно было писать на основании одного документа.
Пример
Давайте для наглядности разберем структуру ТЗ на основе упрощенной страницы раздела каталога.Статика
Страница “Раздел каталога”Используется для отображения товаров, принадлежащих к разделу каталога любого уровня, кроме корневого.
Интегрируется следующий функционал:
- “Хлебные крошки”
- “Дерево каталога”
- “Фильтрация. Общие положения”
- “Фильтрация. Текст”
- “Фильтрация. Текст и изображение”
- “Фильтрация. Диапазон”
- “Сортировка. По умолчанию”
- “Сортировка. По возрастанию цены“
- “Сортировка. По убыванию цены”
- “Превью товара. Плитка”
- “Пагинация. Постраничная”
- “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта
Динамика
Т.к страница содержит очень много интеграций, приведу примеры для двух самых интересных из них.Функционал “Фильтрация. Общие положения”
Внешне фильтрация представляет собой ряд (или несколько рядов) кнопок с названием фильтра. При клике на кнопку открывается выпадающий список с чек-боксами со значениями фильтра (значениями соответствующей характеристики товара). Ширина выпадающего списка зависит от максимальной длины значения в этом списке. В видимой области выпадающего списка отображается не более 10 пунктов. Если значений фильтра больше, то появляется полоса прокрутки. Под значениями фильтра находится кнопка Применить. Если выбрано хотя бы одно значение и пользователь нажимает на кнопку Применить, вне области фильтра или на кнопку с названием фильтра, то:
- выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
- название кнопки фильтра приобретает вид: “Название фильтра: K”, где K - количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
- цвет кнопки фильтра меняется на вид используемого фильтра
- в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
- у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
- пагинация сбрасывается
При переходе из текущей категории в любую другую осуществляется проверка на совпадение активных фильтров и выбранных в них значений с соответствующими фильтрами и значениями категории, в которую был осуществлен переход. В новой выбранной категории активными остаются те фильтры и выбранные в них значения, которые совпали.
Фильтрация может интегрироваться 2 способами: динамически и статически. Динамическая интеграция позволяет задавать характеристику, по которой осуществляется фильтрация, в административной панели. Такие интеграции указываются без дополнительных параметров. Статическая интеграция применяется к странице по умолчанию. При описании интеграции указывается дополнительный параметр - характеристика, по которой осуществляется фильтрация.
Выбранные фильтры добавляются в URL посредством query-параметров.
Функционал “Превью товара. Плитка”
Представляет собой плитку (прямоугольник) с самой важной для пользователя информацией о товаре. В варианте плиткой ключевой информацией является изображение товара. Превью содержит:
- Цена (целое число в рублях РФ)
- Название товара
- Метка “В магазине” или “С витрины”
- Изображение
- Размер
- Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
- Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)
На одной строке должно помещаться 3-4 плитки с превью товара.
Как вы видите, в данный функционал интегрируется другой, что позволяет делать очень удобные разбиения. Например, “Добавить в корзину” и “Добавить в избранное” используются и в карте товара.
Административная панель
Одна страница требует большого количества разделов АП, опишу один из них.Товар
Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:
- Название (текст)
- Бренд (радио)
- Изображения
- Цена (целое число)
- Описание (текстовый блок)
- Тип (магазин/витрина, радио)
- Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
- Статус. Возможны варианты:
- на продаже
- на модерации
- на доработке
- отклонен
- продан
- не прошел проверку
- отменен Продавцом
- Размер с бирки (необязательное). Текстовое поле без валидации
Выводы
Плюсы нового подхода:- Полнота . Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
- Понятность . Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
- Молекулярность . ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
- Простота оценки и конфигурации сметы . Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
- Взаимодействие с заказчиками поднялось на новый уровень . Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
- Рентабельность . Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.
- Внесение доработок . На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
- Сложность восприятия при автоматизации бизнес-процессов . Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
- Стоимость и время разработки . Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.
Каждый проект привносит что-то новое, шлифует углы и позволяет менять его к лучшему.
Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).
В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается "как получится". Как сказал Генри Шоу "Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи".
О чем эта статья?
Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:- В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть ?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
- Вторая часть «Разработка Технического задания. Как формулировать требования ?» будет полностью посвящена выявлению и формулировке требований к информационной системе.
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
- Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
- IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
- Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
- Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
- Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
- Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
- Возможны и другие, реже встречающиеся варианты;
- А почему нельзя разрабатывать Техническое задание всегда одинаково?
- Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
- Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
- Как понять, хорошо составлено Техническое задание или нет?
- За чей счет должно оно разрабатываться, да и нужно ли оно вообще?
Что такое техническое задание?
Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема ». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.
Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».
Если кому-то интересно, о каких ГОСТах я говорю, то вот они:
- ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
- ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
- ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
И так, как следует из определения, основное назначение Технического задания - сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе.
Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.
Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:
- Требования в функциональности;
- Требования к безопасности и правам доступа;
- Требования к квалификации персонала;
- …. И т.д. Вы можете прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).
Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:
- Требование должно быть понятным ;
- Требование должно быть конкретным ;
- Требование должно быть тестируемым ;
На этом повествование о том, что такое Техническое задание можно было бы завершить и перейти к главному: как формулировать требования. Но не так все быстро. Есть еще один крайне важный момент:
- на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
- Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
- А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?
Техническое задание - это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке. При этом может и должна использоваться отраслевая терминология, понятная Заказчику. Никаких привязок к особенностям технической реализации быть не должно. Т.е. на этапе ТЗ в принципе не важно, на какой платформе будут реализовываться эти требования. Хотя есть исключения. Если речь идет о внедрении системы на основе уже существующего программного продукта, то такая привязка может иметь место, но только на уровне экранных форм, форм отчетов и пр. Выяснением и формулированием требований, а также разработкой Технического задания должен заниматься бизнес-аналитик. И уж никак не программист (если только он не совмещает в себе эти роли, такое случается). Т.е. этот человек должен говорить с Заказчиком на языке его бизнеса.
Технический проект - это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуютсятехническим специалистам . Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально). А точнее группа специалистов во главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.
Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.
Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени - это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.
Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.
А нужно ли вообще техническое задание? А Технический проект?
Не перегрелся ли я? Разве такое возможно, вообще без Технического задания ? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого» . Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.
Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.
Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»
Формулирование требований к информационной системе. Структура Технического задания
Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, т.е. предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса - помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть, считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 - пожалуй, перебор. Ведь Техническое задание - это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).
Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть - формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.
- общие сведения;
- назначение и цели создания (развития) системы;
- характеристика объектов автоматизации;
- требования к системе;
- состав и содержание работ по созданию системы;
- порядок контроля и приемки системы;
- требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
- требования к документированию;
- источники разработки.
Раздел 1. общие сведения.
| Рекомендации по ГОСТ | |
| полное наименование системы и ее условное обозначение; | Тут все понятно: пишем, как будет называться система, ее краткое наименование |
| шифр темы или шифр (номер) договора; | Это не актуально, но можно и указать, если требуется |
| наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; |
указывают, кто (какие организации) будут работать над проектом. Можно указать и их роли. Можно вообще удалить этот раздел (достаточно формальный). |
| перечень документов, на основании которых создается система, кем и когда утверждены эти документы; | Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую Вам предоставили для ознакомления с определенной частью требований |
| плановые сроки начала и окончания работы по созданию системы; | Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы |
| сведения об источниках и порядке финансирования работ; | Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников) |
| порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. | Не вижу необходимости в этом пункте, т.к. требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы. |
| Рекомендации по ГОСТ | Что с этим делать на практике |
| Назначение системы | С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Т.к. Заказчик всегда может говорить, что под качеством он имел ввиду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном Техническом задании». |
| Цели создания системы |
Цели - это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, т.к. при разворачивании дерева целей (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит. Вообще, умение выделять цели, формулировать их, строить дерево целей это тема совершенно отдельная. Запомните главное: умеете - пишите, не уверены - вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется. |
| Рекомендации по ГОСТ | Что с этим делать на практике |
|
Требования к системе в целом. ГОСТ расшифровывает перечень таких требований:
|
Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным:
|
| Требования к функциям (задачам), выполняемым системой | Вот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил. |
|
Требования к видам обеспечения ГОСТ выделяет такие виды:
|
На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования:
|
| Рекомендации по ГОСТ | Что с этим делать на практике |
|
Виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему); Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации; |
Настоятельно рекомендую с ответственностью отнестись к порядку сдачи работ и проверке системы. Именно для этого и нужны тестируемые требования. Но даже наличие тестируемых требований может оказаться недостаточно при сдаче системы, если четко не прописан порядок приемки-передачи работ. Например, распространенная ловушка: система сделана, вполне работоспособна, но Заказчик по каким-либо причинам не готов в ней работать. Причины эти могут быть любые: некогда, поменялись цели, кто-то уволился и т.п. И говорит: «Поскольку мы еще не работаем в новой системой, значит и не можем быть уверены, что она работает». Так что учитесь правильно выделять этапы работ, способы проверки результатов по этим этапам. Причем Заказчику такие способы должны быть понятны изначально. Если они зафиксированы на уровне Технического задания, то всегда можно при необходимости к ним обратится и подвести работы с передаче. |
| Рекомендации по ГОСТ | Что с этим делать на практике |
| Приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; |
Весьма важный момент. К примеру, для функционирования системы так, как задумано, может потребоваться использование каких-либо отраслевых или общероссийских справочников и классификаторов. Эти справочники должны каким-то образом появляться в системе, обновляться и правильно использоваться. Могут быть и любые другие правила ввода информации, принятые в компании (или планируемые). Например, информация о договоре раньше заносили текстовой строкой в произвольном виде, а теперь требуется номер отдельно, дату отдельно и т.д. Таких условий может быть очень много. Часть из них может быть воспринята с сопротивлением персонала, поэтому лучше все такие случаи прописать на уровне требований к порядку ввода данных |
|
Изменения, которые необходимо осуществить в объекте автоматизации Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ |
Любые изменения, которые могут потребоваться. Например, в компании отсутствует локальная сеть, устаревший парк компьютеров, на которых система не заработает. Возможно, какая-то необходимая информация обрабатывалась на бумаге, а теперь ее необходимо вводить в систему. Если этого не делать, то какой-либо модуль не заработает и т.п. Возможно, что-то упрощалось, а теперь требуется учитывать более детально, соответственно кто-то должен собирать информацию по определенным правилам. Этот перечень может быть длинным, смотрите на конкретный случай своего проекта. |
|
Создание необходимых для функционирования системы подразделений и служб; Сроки и порядок комплектования штатов и обучения персонала | Про это мы уже говорили ранее. Возможно, система разрабатывается под новую структуру или вид деятельности, которого раньше не было. Если не будет соответствующего персонала, да еще и обученного, то система не заработает, как грамотно ее не строй. |
| Рекомендации по ГОСТ | Что с этим делать на практике |
| Согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов |
Наличие полноценной документации - важная часть результата. Все мы знаем, что документирование чего-либо трудоемкий труд. Поэтому, необходимо заранее оговорить с Заказчиком, какие виды документации будут разрабатываться, как они будут выглядеть (содержание и желательно примеры). Подумайте, как будут представлены руководства пользователя. Возможно, у Заказчика есть принятые корпоративные стандарты, значит надо к ним обращаться. Игнорирование требований к документации очень часто приводит к самым неожиданным последствиям на проектах. Например, все сделано и все работает. Пользователи тоже умеют работать. Про документацию вообще не договаривались и не разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров Заказчика, который даже не участвовал в проекте, но участвует в приемке работ, Вас спрашивает: «А где руководства пользователя?» И начинает Вас убеждать, что о наличии руководств пользователя договариваться было и не нужно, это «само собой» якобы подразумевается. И все, не хочет принимать у Вас работу. За чей счет будете разрабатывать руководства? На этот крючок попадали уже многие команды. |
| Рекомендации по ГОСТ | Что с этим делать на практике |
| Должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы. |
Если честно, это ближе к лирике. Особенно, когда говорят об экономическом эффекте и пр. вещах, которые объективно посчитать практически невозможно. Т.е. можно конечною, то это будет скорее на бумаге, чисто теоретически. Поэтому, лучше сослаться просто на отчет об обследовании, требования ключевых лиц. |
И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.
Но вот без главного: функциональных требований ни одно грамотно Техническое задание не обходится. Хочу заметить, что в практике такие Технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится (т.е. он его утвердит). Но вот работать по нему может не получиться, т.е. практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег именно под Техническое задание, а сделать его надо быстро и не погружаясь в детали. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.
Во второй статье будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.
Почему требования должны быть понятными, конкретными и тестируемыми.
Потому, что практика показывает: по началу большинство ТЗ, которые разрабатывают специалисты либо оказываются не востребованы (не соответствуют действительности), либо становятся проблемой для того, кто из должен реализовать, т.к. Заказчик начинает манипулировать неконкретными терминами и требованиями. Приведу несколько примеров того, какие фразы встречались, к чему это приводило, а затем попробую дать рекомендации, как избежать подобных проблем.Вид требования | Неправильная формулировка |
