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