Собственно мой вопрос: как грамотно и корректно описать методику проверки требований к видам обеспечения - математическому, информационному и т.д. Нужно ли вообще описывать это в ПМИ (ведь требования в ТЗ к ним указаны, значит как-то надо понять, что требования выполнены).

Как? Грамотно. Если в "математическом обеспечении" ТЗ велено применять для синтаксического анализа алгоритм ABC, значит, нужно показать, что он и применяется (в качестве дополнительных аргументов можно даже на свой техпроект сослаться, но именно в качестве дополнительных). Если в требованиях к информационному обеспечению сказано, что хранилище данных должно быть поделено на  "быстрое" и "большое", значит, надо продемонстрировать оба. Или если в том же разделе сказано, что система должна уметь наполнять свои справочники данными какого-то публичного ресурса - значит, надо показать, как она это делает.
В общем случае, уровень потребной "грамотности" определяется спецификой заказчика, ожиданиями на предмет дотошности комиссии и наличием собственных ресурсов.

Нужно ли? Нужно.

Система должна позволять расширять возможности информационного обмена путем  интеграции новых внешних систем.
Как его проверять? Проделать интеграцию с новой внешней системой? Но на такой тест может понадобиться отдельный релиз системы и отдельное ТЗ.

Продемонстрировать наличие в системе внешнего интерфейса. В идеальном случае - предусмотренного  в системе как раз для целей интеграции. Но поскольку такое встречается редко, то можно импровизировать. Можно "предъявить" шину, парсер XML или любого другого формата (вплоть до читалки почты), кастомизируемые веб-сервисы - в общем все, что можно применить для связки сдаваемой системы с чем-то снаружи.

Или вот такое требование:
Структура данных и способ организации должны позволять наращивать объем накопленных данных в системе, а также вносить изменения в систему вслучае изменения законодательства...
Как проверить - начать вносить изменения прямо в момент сдачи системы на глазах у заказчика? Но это тоже может оказаться трудоемким процессом.

1. Наращивание объема. Демонстрируем, что данными в системе манипулирует специально обученная СУБД. Данные организованы в порядке, принятой в этой СУБД. Далее - предъявляем выдержку из документации изготовителя СУБД на предмет того, как она замечательно масштабируется по части объемов.

2. Внесение изменений.
2.а. На испытаниях берем любой инструмент для работы со структурами данных системы, открываем произвольную таблицу, втыкаем туда новое поле с каким-нибудь говорящим предметным названием, сохраняем, закрываем таблицу. Открываем заново - вуаля, поле сохранено, структура данных изменена. Для того, чтобы окончательно "добить" комиссию, в случае наличия в системе простых средств визуализации данных, можно добавить новое поле на экранную форму (к остальным) и продемонстрировать, как легко и непринужденно  система реагирует на изменения.
2.b. Способ для ленивых. Демонстрируем наличие в системе инструмента для работы со структурами данных, показываем документацию изготовителя инструмента, в которой сказано, что инструмент как раз и предназначен для изменения данных. И что он поддерживает с применяемую в системе СУБД (или стандарт, который использует СУБД).

Над этими требованиями ещё работать и работать. В таком виде их проверить, конечно, невозможно.

В ТЗ у госов каждое второе требование примерно такое. Когда от недоработки, но чаще потому, что так и задумано.

В ТЗ у госов каждое второе требование примерно такое. Когда от недоработки, но чаще потому, что так и задумано.

Обычно так задумано. "ТЗ для аудиторской проверки, а работать будем по нормальным документам."
Хотя по ГОСТ-ам вполне можно  работать. Если есть желание, и главное, знания. Знаний обычно нет. В результате изобретается "стыд&срам"

И еще немного добавлю. 34.602, это не требования к ПО!!!! http://blog.shumoos.com/archives/288

"ТЗ для аудиторской проверки, а работать будем по нормальным документам."

Одна из причин, не самая распространенная (а в части после запятой - так и вообще редкость). Чаще просто некогда прорабатывать детально. В итоге доля того, чему место в ТЗ, уходит в техпроект.

34.602, это не требования к ПО!!!!

Он включает требования к ПО. Причем, с практической точки зрения более внятен и конкретен, чем ветеран-работяга 19-й.
А учитывая то, что по 19-му уже мало кто работает (в смысле, мало кто из заказчиков требует), 34-й используют и для разработки заказного софта. Хотя предназначен он для большего, разумеется. С другой стороны, именно разработку софта в чистом виде я уж и не помню, когда запрашивали. Обычно работы идут в комплексе - разработка, пусконаладка, обучение, испытания. Тут 34й более, чем уместен.

И еще немного добавлю. 34.602, это не требования к ПО!!!! http://blog.shumoos.com/archives/288

И про статью. Там высказаны достаточно любопытные мысли человека, который пытался разобраться в чем-то, в чем он не очень ориентируется. Если коллегам интересно, могу разобрать ее "по косточкам".

Интересно!!!

И про статью. Там высказаны достаточно любопытные мысли человека, который пытался разобраться в чем-то, в чем он не очень ориентируется. Если коллегам интересно, могу разобрать ее "по косточкам".

Любопытно послушать Ваши доводы )

И про статью. Там высказаны достаточно любопытные мысли человека, который пытался разобраться в чем-то, в чем он не очень ориентируется. Если коллегам интересно, могу разобрать ее "по косточкам".

Я знаю, что  я в этом не слишком силен. Я просто пытался разобраться. Один черт, материалов очень мало.

Так что, я готов, оппонент. Я действительно хочу понять, где не прав.

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

Принято?

PS. Леонид, я вас уважаю за ваши посты. Сильно, грамотно. Видно, что профи.
Поэтому мне действительно хочется вступить с вами в дискуссию.

Принято?

Коллега, у меня и в мыслях что-то резко громить и самоутверждаться. Я даже специально сказал, "человека, который" видя авторство статьи. В том смысле, что с момента написания статьи прошло некоторое время, и в настоящий момент Вы можете разбираться в предмете лучше меня.
Тем более, что для "гипотезы на обсуждение" содержимое статьи очень и очень близко к реалиям.

Итак, начнем.

Начну, пожалуй, со следующего утверждения.

ТЗ в 34 серии ГОСТ (а именно, 34.602) - это документ не для программистов.

Программисты должны работать по другому (другим) документам, а именно - техническому проекту ("спеки", в т.ч. SRS, по ГОСТ следует относить к техническому проекту). Это недопонимание - одна из основных причин появления мифов о том, что ТЗ по ГОСТ (а потому - и сам ГОСТ) в реальной разработке не работает, он жуткий, неудобный и т.п. И можно понять - закручивать болт отверткой действительно неудобно.

ГОСТовое ТЗ - это документ, который согласуют ключевые лица проекта и первые лица организаций заказчика и исполнителя. И документ этот должен быть разработан на соответствующем уровне абстракции (понятном подписантам и не перегруженном избыточными деталями). Разумеется, это теория. Практика сильно богаче, но чтобы понимать, как решать практические вопросы, желательно знать, откуда растут ноги.

Ну а теперь непосредственно к статье.

"Так, например, раздел «5) состав и содержание работ по созданию системы» это явно документ планирования, ответственность за который несет руководитель проекта."

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

Но обычно ТЗ рассматривается в первую очередь как документ требований к разрабатываемому ПО.

И в этом кроется большая ошибка. Выше писал, почему.

"Но как только мы примем, что это требования не столько к ПО, сколько  ко всей совокупности изменения процесса, все становится на свои места.
Примечание. Это, знание похоже так осталось в 90-х."

Ну, знание до сих пор живо. Пока еще.
И совершенно верно - 34 серия ГОСТ не про ПО, она про создание систем. ГОСТ покрывает весь процесс, от зарождения сомнений "а не слишком ли много мы делаем руками?" до выведения системы на реальный бизнес-выхлоп и сопровождения ее жизнедеятельности. (ГОСТ 34.601-90)
Причем ПО во всем объеме необходимых телодвижений может занимать очень малую часть.

"Изменения со стороны исполнителя ТЗ, делаются за счет поставляемых этим исполнителем товаров и услуг."

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

В вот теперь небольшой комментарий: исполнитель ТЗ влияет на 6 перечисленных пунктов изменений в первую очередь выполняемыми работами (если речь именно о разработке уникальной системы, а не тиражированном внедрении).

"Если поставляются сервера, то возникают требования по электробезопасности и прочие."

Не совсем. Требования по электробезопасности возникают тогда, когда в разрабатываемой системе появляется то, что нужно обезопасить. То есть, если создание системы предусматривает работы по разработке схем подключения серверов и самому подключению (неважно, сервера ли это заказчика или поставленные исполнителем), то появляются требования по электробезопасности. И они могут не появиться, даже если сервера поставляются исполнителем - например, при условии, что эти сервера включаются в инфраструктурную (т.е. другую, а не разрабатываемую исполнителем) систему заказчика. В этом случае за электробезопасность будет отвечать инфраструктурная система.

"Если поставляются тренинги, то появляются требования к навыкам персонала"

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

"Чего в 34.602 не хватает для более простого его понимания, так это раздела «Реестр поставки». Реестром поставки я пользуюсь несколько последних лет, и это экономит мне кучу нервов."

ТЗ  по 34.602 в первую очередь посвящено работам. Даже раздел требований к техническому обеспечению - он про то, на какой технике должна работать система (а не сколько и когда ее должно появиться). А вот для поставок чего-то готового/тиражируемого в ГОСТ 34.201 предусмотрен документ "Ведомость покупных изделий". Вот туда прекрасно ложатся железки, лицензии и т.п.  (документ технического проекта). В ТЗ же, в упомянутом выше 5-м разделе пишется, что на таком-то этапе будут выполнены поставки чего надо. Кстати, именно 5-й раздел ТЗ предлагаю рассматривать в качестве "реестра поставки" (если я правильно понимаю его смысл: документ, в котором перечислено все, что заказчик получит за свои деньги).

"Забыта услуга «Инсталляция ПО»"
"Забыта услуга «Миграция данных»"

Да, именно что забыты. Только это не вина ГОСТ, а явное неследование его рекомендациям. В частности, есть 7 раздел "Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие", который начинается с "приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ". Он непрозрачно намекает, что если у тебя есть какая-то информация, то будь добр, перед началом работы сделай так, чтобы твоя система могла ее обрабатывать. Это в части миграции.
А про инсталляцию есть общая рекомендация в том же 7-м разделе: "3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;"
Ну, то есть, чтобы твоя система заработала, нужно ее, как минимум, инсталлировать. На объекте автоматизации.


"Ну и, конечно же, достаточно тяжело продавать современную банковскую систему, если в реестре товаров и услуг нет услуги «Обучение персонала»."

Совершенно верно. Подготовка персонала - одна из важных составляющих создания системы, без которой просто "не взлетит". По поводу чего ГОСТ нам рекомендует включать в ТЗ "требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;".

"И не нужно давать написание ТЗ системному аналитику. Ответственность за написание ТЗ лежит на главном конструкторе."

Ну почему же? Вообще, чаще всего ТЗ пишут именно аналитики (бизнес, системные - какой под руку подвернется). Реже - техписы. Не царское это дело (главного конструктора, или же архитектора) марать бумажки. Понятно, что пишут не сами по себе, а на основании материалов различных заинтересованных сторон (как и сказано далее в статье). А вот электриков и юристов именно к написанию ТЗ лучше не привлекать, проверено. Напишут такого - тихий ужас. Так что пусть лучше делятся тем, что надо включить в ТЗ, а куда и как - виднее тому, кто в этом разбирается.

Кроме того, очень желательно, чтобы ТЗ писал тот же человек, который впоследствии будет писать Программу и методику испытаний. Это снизит трудозатраты и облегчит сами испытания.

* * *

По статье - все. Готов отвечать на вопросы.

Уже вне статьи, про ГОСТ 34 вообще.
Нужно понимать, что 34 серия ГОСТ - это целостная система. Вырвав одну из ее частей из контекста (например, ТЗ по 34.602), не всегда очевидно, почему эта часть устроена так, а не иначе (потому, что устроена она так для интеграции с остальными частями).
Разумеется, 34.602 можно применять без оглядки на остальной 34-й (весь технорабочий проект), но при этом желательно четко представлять, от чего в конкретных условиях можно отказаться (поскольку "продолжения" не будет), а что желательно оставить на месте.
И да, 34.602 неплохо подходит даже для проектов разработки ПО. Нужно просто "отсечь все лишнее" (каким образом - писать ли "требования не предъявляются" или просто не упоминать ненужные разделы, зависит от обстоятельств).

ГОСТ 34 вообще штука крайне полезная. Снимает массу вопросов "обоснуйте, почему так" от дотошных заказчиков и, главное, проверяющих. Ну, в тех случаях, когда его применение является добровольным, а не обязательным.

Кстати, о добровольности и обязательности. Со слов знакомого нормоконтролера, который бдит за изменениями в этой области, с недавних пор дело обстоит следующим образом. В случаях, когда применять ГОСТ 34 в работах не требуется, исполнитель волен его не применять. Но если исполнитель сам сказал, что он будет применять ГОСТ, то с этого момента рекомендации ГОСТ по сути становятся обязательными к исполнению (а не так, что вот этот абзац я исполню, следующий проигнорирую, а через один - снова исполню).

Немного про жизненный цикл требования в 34 ГОСТ на примере из первого поста темы.

1. Вот есть у нас в ТЗ такое требование:
"- Внесение кредитной оценки УП"
И больше никакой конкретики. С точки зрения аналитика - тихий ужас, а не требование. Однако, "не все так однозначно". Это всего лишь ТЗ.

2. После согласования ТЗ систему начинают проектировать (Ну, в теории. Чаше сразу бросаются кодить, но мы ж про то, как правильно). В процессе проектирования пишутся спецификации или, если уж совсем следовать ГОСТ, разделы документации технического проекта. В которую должны войти:
- общее описание процесса "внесение кредитной оценки УП" (с разделением на человеческую, машинную, внутрисистемную, внешнюю и т.п. составляющие);
- описание автоматизированных в рамках этого процесса функций (например, "регистрация новой карточки УП", "поиск карточки УП", "внесение кредитной оценки в карточку УП", "форматно-логический контроль кредитной оценки" и т.п.)
- описания интерфейсов (как GUI, так и API);
- описание ролей, которые занимаются этой работой в системе;
- описание информационного обеспечения этого процесса (входные и выходные сообщения, логическая модель данных, физическая модель данных, применяемые справочники и классификаторы);
- и т.д. (см. РД 50-34.698-90).

Важно, что проект системы согласуется с заказчиком. Таким образом заказчик подтверждает, что все это "богатство" действительно раскрывает смысл первоначального требования из ТЗ "- Внесение кредитной оценки УП".

3. Далее (помимо кодинга) разрабатывается рабочая (в т.ч. эксплуатационная) документация, в которой будет рассказано, на каком сервере будет развернут этот функционал, как им пользоваться и т.п. И самое главное - будет разработан документ "Программа и методика испытаний".

В этом документе исполнитель предложит один или несколько методов (кейсов, если угодно) испытания исполнения требования ТЗ "- Внесение кредитной оценки УП". Обращаю внимание - проверяется требование ТЗ, а не решения технического проекта. Поэтому испытаний может быть (и должно, пожалуй) сильно меньше, чем требуется для "покрытия" всего содержимого техпроекта.

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

4. На испытаниях всякое бывает. Раз - и не сработало. В этом случае систему дорабатывают в сроки, определенные комиссией, и представляют на повторные испытания (или уже на финальные, см. ГОСТ 34.603-92).