8-900-374-94-44
Техническое решение (ТР) является структурной частью технического творчества. Оно определяет принципиальные, схематические, теоретические решения и не всегда носит конкретную форму реального материального объекта (изделия), но непосредственно связано с его определенным содержанием с конструкцией, технологией, принципом работы пли материалом. Техническое решение представляет собой раскрытую техническую идею, которую можно осуществить с привлечением специалистов, не применяя изобретательских принципов. Оно должно быть практически осуществимым, полезным, работоспособным, причем принцип работы не обязательно должен иметь теоретические обоснования.
Разработка является техническим творчеством, в результате которой создаются технические решения. Созданию технического решения предшествует подготовительный процесс, в котором обобщается предыдущий опыт, ставится задача, уясняется цель. В разработку технического решения непосредственно входит создание его вариантов и их анализ, выбор окончательного варианта. В процессе конструирования конструктор детально обрабатывает техническое решение, воплощает его в конкретную форму реального изделия
Технические решения характеризуются признаками, которые в зависимости от их важности делятся па существенные (главные) и дополнительные. Любой реальный объект воспринимается нами как сочетание его отдельных признаков. Общее понятие, например, ведущего зубчатого колеса в нашем воображении предстает как предмет деталей машины, даже если мы не имеем перед собой чертежа или реального образца. Ведущее зубчатое колесо в нашем воображении предстает как зубчатый венец, посредством корпуса соединенный с центрирующей частью, которая, в свою очередь, имеет устройство для передачи вращающего момента (рис. 2.2).
Таким образом, среди множества признаков, характеризующих техническое решение, имеются такие, которые выражают сущность, природу и коренные свойства технического решения. Эти признаки называются существенными. Каждый существенный признак необходим, а все вместе они достаточны для характеристики технического решения.Дополнительными признаками являются признаки, которые дополняют, развивают и уточняют техническое решение.
Технические решения в зависимости от степени сложности конструктивного исполнения делятся на простые и сложные.
Рис.
2.2. Функциональная структура зубчатого
колеса
Сложныетехнические решения имеют иерархическое строение, т. е. существенные признаки решения в целом представляют собой самостоятельные технические решения низшего порядка. Технические решения низшего порядка, свою очередь, могут делиться на ряд существенных признаков. Эти существенные признаки являются дополнительными признаками решения в целом и могут являться самостоятельными техническими решениями. Технические решения, существенные признаки которых не могут представлять собой самостоятельные технические решения, называются
Технические решения могут откоситься к изделию в целом, его функциональному узлу, к детали узла или к конструктивному элементу детали. В зависимости от места технического решения в общем функциональном строении конструкции решение получает свое наименование, например зубья зацепления с закругленными торцами, а не зубчатое колесо ведущее с закругленными торцами зубьев.
Техническое решение выявляется только в процессе разработки или проведения анализа конструкции и принципов работы изделия. В технической документации и в действующем изделии технические решения воплощены в определенной совокупности узлов, деталей или их элементов. В процессе разработки вырабатываются технические решения, являющиеся основой построения детали, узла или изделия в целом. Чем подробнее прорабатываются выбранные технические решения, тем белее совершенной и качественной получится конструкция. Технические решения могут служить для сравнения и оценки разных изделий. Нередко в практике разработки приходится оценить и выбрать более подходящее изделие из множества аналогов. Всю разработку в целом сравнить трудно, особенно если конструкция сложная и включает в себя разные узлы и системы: электрические, гидравлические и др. Сравнению поддаются технические решения, к которым можно применить общий критерий, характеризующий главный принцип выбора.
Новые разработки, включая применение в них ранее разработанных конструкций и принципов работы, являются творческим созданием конструктора. Каждый конструктор создает собственные решения, которые, по его мнению, не имеют прецедента. Как любой объект творческой деятельности новая разработка в целом и технические решения, заключенные в ней, имеют определенные отличия от известных, обладают определенной новизной. Эти отличия могут проявиться в форме, размерах, компоновке, принципе работы, применяемом материале и др.
Новизна технического решения—важная ее характеристика. Она определяет тот круг лиц, для которых данное решение известно. Техническое решение, новое для автора, может оказаться известным для других лиц. В самом деле, разработчики постоянно «изобретают» уже ранее изобретенные технические решения. Определение степени новизны технических решений дает возможность оценить уровень разработок. Технические решения, характеризующиеся существенными отличиями, новизной и обеспечивающие положительный эффект, представляют общественный и государственный интерес. Эти технические решения лежат в основе изобретений и рационализаторских предложений.
studfiles.net
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)
ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем
Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.
Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.
РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов
Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.
К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.
Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.
5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.
«Видеокадр» — это тоже документ, который выводился на текстовый дисплей. Дисплеи не всегда поддерживали нужные символы и нужное количество символов по горизонтали и строк по вертикали (а графику вообще не поддерживали). Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов.
Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.
Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.
А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.
Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.
Можно смеяться над тем, что создатели стандартов ничего не знали о java или .NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.
Технический проект описывает будущую систему со всех ракурсов. Документы стадии ТП должны после прочтения оставлять после себя полную ясность в предлагаемых подходах, методах, архитектурных и технических решениях. На следующей фазе уже поздно будет описывать подходы и обосновывать технические решения, так что фаза П является ключом к успешной сдаче работ, так как все многообразие требований ТЗ должно находить отражение в документах фазы П. На этапе П система может вообще не существовать.
Рабочая документация предназначена для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Это документы, содержащие совершенно конкретные сведения, описывающие физически существующие сущности, в отличие от фазы П, где описывается будущее великолепие.
Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи, которая обрабатывает приходящую из разных источников информацию в соответствии с некими алгоритмами и выдает результаты обработки в виде документов, структур данных или управляющих воздействий. Примитивная модель простейшего автомата.
Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):
Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?
Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.
Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.
Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?
Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем.
Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.
В этом документе мы должны рассказать, при помощи каких программных средств выполняются алгоритмы, описанные в МО, обрабатывающие информацию, описанная в ИО. То есть, не нужно дублировать тут информацию из других разделов. Тут дается архитектура системы, обоснование выбранных программных технологий, их описание (всякие системные вещи: языки программирования, фреймворки, операционки и т.п.). Также в этом документе мы описываем как организованы средства обработки информации (очереди сообщений, хранилища, средства резервного копирования, решения по доступности, всякие пулы приложений и т.п.). В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист.
Техническое обеспечение (ТО). Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.
Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.
Не забывайте также, что комплекс стандартов качества подразумевает учет и хранение технических документов, и наши «книжицы» у заказчика могут разойтись по разным архивам, в зависимости от предмета описания. Это еще один аргумент в пользу дробления документации.
Организационное обеспечение (ОО). Подавив в себе нормальное для технаря желание проскочить этот раздел поскорее, наоборот, рассмотрю его более подробно. Так как, коллеги, в последнее время на проектах наметились нехорошие тенденции, которые требуют внесения ясности именно в этот раздел.
На стадии ТП раздел содержит всего один документ «Описание организационной структуры», в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.
На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.
Руководство пользователя. Комментарии излишни, я думаю.
Методика (технология) автоматизированного проектирования. В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.
Технологическая инструкция. В связи с модой на формализацию бизнес процессов, в этот документ ушлый заказчик иногда стремится запихнуть регламенты работы службы эксплуатации. Так вот, делать этого ни в коем случае не нужно.
Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы — все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.
Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим. Мы эти бизнес-процессы автоматизируем.
Об описанных граблях я еще напишу отдельно, с красочными примерами, так как это повторяется уже не первый раз и в разных отраслях «народного хозяйства».
Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция — для них. Что в нее писать в XXI веке — я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.
Общесистемные решения (ОР). Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала — менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.
А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.
Варианты использования ГОСТ 34
Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).
habr.com
ГОСТ 15.016-2016
Система разработки и постановки продукции на производство
МКС 01.100.01
Дата введения 2017-09-01
Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены».
Сведения о стандарте
1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ)
2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии
3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 25 октября 2016 г. N 92-П)
За принятие проголосовали:
Краткое наименование страны по | Код страны по | Сокращенное наименование национального органа по стандартизации |
Армения | AM | Минэкономики Республики Армения |
Киргизия | KG | Кыргызстандарт |
Россия | RU | Росстандарт |
Таджикистан | TJ | Таджикстандарт |
4 Приказом Федерального агентства по техническому регулированию и метрологии от 14 марта 2017 г. N 135-ст межгосударственный стандарт ГОСТ 15.016-2016 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2017 г.
5 ВВЕДЕН ВПЕРВЫЕ
Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Настоящий стандарт устанавливает требования к построению, содержанию, изложению, оформлению, порядку согласования и утверждения технического задания на выполнение научно-исследовательских и опытно-конструкторских работ в области изделий машиностроения и приборостроения.
В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:
ГОСТ 2.001-2013 Единая система конструкторской документации. Общие положения
ГОСТ 2.102-2013 Единая система конструкторской документации. Виды и комплектность конструкторских документов
ГОСТ 2.103-2013 Единая система конструкторской документации. Стадии разработки
ГОСТ 2.105-95 Единая система конструкторской документации. Общие требования к текстовым документам
ГОСТ 2.116-84 Карта технического уровня и качества продукции
ГОСТ 2.118-2013 Единая система конструкторской документации. Техническое предложение
ГОСТ 2.119-2013 Единая система конструкторской документации. Эскизный проект
ГОСТ 2.120-2013 Единая система конструкторской документации. Технический проект
ГОСТ 2.301-68 Единая система конструкторской документации. Форматы
ГОСТ 2.601-2013 Единая система конструкторской документации. Эксплуатационные документы
ГОСТ 3.1001-2011 Единая система технологической документации. Общие положения
ГОСТ 3.1102-2011 Единая система технологической документации. Стадии разработки и виды документов. Общие положения
ГОСТ 14.201-83 Обеспечение технологичности конструкции изделий. Общие требования
docs.cntd.ru
ГОСТ 15.005-86
Группа Т52
СОЗДАНИЕ ИЗДЕЛИЙ ЕДИНИЧНОГО И МЕЛКОСЕРИЙНОГО ПРОИЗВОДСТВА, СОБИРАЕМЫХ НА МЕСТЕ ЭКСПЛУАТАЦИИ
System of products development and launching into manufacture. Development of single and small-scale production units assembled at the place of use
МКС 01.110
ОКСТУ 0015
Дата введения 1987-01-01
1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам
РАЗРАБОТЧИКИ
А.Л.Теркель, канд. техн. наук; О.В.Яременко, канд. техн. наук; Ю.А.Кияшев; Г.П.Бассейн; В.Г.Цыкаленко; В.Б.Яров; Б.М.Бейлинсон; Н.Д.Маркозов; М.С.Сахаров; Б.И.Калиненок, канд. техн. наук; И.Т.Ямалутдинов; Л.П.Белоусова; М.К.Комаровская
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 15.10.86 N 3095
Изменение N 4 Принято Межгосударственным советом по стандартизации, метрологии и сертификации (протокол N 49 от 15.03.2012)
За принятие изменения проголосовали национальные органы по стандартизации следующих государств: BY, KZ, KG, RU, UA
Дату введения в действие настоящего изменения устанавливают указанные национальные органы по стандартизации*
________________
* Дата введения в действие на территории Российской Федерации — 2012-09-01.
3. ВВЕДЕН ВПЕРВЫЕ
4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
Обозначение НТД, на который дана ссылка | Номер пункта | |||
ГОСТ 15.012-84 | 1.7 | |||
5. Ограничение срока действия снято Постановлением Госстандарта СССР от 17.07.89 N 2390
6. ИЗДАНИЕ (август 2012 г.) с Изменениями N 1, 2, 3, 4, утвержденными в апреле 1987 г., январе 1988 г., апреле 1989 г., марте 2012 г. (ИУС 7-87, 4-88, 7-89, 11-2012)
Настоящий стандарт устанавливает порядок разработки, согласования и утверждения технического задания, технической документации, а также порядок изготовления, контроля, монтажа, приемки и сдачи в эксплуатацию изделий единичного и мелкосерийного производства и их составных частей, контрольная сборка, доизготовление, окончательная сборка, наладка, испытания и доводка которых могут быть проведены только на месте эксплуатации в составе конкретного производственного объекта.
Стандарт не распространяется на указанные изделия, разрабатываемые по заказам Министерства обороны РФ*.
________________
* Для Российской Федерации.
Положения настоящего стандарта обеспечиваются заказчиком (основным потребителем), разработчиком и изготовителем при создании и освоении продукции.
Термины, применяемые в стандарте, и пояснения к ним приведены в приложении 1.
(Измененная редакция, Изм. N 3, 4).
1.1. Изделия единичного и мелкосерийного производства, собираемые на месте эксплуатации (далее — изделия), подлежащие разработке, на момент сдачи в эксплуатации должны удовлетворять требованиям технических регламентов, межгосударственных, национальных стандартов, сводов правил, обеспечивать эффективное функционирование объекта или выполнение технологического процесса, для которого они предназначены.
Требования к техническому уровню продукции устанавливают с учетом требований, предусмотренных в законодательных и иных нормативных актах.
(Измененная редакция, Изм. N 4).
1.2. Создание изделий осуществляется на основе договоров между заказчиком, разработчиком, изготовителем, а также другими организациями, привлекаемыми ими к выполнению отдельных работ.
Разработка продукции может выполняться по конкурсу в соответствии с положением о нем. Результаты разработки как вид научно-технической продукции передаются заказчику или, по его указанию, изготовителю для производства промышленной продукции.
(Измененная редакция, Изм. N 2, 3).
1.3. Исходным документом для создания изделий является техническое задание или другой документ (контракт, протокол и т.п.), содержащий необходимые и достаточные требования для разработки и признанный заказчиком и разработчиком (далее под техническим заданием следует также понимать документ, заменяющий его).
1.4. Оценка технического уровня изделия проводится на этапе рассмотрения технического проекта (при его отсутствии — рабочей документации) с участием заинтересованных организаций. Результаты оценки являются основанием для отнесения изделия к соответствующей категории качества.
1.3, 1.4. (Измененная редакция, Изм. N 3).
1.5. Карту технического уровня и качества продукции как самостоятельный документ не оформляют, а необходимые сведения о сравнении показателей с аналогами включают в техническое задание.
1.6. Изготовление, приемку и поставку этого изделия (партии) осуществляют в соответствии с техническим заданием.
В случае продолжения производства данных изделий разрабатывают технические условия, которые согласовывают, утверждают и регистрируют в соответствии с НТД.
По согласованию с заказчиком при повторении индивидуального заказа допускается технические условия не составлять, а изготовление, приемку и поставку изделия (партии) осуществлять по ранее разработанному ТЗ.
(Измененная редакция, Изм. N 3, 4).
1.7. Патентный формуляр по ГОСТ 15.012 составляют по согласованию заказчика и изготовителя.
1.8. Решение по разногласиям, возникающим на всех этапах создания изделий, регулируются в претензионном или судебном порядке и руководствуются Гражданским кодексом и иными нормами законодательства стран СНГ.
1.6-1.8. (Измененная редакция, Изм. N 4).
1.9. (Исключен, Изм. N 3).
2.1. Техническое задание (ТЗ) разрабатывают и утверждают совместно заказчик и разработчик, изготовители, организация, осуществляющая сборку, если иной порядок не установлен этими сторонами по договоренности.
В процессе разработки ТЗ для получения исходной информации при необходимости привлекают разработчика (заказчика), изготовителя, головного проектировщика, организацию, производящую сборку и монтаж.
ТЗ на технологический комплекс, поставляемый комплектно потребителю согласно перечню, разрабатывают совместно с организацией, осуществляющей сборку и/или монтаж.
(Измененная редакция, Изм. N 2, 3, 4).
2.2. В ТЗ в общем случае устанавливают технические и экономические требования к изделию, в том числе уровню заводской готовности и монтажной технологичности, требования к разработке, изготовлению и приемочному контролю, включая объем заводской контрольной сборки и испытаний, требования к комплектности поставки, а также требования к строительной части, наладке, испытаниям на объекте, приемке, техническому обслуживанию и ремонту.
В ТЗ должны быть указаны ориентировочные сроки разработки, изготовления, контрольной сборки, сборки, монтажа на месте эксплуатации, монтажа и сдачи изделия в эксплуатацию.
Не допускается включать в ТЗ требования, которые противоречат требованиям стандартов и нормативных документов органов, осуществляющих надзор за безопасностью, охраной здоровья и природы.
При наличии у заказчика индивидуальных требований к разрабатываемой продукции, которые отличаются от требований стандартов, но не снижают эффективности применения продукции в оговоренных условиях, следует составлять специальные технические условия, согласованные в Главгосэкспертизе России*.
________________
* Для Российской Федерации.
(Измененная редакция, Изм. N 1, 3, 4).
2.2.1. (Исключен, Изм. N 3).
2.3. Необходимость согласования ТЗ с заинтересованными организациями определяет разработчик совместно с заказчиком.
(Измененная редакция, Изм. N 1, 3, 4).
2.4, 2.5. (Исключены, Изм. N 3).
2.6. При необходимости изменения ТЗ оно осуществляется на любом этапе создания изделия оформлением протокола, подписанного заказчиком, разработчиком и изготовителем. Указанный протокол является неотъемлемой частью ТЗ. На титульном листе ТЗ должна быть запись «Действует совместно с протоколом N … от …».
2.7. Действие ТЗ распространяется на все этапы создания изделия (п
docs.cntd.ru
Доброе время суток!
Решил создать новый подраздел с примерами конкретных технических решений систем видеонаблюдения с учётом всех нюансов с питанием и заземлением. Примеры будут из жизни, но, естественно, без указания названий и координат объектов. Ну и, чтобы не тянуть кота за хвост, — Пример №1:
Исходные данные.
Имеем длиннючий супермаркет, порядка 130м в длину, к которому добавилась некая пристройка со своей локальной охранной сигнализацией (ОС). В супермаркете имеется действующая аналоговая система видеонаблюдения и охранная сигнализация. Есть еще и пожарная естественно, но в данном случае она нас не интересует. Системы ОС в супермаркете и пристройке совместимы — обе на базе приборов системы «Орион» производства фирмы «Болид» (Королёв) — безусловного российского лидера в системах сигнализации. На одном из видеорегистраторов (самом удалённом — в полном соответствии с законом бутера) имеется несколько свободных видеовходов. Вот максимально упрощённая схема здания:
Задача:
— соединить приборы охраны, находящиеся в пристройке, с приборами, стоящими в помещении поста охраны супермаркета, для создания единой системы охраны;
— разместить в пристройке 3 видеокамеры и вывести сигналы от них на удалённый видеорегистратор;
— добавить в торговом зале супермаркета одну камеру и так же вывести сигнал от неё на видеорегистратор.
Путём титанических напряжений мозговой извилины родилось решение использовать для передачи видеосигнала от камер и данных от приборов охраны (интерфейс RS-485) кабель FTP 4х2 — 4 витых пары в общем экране в уличном исполнении. Дело в том, что потолки этого супермаркета крайне сложны для прокладки кабеля и тащить 100 с лишним метров за потолками- это лучше сразу залезть в микроволновку и самоубиться, как тот кот у Рафшана и Джумшуда.
Здесь надо заметить, что злейшим врагом инженера систем безопасности является дизайнер, интерьерный или ландшафтный — без разницы. Для нас, технарей, идеальный ландшафт — это голое бетонное поле с полосой отчуждения, регулярно встречающимися пулемётными точками, прожекторами, овчарками по периметру и табличками «стой, запретная зона». То же самое, с некоторыми поправками, можно сказать об идеальном интерьере. Но само существование этих ботаников подразумевает наличие густой растительности в самых опасных местах периметра, всяческие неровности и альпийские горки на просматриваемой территории, дурацкие многоуровневые гипсовые потолки, где невозможно протянуть кабель, и прочие громоздкие гадости, которые не только мешают работе, но ещё постоянно норовят обрушиться и похоронить все плоды трудов. Отдельно большое человеческое мерси хочется сказать рекламщикам. Они вешают свои баннеры и всяческие осветительные прожектора перед «мордой лица» телекамер, полностью закрывая обзор или ослепляя, с такой дивной изобретательностью, что просто диву даёшься. В конце концов — можно не любить. но за что же так ненавидеть?
В общем, кабель между пристройкой, постом охраны и удалённым регистратором протянули над крышей по тросу, т.к. чердака у здания нет. Отсюда и кабель в исполнении для уличной прокладки и экран: заземлённый экран значительно снижает вероятность выгорания оборудования от грозовых разрядов (здесь на сайте есть более подробная статья о грозозащите). Согласование 75-омного выходного сопротивления телекамер с волновым сопротивлением витой пары выполнено с помощью пассивных приёмопредатчиков видеосигнала по витой паре (или балунов — balun от слов balanced/unbalanced, по нашему симметричный/несимметричный). Вот так вот оно выглядит:
Пассивные были выбраны, т.к максимальная длина линии невысока — порядка 150м-170м с учётом всяких переходов с этажа на этаж, петель запаса и т.д. Стоимость пары таких балунчиков — рублёв 300-500, кушать ввиду пассивности не просят, монтаж — проще некуда, габариты мизерные, короче — сплошное удовольствие.
Немножко о передаче видеосигнала по витой паре. Я упоминал этот метод в подразделе об интерфейсах видеокамер. Чуть подробнее. Вся прелесть этого способа передачи видеосигнала заключается в симметричности линии передачи. Коаксиальный кабель несимметричен по определению — он состоит из тонкого центрального проводника, закрытого снаружи оплёткой гораздо большей площади, которая выполняет роль второго проводника. Естественно, что внешнее электромагнитное поле наведёт гораздо более сильную помеху на оплётку, чем на центральный проводник. Отсюда между проводниками возникает разность потенциалов т.н. синфазной помехи, накладывающейся на видеосигнал и вызывающей сильные искажения изображения. Так при параллельном пробеге коаксиала с силовыми кабелями наводки могут привести к полному срыву синхронизации и пропаданию изображения.
Витая же пара, выполненная промышленным способом, представляет из себя два проводника, свитых между собой, с постоянным шагом, практически одинаковых геометрически. Соответственно, внешнее электромагнитное поле наведёт одинаковую помеху на оба проводника, т.е. разность потенциалов синфазной помехи на проводниках будет стремиться к нулю, и, как следствие, соотношение сигнал/шум будет гораздо выше. Отсюда и повышенная дальность передачи сигнала и очень высокая устойчивость к наводкам от всяческой «силовухи.» Честно говоря, не знаю, почему аналоговое видеонаблюдение так цеплялось за свои коаксиалы, пока не появилось IP-видео. Информационщики тоже раньше гоняли Ethernet по коаксиалу да быстро перешли на витуху, оттуда и выигрыш по скоростям и технологичности.
Схема соединений получилась следующей:
Схема, в целях компактности, топографически не совпадает с приведённым выше планом, так что напрягаем извилину.
Суть нарисованного следующая. От помещения поста охраны исходит три отрезка кабеля:
— в пристройку,
— к камере в здании супермаркета,
— к удалённому регистратору.
От пристройки приходят сигналы:
— по синей, оранжевой и зелёной парам — видеосигналы от трёх телекамер,
— по коричневой паре — данные по интерфейсу RS-485 для объединения в одну систему оборудования охранной сигнализации, расположенного в щитах ОПС пристройки и основного здания супермаркета,
— свободные от видеосигнала отрезки этих же пар используются для подачи к телекамерам питания 12В от источника, расположенного в шкафу ОПС пристройки (см. схему)
Отрезок кабеля, идущий в сторону камеры расположенной в торговом зале основного здания используется для подачи на камеру питания (зелёная пара) от центрального щита ОПС и передачи от камеры видеосигнала (коричневая пара).
Сигналы интерфейса RS-485 благополучно коммутируются в центральный щит ОПС. А все 4 полученных видеосигнала по третьему отрезку кабеля передаются на удалённый регистратор.
Можно добавить, что схема упрощена. Например 485-й интерфейс подключен через приборы С2000-ПИ (преобразователь интерфейса), использующиеся здесь как буферы с гальванической развязкой. Не стал загромождать рисунок обозначениями экранированного кабеля — и так написано, что витуха с экраном.
В общем, схема проста до неприличия (так и подмывает написать «как и всё гениальное»). Из хитростей наверное можно упомянуть только заземление.Все удалённые источники питания заземлены только по высокой стороне (со стороны 220В). Низковольтная часть и, соответственно, сигнальный общий видеокамер соединены с землёй только через видеорегистратор. О заземлении телекамер я писал уже отдельную статью.
Там же кстати заземлён и экранный контактный проводничок. Это делать крайне желательно при уличной прокладке кабеля для защиты от грозовых разрядов. При прокладке внутри помещений я особого эффекта от подобных экранов не замечал.
Ну вот, в общем и всё. Особо нового здесь ничего не открыто. Достигнуто некоторое снижение стоимости за счет передачи 4-х видеосигналов по одному кабелю, сравнимому по стоимости с приличным коаксиалом. Вот только коаксиалов понадобилось бы 4 шт.
Помехоустойчивость витой пары здесь себя особо не проявила, т.к. кабель протянут по крыше, вдали от мощных источников наводок.
Так что позвольте откланяться до следующего припадка вдохновения.
Вопросы — в комментарии, подписывайтесь — форма внизу.
В общем, до связи.
На главную, к оглавлению, в начало
systemdefend.ru
ГОСТ 19.201-78
Группа Т55
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
Единая система программной документации
ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ
Unified system for program documentation. Technical specification for development. Requirements for contents and form of pressentation
МКС 35.080
Дата введения 1980-01-01
Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. N 3351 дата введения установлена 01.01.80
ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в июне 1981 г. (ИУС 9-81).
Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1627-79*.
________________
* Доступ к международным и зарубежным документам, упомянутым здесь, можно получить, перейдя по ссылке на сайт http://shop.cntd.ru. — Примечание изготовителя базы данных.
(Измененная редакция, Изм. N 1).
1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.
(Измененная редакция, Изм. N 1).
2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
2.2. В разделе «Основание для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
2.1, 2.2 (Измененная редакция, Изм. N 1).
2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
(Измененная редакция, Изм. N 1).
2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.
2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
2.4.5 В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
При необходимости должна обеспечиваться защита информации и программ.
(Измененная редакция, Изм. N 1).
2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
2.5а. В разделе «Требования к программной документации» должны быть указаны предварительный состав программной документации и, при необходимости, специальные требования к ней.
(Введен дополнительно, Изм. N 1).
2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.
2.8. В приложениях к техническому заданию, при необходимости, приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
другие источники разработки.
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
Единая система программной документации:
Сборник национальных стандартов. —
М.: Стандартинформ, 2010
docs.cntd.ru
Раздел ТХ «Технологические решения» В большинстве случаев, раздел ТХ разрабатывается параллельно с разделом «Архитектурные решения». В процессе работы, инженер-технолог выдает задания архитекторам, конструкторам и инженерам для увязки всех решений в единую систему. Раздел «Технологические решения» выполняется для объектов: Производственного назначения Общественных Общественного питания Административных зданий Торговых Здравоохранения Образования и др.
Технические решения Если такой документ как «Технические решения»? Если есть , то по какому ГОСТу следует его делать?
Заранее спасибо
Наш заказчик в одном ТЗ сам составил список того, что должно быть в Технических решениях.
Техническое обоснование. Пример, шаблон, образец. Советы, рекомендации по составлению, написанию Как правильно составить техническое обоснование?
Рекомендации с примерами. (10+) обоснование. Образец Материал является пояснением и дополнением к статье: Как написать, составить обоснование?
Как обосновать предлагаемое решение?
Приведу пример обоснования.
условия в строительстве Однако, важнейшей и неотъемлемой частью проектно-технической документации все же остаются условия в строительстве (ТУ).
Виды условий В зависимости от обеспеченности планируемого к строительству здания действующими нормативными положениями, ТУ могут быть разработаны в следующих вариантах или видах: Разработка условий Технические условия должны разрабатываться лишь после утверждения здания на проектирование.
Оформление исполнительной документации в строительстве: основные требования
Общая информация Порядок ведения документации Один из ключевых вопросов в сфере исполнительной документации — порядок ее ведения: Что входит в состав? Один из ключевых вопросов — что является частью исполнительной документации.
Строительная документация. Виды строительной. При подготовке можно выделить следующие этапы: 2.
Стадия подготовки технико-экономического обоснования, которая включает определение важнейших параметров объекта, предварительное согласование с государственными уполномоченными органами, а также органами местного самоуправления. 3. Стадия проектирования заключается в конкретизации основных положений проектно-технической, выполнение всех чертежей и составление сметы на строительство.
ТЕХНИЧЕСКОЕ РЕШЕНИЕ СТРУКТУРНАЯ ЧАСТЬ РАЗРАБОТКИ ТЕХНИЧЕСКОЕ РЕШЕНИЕ СТРУКТУРНАЯ ЧАСТЬ РАЗРАБОТКИ — раздел Философия, СПЕЦИАЛИЗАЦИЯ КОНСТРУКТОРСКИХ ОРГАНИЗАЦИЙ Решение (Тр) Является Структурной Частью Технического Творчества. Технические решения в зависимости от степени сложности конструктивного исполнения делятся на простые и сложные.
Строительная: ее основные виды и особенности
Производственная документация ( о соответствии) Исполнительная документация Обеспечивает и подтверждает проведение строй контроля по производству монтажно-строительных работ объекта. В ней должны содержаться все показания тех-состояния строящегося сооружения.
Техническая документация в строительстве Проектная организация «Галактион» предлагает полный спектр услуг по составлению для строительства по всей России.
Проектно сметная документация Разработка проектно сметной документации В окончательный комплект проектно-сметной документации, как правило, входят проектная и рабочая.
respect66.ru