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

[lazarev andrey]

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

кто какие стандарты использует в работе для формализации процесса? (в данный момент пытаемся организовать библиотеки под новый САПР, про старое железо разговора нет)
например:
- для УГО стандарт IEC 60617
- не нашел еще пока что соглашение об именовании элементов (кто знает киньте номерок)
- для footprint, padstack - IPC7351B (размеры, именование)

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

может быть тема вообще бред?
до этого смотрел темы:
1. http://electronix.ru/forum/index.php?showt...50314&st=60
2. http://electronix.ru/forum/index.php?showt...%ED%E4%E0%F0%F2

[lazarev andrey]

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

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

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

[vitan]

на самом деле в блок-схеме процесса не один человек и система проверок тоже предусмотрена.

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

вопрос то о правилах, по которым создавать элементы

Нет, не в этом. Эти правила Вы зачем-то хотите ввести. Вопрос именно в том, зачем и чего надо этим добиться.

[lazarev andrey]

Нет, не в этом. Эти правила Вы зачем-то хотите ввести. Вопрос именно в том, зачем и чего надо этим добиться.

добиться? добиться того что библиотека будет пополняться компонентами "с некоторой вероятностью это правильно" и все остальные участники будут ей пользоваться.
- УГО будут выполнены по некоторым правилам (какой стандарт это вопрос не главный).
- футпринты элементов будут оформлены по неким правилам с привлечением некоторых стандартов+некие требования по конструктиву (шелкуха там и прочие).
- можно еще придумать что нибудь.

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

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

[vitan]

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