Разделы ТЗ по ГОСТ 34: нужны статьи на эту тему?

Образец ТЗ по ГОСТ 34 отличается от такого же боевого только содержанием разделов с функциональными требованиями и требованиями к видам обеспечения. В первом приближении.

Таким образом, можно потратить время, которого и так нет, потерять деньги (прикиньте стоимость ч/ч на основе данных статьи, поделив 190 тыс. рублей на 164 часа), подарить миру шаблон ТЗ и, таким образом, потерять потенциальных заказчиков.Зачем им мы, если в сети лежит готовый шаблон, который их техпис заполнить может? В нынешних интересных условиях такое не сильно радует.

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

Если идет речь о портале типа sportbox.ru, у которого посещаемость за минуту составляет сотни тысяч пользователей - тут уж без ГОСТ 34 не обойтись - там в КТС входят более 40 серверов со всей обвязкой, команда, обслуживающая систему, составляет более 60 человек. А уж когда прямые трансляции идут - мама, не горюй! Работают круглосуточно, чтобы нигде ничего не упало.

ЗЫ. Несколько формальных разделов ТЗ по ГОСТ 34 выложены на authorit.ru

Всё-таки у меня этот пост вызывает больше вопросов, чем ответов.
Почему тогда образец ТЗ по гост 19 присутствует на authorit.? Ведь ТЗ на сайт или по грамму значительно более распространены, нежели ТЗ на АС. Впрочем, соглашусь, что стоимость разработки ТЗ по 34 может быть в разы больше. Но ведь это и уровень работы иной...

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

Почитайте Стоимость разработки технической документации. Обратите внимание на стоимость разработки ТЗ Если образец боевого ТЗ по ГОСТ 34 будет лежать в сети - многие из нас останутся безработными...

ЗЫ. Несколько формальных разделов ТЗ по ГОСТ 34 выложены на authorit.ru

Есть желание поделиться навыками разработки ТЗ по ГОСТ 34 (на автоматизированные системы), вплоть до методик запонения отдельных разделов документа.

Надо или ну его на? Писать статьи или нет? Какие есть первоочередные пожелания в части разделов такого ТЗ?

Я, конечно, понимаю, что слишком много времени утекло с момента первого сообщения, но всё же вставлю свои 5 копеек. Во первых поблагодарю авторов за очень хороший и, что самое главное, действенный пример ТЗ по госту 19. Он лежит у меня в распечатанном виде в первом ящике стола как наглядная (и в то же время единственная) методичка по созданию ТЗ.

С одной стороны, он очень мне помог в осмыслении построения ТЗ.
Но так как мне нужно было создавать ТЗ именно на АС, то примера ТЗ по ГОСТ 34 очень не хватает.
Конечно, многие могут заметить - "возьмите рыбу" с предприятия, на основе которой сделайте ТЗ. А вот если нет этой самой рыбы? А руководство, взяв на работу инженера-программиста считает, что он и с созданием ТЗ должен справится на ура.
Поскольку понимаешь, что от качества ТЗ зависит сколько втыков перепадёт в процессе внедрения, то хочешь постараться составить ТЗ как можно конкретнее. Поэтому, если бы был пример ТЗ по госту 34, было бы очень здорово. Понятное дело, что опыт повышается с каждым написанным ТЗ, но для дилетанта хочется иметь качественный материал, изучив который можно было сделать первый уверенный шаг...

Поищите в сети ГОСТы по базам данных и по защите информации - по фамилиям всех не помню.

А в каких НД можно подсмотреть, как писать требования к способам защиты и сохранности данных? Вообще-то я лелеял розовую мечту, что однажды к серии статей по ГОСТ 34.602 прибавится еще одна заветная про надежность и безопасность ... Об этом-то тема

Посмотрите (в частности раздел 3).
ГОСТ 27.003-90 Надежность в технике. Состав и общие правила задания требований по надежности

Если его не смотрели, то лучше предварительно ознакомится с
ГОСТ 27.002-89 Надежность в технике. Основные понятия. Термины и определения

Уникальный случай. Чаще все наоборот

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

Статью про ПОН прочитал еще до того, как задал вопрос - считаю правилом хорошего тона сначала сориентироваться на форуме хоть чуть-чуть, а потом калякать

Главного по ИБ сюда не затащить - уж больно занят. Его в первую очередь волнуют не вопросы надежности системы, а защита от НСД и сохранность данных.

Пытаюсь конкретизировать вопрос: подскажите, как расписать следующие пункты и подпункты ТЗ по ГОСТ 34.602:

2.6.1.4. Требования к надежности
2.6.1.9. Требования к защите от НСД
2.6.1.10. Требования по сохранности информации.
2.6.3.2. 7) требования к защите данных от разрушений при авариях и сбоях в электропитании системы. 8. требования к контролю и восстановлению данных
2.6.3.7. Требования к организационному обеспечению:
1) к структуре и функциям подразделений
2) к организации функционирования системы
3) к защите от ошибочных действий персонала.

Мы занимаемся внедрением системы управления данными о изделии (PDM). Это крайне масштабная система, поэтому мы поэтапно работаем над ее подсистемами, постепенно наращивая функционал системы и количество сотрудников предприятия, пользующихся ей.

Техписов здесь отродясь не было Так что выживаем как умеем

На главной странице сайта http://authorit.ru/ кое-что появилось и про надежность. Давайте сюда Главного - мы его тут опустим (в хорошем смысле слова), а еще лучше - конкретизируйте Ваш вопрос. Ох, не люблю этих недоучек Главных

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

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

В Транзасе не копеечные заказы, а копеечные зарплаты, хотя сам и ушел из ТРАНЗАСА на всего сто баксов больше. Но ушел из за интереса. ПО аспирантуре предложили работу некие ООО"Новейшие Технологии" из которых я имел честь и счатье также уволиться на прошлой недели, все кстате из за образа работа бывших военных инженеров .

А Вас Вадим скорее всего в ТРанзас не взяли, потому как Вы хотели достойную зарпалату, а не зарплату в два-три раза больше военной пенсии, которой большинство пришедших именно в Вашем, Вадим, возрасте инженеры рады радешеньки.
Жалеть не о чем в Вашем случае. Вы бы тоже уволились оттуда вскоре.

В ТРАНЗАСе заказы далеко не копеечные, а вот насчет делать... Посмотрите job.ru, почти постоянно приглашаются специалисты на замену ушедшим по разным причинам как chuga .

В адрес этих деятелей так и подмывает высказаться в духе "мама не хотела, папа не старался" Хватают какие-то копеечные заказы, а то и вовсе убыточные, не думая о том, кто будет все это делать. Главное - хапнуть побольше, чтобы перед командирами себя показать эффективным манагером. А потом Заказчики дрючат контору по самое не балуй

Из моего скромного опыта общения с ТРАНЗАСом (в период поиска работы обращался к ним с предложением отдать им все свои знания, силы и опыт, кои имеются , однако не удостоился даже ответа на резюме — хватило им моего возраста 59 лет) сложилось об этой фирме мнение, что и у них в руководстве не специалисты, понимающие суть проблем, а манагеры-управленцы :twisted: . Так что я с Вами полностью согласен, уважаемый chuga . Кстати, как я понял, Вы с ТРАНЗАСом расстались именно на этой почве? И как новое место работы — поделитесь с коллегой-питерцем .

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

А второе. Не совсем понимаю причем тут водопадная модель?!
В общем то в любой книге по проектированию сказано что даже для итеративного процесса нужно писать ТЗ, как то даже смешно . Уж не смотря на то что каждая итерация в общем представима водопадом....

Мне приходится встречаться с иным подходом - инженеры новой волны всячески отбрыкиваются от ГОСТ и отмахиваются от разъяснений. Какие-то, пардон, чудаки на букву М обучали их в расплодившихся университетах и академиях, что ГОСТ 34 - это устаревшая каскадная или водопадная модель, по которой работать нельзя в принципе. Что взять с этих, с позволения сказать, инженеров?
А результат - плачевный. На моих глазах рассыпается очередная софтверная контора, причем из первой двадцатки в рейтинге. А все из-за непонимания того, что мало просто уметь что-то там программировать, гораздо важнее уметь грамотно проводить работы и все грамотно задокументировать.
В-общем, вопрос тяжелый и неприятный, хочется сразу кулаком по столу колотить, беседуя со "спецами новой волны".

А какие тут могут быть коментарии:
Комментарии так сказать к положению дел:)

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

Вот ВЫ surgeon частенко ссылаетесь на бравую оборонку. Так вот в мною уже упомянутом Транзасе (который так же работает с пограничниками РФ) создание тех документации занимает львиную долю рабочего процесса, но, как Вы сами утверждаете "Каждый умирает в одиночку", инженеры новой волны отправлены на борьбу с ГОСТовским змеем практически с голыми руками, и с тыла их не прикрывают хваленые отставные военные инженеры, потому как на большинство вопросов можно получить только сухие цитаты из того самого ГОСТа который зеленый инженер просит разъянить.

Естественно я говорю не о всех представителях военной инженерии...

Так что вопрос актуальности статей не вызывает ни малейшего сомнения

СПАСИБО ВАМ ЗА ЭТО.

ССЫЛКУ НА ВАШ ФОРУМ Я УЖЕ ОТПРАВИЛ СВОИМ БЫВШИМ КОЛЛЕГАМ ИЗ УПОМЯНУТОГО ТРАНЗАСА

НАДЕЮСЬ НА ПЛОДОТВОРНОЕ СОТРУДНИЧЕСТВО :!:

Огромное спасибо!

Можно, ссылки подправил.

Surgeon, а можно ли еще посмотреть Ваши статьи? По приведенным ссылкам, а было бы очень интересно.

А разве это пункт №7? Оччень уж на 5-ый похоже....
И касательно

тоже странности...

Разве не так должно быть:

1) общие сведения;
2) назначение и цели создания (развития) системы;
3) характеристика объектов автоматизации;
4) требования к системе;
5) состав и содержание работ по созданию системы; .
6) порядок контроля и приемки системы;
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8) требования к документированию; 
9) источники разработки.

Ввиду того, что решение принято единогласно, сообщаю, что на сайте:

- открыт раздел Применение ГОСТ 34 при создании автоматизированных систем;
- опубликована статья Состав и содержание работ по созданию системы (раздел 7 технического задания).

[quote="surgeon

Безграмотных -- да, надо гнать ... а толковых -- их во все времена не много ... А если человек толковый, да еще и теорию управления хорошо знает, да на практике ее применять может -- так что его гнать-то?
Другой вопрос что толковых да грамотных -- крайне мало, и это беда нашей страны. ... Я вот только сегодня послушал курсы по управлению проектами ... преподавание не ахти, на практические вопросы по планированию и управлению итеративной разработкой ПО от преподавателя не получил ответа ...
А что касаемо оборонки -- так у нас все строилось по-большевистски -- при помощи "товарища маузера" (вспомним Королева, Туполева, Грабина, ...). Было ли это эффективно -- да, было ... только людей достает в конце концов жить в режиме "вечного подвига". А опыт нашей оборонки умирает вместе с ней, школ не осталось практически (ну в аваиастроении немного оосталось). А книгами и обощениями этого опыта так так никто и не стал заниматься ... так что учимся у буржуев, ибо неукого в стране учиться (или таки есть у кого?)

Требования к чему? К оформлению? К содержанию документов?

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

Замечательная хотелка - из области предпроектного обследования. В техническом задании может улечься в раздел "Характеристики объекта автоматизации". Спасибо за конкретику, обязательно будет учтена.

Проджект-менеджеров новой формации гнать надо в три шеи Эх, батенька, не работали вы в оборонке...

Все наоборот. Сначала требования из ГОСТ, потом разъяснения. Кстати, требования к ПО сформулированы в цикле статей по ГОСТ 19. Не все, чтол хотелось бы, но в рамках ЕСПД.

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

IMHO, все гораздо хуже ... нужно пояснять что такое требования к ПО вообще и как их формулировать. И какие требования вообще бывают. А потом растолковывать, как эти требования отражаются в разных ГОСТАх и прочих стандартах и методологиях ...

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

...

А как не повеситься, когда не было централизованного подходу и кажин участник (подразделения) ваял свое: рукава, подол, пуговицы вот пришивал, а за пинжак никто отвечать не хочет и кивает на других?

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

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

А как поступать с чужеродным, но весьма существенным (ОСи, СУБДы, всякие серверы приложений, что-нибудь пристроганное из OpenSource)?

А как не повеситься, когда не было централизованного подходу и кажин участник (подразделения) ваял свое: рукава, подол, пуговицы вот пришивал, а за пинжак никто отвечать не хочет и кивает на других?

То, что потихонечку голоса накапливаются - хорошо. Только хотелось бы комментариев.

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

Статья, как мне кажется, будет всем очень полезна. Я писал ТЗ на АС и уже нашел в своих прошлых работах некоторые недочеты :oops: , а так как ТЗ еще будет навалом, хотелось бы изучить и чужой опыт !