Уважаемые коллеги, наверняка эта тема раньше поднималась, но в архивах мне её найти не удалось. Тем кто работал на госзаказчика наверняка, хорошо знакома регламентированная ГОСТ-ами очередность этапов разработки - НИР-ОКР, эскизный проект - технический проект, ну и т.д.

Вопрос, есть ли аналогичные регламенты в Европах и США? Насколко они отличаются от наших? Этапы у них те же или все устроено по-другому?

Заранее спасибо!!!

А нахрена вам это надо? В госучреждении восстание не пройдет. В частной конторе о Госте можно забыть при согласии заказчика/начальства.

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

Есть у них этапы и следуют им довольно жестко. Вот только это не то, к чему привыкли в госконторах...
Это и маркетинговые исследования и поиск спонсоров и продажа еще не сделанных изделий...
У меня на сайте есть статья "про инофирмы"... Почитайте, потом продолжим... ОК? Будут вопросы - пишите.

Во-первых, интересно. Во-вторых мне в следующем семестре читать лекции по САПР, - хочу сопоставить различные существующие САПР с различными этапами разработки. В-третьих, по своему опыту могу сказать, что на госпредприятиях сейчас как раз на ГОСТ-ы плюют чаще, чем у частников. НИР-ы объединяютс с ОКР-ами с соответствующим урезанием времени и денег. Разбивка на этапы осуществляется волюнтаристски исходя из желаний бухгалтерии, а не инженеров и т.д.




Да, поспрашивайте - расскажите, если что-то узнаете. Ну уж ТЗ у буржуев, я думаю, пишут.




Скачал. Почитаю. Спасибо!!!

в буржуйских конторах, если это, конечно, не гаражный стартап из 1-2 человек. маркетинговыми исследованиями занимается маркетинговый отдел, поисками спонсоров финансовый отдел, продажами отдел сбыта и т.д. то есть к САПРам эти дела не имеют никакого отношения.
в больших конторах, типа, самсунга, эти отделы представляют собой огромные иерархические образования, деятельность которых секретна и недоступна в остальных подразделения.

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

также фирмы содержат и поддерживают связь с институтскими группами (SAIT у Самсунга, Cadense|Synopsys раздают гранты в американских институтах и т.д.) - там вобщем-то такая же "вольница" (и проблемы с финансированием кстати тоже) как в отечественных НИИ

то есть остаются RnD отделы, которые есть у каждой уважающей себя фирмы

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

как-то так

Может Вам design flow нужно сопоставить? тут всё более менее определено производителем сапра... для ASIC тулзов по крайней мере...

А насчёт ТЗ - в основном по телефону...
И вообще - документация есть, а содержания и системы - нет. Но это правда у всех в разной степени....



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

Шо? Маркетинг отделы? Где? Никогда не видел и не слышал.
В супербольших компаниях механизм принятия решений непрозрачен.

Зависит опять же от чего делать: новый вариант изделия или осваивать новое направление.
В основном решения принимают те директора, у кого бюджет.
Часто прислушиваются к сейлс персонам, какой фидбек они принесут от продаж.
Ну и естественно смотрят на сторону.
Каждый в пределах своего направления, которое курирует.

ТЗ как правило довольно аморфно, и начинается все с R&D (рисеч), в основном в имейлах все.
Ну а а если удалось, там уже строже на производстве.
Частенько вся документация держится в базе вместе с багами.

В общем, процесс довольно свободен и направлен на быстрый результат

Меня в первую очередь интересуют этапы технической разработки, когда маркетологи уже опрелелили требования к будущему продукту, деньги уже выделили, и инженерам сказали "Фас!!!". В рамках отечественной системы сопоставление между маршрутами проектирования и просто отдельными видами САПР провести, пусть и с натяжкой, но можно. НИР - поведенческое проектирование, ЭП - функциональное, ТП - физическое. Я именно что хотел узнать, есть ли какие-то аналоги этих этапов в зарубежной практике.




Ну собственно да. Design Flow если САПР сквозной. Но ведь есть САПР-ы, позволяющие выполнять только функциональное или только логическое проектирование. В этом случае маршрут проектирования может строиться из САПР различных производителей.




Хорошо, а если нужно уточнить какую-то деталь, - листать почтовый архив? Или заниматься бесконечными согласованиями?

1) Незнаю с каких это стандартов буржуйских, но неформально у них выделяются такие этапы:

Marketing\Customer - решаем чё делать
Concept Design - решаем можно-ли и как сделать
Kick-Off (KO) - на этой стадии понятно какой дизайн и как впринципе можно сделать
Design & Verification - дизайним, симулим
Tape Out (TO) - дизайн доведён до физической реализации и просимулирован
Characterization - меряем параметры получившегося изделия
Transfer to Production (TTP) - на этой стадии передаём в производство

Собственно KO, TO, TTP где-то и отвечает стадиям о которых вы спрашиваете....


2) Набор САПР определяется задачей...
Например возможности САПР и этапы проектирования CADENCE для ASIC дизайна можно посмотреть тут:
http://www.cadence.com/products/Pages/default.aspx
Это более-менее сквозной вариант от одного производителя...

Вот тут на 4-5 страницах хорошо нарисовано что и какой САПР делает поэтапно (это похоже на НИР, ЭП, ТП, которое находится между KO & TO):
http://www.ee.ncu.edu.tw/~jfli/vlsidi/lecture/soc

Опять-же, необходимость розделения на НИР, ЭП, ТП скорее условность на бумаге чем реалия жизни.
так розделять может и есть смысл, когда самолёт проектируеш, а когда всего-то одну микросхемку или платку.... то всё замешано в кашу многими итерациями...
Я-бы студентам это вообще в голову не забивал, честно говоря.....
Вот чем напр НИР от ЭП отличается когда плату с микроконтроллером проектируеш - ума не приложу

3) А если уточнить детали - да листать архив, звонить, проявлять проактивность
Если заказчику требования надо задать, а он лыко не вяжет бо сам не знает - предлагать свой вариант..
И да, бесконечно нельзя - дедлайн-же всегда наносу

Да. Иногда пристрелить хочется тех, кто не листает, а просто тупо спрашивает. Приходится самому листать, копировать из предыдущего имейла и посылать.
А что такое "бесконечные согласования"? Если между компаниями, то или имейл или конференц кол, по результатам которого все равно рассылается имейл.
А в компании, если рядом, можно подойти, поговорить. По результатам имейл.

На самом деле там прототип показывается заказчику, если заказчик есть. Он причмокивает языком и по результатам делаются выводы куда двигатся.
Вообще, как правило, результат не полностью соответсвует записанным требованиям по причине:
а) так нельза было
б) так не смогли
в) заказчик по телефону изменил требования..

Хм, или в моей фирме не все так как у других, или тут на форуме народ не в курсе, как это дело идет у буржуинов.

Если речь идет о продвинутых фирмах с мировым именем и которые делают крупные R&D проэкты, то есть давно определенные этапы разработки. И как минимум я видел данную реализацию не раз.

Речь идет о т.н. Gate Review процессах.
Я с ГОСТовским понятиями знаком мало, поэтому сравнить не могу, но принцип следующий:

Во первых есть четкое разделение - Technology Development и Product Develoipment - надеюсь разница понятна. Помему как у нас НИР и ОКР.
Этапами Technology development являются Initial Review(IR) и Gate Review 1-3(GR1..GR3)
Этапами Product Development являются GR4-GR6 и Feedback Review.
Фактически каждый этап разработки заканчивется Review, которое проходит инстанции утверждения между всеми участниками и при этом решается - продолжать проект или нет. На каждом этапе дается формальное разрешение - т.е. Каждый проект проходит все этапы от IR до GR3 или GR6.
В различных фирмах по разному, но то что я видел в основном выделяют следущие этапы разработки и решения после Review
IR - дается разрешение на проверку необходимости разработки новой технологии или продукта
GR1 - определение ориентировчного бюджета и плана разработки. Дется разрешение на исселдование новой технологии.
GR2 - исследование завершено и понятно, как технология может трансформироваться в продукт. Дается разрешение на разработку данной технологии. Дается разрешение на реальные прототипы для демонстрации и проверки технологии
GR3 - Разработка технологии завершена. .
GR4 - Исследование необходимости разработки нового продукта. Определение спецификации, Бюджета, Return on Investment и.тд. Дается разрешение на старт разработки нового продукта
GR5 - Разработка завершена. Основные узлы разработаны. Дается разрешение на проведение тестирования, утверждения сертификации продукта
GR6 - Утверждение завершено. Дается разрешение на подготовку в серийное производство. На этом этапе продукт можно начинать продавать.

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

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

А каким буржуйским стандартам эти этапы соответствуют IEEE, ISO, etc.?
Изначально в этом и был вроде вопрос.....

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

syoma, это в Европах так?
Если в Америке, то разве что IBM/EMC и иже с ними, не мельче.

Это внутрифирменный фольклёр. У нас этим занимаются люди в костюмах, которые только и делают, что всякие инструкции рассылают и требуют Key Performance Indicators каждый месяц. И эти товарищи гордо именуют себя R&D. А я, блин, тогда кто?

То что стандартов нет - я в этом почти уверен. Но подход примерно во всех больших фирмах одинаковый, так как любая большая фирма в конце-концов превращается в банк. И ты начинаешь просить у него денег на разработку, как кредит, постоянно доказывая, что ты его целево используешь и отчитываешься за каждую копейку. А банк от тебя взамен хочет получить продукт, который она будет продавать и зарабатывать деньги.
Так как R&D процесс сложно контролировать и понимать людям с дипломами MBA - вот они и придумали такую формализацию контроля.

Это в европах. Ну и ессно в фирмах от 10000 сотрудников. И ессно не в IT фирмах.

немного разный подход в стандартах пост советского пространства и европейского или американского. Мировые стандарты дают философию, концепт и на основании этих стандартов каждый создает свои локальные процедуры и стандарты предприятий.
что это дает, стандарт не связывает по рукам и ногам и не говорит делай раз, делай два....., он дает общий подход, а организация создает и постоянно усовершенствует свои внутренние стандарты, что позволяет становиться более конкурентным.
Например стандарт IEC 61508 дает жизненный цикл (life cycle) (http://www.rvs.uni-bielefeld.de/Bieleschweig/fifth/download/B5-Ladkin.pdf) стр 21 и 22 имеет неплохую визуализацию - рисунки из стандарта.

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

Вопрос - найти аналоги у них ? Или что-то другое необходимо?

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

Что мешает становиться более конкурентным?

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

У буржуев такого нет я думаю по следующим причинам:
- Всё что не милитари - никто не заставляет
- В комерческих фирмах никто не умеет выражать мысли письменно
- Из-за неумения - думают что это сложно и невозможно
- тупо незнают что там много умного и полезного
- стандарты ихние - фуфло, как рекламный флаер - одни общие рекомендации ... вот никто их и не использует
- стандарты носят общий характер - чтобы взять деньги с тех кто пытается их применить за сертификацию, рекомендации, реальные данные измерений и т.п.
чтобы продать IP core стандартного интерфейса, который "очень не внятно" описан на бумаге....
- отсутствие стандартов порождает огромное количество пустопорожних митингов, мейлов и розговоров....

Чисто из опыта....
После оформления User Manual по ГОСТ 2.105, ГОСТ 2.601, ГОСТ 2.610 от буржуев - восторг, very positive feedback и офигение от того что в стране, где по улицам медведи с балалайками шастают, и стандарты такие есть уже лет 50 и ракеты в космот летают...

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

Ну и вообще, чтобы Мерс и БМВ обменивались стандартами разработки на свои авто - это только в фантастике. Хотя ничто не мешает им сидеть вместе и клепать стандарты на всякие там системы генерации безопасного кода и т.д.


Ну об этом можно много говорить. У меня тут тоже часто на фирме офигевают, когда я заставляю AutoCadчика с 20-летним опытом делать сборочные чертежи с хоть каким либо намеком на разбивку по модулям и сборкам, чтобы потом это правильно задокументировать, и ввел хоть какую-никакую но систему нумерации, учета и утверждения документации. Народ потом долго спрашивает - откуда у меня - с КПИшным дипломом по измерительным системам такие знания? А что поделать - незачет по инженерной графике и двояк по теормеху - были прямыми путями в армию в свое время - у тех преподов, помоему, задача такая была. Ну и стандартизацию мне тоже вдолбили, хотя всего семестр был.

Мне было даже интересно не столько найти прямый аналоги. Я не думаю, что где-то есть некий "Outline Project" как аналог нашего эскизного проекта. Мне скорее интересно в принципе, - на какие стадии разбивается разработка у них. Насколько они соотносятся с нашими? Есть ли некий общий стандарт, как наши ГОСТ-ы типа 15.101 или 15.203?

Хотя, разговор принимает интересный оборот. Появляется вопрос, - почему если у буржуев все так плохо организовано, у них все так хорошо работает. Хотя подобные же мысли у меня появляются от прочтения иностранных книг по инженерному делу, вроде "The art of designing Embedded Systems". Там тоже много про бардак в процессе разработки и менеджеров, которые пытаются управлять инженерами, как юнитами из компьютерной стратегии.

1) кто сказал что у них "все так хорошо работает"?
Если люди испытатели про метрологию и точность приборов не вкурсе, Вы представляете что они намеряли
Да и глюки первой версии любой мобилки Вам разве не встречались?
И типичной практикой есть сдать напр. сырую микросхемку заказчику... он сделает модуль для своего заказчика... а тот наобещает с три короба в рекламе пользователям... а потом год-два идёт дебаг и патч глюков в микросхемке... и исполнителя не смениш - слишком много завязано и розработано и время ушло .... и бывает бюджет 100тищ, а в итоге на доводку ушло 1000тищ и ничё.....

2) А насчёт создания илюзии что у "них-то там всё хорошо" - так это не к инженерии вопрос.....
Задумайтесь - зачем Вы купили эту глючную новую мобилку?
Главное ведь на рынке - кто первый лоха зацепит

3) ну и почему-же всётаки работает?
да потому что розработчики заинтересованы это впарить любой ценой.
Если это имигрант-индус то для него это вопрос жизни и смерти - не сдал результат - фиг тебе контракт на след. год

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

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

Думаю дело тут в том, что в комерции нет бабушки-нормконтроля которая 15 дней схему не принимает на учёт, бо петли из проводков ей не нравятся и аналог новой микросхемки в госте отсутствует...
Дело в розумности подхода.

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

Вот спросил у нашей R&D организации насчет чего они базировались. Ответ такой:
Наш R&D Процесс не базируется ни на каких стандартах. Он более приближен к классическим стандартам качества(DMAIC, PDCA) и цель данного процесса - улучшение качества разработки и исследований в области:
- соответсвия начальным требованиям по характеристикам, стоимости и качеству
- оптимизация разработки в области ресурсов, бюджета и time-to-market.
Кстати другая линия продуктов в нашей фирме (еще 10000 людей о которых я только знаю, что они выпускают) после анализа ихнего слабого R&D процесса и с помощью внешнего консульстанта пришла на 99% к такому же процессу, как и у нас.

Вопрос в том - а насколько вышеупомянутые ГОСТы берут указанные мной факторы - особенно time-to market во внимание?

И второй вопрос - а имеет ли смысл применять такой стандарт на маленьких фирмах с 10-100 человек? Это не слишком большая бюрократия?

В бывшем совке имеет смысл брать Гост, урезать и хоть что-то применять для уменьшения хаоса.
Да в конторе где 10 человек - все этапы разработки смазаны, все в умах людей, но идея и принцип остается.
В конторе, где более 100 чел без Гостов не обойтись, т.к. проблема человеческого фактора на 1 месте.
Нужно максимально структурировать процесс, да, больше бюрократии, бумаг и т.д., но процесс зато идет,
а если нет Гостов - одни "пожары" и эффективность конторы - около 2-5% (сам мерял).

На западе и востоке - другие подходы, они сами хотят быть лучше из-за конкуренции и сами делают
оптимизацию своих процессов. Есть Исо 9000 или 14000, там для общего случая - так сказать от чего
оттолкнуться, а дальше сами. Военку не берем - и там и тут отдельная песня.

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

Я понял одно - наши Госты для нас (совка) подходят идеально, такое уж у нас мышление.

А зачем ГОСТ и time-to market связывать?

Насчёт - слишком большая бюрократия...
Будучи студентом, я мог оформить строго по ГОСТ пакет конструкторской документации на модуль (микроконтроллер на платке в корпусе) (ТУ, ПМ, Схемы, ПЭ, ВП, РЭ, СБ PCB, кабелей и корпуса и т.п.) где-то за 2-3 недели... Правда на однотиповые изделия.
У буржуев эта мисия считается невыполнимой
Для них даже FPGA в плате проблема:
- "А как это мы прошивки не перепутаем?"
- Так в соответствии с СБ....
- А разве возможно это записать на бумаге как-то?....

Имхо, этот параметр в военных условиях у ГОСТа, все-таки, лучше.

Тупые (с) Задорнов.

Ничего создать не в состоянии.

ну если в военных условиях лутше (а это екстра минимальный time-to-market... с дулом у виска ) - то вот и найдено идеальное решение.

По тону дискусии складывается впечатдение что применение стандартов кому-то замедляет процесс розработки...
У кого есть такой печальный опыт?


И в чём ирония?
Раз "тупые", а деньги гребута то вывод очевиден - не в правильной и быстрой технической реализации суть, и не в инженерах в том числе....
Вот об этом и стоит поговорить....

Применение стандартов скорее ускоряет процесс разработки (конечно при условии что разработчик знаком с этими стандартами). Если речь идет конкретно об оформлении документации согласно ГОСТ, то тут да - тратится уйма времени на документирование изделия, которое можно будет будет изготовить ну лет через 5,10,20..и т.д. Вот только кому такое изделие будет нужно даже допустим через 5 лет? Конечно речь идет в первую очередь об электронике. Т.о. трудозатраты на оформление документации могут быть сопоставимы со трудозатратими по проектированию изделия.

Из своего опыта.. Максимум что я оформлял - это Design Specification листов на 20, на IP модуль. А так - краткая характеристика ключевых параметров IP и рекомендации по подключению. При этом 98% времени уходило на разработку. Каждые 4..5 месяцев IP дорабатывалось и, соответсвенно, уточнялась спецификация. Но это все в условиях работы в строгом соответствии с регламентом работ (стандартов) компании - выполнил операцию - поставь галочку. Писанины - минимум.

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

ГОСТ создает "нижний уровень" разработки, где требования к специалисту минимальные,
т.е. он может копать/паять/писать и читать PDF одинаково плохо.
В этих условиях Совку нужно было от чегото оттолкнуться, хоть как-то запустить телегу,
вот и писались ГОСТы по различным темам. ДА, бумаг и бюрократии масса, но в условиях
технического хаоса, когда ты паяешь, а потом это пытаешся описать, а еще придумать ПМ
для испытаний, а если ядерная техника или не дай бог птичка, то еще и по функциональной
безопасности пройтись - смотришь сам выловишь свои же ошибки. Времени много уходит ?
Да. Природу прожект-менеджмента не обманешь...

Конечно, если вы более опытны, то этот ГОСТ у вас в голове и вы делаете это на порядок (!)
эффективнее. Я приводил цифру 2-5% эффективности работы современного КБ или НИИ.
Кстати сравнивали НИИ и команду спецов из 7 человек - результат по выходу разработки
почти равен.

Так что если с компетенцией беда - юзай ГОСТы ты всегда.

А может все гораздо проще, и таки не "тупые"?

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