Comments 14
Ведомость машинных носителей информации – это вообще-то чрезвычайно полезный документ, а никакой не атавизм. Как вы будете без него, например, суду доказывать содержание переданных заказчику материалов, если возникнут разногласия? А там документ с контрольными суммами и подписью, не отвертишься.
Очень поверхностный взгляд на вопрос.
Согласен.
Например "Технологический процесс сбора и обработки данных на периферийных устройствах при децентрализованной обработке данных"
Это это вообще история из набора понятий Edge computing.
Выходит новое - это хорошо забытое старое :)
Извините, но суду ведомость необязательна! Если в ТЗ оговорено, а по 34 серии точно должен быть раздел требования к документации, то там как правило написано предоставляется заказчику в бумажно и на электронном носителе. Вы просто официальным письмом направляете и все. И в суде покажете свою копию письма с описью ( конечно же письмо должно быть правильно оформлено в соответствии с действующими инструкциями по делопроизводству).
Это верно. Но заказчик может в суде отрицать, что вы ему направили именно интересующий его продукт. А в описи будут просто какие-то диски. А тут будет контрольная сумма, диски с указанной контрольной суммой, и можно при желании назначать экспертизу по поводу соответствия содержимого этих дисков требованиям ТЗ.
Конечно, необязательно оформлять это именно ведомостью, да она и по госту не является обязательным документом. Но содержательный её смысл понятен.
И это хороший критерий определения «оформить минимум полезных для разработки и сдачи документов»
Было изменено 6 ГОСТ'ов. В части РД 50-34.698-90 вместо него вышел ГОСТ Р 59795-2021. Содержание нового ГОСТа было изменено под текущие реалии, но не кардинально, т.к. основные требования к АС и ее компонентам, изложенные в других ГОСТ, сильно не изменились. Помимо этого ГОСТ, были откорректированы и другие. Атавизмы и архаизмы по возможности были удалены или изменены под современные реалии. Знаю об этом не понаслышке, довелось принять участие в этой работе.
Документация на создаваемые системы, стоящие гораздо дороже, чем современные поделки типа "Hello, world", нужна и важна не только для разработчиков, но и для последующих доработчиков, которые будут сопровождать и дорабатывать сложнейшие системы со сроком эксплуатации десяток лет, а также персонала на объекте автоматизации. Не говоря уже о массе контролирующих органов...
Тема создания автоматизированных систем в последнее время немного затухает. Наши отцы делали интересные вещи, многое работает до сих пор. И документация сохранилась, т.к. была обязательной.
Что будут читать наши дети, чтобы понять, как работает сделанная на коленке по Agile и как-то еще работающая софтверная поделка? Confluence? Canban? Или полезут в Git?
Документ "Шаблон формы документа (видеокадра)" в рамках разработки АС можно было использовать при согласовании с Заказчиком например интерфейсов АС. В документе указывались видеокадры (скриншоты) интерфейса или формы документа.
То есть, документы и стандарты нужные, но из-за "устаревших словесных оборотов" мы их применять не будем?
Всегда говорил и продолжаю говорить, что все проблемы ИТ ровно в одном - организация производства в ИТ находится на уровне средневековых цеховых мастеров. Каждый (не просто компании, а отдельные "мастера") работают как хотят, в меру своего разумения. Никаких стандартов. Никакого устоявшегося общепринятого технологического процесса. Никакого контроля (в том понимании, в каком контроль осуществляется в машиностроении).
Современное машиностроительное производство - это стандарты, стандарты и еще раз стандарты. Плюс стандарты предприятия. И контроль на всех этапах как подготовки производства, конструкторского и технологического, так и производства в металле.
Современное ИТ - это средневековье. В первую очередь - из-за неприятия стандартов.
Есть ещё одна не озвученная проблема, в ГОСТах до 91 года много атавизмов, связанных особенностью регуляции документооборота в СССР, типа «Всесоюзного реестра» чего бы то ни было. А также отсутствие современных решений индустрии, необходимость описывать детально и низкоуровнево решения, принятые в проекте.
Отдельно отмечу, что большая часть требований относится к «а зачем нам это вообще все надо», не сложно догадаться, что исходные данные поменялись, и сейчас просто без автоматизации никак.
Про «скорость разработки» по ГОСТ я умолчу, учитывая, что каждый документ должен пройти полный цикл разработки, включая материализацию документа и его хранения.
В какой раздел эскизного, а возможно и технического проекта Вы включите описание алгоритмов работы технологического оборудования ?
С последним утверждением согласен. Надо выбрать "золотую середину", например такие документы как ПМИ очень желательно иметь под рукой - при сдаче систем согласованные, с Заказчиком, документы всегда помогают отшивать "хотелки" и прочие вольности Заказчика. + описанные в ГОСТе протоколы, позволяют отсеивать много ненужных вопросов. Да и для Заказчика, если он не очень знаком с разработкой и внедрением системм, фраза "так по ГОСТУу положено..." звучит как волшебное слово, а если при этом в ТЗ в перечне документов указан ГОСТ 34, то это вообще сказка.
Когда я слышу "по ГОСТу", мне хочется хвататься за пистолет
А давайте… по ГОСТу