Pull to refresh

Comments 13

PinnedPinned comments

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

Какую вы ставили цель, когда писали эту статью?

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

Да это понятно, но так тонуть в минусах и нести пургу, лучшая антиреклама.

но так тонуть в минусах и нести пургу

Неблагодарные тролляки в камментах сорвали план захвата Вселенной пиар-стратегию Автора…

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

Человек с точкой зрения аналитика, ставлю плюс ➕

Из своего опыта общения с экспертами. (применительно к проектированию сетей автоматизации, диспетчеризации и контроля)

Я бы описывал (стараюсь описывать) так.

  1. Назначение АС

-- цели создания АС. Их надо обозначать, т.к. от них "пляшет" набор ГОСТов и СП в дальнейшем. Например СОЭ и АПС близкие, но разные наборы нормативов. Иногда это система безопасности (АПС) иногда это технологическая система (техпроцесесс), контроль (видеонаблюдение или дистанционный контроль). Сталкивался, когда опасное производство контролируется видеокамерами - контроль+АТХ.

  • задачи проекта - те решения, которые приняты для достижения целей. Создание автономной системы, внедрение контроллера на третью полку, подключение и т.д

    Цели и задачи "огораживают" футбольное поле, они же являются первой проверкой на соответствие ТЗ или ЗнП.

1.1   Вид деятельности, для автоматизации которой предназначена АС (краткое описание проекта который пытаемся построить)

описание тех решений и особенностей. Это на соответствие нормативам: контроль линий, точки управления и контроля и т.д

1.2   Перечень объектов автоматизации, на которых используется АС

1.3   Перечень функций, реализуемых АС

  1. Описание АС

2.1   Структура АС и назначение ее частей

2.2   Сведения об АС в целом и ее частях, необходимые для обеспечения эксплуатации

2.3   Описание функционирования АС и ее частей

  1. Описание взаимосвязей АС с другими АС

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

3.2   Описание связей между АС

3.3   Описание информации взаимообмена

  1. Описание подсистем (при необходимости)

4.1   Структура подсистем и назначение их частей

4.2   Сведения о подсистемах и их частях, необходимые для обеспечения их функционирования

4.3   Описание функционирования подсистем и их частей

Скажите, хоть раз удавалось написать полезный документ по программному продукту , руководствуясь государственными стандартами?

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

Статья очень полезная, но молодым/малоопытным разработчикам покажется не интересной.

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

Sign up to leave a comment.

Articles