Документирование по ГОСТ 34* — это просто / Хабрахабр
Софт. Программы для компьютера. Для пк

Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны.

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

Гост документации по разработке программного обеспечения

А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел. Что такое стандарты на документацию? В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию: Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований.

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

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

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

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

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

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

NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества. Как читать и понимать стандарты документации по ГОСТ серии 34 Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ Имеют отношение к документированию из них три: Эскизный проект ЭП Технический проект ТП Разработка рабочей документации РД Эскизный проект следует после стадии Техническое задание и служит для разработки предварительных проектных решений.

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

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

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

Примитивная модель простейшего автомата. Математическое обеспечение МО , отвечающее на вопросы: Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты? Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно.

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

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

Я уж не говорю о том, что этот документ не особенно сейчас и нужен. Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем. Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ!

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

В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист. Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП. А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать править по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.

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

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

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

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

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

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

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

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

Если не этому заказчику, так следующему передадите продадите.

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

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

Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую загашника у меня нет, пишу из головы. Программирование 2,9k авторов , 6,6k публикаций. Разработка веб-сайтов 4,1k авторов , 9,6k публикаций. Информационная безопасность 2,4k авторов , 6,4k публикаций.

Анализ и проектирование систем авторов , публикаций. Алгоритмы 1,3k авторов , 2,4k публикаций. NoSQL авторов , публикаций. Разработка игр 1,3k авторов , 2,9k публикаций. API автора , публикации. Open source 1k авторов , 2,3k публикаций. Тестирование веб-сервисов автора , публикации. Нда… Мне явно нужен хороший техписатель.

Где бы найти такого на постоянно-фрилансной основе за разумные средства? Тут на носу стадия ТП по крупному проекту. А всех техписов разобрали на другие проекты. А почему это хороший техписатель будет стоить разумных средствов? Типа, слова писать — наука не точная, не то что девелопмент, потому и стоит дешевле? А где я сказал что он должен стоить дешевле?

А разумные деньги — это вообще миф. Дорого стоит дорогой разработчик. А хороший стоит разумные деньги: На HH поищите, после собеседований можно найти светлую голову. Не в смысле блондинку, а человека адекватного хотя, может повезед и найдется адекватная блондинка: Да по-моему в нашей деревне всё плохо.

Да, свободный рынок как-то не очень работает. Я, например, ни разу не менял работу через агентство. Все время по знакомству переводился. А теперь вообще командой кочуем. Несколько раз делал попытки собеседоваться через ХХ. Кадровикам непонятно, за что мне вообще деньги платят.

Проще всего принять на работу админа начального уровня. Он только в дверь входит, а я уже знаю, подходит чувак или нет: С другими — пачка вопросов на адекватность и уменее свои мысли излагать особенно к техническим писателям: С кадровиками — это да, не все достаточно эффективно работают: Когда надо было — искал несколько месяцев, но нашел: Собственно стандарт нужен в лучшем случае при работе с гос-проектом, а в остальных случаях есть более специализированные и современные варианты.

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

Главное правило составления — устранение разночтений одних и тех же предложений. Это первое, что приходит в голову. Но обычно в шаблонах ТЗ есть ошибки, и эти ошибки тянутся шлейфом. Проще один раз взять ГОСТ и просто пойти по нему, глядя для справки в РД Ну я поэтому и сказал корректировать, хотя согласен что действительно лучше писать с нуля.

Примеры они на то и примеры чтобы просто посмотреть. Благодарность за статью, ценный труд. Спасибо, реализовал давний замысел зафиксировать накопленные знания. Теперь буду ссылку давать на свой же топик вместо того, чтобы по сто раз одно и то же объяснять: Проект на 15 человекомесяцев, требований со стороны заказчика по документированию нет, какие документы посоветуете написать?

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

Взять хотя бы бумажную документацию на 1С. Есть какие-то схемы, примеры, списки документов? Попробую в двух словах дать выжимку своих ощущений от этой темы. В идеале должно быть удобно и понятно пользователю продукта. Иначе говоря, тут две переменных — продукт и его целевая аудитория. Неказистый недостаточно хорошо спроектированный продукт порождает сложную документацию.

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

Клёвый продукт документировать легко, потому что целевая аудитория чётко определена. Автору тогда не нужно писать все возможные варианты документации, потому что он не представляет, чего захочется людям. Информационная плотность манов очень велика, воды там минимум, потому что они ориентированы на очень узкую ЦА, системных администраторов и внимательных энтузиастов. С другой стороны, если совокупная сложность продукта превышает определённый порог, иногда полезнее написать книгу, чем стописят манов, факов и экзамплов.

И почему, скажем, разработчикам байнда было сразу не написать увлекательную книжку, как поступили Крикет и Ли? Отдельный разговор — внутренняя документация для разработчиков. Для них иногда самая клёвая документация — это UML-диаграммы. И вот как на это всё можно натянуть ГОСТ? Польза ГОСТа, равно как и прочих стандартов, в, простите, стандартизации.

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

Если формат продукта такой, что это допустимо, ничего страшного нет. Хотя мне кажется, у авторов клёвых продуктов вообще изначально забота о пользователях выше. Какие-то схемы, примеры и списки я приводить, пожалуй, не буду — кажется, особого смысла нет.

Гост документации по разработке программного обеспечения

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

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

У программистов нет фантазии, им это вообще не нужно. Постановка может содержать уже и Use Case, и эскизы интерфейсов и все, что угодно, чтобы программист понял задачу. Документация по ГОСТ сделана таким образом, что она может появляться вместе с системой, параллельно.

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

Думаю, последнее можно обобщить — документация по любому стандарту может появляться вместе с системой. Популярная книжка, конечно, требует какой-то живой экосистемы продукта, но хочется подчеркнуть, что дефолтная документация не должна быть убогой. Документация убогая, когда пишущий: Мы по ГОСТ работаем и пишем вполне себе приятные тексты на литературном русском языке: Просто не все понимают, что ГОСТ оставляет ОЧЕНЬ много свободы для адаптации документов под конкретные задачи или ввода новых документов хотите инструктивный материал — ввели новый документ и вперед!

А там это черным по белому написано: Даже если тыкнуть носом в абзац РД50, где написано, что разработчик может на свое усмотрение исключать или добавлять разделы, иной заказчик все равно подозревает страшное. У адекватных людей проблем никаких нет. Есть типовое решение подобных вопросов, которое я знаю оно не обязательно верное.

О пользе эскизного проекта я не слышал. Образно говоря, ЭП нужен для изъятия дополнительных дензнаков у заказчика. Вам в итоге можно ограничиться двумя тремя документами. Пишете Пояснительную записку к техпроекту П2 , куда включаете необходимый вам контент в виде разделов по РД50 и руководство пользователя по ГОСТ. Если у вас приложение сложное в обслуживании, сделайте еще Руководство администратора отдельная книжечка. По сути это просто глава из РП, но так будет проще согласовывать. Заодно там будет минимально необходимый технический контент стадии РД см.

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

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

Статья и так распухла до безобразного размера, чтобы ее наполнять еще и описанием жизненного цикла. Это будет уже книжка, а не статья. Во что я твердо верю, это в то, что при желании и ясном представлении цели можно сделать очень многое. У нас в стране светлые головы еще не перевелись. Раньше несоблюдение стандартов преследовалось по закону. Сейчас выполнение стандартов не обязательно — вместо них пытаются ввести новые виды документов. Стандартизация — тормоз прогресса. Если бы проекты писались по всем стандартам, то многого, что у нас сейчас есть не было.

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

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

А исполнитель не будет ломать голову над форматом изложения, например, правил написания конфига, а откроет ГОСТ, найдет структуру соответствующего документа и ее заполнит. Посмотрите мой материал на Хабре по американскому стандарту ИТС.

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

Что же касается самого ГОСТ, то при разумном его использовании, можно создавать внятные и полезные документы. Если доки не просто формальная отписка и написаны толковыми спецами, то по ним вполне можно вникнуть как работает система, посмотреть на нее с разных аспектов. В чем готовите документы, если не секрет? Слышал, что наиболее эффективно готовить в спецпакетах — Adobe FrameMaker и иже с ним. Сам никогда во FrameMaker, но судя по описанию принципа работы, подготовка комплекта документов в нем более гибка, чем в Ворде.

Я слышал, что ГОСТ 34 выпускали в спешке. И за 20 лет он конечно успел устареть. Но в СССР ГОСТы обновлялись гораздо чаще. Все равно, это лучше, чем ничего. Обычно ТЗ пишут в форме потока сознания, а все схемы исполнитель рисует от руки. Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи … и персонала. Если система работает без участия человека, то она уже автоматическая например, пожаротушения , а не автоматизированная. Сейчас Вчера Неделя Как и зачем скрывать телефонные номера 35k Увольнение — это маленькая смерть.

Как сохранить ценного специалиста решившего уволиться? Вы ни черта не понимаете в цветах 37,6k Интересные публикации Хабрахабр Geektimes.

Гост документации по разработке программного обеспечения

Lockheed Martin строит прототип обитаемого модуля для глубокого космоса GT. Приглашаем на Tarantool Meetup 10 августа. JSDash промежуточные результаты 2. Обзор интраоральных стоматологических 3D-сканеров GT. Новые механические клавиатуры HyperX Alloy Elite и Alloy FPS Pro: Национальная инновационная система США GT.

Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.

Опубликовано в рубрике Xerox
Twitter Delicious Facebook Digg Stumbleupon Favorites More
  • Прикрепленное видео

Все права защищены. © 2001 toozza.ru