Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Freez от 18 Октября 2014, 16:38:16
-
Приветствую всех.
Возникла необходимость написать ТЗ в соответствии с ГОСТ 34. Нужны ваши советы и рекомендации.
При написании возник следующий вопрос.
В ГОСТе 34.602 есть такой пункт: "Требования к функциям (задачам), выполняемым системой", где нужно указать
по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации.
В интернете нашел несколько рабочих примеров (довольно известных it компаний), в которых пишут эти требования вот
таким образом (к одной из подсистем):
- Внесение кредитной оценки УП
- Создание дисциплин
- Фиксация окончания формирования УП
то есть никакой конкретики - кем внесение? зачем? какие предусоловия? и тд.
Не очень понимаю, в чем смысл такого описания этого пункта в ТЗ? Если мы, допустим, имеем список подробно описанных ФТ, где каждое требование пронумеровано, то там понятно как потом проверить, как сослаться на это требование. А что делать с таким описанием и как оно вообще может нам помочь?
По сути краткое описание подсистем мы уже сделали в том же ТЗ немного выше, пункт 4.1.1 "Требования к структуре и функционированию системы".
До этого момента предполагал, что в пункте "Требования к функциям (задачам), выполняемым системой" нужно приводить четкие и конкретно сформулированные ФТ по каждой из подсистем. В таком случае только один этот пункт ТЗ может потянуть на 100 с лишним страниц (это нормально?).
Разъясните, пожалуйста, ситуацию с этим пунктом ТЗ, кто знает.
Заранее спасибо.
-
До этого момента предполагал, что в пункте "Требования к функциям (задачам), выполняемым системой" нужно приводить четкие и конкретно сформулированные ФТ по каждой из подсистем. В таком случае только один этот пункт ТЗ может потянуть на 100 с лишним страниц (это нормально?).
Так и есть, а что Вас удивляет?
-
В первую очередь удивляют те примеры ТЗ, которые мне удалось найти - в них требования в этом разделе указаны буквально в двух словах.
То есть раздел "Требования к функциям (задачам), выполняемым системой" - должен представлять собой полное описание всех функциональных требований в развернутой форме со всеми входными и выходными параметрами?
А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".
-
В первую очередь удивляют те примеры ТЗ, которые мне удалось найти - в них требования в этом разделе указаны буквально в двух словах.
Ничего не могу ответить на это. Кроме догадок у меня ничего нет.
То есть раздел "Требования к функциям (задачам), выполняемым системой" - должен представлять собой полное описание всех функциональных требований в развернутой форме со всеми входными и выходными параметрами?
Техническое задание должно содержать достаточное количество фактической информации для решения поставленной задачи.
А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".
В ТП должно быть описано проектное решение по автоматизируемым функциям. Не самый лучший пример, но (http://rugost.com/index.php?option=com_content&view=article&id=135:q-q13&catid=26&Itemid=63)
-
Несколько гипотез:
* http://blog.shumoos.com/archives/288
* У Влада Балина (http://gaperton.livejournal.com/) была интересная статья о работе по ГОСТ
* Кроме ТЗ можно писать кучу Частных ТЗ. Каждое на сотни страниц.
-
В интернете нашел несколько рабочих примеров (довольно известных it компаний), в которых пишут эти требования вот
таким образом (к одной из подсистем):
- Внесение кредитной оценки УП
- Создание дисциплин
- Фиксация окончания формирования УП
то есть никакой конкретики - кем внесение? зачем? какие предусоловия? и тд.
Не очень понимаю, в чем смысл такого описания этого пункта в ТЗ?
Это нормально. Заказчик хочет "создание дисциплин". Кем, зачем и предусловия вы проработаете в техническом проекте. И согласуете с заказчиком - все ли правильно понято и спроектировано. А потом, к сдаче, сформулируете конкретные кейсы испытаний, которые заказчик утвердит, как полностью и достоверно демонстрирующие, что требование "создание дисциплин" реализовано именно так, как он хотел.
Если мы, допустим, имеем список подробно описанных ФТ, где каждое требование пронумеровано, то там понятно как потом проверить, как сослаться на это требование. А что делать с таким описанием и как оно вообще может нам помочь?
Цель ТЗ - обозначить, что делаем. Как делаем - предмет эскизного (если у вас он предусмотрен) и технического проектов.
А что делать с таким описанием...?
Пронумеровать? :)
По сути краткое описание подсистем мы уже сделали в том же ТЗ немного выше, пункт 4.1.1 "Требования к структуре и функционированию системы".
Там было про то, из каких компонентов состоит система, для чего они нужны, как связаны между собой и с окружающим миром. Функционал каждого из компонентов и системы в целом - это все-таки раздел 4.2.
До этого момента предполагал, что в пункте "Требования к функциям (задачам), выполняемым системой" нужно приводить четкие и конкретно сформулированные ФТ по каждой из подсистем.
Да. Чем требование "Система должна позволять ... создание дисциплин" Нечеткое и неконкретное?
Уровень абстракции выбирается исходя из сложившихся реалий и преследуемых целей.
В таком случае только один этот пункт ТЗ может потянуть на 100 с лишним страниц (это нормально?).
Да.
То есть раздел "Требования к функциям (задачам), выполняемым системой" - должен представлять собой полное описание всех функциональных требований в развернутой форме со всеми входными и выходными параметрами?
Ну вот что значит "полное"? Например, "Перечень входных сигналов и данных" или "Перечень выходных сигналов (документов)" по ГОСТ 34 - это документы технического проекта (даже не эскизного).
Вообще, для лучшего понимания - что, где и как предусмотрено в ГОСТе, было бы полезно прочитать 34.201, 34.601 и РД 50-34.698-90.
ГОСТ 34 - цельная система. ТЗ, как одна из ее частей, очень сильно связана со всем остальным. Понять, почему ТЗ именно такое, без понимания его места и роли в общей картине (т.е. глядя на мир только "изнутри" ТЗ) достаточно проблематично.
А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".
Описывать там то, что вы наавтоматизировали.
-
В первую очередь удивляют те примеры ТЗ, которые мне удалось найти - в них требования в этом разделе указаны буквально в двух словах.
И да... Не относитесь к этим примерам слишком серьезно. Я пока не видел в интернетах примера ТЗ по 34 ГОСТ, на который можно было бы равняться. Их и в жизни-то крайне мало. В одном хорошо одно, в другом - другое. Поскольку каждое "живое" ТЗ - продукт жесткого компромисса между сроками, функционалом, стоимостью и внутренней согласованностью (безбаговости самого ТЗ, если угодно).
-
Нашел: http://gaperton.livejournal.com/49867.html
Работать по ГОСТ-у сложно. Очень мало кто способен составить план работы. Под планом понимается "декомпозия конечной цели на промежуточные результавы в терминах критериев завершенности." Не может содержать активностей, исполнителей, трудоемкости и прочего.
-
Нашел: http://gaperton.livejournal.com/49867.html
У автора довольно своеобразная трактовка. Как минимум, огребет большие неприятности при мало-мальски квалифицированной проверке заказчика (в смысле, не только заказчиком, но и когда заказчика будут проверять вышестоящие). Максимум - будет послан осторожным (читай, опытным) заказчиком еще на подходах.
Масса спорных утверждений. Некоторые положения на практике с серьезным заказчиком нереализуемы. Например: "Единственная "задача" - это ТЗ. Правильный ответ - выделять частные, более мелкие ТЗ, на более мелкие работы. И так - до самого мелкого уровня.". Проблема в том, что ТЗ - один из основных документов во взаимоотношениях заказчика и исполнителя. И если писать ЧТЗ на каждый чих, первые лица и исполнителя, и заказчика (особенно заказчика) быстро утомятся утверждать все чихи мелочь. И деликатно выскажут свое отношение плодовитому писателю.
Ну, либо автор пишет о чем-то своем, а не применении ГОСТ в разработке для заказчика.
Работать по ГОСТ-у сложно.
Дело привычки, полагаю. Мне сложно работать не по ГОСТу - нет ни понятных и принятых обеим сторонам правил игры, зад прикрыть нечем (в т.ч. заказчику), зато креатива (с обеих сторон) - хоть отбавляй.
Очень мало кто способен составить план работы. Под планом понимается "декомпозия конечной цели на промежуточные результавы в терминах критериев завершенности." Не может содержать активностей, исполнителей, трудоемкости и прочего.
Не совсем понял, какое отношение этот текст имеет, скажем, к 34 ГОСТ?
Ну и "план работы" без исполнителей, трудоемкости и активностей - тот еще план.
-
Спасибо всем за ответы.
Возник новый вопрос - кто может поделиться информацией как правильно отформатировать документ ТЗ по ГОСТ 34?
Название шрифта, размер, поля, интервал и т.д.
В ГОСТ 2 такую информацию не нашел :(
-
Добрый день!
В рамках выполнения работ по ГК мы, как правило, по согласованию с проектным офисом и тех.политикой (правда, не всегда такие организационные единицы есть :) ) готовили, согласовывали, утверждали и тиражировали на все проектные команды документ типа "Правила оформления отчетной документации".
Структуру данного документа, думаю, приводить не обязательно. Но в качестве использованных источников для нас всегда было следующее:
1. ГОСТ 2.105-95. Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к текстовым документам
2. ГОСТ 7.1 – 2003. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Библиографическое описание. Общие требования и правила составления
3. ГОСТ 7.21-2001. Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления
4. ГОСТ 19.105-78. Единая система программной документации. Общие требования к программным документам
5. И некоторые другие типа ОК 005 и прочие ГОСТ, например, по видам и комплектности документов.
Само оформление складывалось из четкого соответствия требованиям к:
1. Лист утверждения
2. Титульный лист
3. Список исполнителей
4. Аннотация
5. Содержание
...
8. Основная часть
8.1. Оформление раздела
8.2. Оформление подраздела
...
8.6. Оформление рисунков
8.7. Оформление таблиц
И т.д.
Сами требования к оформлению, допустим, основного текста отчетных документов, описывали следующим образом:
"Абзацы должны быть оформлены следующим образом:
- шрифт: Times New Roman, 12 пт.;
- первая строка: отступ 1,27 см;
- междустрочный интервал: 1,5 строки;
- выравнивание: по ширине;
- без переноса в словах."
Разумеется, в соответствии с выше изложенным фрагментом требований вся отчетная документация по всем проектам и оформлялась. Для упрощения процедуры подготовки документов также были разработаны и тиражированы на все команды шаблоны документов с уже интегрированными в них стилями.
Конечно, здесь можно много спорить относительно использования различных государственных стандартов смежных по отношению к 34-ой серии. Однако в нашем случае практика показала, что отказ в передаче отчетного документа Исполнителя на тех.политику Заказчика по формальным признакам ГОСТ после предварительного рецензирования методологами побуждает проектные команды использовать положения выше указанных Правил для сдачи этапа / проекта в целом.
-
В рамках выполнения работ по ГК мы, как правило, по согласованию с проектным офисом и тех.политикой (правда, не всегда такие организационные единицы есть :) ) готовили, согласовывали, утверждали и тиражировали на все проектные команды документ типа "Правила оформления отчетной документации".
Вот если бы вы могли поделиться здесь этим документом - было бы интересно.
-
"Абзацы должны быть оформлены следующим образом:
- шрифт: Times New Roman, 12 пт.;
Надо же, до чего дошёл прогресс - до пропорциональных шрифтов. Мы, помнится, первые официальные документы на компьютере набирали строго курьером 13пт, чтобы на печатную машинку было похоже.
-
Приветствую всех еще раз!
Чтобы не плодить схожие темы на форуме, продолжу эту тему (тем более что вопрос все про тот же ГОСТ 34).
Собственно мой вопрос: как грамотно и корректно описать методику проверки требований к видам обеспечения - математическому, информационному и т.д. Нужно ли вообще описывать это в ПМИ (ведь требования в ТЗ к ним указаны, значит как-то надо понять, что требования выполнены).
К примеру - вот такое требование:
Система должна позволять расширять возможности информационного обмена путем интеграции новых внешних систем.
Как его проверять? Проделать интеграцию с новой внешней системой? Но на такой тест может понадобиться отдельный релиз системы и отдельное ТЗ.
Или вот такое требование:
Структура данных и способ организации должны позволять наращивать объем накопленных данных в системе, а также вносить изменения в систему вслучае изменения законодательства...
Как проверить - начать вносить изменения прямо в момент сдачи системы на глазах у заказчика? :) Но это тоже может оказаться трудоемким процессом.
В поиске полезных примеров документации случайно наткнулся на вот такой ресурс - Информационное общество Минэкономразвития. http://aisup.economy.gov.ru/pubportal/ Оказывается, там на суд общественности выкладывают документацию к различным продуктам, сделанным по заказу министерства.
Вот несколько занимательных примеров, из ПМИ в одном из документов оттуда:
Действия пользователя (Д): Нажать кнопку «Регистрация».
Ожидаемый результат (Р): Пользователь пытается зарегистрироваться.
(Д) Нажать «Войти».
(Р) Пользователю отображается следующие элементы экрана: поля ввода учетной записи (адрес электронной почты e-mail и пароль); кнопка «Вход»; форма для восстановления пароля.
А вот так предлагают тестировать быстродействие:
(Д) Последовательно зайти на все информационные страницы
(Р) Загрузка любой страницы, занимает не более 5 секунд.
Может ли кто-нибудь поделиться примером про тестирование требований к видам обеспечения, дать ссылку на книгу или еще какой-нибудь источник? Облазил весь интерент, грамотных примеров так и не нашел :(
-
Собственно мой вопрос: как грамотно и корректно описать методику проверки требований к видам обеспечения - математическому, информационному и т.д. Нужно ли вообще описывать это в ПМИ (ведь требования в ТЗ к ним указаны, значит как-то надо понять, что требования выполнены).
К примеру - вот такое требование:
Система должна позволять расширять возможности информационного обмена путем интеграции новых внешних систем.
Как его проверять? Проделать интеграцию с новой внешней системой? Но на такой тест может понадобиться отдельный релиз системы и отдельное ТЗ.
Или вот такое требование:
Структура данных и способ организации должны позволять наращивать объем накопленных данных в системе, а также вносить изменения в систему в случае изменения законодательства...
Как проверить - начать вносить изменения прямо в момент сдачи системы на глазах у заказчика? :) Но это тоже может оказаться трудоемким процессом.
Над этими требованиями ещё работать и работать. В таком виде их проверить, конечно, невозможно.
-
Собственно мой вопрос: как грамотно и корректно описать методику проверки требований к видам обеспечения - математическому, информационному и т.д. Нужно ли вообще описывать это в ПМИ (ведь требования в ТЗ к ним указаны, значит как-то надо понять, что требования выполнены).
Как? Грамотно. Если в "математическом обеспечении" ТЗ велено применять для синтаксического анализа алгоритм 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).
-
Я прямо вижу, как в этом топике на глазах вырастает готовый раздел "FAQ по ГОСТ 34" для сайта.
-
Я прямо вижу, как в этом топике на глазах вырастает готовый раздел "FAQ по ГОСТ 34" для сайта.
Будут появляться "Q", может и наберется достаточно материала. :)
Хотелось бы конечно, чтобы не только я отвечал. Пусть у меня имеется богатый опыт и были хорошие наставники, но это не значит, что я везде прав или что не разжился в процессе жизнедеятельности совершенно искаженным пониманием каких-то нюансов.
-
Предлагаю в этой теме общими усилиями сформировать список вопросов по ГОСТ 34, а потом сделать из них FAQ.
У меня получился такой список. Критикуйте, предлагайте свои вопросы и более правильные формулировки.
Является ли ГОСТ 34 методологией разработки?
Когда следует использовать ГОСТ 34?
Когда не следует использовать ГОСТ 34?
В каких случаях ГОСТ 34 обязателен к исполнению?
На каких этапах жизненного цикла разрабатываются требования по ГОСТ 34?
В каких документах по ГОСТ 34 содержатся требования?
Какие документы ГОСТ 34 являются самыми важными?
Какие документы ГОСТ 34 являются самыми полезными?
Что нужно изучить, прежде чем браться за разработку ТЗ по ГОСТ 34?
Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?
Обязательно ли заполнять все разделы ТЗ, перечисленные в ГОСТ 34?
Какие ошибки чаще всего совершают аналитики, использующие ГОСТ 34?
-
Кто и зачем разработал ГОСТ 34?
Представители каких профессий должны создавать отдельные документы ГОСТ 34?
В чём особенности и преимущества ГОСТ 34 в сравнении с международными стандартами и вендорскими процессными библиотеками?
В чём устарел ГОСТ 34?
Почему не появилось нового поколения российских стандартов, заменяющих ГОСТ 34?
-
Спасибо всем, что помогаете разобраться в таком нелёгком деле, как работа по ГОСТ34 :)
Добавлю от себя список некоторых вопросов, с которыми сталкивался в процессе:
- Возможно ли в рамках разработки документации часть написать по ГОСТ34, а часть допустим по 19? Т.е. ТЗ пишем по 34, а руководство оператора по 19?
- Возможно ли оставить пакет документов без единого ТЗ, сразу оформить несколько ЧТЗ на каждую из подсистем?
- Как правильно отформатировать документ(ы)? Шрифт, поля, интервалы и тд.
- Какие из документов, описанных в 34201 являются СТРОГО обязательными?
- Насколько подробно необходимо описывать требования именно в ТЗ? И как понять, что необходимый уровень точности уже достигнут. (Здесь будем исходить из того, что подробные ФТ пишутся все-таки на стадии ТП, а в ТЗ пишутся требования верхнего уровня).
Могу добавить еще вопросы относительно ПМИ, если это пойдет в эту же тему.
-
Я бы добавил, то о чем говорил уважаемый greesha в соседнем посте.
Сравнительный глоссарий ГОСТ 34 и других стандартов методологий (Не только с Вигерсом но и с другими) по разработке ПО/ИС
-
Предлагаю в этой теме общими усилиями сформировать список вопросов по ГОСТ 34, а потом сделать из них FAQ.
Перечень вопросов для FAQ - это хорошо. А как видишь работу с ответами? (пока предложено только формировать перечень вопросов).
-
Спасибо всем, что помогаете разобраться в таком нелёгком деле, как работа по ГОСТ34 :)
В продолжение помощи...
- Возможно ли в рамках разработки документации часть написать по ГОСТ34, а часть допустим по 19? Т.е. ТЗ пишем по 34, а руководство оператора по 19?
Да. Но такое бывает очень редко (как и использование 19-го вообще).
- Возможно ли оставить пакет документов без единого ТЗ, сразу оформить несколько ЧТЗ на каждую из подсистем?
Не слышал о таком. Нормальный подход в таком случае - сделать для всех ЧТЗ одно ТЗ-папку, в котором будут обозначены какие-то общие вопросы, а в остальном - ссылки на ЧТЗ.
- Как правильно отформатировать документ(ы)? Шрифт, поля, интервалы и тд.
Нет единого мнения. ГОСТ 2.105, который как раз об этом, разрабатывался для печатных машинок и "чертежного шрифта", которым красиво писали на ватмане от руки. Сейчас никаких проблем не вызывают ТЗ, оформленные 14 или 12 размером с полуторным интервалом. Шрифт - в принципе, что удобно. Чаще всего попадался Times New Roman. Вообще, ГОСТ 2.105 иногда оказывается довольно важным при согласовании ТЗ с заказчиком. При наличии у последнего свирепого нормоконтроля, вернуть документ могут просто по совокупности нарушений правил оформления (точки не там, списки нумерованные, а не маркированные, абзацные отступы не те и т.п.). К счастью, такое встречается редко.
Есть смысл поискать на форумах техписов: наверняка ГОСТовые шаблоны стилей для Ворда (а то и рыбы ТЗ) водятся в изобилии.
- Какие из документов, описанных в 34201 являются СТРОГО обязательными?
Думаю, это не очень корректная постановка вопроса. Обязательность диктуется ситуацией. Минимальный набор, который я видел, это ТЗ, Пояснительная записка к техпроекту, руководство пользователя и ПМИ.
- Насколько подробно необходимо описывать требования именно в ТЗ? И как понять, что необходимый уровень точности уже достигнут. (Здесь будем исходить из того, что подробные ФТ пишутся все-таки на стадии ТП, а в ТЗ пишутся требования верхнего уровня).
Это зависит. Невысокая детализация применяется тогда, когда:
- есть налаженные отношения с заказчиком;
- нет особо времени детализировать;
- есть сомнения в корректности и актуальности частных требований (когда кроме нужного придется делать еще и то, что поспешили навалить в ТЗ). Надо отметить, что в ГОСТ 34.602 (ТЗ) предусмотрен механизм внесения изменений, но на практике он применяется достаточно редко. Хлопотно это, да и чревато повышенным вниманием ревизоров.
Детализируют по максимуму тогда, когда:
- есть высокие риски того, что заказчик постарается "нагнуть" исполнителя на куда большее, чем оговаривалось изначально (пользуясь размытыми формулировками).
- есть возможность тщательно разобраться и "от души" разработать требования;
- вероятность значительного изменения требований невысокая (относительно небольшие сроки, высокая стабильность предметной области).
На практике народ лавирует между этими полюсами по обстоятельствам.
Могу добавить еще вопросы относительно ПМИ, если это пойдет в эту же тему.
Если составлять ЧАВО по ГОСТ 34 вообще, то будет в тему. На мой взгляд, связка ТЗ+ПМИ имеет наибольший "вес" при работе по ГОСТ 34.
-
Перечень вопросов для FAQ - это хорошо. А как видишь работу с ответами? (пока предложено только формировать перечень вопросов).
Попросим ответить экспертов. Одного мы уже знаем. :)
-
Попросим ответить экспертов. Одного мы уже знаем. :)
А... Ну, как соберетесь, меня растолкайте. Я тоже хочу экспертов послушать. А то и сам что скажу. :)
-
Еще вопросики:
* Можно ли use-case запихать в ГОСТ 34 и куда?
* Чем отличается ГОСТ 34 от 19?
-
Еще вопросики:
* Можно ли use-case запихать в ГОСТ 34 и куда?
В программу и методику испытаний отлично запихивается. Но это уже стадия рабочего проектирования (для IT - написания кода). Из документов технического проекта для use-case наверно подойдёт "Описание автоматизируемых функций".
* Чем отличается ГОСТ 34 от 19?
ГОСТ 19 - стандарт для разработки программного обеспечения. Результат разработки по 19 ГОСТу - код и документация к нему.
ГОСТ 34 - для разработки автоматизированных систем. Автоматизированная система кроме программного обеспечения, включает в себя техническое обеспечение и персонал. Результат разработки по 34 ГОСТу - автоматизация определенного рабочего процесса. Т. е. ПО не только написано и задокументировано, но и установлено, при необходимости закуплено необходимое оборудование, протянуты сети, пользователи обучены, распределены роли их работы в системе, написаны инструкции для каждой роли и т.д.
-
В программу и методику испытаний отлично запихивается. Но это уже стадия рабочего проектирования (для IT - написания кода). Из документов технического проекта для use-case наверно подойдёт "Описание автоматизируемых функций".
Согласен. ПМИ - единственное место, где они смотрятся органично. Но увы, уже не относятся к требованиям.
Кроме упомянутого документа, в Техпроекте их можно, совершив определенное насилие над здравым смыслом, разместить во втором разделе Пояснительной записки к техпроекту ("Описание процесса деятельности"). Хоть вместе с диаграммой ВИ. Разумеется, сценарии должны быть для этого достаточно высокоуровневыми.
Use-case в качестве носителей требований родом из совсем другого подхода к разработке. С традиционной точки зрения они представляют из себя не требования, а полуфабрикат для их подготовки. Полуфабрикаты включать в ТЗ и техпроект не принято (а вот в "Отчет об обследовании", наверное, можно). По этой причине я бы рекомендовал не включать сценарии в тело документов ТЗ или Техпроекта, а оформлять их приложениями. В смысле, если очень-очень надо их хоть куда-то приткнуть, а возможности сформулировать на их основе нормальные требования нет.
-
ГОСТ 19 - стандарт для разработки программного обеспечения. Результат разработки по 19 ГОСТу - код и документация к нему.
ГОСТ 34 - для разработки автоматизированных систем. Автоматизированная система кроме программного обеспечения, включает в себя техническое обеспечение и персонал. Результат разработки по 34 ГОСТу - автоматизация определенного рабочего процесса.
1. Правильно ли я понимаю, что для проектов внедрения АС, ту часть которая про ПО можно описать, например по 19 ГОСТу (ну или формате функциональной спецификации), а все что относится к его внедрению как системы по 34?
Если это так, то возможно ли обосновать такой подход, опираясь на сам ГОСТ?
2. В общепринятой терминологии, в том числе при написании проектных документов, принято любой программный продукт называть системой, тогда получается, что даже если ты продаешь заказчику ПО без внедрения, но в договоре обозвали это системой, то формально необходимо описывать ее с применением ГОСТ 34 (Если, в том же договоре, допустим будет прописано, что вся сопровождающая документация должна быть подготовлена на основе соответствующих ГОСТов)?
-
1. Правильно ли я понимаю, что для проектов внедрения АС, ту часть которая про ПО можно описать, например по 19 ГОСТу (ну или формате функциональной спецификации), а все что относится к его внедрению как системы по 34?
Если это так, то возможно ли обосновать такой подход, опираясь на сам ГОСТ?
Можно, наверно, написать ЧТЗ на разработку ПО для системы и в нем оговорить разработку по 19 ГОСТу.
2. В общепринятой терминологии, в том числе при написании проектных документов, принято любой программный продукт называть системой, тогда получается, что даже если ты продаешь заказчику ПО без внедрения, но в договоре обозвали это системой, то формально необходимо описывать ее с применением ГОСТ 34 (Если, в том же договоре, допустим будет прописано, что вся сопровождающая документация должна быть подготовлена на основе соответствующих ГОСТов)?
Что, как и насколько строго нужно документировать, сильно зависит от заказчика, и согласовывать это нужно с ним (и по возможности фиксировать в договоре и ТЗ всё, что согласовали). Я никогда не встречалась с формулировкой "на основе соответствующих ГОСТов" (правда, у меня и опыт не очень большой). Обычно указываются конкретные номера ГОСТов, которых нужно придерживаться, часто и названия документов из указанных гостов.
-
1. Правильно ли я понимаю, что для проектов внедрения АС, ту часть которая про ПО можно описать, например по 19 ГОСТу (ну или формате функциональной спецификации), а все что относится к его внедрению как системы по 34?
Если это так, то возможно ли обосновать такой подход, опираясь на сам ГОСТ?
В норме так не делают. И обосновать такой подход нечем (по крайней мере, с точки зрения ГОСТ, а не развитого воображения). Теоретически, ваши отношения с заказчиком - это дело ваше, в их рамках может происходить все, что угодно (19, 34, 24, спеки и презентации). Но если вам по какой-то причине нужно делать "правильно" (для развития собственных компетенций или при наличии "внешних угроз"), то делать коктейли не следует. В этом случае лучше как раз максимально придерживаться одного выбранного семейства стандартов.
2. В общепринятой терминологии, в том числе при написании проектных документов, принято любой программный продукт называть системой,
Не совсем так. В общепринятой практике принято давать определение тому, что в данном конкретном документе называется "Системой" (именно с большой буквы). Бывает так, что в одном комплекте документации от документа к документу "системами" зовут совершенно разные вещи. Это широко распространенная практика. Упрощает использование рыб-шаблонов, и даже выглядит эстетично. Но чревато проблемами.
А чтобы не было проблем, надо поступать дешево, надежно и практично: называть вещи своими именами. Например, везде по тексту (включая заголовки разделов), употреблять не "Система", а "АИС ТПРВД ГРК". Как минимум, поможет избежать накладок при компоновке каких-то сводных документов.
тогда получается, что даже если ты продаешь заказчику ПО без внедрения, но в договоре обозвали это системой, то формально необходимо описывать ее с применением ГОСТ 34 (Если, в том же договоре, допустим будет прописано, что вся сопровождающая документация должна быть подготовлена на основе соответствующих ГОСТов)?
Нет, не получается. "Система" - это просто слово-заменитель, оно ни на что не влияет. Важно то, о каких "соответствующих ГОСТах" вы договоритесь с заказчиком, если прямо в контракте они у вас не прописаны.
-
Леонид. Спасибо за подробные разъяснения моих "заблуждений" :)
-
Леонид. Спасибо за подробные разъяснения моих "заблуждений" :)
Рад стараться! :)