Для чего техническая документация
Технические документы
Заказать любые необходимые документы (технические условия, технологические регламенты и инструкции, СТО и т.д.) вы сможете в центре «КубаньСертификация». Минимальные сроки разработки. Бесплатные консультации. Доставка по всей России.
Техническими называют сопроводительные документы, используемые для производства продукции, её ремонта, проектирования и эксплуатации. В зависимости от этапа, на котором она потребуется, различают конструкторскую, ремонтную (сервисную), технологическую и эксплуатационную документацию. У каждого документа своя задача:
Кроме этих (основных) документов в пакет техдокументации предприятия входят и другие документы для получения сертификата:
Основной документ – технические условия
Это единственный документ, который не описывает и не регламентирует уже имеющиеся, а устанавливает новые правила и режимы – т.е. порядок технологического процесса.
ТУ похожи на ГОСТ. Независимо от того, были ли они разработаны на самом предприятии, куплены у изготовителя похожей продукции или заказаны специалистам, ТУ будут охраняться государством в качестве частной собственности вашей организации.
Когда для подтверждения соответствия выбирается нормативный документ, технические условия тоже могут быть использованы в этом качестве, если –
ТУ могут быть разработаны на весь техпроцесс или отдельный его этап. Если речь идет все же об основном для вашего производства техпроцессе, то технические условия обозначают все этапы цикла, периодичность, средства и методы контроля, методики проверки качества продукции, требования к условиям ее хранения и транспортировки.
Другие технические документы для получения сертификата
ТИ – технологические инструкции описывают (не устанавливают) процессы: последовательность операций, методы и приемы;
ТР — технологические регламенты нормируют установленные ТУ процессы в части эксплуатации оборудования, норм расхода (времени, материалов, сырья и др;
СТО – созданный предприятием стандарт управления;
Вам не обязательно досконально разбираться в особенностях каждой бумаги. Вы можете
просто заказать у нас сразу все документы для получения сертификата или вступления в СРО, участия в тендере и т.д. Наши специалисты разъяснят значение каждого из них для предприятия, есть ли реальная необходимость в них и т.д.
Для чего техническая документация
ГОСТ Р ИСО 11442-2014
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ НА ПРОДУКЦИЮ
Technical product documentation. Document management
Дата введения 2016-01-01
Предисловие
1 ПОДГОТОВЛЕН ООО «НИИ экономики связи и информатики «Интерэкомс» (ООО «НИИ «Интерэкомс») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
6 ПЕРЕИЗДАНИЕ. Декабрь 2018 г.
1 Область применения
Настоящий стандарт устанавливает основные правила организации работ с техническими документами.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты*, которые необходимо учитывать при использовании настоящего стандарта. В случае ссылок на документы, у которых указана дата утверждения, необходимо пользоваться только указанной редакцией. В том случае, когда дата утверждения не приведена, следует пользоваться последней редакцией ссылочных документов, включая любые поправки и изменения к ним:
ISO 16016, Technical product documentation. Protection notices for restricting the use of documents and products (Техническая документация на продукцию. Защитные уведомления, ограничивающие использование документов и продуктов)
3 Термины и определения
В настоящем стандарте применены термины по ИСО 10209-1, а также следующие термины с соответствующими определениями:
3.1 анализ (analysis): Часть процесса разработки продукции, связанного с подготовкой спецификации требований.
3.2 фаза утверждения (approval phase): Стадия, на которой содержание документа формально проверяется и утверждается.
3.3 архивная копия документа (archive master): Репродукция документа для длительного хранения в соответствующем формате кодирования.
3.4 фаза архивирования (archiving phase): Стадия, на которой документы на продукцию передаются из хранилища активных документов в исторический архив.
3.5 авторизация (authorization): Определение привилегий для конкретного идентифицированного пользователя в части доступа к указанным операциям.
3.6 эскизное проектирование (basic design): Часть процесса разработки продукции, предполагающая оценку проектных предложений и подготовку базовой проектной документации.
3.7 концептуальное проектирование (conceptual design): Часть процесса разработки продукции, включающего подготовку проектных спецификаций и проектного предложения.
3.8 фаза создания (creation phase): Стадия, на которой выполняются работы по проектной документации.
3.9 техническое проектирование (detailed design): Часть процесса разработки продукции, включающая разработку конечного определения продукта.
3.10 документ (document): Фиксированное и структурированное количество информации, разрабатываемое и передаваемое как целостная единица между пользователями и системами.
3.11 репродукция документа (document replica): Точная или максимально приближенная копия оригинального документа.
3.12 опубликованный документ (document issue): Идентифицированная версия документа.
3.13 статус документа (document status): Шаг (стадия) жизненного цикла готового документа.
3.14 оригинальный документ (original document): Документ, содержащий техническое описание (определение) продукции и формирующий базу для его будущих изменений.
3.15 выпустить (документ) (release): Создать документ, пригодный для использования по предназначению.
3.16 фаза выпуска (release phase): Стадия выпуска готового документа.
3.17 точность воспроизведения репродукции (replica fidelity): Качественный показатель репродукции документа в части передачи информации, содержащейся в оригинальном документе.
3.18 уведомление о пересмотре (revision notice): Часть документа (отдельный документ), содержащая информацию о пересмотре документации на продукцию.
3.19 фаза пересмотра (revision phase): Стадия, на которой производятся изменения документации на продукцию.
3.20 спецификация требований (specification of requirements): Совокупность общих требований, официальных требований (например, законов, постановлений, директив) и корпоративных требований.
3.21 хранение/активная фаза (storage/active phase): Стадия, на которой производится сохранение активной документации.
3.22 подписанный документ (signature document): Копия оригинального документа, имеющая утверждение, требуемое заказчиком, и представляющее собой основание для последующих утверждений.
3.23 рабочая копия (viewing copy): Репродукция документа, предназначенная для просмотра, внесения изменений и изготовления печатных копий.
4 Оригинальные и воспроизведенные документы
4.1 Общие положения
Следующие положения помогут при пользовании системы документации и облегчат понимание принципов ее работы.
4.2 Оригинальный документ
Оригинальный документ (документ-первоисточник) не имеет идентифицированного документального источника. Отдельный оригинальный документ или система ассоциированных оригинальных документов формируют техническое определение (описание) продукции. Оригинальный документ создает основу, в которую вносятся изменения в течение всего срока службы продукции.
Каждый утвержденный оригинальный документ хранят в архиве оригиналов (электронном хранилище). Доступ к данному архиву регулируют путем проведения специальных процедур «входной/выходной учет (регистрация)». Оригинальный документ в электронной форме хранится в идентифицированном формате на специальном носителе информации (например, магнитном или оптическом). Если документы оформляют вручную, то носителем представительных данных (рисунок, текст) может быть удобный для воспроизведения носитель, например, бумага или пленка. Любой пересмотр должен быть произведен в строгом соответствии с оригинальным документом.
Если предпочтительный файловый формат больше не поддерживается (например, векторный формат), то оригинальный статус передается файловому формату длительного использования (например, растровому формату). Как правило, при этом часть информации утрачивается (см. 4.5). Переход в другой файловый формат может также зависеть от используемых корпоративных процедур.
4.3 Подписанный документ
Оригинальный документ требует выполнения обычных процедур утверждения. Некоторые документы утверждает заказчик или официальный орган. Подписанный документ может требовать дополнительного утверждения. Обычно его оформляют на бумаге. Он является копией оригинального документа. Данный документ не может быть изменен без дополнительного утверждения с постановкой подписи и печати.
4.5 Архивная копия документа
Для документации, представленной в электронной форме, репродукция документа (см. 4.6) необходима для обеспечения его длительного хранения. Репродукция сохраняется в проверенном нейтральном формате. Формат архивной копии документа должен быть легко интерпретируемым и воспроизводимым для определенного периода времени (он может зависеть от срока службы продукции). Представление продукции должно быть открытым и независимым от перспективных версий используемых электронных средств и программного обеспечения.
4.6 Репродукция документа, точность воспроизведения репродукции
Значения степени точности воспроизведения репродукции классифицируют следующим образом:
— клонированное воспроизведение (точная копия);
— эквивалентное воспроизведение (с некоторой потерей информации для целевого эквивалента);
— существенное воспроизведение (некоторые свойства оригинала могут быть утрачены, например, цвет).
5 Фазы работы с проектной документацией
5.1 Общие положения
Следующие положения указывают, на какой стадии проектного цикла должны разрабатываться рассматриваемые документы. Все этапы процесса разработки продукции могут быть поделены на анализ, концептуальное проектирование, эскизный проект и технический проект (см. рисунок 1).
Как правило, техническое задание представляет собой спецификацию общих требований, частных требований и корпоративных требований.
Проектные спецификации рассматриваются как база для последующих разработок. Данные спецификации могут содержать возможные функциональные решения и (или) представления формы. Они составляют основу для оценки одного или нескольких рассматриваемых предложений. Результатом данной оценки и является базовая проектная документация.
На этапе технического проекта документы готовятся к использованию по назначению и формализуются в соответствии с установленными правилами управления документами.
Техническая документация МКД : что в неё входит?
У многих управляющих организаций возникает вопрос: что входит в состав технической документации МКД, обязательной для хранения? Некоторые УО жалуются, что в этом вопросе нет полной ясности, потому что в законодательстве представлен размытый перечень. В действительности же это не так. В законе вполне ясно говорится о составе, порядке хранения и обновлении ТД.
Перечень документов
Перечисленные документы передаются от застройщика, предыдущей УО или собственников (в том случае, если дом находился в непосредственном управлении). Таких документов, как инструкции по эксплуатации МКД и проектная документация, у УО может и не быть, если они были по каким-то причинам утрачены. В первую очередь это относится к старым домам, построенным в прошлом веке или раньше.
Другие документы, которые есть далеко не всегда, – договоры об использовании общего имущества МКД и документы о действии сервитута или иного обременения. Очевидно, что они есть только в тех МКД, собственники которых сдают в аренду ОИ или согласились на установление сервитута.
Поясним, что сервитут – это право ограниченного пользования чужим объектом недвижимого имущества. Он может устанавливаться, к примеру, для прокладки коммуникаций, или это может быть разрешение провести через свой участок какие-то инженерные сети или дорогу, которыми будут пользоваться собственники других домов.
Напротив, градостроительный план земельного участка – документ, который нужен для новых домов. С того момента, как в вашем городе был принят градостроительный план, его наличие в техдокументации для МКД, построенного после его принятия, становится обязательным.
Часть названных документов хранится в неизменном виде, а часть обновляется: это информация о собственниках и нанимателях помещений в МКД, а также о лицах, использующих ОИ в МКД на основании договоров, в том числе и ведение списков. Это устанавливается Стандартами управления МКД, которые введены постановлением Правительства РФ N 416. Соответственно, регулярно должны актуализироваться списки собственников, нанимателей и арендаторов, потому что меняется их состав.
Также обновляется выписка из Росреестра, в которой содержатся сведения о том, кому принадлежат жилые и нежилые помещения.
Иные документы
Самый загадочный пункт в перечне технической документации – «иные документы». Дело в том, что перечень благодаря этому пункту становится по сути открытым, в него могут входить любые документы, которые имеют какое-то отношение к управлению МКД. Достаточно того, чтобы решение о вхождении какого-то из документов в состав техдокументации было принято на ОСС простым большинством голосов.
Таким «дополнительным» документом может быть, например, договор с подрядчиком и даже какой-то внутренний документ УО – табеля зарплат или штатное расписание. Отметим, что если такое решение на ОСС будет принято и согласовано с УО, то документ войдёт в состав технической документации. А это значит, что тогда у собственников появится право знакомиться с ним.
У УО есть возможность предвосхитить такое развитие событий ещё на этапе заключения договора управления: достаточно просто внести в него закрытый перечень документов, согласовав его с собственниками. Тогда у собственников не будет возможности расширять этот список.
Приём-передача техдокументации
Обратим ваше внимание на то, что нужно крайне ответственно подходить к вопросу о полноте технической документации и её своевременном обновлении. Потому что в случае передачи МКД другой УО, ТСЖ или собственникам в управление, вся техдокументация должна быть передана в полном объёме в 30-дневный срок. Если же какие-то документы отсутствуют либо утрачены, они должны быть восстановлены. (Порядок приёма-передачи технической документации установлен в постановлении Правительства РФ N 416.)
При приёме-передаче ТД новая УО проверяет не только наличие всех документов, но и их актуальность на момент передачи. Если здесь возникают какие-то проблемы, то новая УО указывает в протоколе приёма-передачи, что требует восстановления или обновления. После этого прежняя УО обязана в течение 3 месяцев восстановить или обновить документы, а затем передать их по отдельному акту приёма-передачи вновь выбранной УО.
И на какие бы причины отсутствия техдокументации старая УО ни ссылалась, она обязана её передать, что явно следует из постановления Президиума Высшего Арбитражного Суда РФ. Согласно ему, отсутствие или утрата ТД не прекращает обязанность по её передаче.
Если и после 3 месяцев документы не переданы новой УО, можно смело обращаться в суд, в ГЖИ, в прокуратуру. И это вполне адекватная мера, поскольку иначе невозможно будет осуществлять полноценное управление домом. Это также позволит подстраховаться на случай передачи МКД другой УО – избежать затрат на восстановление технической документации (ведь затраты при этом ложатся именно на УО) и возможных штрафов.
Если у вас остались вопросы, вы всегда можете обратиться к нам за консультацией. Также мы помогаем управляющим компаниям соответствовать 731 ПП РФ о Стандарте раскрытия информации (заполнение портала Реформа ЖКХ, сайта УК, информационных стендов) и ФЗ № 209 (заполнение ГИС ЖКХ). Мы всегда рады вам помочь!
Техническая документация в разработке ПО: кто, зачем, когда и как описывает проект
Привет! Меня зовут Даша Григорьева, я технический писатель в компании 65apps. Мы занимаемся разработкой сложных мобильных решений, и моя задача — подготовка технической документации по проектам. Очень часто роль технического писателя бывает недооцененной в компании (не у нас, конечно). Поэтому я хочу рассказать, зачем компании-разработчику нужен такой специалист, что такое технический проект, чем он отличается от ТЗ и почему это все необходимо для разработки мобильного приложения.
Общаясь с большим количеством компаний, я все еще встречаю твердое убеждение в том, что написание технического задания для разработки ПО — пустая трата времени и денег. Мы в 65apps считаем иначе. Поэтому приведу несколько аргументов в пользу технической документации и расскажу, кто и как ее пишет.
Техническая документация позволяет оценить стоимость разработки и согласовать функциональность будущей системы. При возникновении споров о стоимости и сроках разработки той или иной фичи она может стать определенной гарантией для заказчика. С другой стороны, если возникнет потребность в развитии приложения, документация облегчит процесс доработки и даст четкое понимание, возможно ли встроить новую функциональность в существующую систему.
Другой пример — государственные организации или организации, чья деятельность ограничивается или подчиняется законам и надзорным органам. Они обязаны осуществлять разработку ПО по всем правилам и с соблюдением всех стандартов. В таких проектах техническая документация, подготовленная по ГОСТам, — необходимое условие.
И разумеется, грамотно составленная и актуальная документация необходима для того, чтобы каждый участник в процессе разработки мог обращаться к документам, если возникают вопросы по конкретной задаче или по всей системе в целом.
Техническое задание и технический проект — два разных документа. Техническое задание отвечает на вопрос «что нужно сделать?», его составляет аналитик в самом начале проекта. Технический проект разрабатывает технический писатель. Этот документ создается после ТЗ и отвечает на вопрос «как нужно делать?».
Кто пишет техническую документацию
Обычно разработкой ТЗ занимается аналитик. Именно он общается с заказчиком / заинтересованным лицом и выявляет у него требования. В сложных случаях к процессу можно привлечь менеджера проекта, разработчиков, тестировщиков и других специалистов. Чем сложнее проект — тем больше требований к документации. Серьезные заказчики из крупных корпораций и госсектора требуют составлять документацию в соответствии с ГОСТами, а это задача очень трудоемкая, требующая внимательности к деталям и постоянной вовлеченности в процесс. И это не только ТЗ, но и технический проект, полностью описывающий все используемые в разработке решения, подходы и методологии. На него также распространяются ГОСТы. Подготовкой такой документации должен заниматься специалист — технический писатель.
Для крупных проектов иметь в штате технического писателя просто необходимо. Разработка решений для крупных заказчиков может длиться год и более, это довольно долгий срок. За это время возникает достаточное количество изменений, провоцирующих обновление документации. Кроме того, любая долгосрочная разработка ПО предполагает развитие. В этом случае актуальная техническая документация позволит снизить риски, закладываемые в работу исполнителей.
Исключение может быть сделано для представителей госсектора. Таким организациям необязательно иметь в своем штате специалистов соответствующего профиля, так как при возникновении необходимости всегда можно обратиться к профессионалам, которые выполнят качественно свою работу.
Кто такой технический писатель
Строго сформулированного перечня должностных обязанностей технического писателя не существует: каждая компания формирует его сама, а иногда возлагает на такого специалиста и дополнительные задачи. Поэтому иногда бывает сложно даже определить род деятельности технического писателя. В нашей компании такой специалист составляет документацию, необходимую для дальнейшей разработки программного обеспечения.
Для этого он собирает информацию и материалы от участников проекта и документирует эти данные согласно требованиям заказчика, в том числе и в соответствии с ГОСТами. Речь идет о ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Информационная технология. Комплекс стандартов на автоматизированные системы». Также технический писатель следит за актуальностью технической информации, если это необходимо на длительных и сложных проектах.
Какая техническая документация нужна разработчику
Рассмотрим идеальный с точки зрения ГОСТа процесс разработки системы.
Все начинается с требований заказчика или заинтересованных лиц, которые необходимо выявить и обязательно зафиксировать в документе «Техническое задание».
Техническое задание — это документ, регламентирующий бизнес-цели, общее описание системы, объем работ, границы проекта, а также порядок разработки, оценки и приемки. Данный документ отвечает нам на вопрос «что нужно сделать?» и фактически является постановкой задачи.
Аналитик составляет ТЗ и согласует его со всеми заинтересованными сторонами. После того как собраны и утверждены все требования, можно приступать к созданию прототипов будущей системы и разработке программного обеспечения.
На этом этапе начинается разработка макетов, сценариев, архитектуры и др. Раз уж мы говорим об эталонном процессе разработки, то все это должно быть описано в техническом проекте, который также использует часть информации из ТЗ.
Технический проект — это совокупность документов, описывающих и обосновывающих все подходы, методы, архитектурные и технические решения, применяемые для создания системы. Например, в технический проект включают макеты интерфейсов, описание протоколов для интеграции со смежными системами и оборудованием, пользовательские сценарии, описание алгоритма и их формирование, структура серверов и баз данных, а также другие требования к системе и ее взаимодействию с другими внешними системами.
это далеко не все: существует много стандартов для написания технической документации, и для каждой страны они свои. В отечественных стандартах есть отдельно ГОСТ на создание автоматизированных работ и на программное изделие. Например, технический проект по ГОСТу 19 «Единая система программной документации» может включать в себя следующий перечень работ:
Теперь, когда есть четкое понимание архитектуры, функциональности и дизайна проекта, можно перейти к разработке системы и ее тестированию.
На этапе тестирования, помимо проверки работоспособности системы, проверяется также выполнение всех требований, зафиксированных в документах, что позволяет разрешить спорные ситуации с заказчиком.
Когда составлять техническую документацию
Выше я описала идеальный процесс создания программного обеспечения, но иногда некоторые документы технического проекта составляют уже после этапа разработки.
Есть проекты, в которых важно иметь полную документацию до начала работ. Это касается решений с высокими требованиями к безопасности, соблюдению законодательства и т. д. Например, мобильные приложения для банков. В этом случае важно сначала продумать все детали системы (информационная безопасность клиентов и самого банка, соответствие законам). На это уйдет больше времени, но позволит избежать финансовых и репутационных рисков.
Если разработка идет по методологии Agile, то нет смысла прописывать всю документацию до старта работ. Если заказчику важно работать по спринтам и контролировать ход разработки, документацию можно дописывать параллельно основному процессу.
В нашей компании возможны оба варианта — мы умеем адаптироваться под условия и пожелания заказчика.
На сегодняшний день технический писатель не самая распространенная специальность, но для серьезной компании-разработчика такой сотрудник не менее важен, чем, например, аналитик.
Техническая документация обязательно разрабатывается для госзаказчиков, она необходима и для долгосрочных проектов, на которых с бОльшей вероятностью могут меняться подрядчики. Имеет смысл создавать технический проект для ноу-хау технологий и проектов высокой сложности — документация понадобится отделу QA, чтобы отличить баги и фич.