• новости, помощь наших специалистов
• применение ГОСТ 19, применение ГОСТ34
• образцы документов, публикации
• критика, о жизни, консультации в форуме
• книга об AuthorIT

Применение ГОСТ 34 при создании автоматизированных систем

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

Мотивы подготовки цикла статей по применению ГОСТ 34 при создании автоматизированных систем

Применение ГОСТ 34 при создании автоматизированных систем - задача для многих нетривиальная. Сложность применения ГОСТ 34 вызвана целым рядом причин, основная из них - нынешняя прозападная ориентация.

По прозападной ориентации, по нелепым попыткам тупо и бездумно подгонять себя под западные мерки, совсем недавно «прошелся» известный сатирик г-н Задорнов, начитавшись, видимо, Сергея Есенина . Тем самым вызвал к себе глубокое уважение у автора настоящей статьи.

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

Доморощенные «инженеры человеческих душ» также не отстают. Интересно, какова была бы судьба создателей культового фильма «Бригада», посмотри его, скажем, Юрий Владимирович Андропов или, что покруче будет, Лаврентий Палыч?

Прозападная ориентация и стремление во что бы то ни стало вступить в ВТО повлекло за собой:

1. разруху в оборонной отрасли;
2. разруху в системе стандартизации;
3. разруху в системе высшего образования.

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

Разруха в системе стандартизации есть следствие разрухи в оборонке и ухода государства из сферы стандартизации. Закон «О техническом регулировании» внес весомый вклад в процесс развала системы стандартизации. Нет смысла подробно освещать последствия (и возможные последствия) принятия указанного закона, поскольку имеется ряд великолепных статей г-на Б.Г. Бронфельда.

О разрухе в системе высшего образования, о подгонке ее под западные шаблоны лучше всех расскажет ректор МГУ. Вряд ли автор настоящей статьи способен высказаться яснее и полнее уважаемого г-на Садовничего.

По роду деятельности автору приходится ежедневно сталкиваться с юными и не очень, но изрядно распальцованными «главными инженерами», «первыми заместителями гендиректора», да и просто «проектировщиками» из относительно крупных, мелких и средних контор, занимающихся «проектным» бизнесом. Беглый просмотр предъявляемой ими документации поначалу вызывает нервные смешки, затем эпитеты вроде «бред, бредятина, полнейшая бредятина!», после чего группа экспертов как по команде срывается с места и идет курить, чтобы хоть чуточку прийти в себя.

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

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

Задачи цикла статей по применению ГОСТ 34 при создании автоматизированных систем

Задачи цикла статей по применению ГОСТ 34 при создании автоматизированных систем:

1. разработать идеальное (с позиции стороннего эксперта, далее по тексту - эксперта) техническое задание на создание автоматизированной системы;
2. показать методики заполнения разделов идеального технического задания;
3. сократить идеальное (с позиции эксперта) техническое задание до необходимого и достаточного состава требований, при котором создаваемую автоматизированную систему возможно будет сдать Заказчику.

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

Согласно п. 1.3 ГОСТ 27.003-90 типовая модель эксплуатации изделий должна содержать последовательность (циклограмму) этапов (видов, режимов):

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

В текстах статей будут встречаться заголовки вида «- п. такой-то ГОСТ такой-то», а вслед за ними - аутентичные тексты соответствующих пунктов ГОСТ. Знак минуса есть признак того, что заголовок не должен быть виден в теле документа. Это для удобства и для понимания того, насколько выгодно применять для разработки технической документации инструментарий на основе single source.

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

Эксперт, как правило, представляет организацию, разработавшую узаконенные технические требования на конкретный вид автоматизированной системы. Указанная организация является также организацией-экспертом. Разработчик такого вида автоматизированной системы вынужден передавать документы на экспертизу в экспертную организацию, в противном случае созданная система будет бесправной, как в былые времена незаконнорожденный ребенок.

Правильные, обоснованные действующими стандартами требования, сформулированные в техническом задании, вызовут восторг эксперта, готового «вдребезги пополам» разнести «эту писанину». Эксперт, в силу собственного опыта, справедливо полагает, что в очередной, тысячустодвадцатьпятый раз, ему придется внимательно вычитать две сотни страниц полнейшей бредятины. А тут вдруг такое!

Но эксперт не заинтересован в том, чтобы система была создана и введена в действие (промышленную эксплуатацию), ему за это денег не платят. Посему эксперт действует формально и жестко: чуть что не так - «от винта!».

Есть и оборотная сторона медали. Сдать (да и выполнить) работу, проведенную на основании технического задания, разработанного по всем правилам военного искусства, попросту невозможно. И это прекрасно понимает «несторонний» эксперт, к примеру, начальник, отец-командир разработчика.

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

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

Соглашения

Исходя из целей и задач настоящей статьи, придется изредка нарушать ГОСТ 34.602-89, в частности, п. 3.1.

Согласно п. 3.1 ГОСТ 34.602-89 разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд. 2 настоящего стандарта.

Смириться с таким нарушением требует логика изложения материала.

Иногда доказать теорему возможно лишь «от обратного». Аналогия не совсем удачна, но житейский опыт подсказывает: прежде, чем во что-то вляпаться, следует прикинуть, как потом выбираться из сложившейся ситуации. Житейский опыт применим и при разработке технического задания.

Чтобы дать читателю возможность оценить объемы работ и возможные последствия «неосторожной» разработки технического задания по ГОСТ 34.602-89, изложение материала начнем с седьмого, типового (общего практически для всех ТЗ) раздела технического задания - «Состав и содержание работ по созданию системы».

Версия для печати