Comments 15
Вопрос вообще шире: Всегда ли нужен < стандарт | ГОСТ | ISO 9000 | TickIT | SEI SW-CMM > при разработке крупных проектов?
Рекомендую прочесть мнение: https://gaperton.livejournal.com/49867.html
Спасибо. Мы за то, чтобы документация была удобна команде, а разрабатываемый продукт - пользователю. Конечно, в определённом смысле стандарты разработки нужны - критерии качества требований, принципы хорошего кода, принципы тестирования ПО и т.д. Однако, это то, чем мы внутри команды измеряем качество разработки. Заказчик же иногда может быть далёк от IT-среды, но ему нужно какое-то мерило, и он берет утверждённый стандарт, полагая, что это и есть критерий качества. ГОСТ в данном случае может оказаться попыткой на велосипеде победить в ралли Формулы-1. Утверждённые стандарты могут не успевать за темпами развития технологий и методологий в отрасли.
Писать ТЗ заказчику не обязательно, особенно если он в этом слабо разбирается. Заказчик имеет право за денежку нанять предполагаемого исполнителя или даже совсем стороннюю компанию для оказания данной услуги.
ГОСТы 34 группы предназначены не для программных продуктов, а для создания автоматизированных систем (т.е. скорее программно-аппаратных комплексов, где требования к ПО как раз и могут раскрываться в ЧТЗ) и говорить, что они устарели для описания программ как-то нелепо. Программные ГОСТ 19 группы - вот и ссылайтесь на них.
РД 50-34.698-90 - имеет статус "недействующий".
Почему-то забывают, что ТЗ нужно в том числе и при приемке работ - сверка чего хотели и что получили. Если писать много конкретики, то сдавать систему бывает проблематично, поэтому я сторонник указывать в ТЗ только функциональные требования, без описаний реализаций (но это не в части ПО).
И как уже надоело это "делаем по ГОСТ" - стандарт указывает направление движения, все отступления от него под ответственность лиц принимающих решения.
Очень рассчитывал увидеть принцип выбора ГОСТ 34 или 19. Но упоминание второго было только в названии и тегах. Тем не менее, как мне кажется, ошибка часто заключается в том, что выбирают 34, когда нужен 19. АИС - это не только программное обеспечение, но и оборудование. Зачем использовать 34 ГОСТ, если идет только разработка ПО? Зачем, например, от разработчиков требовать написания пункта про запасные части? Это явная отсылка к аппаратному обеспечению в 34 ГОСТ. Да, по итогам разработки ПО можно у разработчиков заказать еще и ТЗ по 34 ГОСТ, но уже как часть отчетной документации, а не как "дорожную карту" разработки.
Много слышал о том, что эти ГОСТы устарели. Но и в этом статье не увидел, конкретно в чем. Кажется, что причина мнения об устаревании, как раз кроется в том, что выбрали изначально не тот ГОСТ.
Кроме того, и в 34 и 19 ГОСТах есть "волшебная фраза" о том, что разделы и их содержание могут дополняться, объединяться. Что превращает их в достаточно гибкий инструмент, который носит рекомендательный характер. А значит нужно еще очень постараться, чтобы доказать (даже в суде), что то или иное техническое задание не соответствует какому либо ГОСТу, даже если его автор в глаза их не видел.
ГОСТ 34 действительно шире, потому что охватывает всю инфраструктуру – от непосредственных участников бизнес-процессов до аппаратного обеспечения. И когда речь идет о создании АИС на предприятии с нуля, заказчики зачастую выбирают ГОСТ 34, одновременно рассматривая разработку ПО и изменения в инфраструктуре. По нашим наблюдениям, ГОСТ 19 чаще применяют при разработке либо отдельных продуктов в составе существующей АИС, либо ПО для более массового использования, не требующего строго определённых условий (аппаратных или бизнесовых).
Отметим также, что стандарты заточены под водопадную методологию разработки, поэтому при реализации появляется необходимость найти баланс между утверждёнными стандартами и эффективными процессами
Для успешного выполнения работы считаю обязательным перед ее выполнением проводить НИР и НИОКР (для физических реализаций). Тогда не будет этого:
"Здесь стоит задуматься о том, будет ли команда разработки читать ТЗ по ГОСТ, если в нем слишком много текста? Если ТЗ громоздкое, то большую его часть могут проигнорировать, и найти в нем “зерно истины” будет сложно из-за сложной навигации. Представьте, какая это пытка для программиста и для тестировщика."
в составе конкурсной документации нет понятия "Техническое задание" — этот документ правильнее называть “техническими требованиями”
как действующий юрист по закупкам, работающий на стороне гос.заказчика не могу согласиться с таким заявлением. 44фз не имеет обоих понятий указанных понятий - ни "техническое задание" ни "технические требования". Есть только одно - "описание объекта закупки" в описании объекта закупки указываются функциональные, технические и качественные характеристики, эксплуатационные характеристики объекта закупки (более подробно - ст.33 указанного закона). Как правильно заметили выше гос.заказчик можетне самомтоятельно описывать закупку. Классический пример из стройки - сначала заказывают проект, а потом готовый проект используется в качестве описания закупки.
Тут надо обратить внимание, что "ТЗ по ГОСТу" в самом ГОСТе называется "ТЗ на создание автоматизированной системы". То есть в общем случае оно содержит требования не столько к самой АС (там они рамочные), сколько к процессу создания, а именно: план, бюджет и источники финансирования, сроки, порядок и условия привлечения подрядчиков, план запуска очередей и предоставления промежуточной и итоговой отчетности, порядок приемки готовой системы. То есть ТЗ по ГОСТ 34 это высокоуровневый план работ, а не SRS, software requirement specification или product description, или как там принято называть
ГОСТы 34 серии охватывают максимальный спектр задач, но они не требуют дословного прописывания каждого раздела или выполнения каждого документа. Они больше являются вектором для проектировщика, чтоб тот ничего не забыл важного. А воду лить только потому, что в ГОСТе есть такой раздел совершенно не надо.
Это всего лишь шаблон для максимального и заведомо избыточного расписывания характеристик системы. Когда так его воспринимаешь, то это очень удобно.
В чем заключается устаревание данного ГОСТ? Я про ГОСТ 34. Так говорят, кто не хочет заморачиваться с разработкой проектной документации и сдать в эксплуатацию систему по принципу "И так сойдет". Ничего не знаю про ГОСТ 19, не приходилось его использовать.
И кстати. РД 50-34.698-90 уже отменен более 2-х лет назад :-)
С большинством Ваших рассуждений согласен, но Вы повторяете принципиальную ошибку многих авторов, пишущих на эту тему – ошибка в назначении ТЗ. Вы пишите:
Кому будет полезна статья:
представителям заказчиков …;
тендерным специалистам со стороны как заказчика …;
заинтересованным лицам команды разработки (аккаунтам, ПМ, аналитикам).
И при этом забываете, что сущность ТЗ заключается в самом названии этого документа –задание кому? Заказчику? Абсурд! ТЗ на АС – это задание программистам, в широком понимании. Т.е. это задание ИТ-специалистам, которые непосредственно будут выполнять разработку системы. ТЗ – это настольная книга для программиста, и прежде чем что-то накодить, он должен посмотреть в ТЗ.
Соответственно этому и писать ТЗ надо, как задание программисту. Тогда становится ясно, что из всей проектной документации ТЗ присутствует ВСЕГДА! Печати и подписи начальников не всегда обязательны, но нормальный программист ВСЕГДА хоть на полстраницы, сделает его для себя, прежде чем что-то закодировать.
А ГОСТ 34 до сих пор живой, потому что в нем заложен универсальный алгоритм мышления человека. Что бы вы не делали, хоть табуретку, хоть полет на Марс, вы будете мыслить по этому алгоритму. Все прочие методологии используют этот же алгоритм и отличаются в мелочах.
Вот только системным и логическим мышлением не каждый специалист обладает. Плюс лень-матушка: как не хочется тратить свое драгоценное время на писанину. Да и литературные способности не помешали бы. Поэтому за четверть века своей работы я видел единицы хороших ТЗ. Приходится самому писать или переписывать. Но оно того стоит!
Добрый день. Мы полностью согласны с тем, что документация должна быть полезна для команды разработки. Однако, её объем и степень детализации определяются особенностями проекта. Говоря подробнее о роли клиента, мы исходим из того, что требование к соблюдению ГОСТ – это требование именно клиента. При этом команда разработки зачастую ведет документацию своими методами. Например, у нас для этого есть база знаний и проверенных практик, основанных в том числе на зарубежных стандартах и отечественных ГОСТах. С их помощью аналитики могут наиболее точно доводить требования до команды с учётом применяемой методологии разработки и специфики проекта.
ГОСТы 34-й серии по сути задают стандартную структуру проектной информации и определённую базовую терминологию.
Их использование оказывается полезным при наличии на стороне заказчика и исполнителя специалистов, знакомых с такой структурой и такой терминологией - им оказывается проще понимать друг друга, проще искать нужную информацию (либо обнаруживать факт её отсутствия в документации проекта), проще выстраивать процесс работы над контентом.
Это как стандарт оформления кода и типовая организация модулей - позволяет не спорить о мелочах и не терять важное за частным.
Понятно, что есть альтернативы - более "легкие" шаблоны и наборы правил, придуманные в принципе с той же целью. Или вполне аналогичные (но отличающиеся реализацией) инженерные стандарты западного происхождения.
В итоге важно, чтобы стандарт был выбран и более-менее всеми соблюдался - а какой именно, вопрос сильно религиозный.
Всегда ли нужен ГОСТ при разработке крупных проектов?