![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Об отношение к стандартам при разработке электроники
В![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif)
ru_radio_electr затронули тему оформления документации по ГОСТам. Обсуждение раскинулось еще на
http://nicka-startcev.livejournal.com/1707894.html
http://metaclass.livejournal.com/693363.html
http://alex-avr2.livejournal.com/79735.html
Во всех тредах народ активно смешивает сторонников стандартизации и процессов с говном, рассказывая какие идиоты все эти нормоконтролеры, ратующие за форматки, толщины линий, обозначения элементов и правила именования документов. Пользы от них никакой, вред один.
Со своей интересной колокольни мне представляется, что все эти господа то ли в пылу дискуссии сильно перегибают палку, то ли лукавят, то ли ни разу не выпускали крупные и/или требующие сертификации и/или поддержки на протяжении 5-25 лет, изделия.
Во всех нормальных проектах что я видел и в Мотороле и в Сименсе, форматка есть всегда (да, может быть не ГОСТовская, а ISOшная или, там, RUPовская). Потому что форматка задает единый шаблон, из которого можно узнать автора, версию документа, название проекта, много чего еще. Толщина линий в чертежах таки отличается, чтобы размерную линию не перепутать с границами платы. Изображения резисторов в США и Европе разные и Моторола использовала американский стандарт, а Сименс использует европейский. Правила наименования и расположения документов в дереве документации всегда регламентированы. И, блин, за этим всем следят. Что не мешает компаниям выпускать довольно неплохую продукцию в установленные сроки и с требуемым качеством. И потом вполне сносно её сопровождать долгие годы.
Предположим, что это большие конторы, а у маленьких пофигу что где лежит, как именуется и т.п. Ок. Но проблемы неизбежно начнутся, как только потребуется быстро разобраться с проектом, сданным 3,5 года назад. Дополнительно предположим что автор проекта 2 года назад уехал на ПМЖ в США и связи с ним утеряна. Вот какие проблемы видятся: во-первых, надо найти информацию по проекту в архивах; во-вторых, вспомнить как в тот раз именовали файлы и где лежит например BOM на плату предусилителя; в-третьих, по какой-то удивительной причине, устройство надо сертифицировать на применении в какой-нибудь Голландии. Где-то после решения всех этих проблем даже маленькая конторка начинает задумываться, а не начать ли унифицировать свои правила именования, размещения и т.п. документов. В этот момент окажется, что таки есть стандарты, в которых уже ВСЁ написано. И надо тупо взять и начать умно (!) применять.
Бумажная документация сейчас выглядит анахронизмом. Однако на этот анахронизм по прежнему завязано закрытие договоров. Придется терпеть. Кроме того, бумага при правильном хранении пролежит много-много лет и может принести пользу на этапе эксплуатации изделия. С электронным файликом в формате PCad 4.5 уже сейчас не очень понятно что делать (а ну как компьютера, на котором PCad запустится рядом не оказалось?), а уж еще лет через 10 он окажется совсем бесполезным. Размеры изображений элементов кажется разумным делать как в ГОСТе опять же из соображений применения документации на этапе эксплуатации: если взять раз 50 жирными грязными пальцами А4 со схемой той же Ардуино мега (ну вот управляет она у нас станком), то разобраться потом что куда идет будет довольно тяжело - все названия линий окажутся заляпаными.
В области разработки софта программисты довольно давно пришли к неким более-менее единым стандартам управления артефактами и назвали это дело "Управление конфигурацией". Если этот процесс работает, выдать заказчику гору бумаги в любом виде занимает очень-очень мало времени. БОльшая часть из окружающих меня программисто с этим "управлением конфигурацией" знакомы и активно применяют даже для крошечных проектиков "для дома для семьи". Жаль, что разработчики аппаратуры пока не добрались до этого состояния.
ru_radio_electr затронули тему оформления документации по ГОСТам. Обсуждение раскинулось еще на http://nicka-startcev.livejournal.com/1
http://metaclass.livejournal.com/69
http://alex-avr2.livejournal.com/79735.html
Во всех тредах народ активно смешивает сторонников стандартизации и процессов с говном, рассказывая какие идиоты все эти нормоконтролеры, ратующие за форматки, толщины линий, обозначения элементов и правила именования документов. Пользы от них никакой, вред один.
Со своей интересной колокольни мне представляется, что все эти господа то ли в пылу дискуссии сильно перегибают палку, то ли лукавят, то ли ни разу не выпускали крупные и/или требующие сертификации и/или поддержки на протяжении 5-25 лет, изделия.
Во всех нормальных проектах что я видел и в Мотороле и в Сименсе, форматка есть всегда (да, может быть не ГОСТовская, а ISOшная или, там, RUPовская). Потому что форматка задает единый шаблон, из которого можно узнать автора, версию документа, название проекта, много чего еще. Толщина линий в чертежах таки отличается, чтобы размерную линию не перепутать с границами платы. Изображения резисторов в США и Европе разные и Моторола использовала американский стандарт, а Сименс использует европейский. Правила наименования и расположения документов в дереве документации всегда регламентированы. И, блин, за этим всем следят. Что не мешает компаниям выпускать довольно неплохую продукцию в установленные сроки и с требуемым качеством. И потом вполне сносно её сопровождать долгие годы.
Предположим, что это большие конторы, а у маленьких пофигу что где лежит, как именуется и т.п. Ок. Но проблемы неизбежно начнутся, как только потребуется быстро разобраться с проектом, сданным 3,5 года назад. Дополнительно предположим что автор проекта 2 года назад уехал на ПМЖ в США и связи с ним утеряна. Вот какие проблемы видятся: во-первых, надо найти информацию по проекту в архивах; во-вторых, вспомнить как в тот раз именовали файлы и где лежит например BOM на плату предусилителя; в-третьих, по какой-то удивительной причине, устройство надо сертифицировать на применении в какой-нибудь Голландии. Где-то после решения всех этих проблем даже маленькая конторка начинает задумываться, а не начать ли унифицировать свои правила именования, размещения и т.п. документов. В этот момент окажется, что таки есть стандарты, в которых уже ВСЁ написано. И надо тупо взять и начать умно (!) применять.
Бумажная документация сейчас выглядит анахронизмом. Однако на этот анахронизм по прежнему завязано закрытие договоров. Придется терпеть. Кроме того, бумага при правильном хранении пролежит много-много лет и может принести пользу на этапе эксплуатации изделия. С электронным файликом в формате PCad 4.5 уже сейчас не очень понятно что делать (а ну как компьютера, на котором PCad запустится рядом не оказалось?), а уж еще лет через 10 он окажется совсем бесполезным. Размеры изображений элементов кажется разумным делать как в ГОСТе опять же из соображений применения документации на этапе эксплуатации: если взять раз 50 жирными грязными пальцами А4 со схемой той же Ардуино мега (ну вот управляет она у нас станком), то разобраться потом что куда идет будет довольно тяжело - все названия линий окажутся заляпаными.
В области разработки софта программисты довольно давно пришли к неким более-менее единым стандартам управления артефактами и назвали это дело "Управление конфигурацией". Если этот процесс работает, выдать заказчику гору бумаги в любом виде занимает очень-очень мало времени. БОльшая часть из окружающих меня программисто с этим "управлением конфигурацией" знакомы и активно применяют даже для крошечных проектиков "для дома для семьи". Жаль, что разработчики аппаратуры пока не добрались до этого состояния.
no subject
Речь идет про конкретные стандарты - ГОСТ, которые практически не обновлялись последние 20 лет и банально устарели, не удовлетворяя современным требованиям, при этом внося устаревшие требования.
no subject
Я смотрел стандарты из группы "Единая система конструкторской документации. Обозначения условные графические в схемах"
Угол в обозначении транзисторов отличается от 90 градусов даже в EN 60617-2/-11:1996 (IEC 60617-2/-11:1996).
no subject
На мелкой конторе и с мелкими проектами (несколько человек * несколько лет) можно использовать только систему контроля версий и баг-трекер, а когда в проект вовлечены сотни людей, да из разных фирм - тут уже без полноценной документации, оформленной по стандартам особо никуда не сунешься.
Я пытался прикинуть, можно ли использовать стандартные спецификации требований и дизайна системы в небольшом проекте, выходило, что проект будет не сделан вовремя - оверхед на ведение полноценной документации превышает собственно затраты усилий на проект. Впрочем, документация все равно ведется, только без стандартных форм, а в виде записей и документов в трекере.
no subject
я вроде бы с говном не мешал. Я намекал, что часть стандартов устарела, часть дублируется другими.
Если и поставщик и заказчик хотят файлы в формате А (ибо это родной формат каких-нибудь станков для резки-пайки плат), а стандарт хочет файлы в формате Б, то конвертация А-Б-А будет явно избыточна.
На что завязано закрытие договоров -- тоже анахронизм, еще с тех времен, когда печать/подпись подделывать было накладно. Сейчас же 'изготовление печати по оттиску' стоит копейки и занимает мало времени. То есть, этот стандарт.
“Водопада” не существует