Проблема еще и в подходах нашего государства, какими методами оно пытается развивать эту самую электронику. К примеру, есть перечни эквивалентов западных микросхем отечественными. Разумеется, устаревшие на много лет. Главный конструктор обязан на них ориентироваться, и отдельно объяснять, почему он использовал то, что нет в этом перечне — и тем более, если аналог в нем есть. Причем перечни приходят (к нам, по крайней мере) в виде бесконечных… бумажных документов, не всегда даже вордовый вид удается достать. Занимается выпуском этих перечней целый институт на севере Москвы…
При этом рассылаются вопросы: какие микросхемы вы собираетесь использовать в ваших будущих работах. Мол, от всех предприятий будут собраны предложения, заданы ОКРы заводам, будет изготовлено нужное (какое???) количество компонентов, и главные конструктора смогут это использовать. А если через 5 лет, когда это доберется до производства, появиться более удачная микросхема? По моему, это совершенно тупиковый путь. Поэтому — какие внешние рынки? Кому выходить? Некому, некуда и нечем.
… тогда покупатель вашего изделия, для которого нужно что-то древнее, напишет письмо предприятию-разработчику(или изготовителю — если была серия, или заказчику, если последних уже нет), ссылаясь на вашу эксплуатационную документацию, с просьбой изготовить, заплатив денежку.
Ведь для этой области не бывает, что «операционки нет». Был ОКР, был результат, выпущена документация, заложена в архив. Если это не разработка на собственные деньги, то результатом распоряжается заказчик. Есть ответственные за сохранение результата лица. И, в теории, хоть через 100 лет, используя документацию к изделию, его можно взять и изготовить.
Есть еще одно соображение: если вы попробуете вместе со своим изделием хранить чужие изделия, и потом «копировать» все вместе своему заказчику, то вы станете типичным производителем контрафакта. Т.е. без договора с предприятием, обладающим правами на изготовление, изготовлять и продавать.
А вы не смотрели Р-схемы как замену блок-схем для многопоточных программ? Я сам не пробовал, возможно у вас есть такой опыт?
Это не возражение, а скорее созвучные мысли.
Что такое ЕСПД: это оформление+состав со структурой документов. Т.е. оно говорит, о чем должно быть сказано, как это структурировать, и как оформить. Эти вопросы мы решаем всегда, если речь заходит о документации. Чем проще проект, тем меньше нужно документов, и тощее они. Смотрим 19.101-77, п. 2.5. Мы видим, что страшный ЕСПД обязательными считает только… спецификацию и текст программы. Остальное — по решению заказчика. И это логично. Глупости начинаются, когда глупый исполнитель верноподданически предлагает изготовить полный комплект документов для любой фитюльки, и заказчик включает это в ТЗ.
Поэтому мой ответ такой — чем больше, чем крупнее проект, тем больше польза от применения ЕСПД.
С другой стороны, можно поставить вопрос шире — а нужно ли вообще описывать программу в виде классического документа? Не является ли более эффективной заменой документам специализированные программы, в которых накапливается в связном виде информация? К примеру, в инженерных областях есть PDM — так ли нужно ли при этом все выводить на бумагу? В программировании есть багтрекеры, системы управления требованиями, системы управления версиями — не содержат ли они больше информации, чем самый-пресамый толстый 13 документ?
С многопоточными программами мне до сих пор удавалось избегать блок-схем. Я полагаю, что блок-схемы — не для этого.
По поводу компиляторов и т.д. — так называемыми инструментальными средствами. Мы делаем так: формируем диск 12 03, куда все это записываем, в бинарном виде. Главное условие — чтобы ничего с этого диска не нужно было для работы программы, т.е. не входило в поставку. «Все это» — это все, что нужно для сборки, но не образует отдельных продуктов. К примеру — mingw нужной версии, lex-yacc, nsis и т.д. Этот инструментальный диск не включается в схему деления, на него не выпускается документация, нет его в спецификации и т.д. Но ссылка на него есть в 96 документе «Инструкция по сборке», и он есть в архиве.
«Определенность» версии того, что нужно для сборки — это содержание «Инструкции по сборки» и инструментального диска. В «Инструкции..» написано, мол, брать из папки на диске такой-то файл, запускать с такими-то ключами, и т.д.
Если для сборки нужно другое изделие (например, операционка, или кросс-компилятор), то в «Инструкции...» указываем, то нужно, к примеру, ФЛИР.80001-12. В архив оно не сдается, т.к. это не наше изделие, мы не имеем права его «изготавливать».
То, что нужно для функционирования — это уже в ТУ.
Вы слишком ограничиваете понятия. Стандарт не обязательно всех устраивает, особенно разработчиков. Вообще, заметил, что большинство процедур обеспечения качества разработчиками воспринимается плохо. Не обязательно он всем подходит. Знаете как лучше? И можете обеспечить качество? И договорились с заказчиком = он счастлив? Решили проблемы с сопровождением и модернизацией? Замечательно!
Авторитет за ГОСТом такой, что по нему фигову тонну времени разрабатывается ПО. И поверьте — если бы он был бесполезен, ненужен — уж за 35 лет бы сподобились его отменить. Я не спорю, что в некоторых частях он устарел — но даже в таком виде он хорошо систематизирует результаты работы.
Что касается разборки по сорцам: вы идеалист. Вы полагаете, что код пишут Программисты. И среди них нет Уродов. Или, к примеру, Студентов. Я за последние пару лет несколько раз наблюдал, как списывают мегабайты кода после месяцев разборки с ними, потому что бесполезно. Документация левая, код из архива не собирается. И все.
Вопрос в чем — зачем нужны стандарты вообще, стандарты на оформление или стандарты на содержание? Стандартизировать оформление приходиться для того, чтобы гарантировать читаемость документа + фирменный стиль. На хабре оно тоже, кстати, стандартизировано. Насколько подробно — должно определяться практикой. Конечно, есть в ГОСТе перегибы, когда в ЕСКД точка после номера пункта не ставится, а в ЕСПД — ставится, в ЕСКД Рисунок, и в ЕСПД — Рис. и прочее. Но во первых, есть средства, которые это частично решают, а во вторых — вы же не возмущайтесь, что есть Coding Standards.
Стандартизировать виды документов и содержание нужно, чтобы в вашем творчестве смогли разобраться другие люди — по возможности, быстро. Это раз. Чтобы не забыть описать один из аспектов изделия — два. Чтобы заказчик, не в зуб ногой в программировании, мог по формальному признаку принять документацию — три.
А бюрократия возникает от непонимания, зачем все это нужно. Когда люди кописастят по 300 страниц из «Описания программы» в «Руководство оператора», а потом сами не знают, куда смотреть, глядя на эту кипу.
При этом рассылаются вопросы: какие микросхемы вы собираетесь использовать в ваших будущих работах. Мол, от всех предприятий будут собраны предложения, заданы ОКРы заводам, будет изготовлено нужное (какое???) количество компонентов, и главные конструктора смогут это использовать. А если через 5 лет, когда это доберется до производства, появиться более удачная микросхема? По моему, это совершенно тупиковый путь. Поэтому — какие внешние рынки? Кому выходить? Некому, некуда и нечем.
Ведь для этой области не бывает, что «операционки нет». Был ОКР, был результат, выпущена документация, заложена в архив. Если это не разработка на собственные деньги, то результатом распоряжается заказчик. Есть ответственные за сохранение результата лица. И, в теории, хоть через 100 лет, используя документацию к изделию, его можно взять и изготовить.
Есть еще одно соображение: если вы попробуете вместе со своим изделием хранить чужие изделия, и потом «копировать» все вместе своему заказчику, то вы станете типичным производителем контрафакта. Т.е. без договора с предприятием, обладающим правами на изготовление, изготовлять и продавать.
А вы не смотрели Р-схемы как замену блок-схем для многопоточных программ? Я сам не пробовал, возможно у вас есть такой опыт?
Что такое ЕСПД: это оформление+состав со структурой документов. Т.е. оно говорит, о чем должно быть сказано, как это структурировать, и как оформить. Эти вопросы мы решаем всегда, если речь заходит о документации. Чем проще проект, тем меньше нужно документов, и тощее они. Смотрим 19.101-77, п. 2.5. Мы видим, что страшный ЕСПД обязательными считает только… спецификацию и текст программы. Остальное — по решению заказчика. И это логично. Глупости начинаются, когда глупый исполнитель верноподданически предлагает изготовить полный комплект документов для любой фитюльки, и заказчик включает это в ТЗ.
Поэтому мой ответ такой — чем больше, чем крупнее проект, тем больше польза от применения ЕСПД.
С другой стороны, можно поставить вопрос шире — а нужно ли вообще описывать программу в виде классического документа? Не является ли более эффективной заменой документам специализированные программы, в которых накапливается в связном виде информация? К примеру, в инженерных областях есть PDM — так ли нужно ли при этом все выводить на бумагу? В программировании есть багтрекеры, системы управления требованиями, системы управления версиями — не содержат ли они больше информации, чем самый-пресамый толстый 13 документ?
По поводу компиляторов и т.д. — так называемыми инструментальными средствами. Мы делаем так: формируем диск 12 03, куда все это записываем, в бинарном виде. Главное условие — чтобы ничего с этого диска не нужно было для работы программы, т.е. не входило в поставку. «Все это» — это все, что нужно для сборки, но не образует отдельных продуктов. К примеру — mingw нужной версии, lex-yacc, nsis и т.д. Этот инструментальный диск не включается в схему деления, на него не выпускается документация, нет его в спецификации и т.д. Но ссылка на него есть в 96 документе «Инструкция по сборке», и он есть в архиве.
«Определенность» версии того, что нужно для сборки — это содержание «Инструкции по сборки» и инструментального диска. В «Инструкции..» написано, мол, брать из папки на диске такой-то файл, запускать с такими-то ключами, и т.д.
Если для сборки нужно другое изделие (например, операционка, или кросс-компилятор), то в «Инструкции...» указываем, то нужно, к примеру, ФЛИР.80001-12. В архив оно не сдается, т.к. это не наше изделие, мы не имеем права его «изготавливать».
То, что нужно для функционирования — это уже в ТУ.
Авторитет за ГОСТом такой, что по нему фигову тонну времени разрабатывается ПО. И поверьте — если бы он был бесполезен, ненужен — уж за 35 лет бы сподобились его отменить. Я не спорю, что в некоторых частях он устарел — но даже в таком виде он хорошо систематизирует результаты работы.
Что касается разборки по сорцам: вы идеалист. Вы полагаете, что код пишут Программисты. И среди них нет Уродов. Или, к примеру, Студентов. Я за последние пару лет несколько раз наблюдал, как списывают мегабайты кода после месяцев разборки с ними, потому что бесполезно. Документация левая, код из архива не собирается. И все.
Стандартизировать виды документов и содержание нужно, чтобы в вашем творчестве смогли разобраться другие люди — по возможности, быстро. Это раз. Чтобы не забыть описать один из аспектов изделия — два. Чтобы заказчик, не в зуб ногой в программировании, мог по формальному признаку принять документацию — три.
А бюрократия возникает от непонимания, зачем все это нужно. Когда люди кописастят по 300 страниц из «Описания программы» в «Руководство оператора», а потом сами не знают, куда смотреть, глядя на эту кипу.