Классификация требований по ГОСТ 34.602-89

Все ниже написанное – гипотеза, которую я выношу на обсуждение.

Внимание. Уровень сложности статьи  выше среднего (”Осторожно, вдумчивое чтение нижеследующего текста способно нанести непоправимый ущерб рассудку. Вас предупреждали.”).

———————————-

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

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

Примечание. 34-й ГОСТ вполне позволяет прописать в этом разделе 2-х или 4-х недельные итерации при создании ПО. Таким образом вы вполне можете сочетать ГОСТ с XP, RUP, SCRUM и т.д.

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

Это раздел «4) требования к системе». И требования к составу и содержанию  этого раздела способны вогнать в ступор даже закаленного системного аналитика.

Вот несколько выдержек из требований к содержанию и оформлению:

    2.6.1. В подразделе “Требования к системе в целом” указывают:

требования к численности и квалификации персонала системы и режиму его работы;

2.6.1.5. В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п.), по допустимым уровням освещенности, вибрационных и шумовых нагрузок.

2.6.3.7. Для организационного обеспечения приводят требования:

к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию;

к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

к защите от ошибочных действий персонала системы.

Причем здесь спецификация требований к ПО?

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

Примечание. Это, знание похоже так осталось в 90-х.

Изменения процесса могут касаться изменений в:

  • исходном материале;
  • производимом продукте;
  • процессе преобразования материала в продукт;
  • средствах преобразования;
  • нормах деятельности;
  • навыках персонала.

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

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

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

из книги «Записки автоматизатора»:

    … я сам столкнулся с ситуацией, в которой внедренцы забыли, что «нарезка» 80 различных видов рабочих мест потребует определенного времени и определенных ресурсов. …

Забыта услуга «Инсталляция ПО».

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

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

Также очень забавно обслуживать стенды «Образ заказчика» если не была создана служебная утилита «Обрезка БД» при 10ТБ базе. Собственно, и боевой стенд в таких условиях обслуживать довольно тяжело. И лучше бы на самом раннем этапе проекта заложить в реестр поставки утилиту «Компрессия БД». Ну и, конечно же, достаточно тяжело продавать современную банковскую систему, если в реестре товаров и услуг нет услуги «Обучение персонала».

Да что говорить, даже относительно простая система трекинга TrackStudio поставляется с:

  • услугой по настройке;
  • стандартными схемами;
  • руководством пользователя.

Мой совет: в самом начале сделайте первую версию реестра поставки и уже исходя из него, пишите ТЗ. Структурировать реестр удобно по вышеприведенной классификации: «средства преобразования», «навыки персонала», «нормы деятельности». Например, инструкция по обслуживанию (бэкапы, обновления, …) – это раздел «нормы деятельности».

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

PS. В абзаце выше названия проектных ролей используются следующим образом:

  • Системный аналитик: инженер, который пишет спецификацию требований к ПО, используя UML, usecase, ER-диаграммы, и прочие способы записи требований к ПО.
  • Главный конструктор – отличный (выдающийся) инженер, сочетающий инженерную деятельность с административными функциями. Примерно соответствует главврачу в медицине. Как только ГК перестает выполнять инженерные функции, он перестает быть ГК.
  • Руководитель проекта – человек, в том числе, отвечающий за составление плана и календарного графика проекта.
  • Бизнес аналитик: инженер, который предлагает изменение существующих процессов организации. Описание изменений касаются: материала, продукта, норм деятельности и т.д.. Может работать с логическими диаграммами Голдратта, диаграммой «рыбий скелет» и прочими. Но не с UML и ER.

Комментариев: 2

  1. Llanie написал:

    В PS почему-то установлен “font-family: Symbol”, так что описания проектных ролей показываются закорючками. Это специально?
    Usecase греческими буквами так красиво смотрится.

  2. SALar написал:

    Вордпресс такой вордпресс… Давно хочу перейти на статический HTML. Это в разы быстрее и проще.
    поправить то я поправил, но где это еще вылезет…

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.