Эскизный проект и технический проект в чем разница
Этапы конструкторской подготовки
Исходным для проектирования новой продукции является проектное (техническое) задание, которое составляется заказчиком (предприятием) или по его поручению проектной организацией. В проектном задании указывается наименование продукции, ее назначение, область применения, технические и экономические показатели в процессе производства и эксплуатации. На уровне проектного задания должны быть определены принципиальные отличия новой конструкции или изделия от ранее выпускаемых, приведены перечень и обоснование необходимости оригинальных изделий, даны подробные расчеты эффективности нового изделия с учетом эффекта, рассчитанного как для потребителя, так и для производителя.
На основании анализа проектного задания заказчика и сопоставления различных вариантов возможных решений изделий, сравнительной оценки решений с учетом конструктивных и эксплуатационных особенностей разрабатываемого и существующих изделий, а также патентных материалов составляется техническое предложение – совокупность конструкторских документов, содержащих технические и технико-экономические обоснования целесообразности дальнейшей разработки проекта.
Техническое предложение после согласования и утверждения в установленном порядке является основанием для разработки эскизного (технического) проекта.
Эскизный проект – совокупность конструкторских документов, которые должны содержать принципиальные конструктивные решения, дающие общее представление об устройстве и принципе работы изделия, а также данные, определяющие назначение, основные параметры и габаритные размеры разрабатываемого изделия. При разработке эскизного проекта определяется принципиальная характеристика нового изделия, производится выбор наиболее эффективного решения, его технических, технологических, эксплуатационных параметров.
Эскизный проект всегда составляется в нескольких вариантах для последующего выбора одного из них. Эскизный проект после согласования и утверждения в установленном порядке служит основанием для разработки технического проекта или рабочей конструкторской документации.
Технический проект– совокупность конструкторских документов, которые должны содержать окончательные технические решения, дающие полное представление об устройстве разрабатываемого изделия, и исходные данные для разработки рабочей документации.
Технический проект позволяет осуществлять выбор материалов и полуфабрикатов, определять основные принципы изготовления продукции и проводить экономическое обоснование проекта.
Технический проект после согласования и утверждения в установленном порядке служит основанием для разработки рабочей конструкторской документации. Ранее разработанные конструкторские документы обычно применяют при разработке новых или модернизации изготавливаемых изделий, что приводит к сокращению сроков проектирования.
Заключительной стадией (этапом) конструкторской подготовки производства является разработка технической документации (чертежей, инструкций и т.д.), технических условий.
Технические условия (ТУ) являются неотъемлемой частью комплекта технической документации на продукцию (изделие, материал, вещество и т.п.), на которую они распространяются. ТУ должны содержать все требования к продукции, ее изготовлению, контролю, приемке и поставке, которые целесообразно указывать в конструкторской или другой технической документации.
При отсутствии конструкторской или другой технической документации на данную продукцию ТУ должны содержать полный комплекс требований к продукции, ее изготовлению, контролю, приемке и поставке.
ТУ разрабатывают на одно изделие, материал, вещество, а также на несколько конкретных изделий, материалов, веществ (групповые технические условия). Состав ТУ и содержание разделов определяются в соответствии с особенностями продукции.
После испытания и доводки опытной партии уточняется рабочий проект, который передается в законченном виде для технологической подготовки производства. На всех стадиях проектирования уточняются, конкретизируются и окончательно определяются все технические и экономические характеристики изделия, определяется целесообразность использования первоначально выбранного пути совершенствования продукции и принимается решение о ее выпуске.
Установленный и рассмотренный выше порядок конструкторской подготовки изделия характерен в полной мере лишь для массового и крупносерийного производств, продукции сложного профиля (автомобили, станки, тракторы и т.п.). Для мелкосерийного и единичного производств, независимо от технической сложности изделия, количество стадий и объемы работ по каждому из них уменьшаются. В отраслях металлургической и химической промышленности, переработки сельскохозяйственного сырья, а также в добывающих отраслях проектирование изделий выполняется главным образом на стадии прикладных исследований, изысканий и разработок, а также технологической подготовки производства.
Конструкторская подготовка производства осуществляется в соответствии с комплексом государственных стандартов, устанавливающих единые взаимосвязанные правила и положения ее проведения, оформления и обращения конструкторской документации, разрабатываемой и применяемой промышленными, научно-исследовательскими, проектно-конструкторскими организациями и предприятиями, получившим, соответственно, название Единой системы конструкторской документации (ЕСКД). Применение ЕСКД позволяет создавать благоприятные ; условия для обеспечения научно-технической подготовки производства на высоком уровне, способном гарантировать конкурентоспособность выпускаемых изделий, сокращать время проектирования, обеспечивать необходимое единообразие этого |процесса на различных предприятиях в разных отраслях экономики.
ЭСКИЗНЫЙ И РАБОЧИЙ ПРОЕКТ, В ЧЕМ РАЗНИЦА?
-Обе эти стадии проектирования неразрывно между собой связаны. Эскизный проект составляется в соответствии с тех.заданием, тех.условиями, СНиПами и ГоСТами и согласовывается с заказчиком и архитектурой. На основе эскизного проекта (если речь идет об обыкновенном загородном доме или строительстве, не требующем специальных разрешений) выдается разрешение на строительство и сопутствующие документы. А уже на основе согласованного Эскизного Проекта ( ЭП) делается Рабочий Проект, если такой потребуется.
Все проекты разные и кол-во листов альбома и разворотов проекта зависит прежде всего от его сложности и уникальности.
Но все же Основной состав Эскизного Проекта приблизительно у всех одинаковый:
В среднем альбом Эскизного Проекта составляет 12-16 листов.
У Рабочего Проекта совсем другая задача: максимально раскрыть все сложные технические элементы, выполнить необходимые расчеты прочности или теплотехнические расчеты, раскрыть максимально все размеры, разрезы или элементы фасадов для того чтобы дом получился «как на ладони» ясным, четким и понятным как его можно воплотить и сколько это будет стоить.
Также Рабочий Проект можно заказывать на отдельные элементы (фундаменты, кровля и т.д.).
Рабочий Проект делится на несколько частей:
Каждая часть полного Рабочего Проекта требует точных расчетов и чертежей. Состав альбома для каждой части индивидуален.
Примерный состав альбома Рабочего Проекта для Индивидуального Жилого Дома, часть АР/КР:
И это далеко неполный список состава альбома Рабочего Проекта. Все зависит от сложности исходного проекта, — поэтому и есть такая большая разница в цене.
Эскизный и технический проект
Эскизный проект должен выполняться в соответствии с требованиями ГОСТ 2.119, является вторым этапом компоновки оригинального изделия. На этой стадии проектирования следует также выполнять необходимые инженерные расчёты, требования к ним такие же, как и при разработке технического предложения. Чертёж изделия, представляющий собой дальнейшую разработку первого этапа компоновки, должен включать необходимое количество проекций, дополнительные виды, разрезы и сечения. Для облегчения последующих работ по составлению спецификаций следует приводить на чертежах эскизного проекта на выносных линиях сведения об использовании стандартных изделий. Эскизный проект после рассмотрения должен быть утверждён, после чего становится основой для разработки технического проекта. Технический проект должен содержать чертеж общего вида и пояснительную записку.
Чертёж общего вида
Чертёж общего вида [по ГОСТ 2.119] должен дать сведения о конструкции, взаимодействии составных частей, эксплуатационно-технической характеристике проектируемого изделия и пояснять принцип его работы.
На чертеже общего вида должны быть:
◘ изображены виды, разрезы и сечения изделия, нанесены надписи и текстовая часть, необходимые для понимания конструктивного устройства изделия;
◘ указаны наименования составных частей изделия [если это возможно], приводятся технические характеристики, указывается материал, поясняются изображения общего вида и состав изделия;
◘ приведены необходимые размеры, техническая характеристика и технические требования.
Габаритный чертёж
Габаритный чертёж следует выполнять с максимальными упрощениями. Число видов должно быть минимальным, но достаточным, чтобы дать представление о внешних очертаниях изделия и его выступающих элементах. На габаритном чертеже должны быть нанесены габаритные, установочные и присоединительные размеры, определяющие положения выступающих частей, без указания того, что эти размеры справочные. Установочные и присоединительные размеры должны быть с предельными отклонениями. На габаритном чертеже можно указывать условия применения, хранения, трансопртирования и эксплуатации изделия.
Разработка текстовых документов
Текстовые документы на стадии технического предложения должны содержать технические и технико-экономические обоснования целесообразности разработки документации изделия на основе анализа технического решения, технической литературы, а также вариантов предлагаемых технических решений, сравнительной оценки с учётом конструктивных и эксплуатационных особенностей разрабатываемого или модернизируемого изделия, а также на основе патентных данных.
Текстовые документы, входящие в состав эскизного и технического проекта, должны пояснять принятые принципиальные констуктивные и конструкторские решения, дающие общие представления об устройстве и принципе работы изделия, данные, определяющие основные параметры и габаритные размеры разрабатываемого оригинального изделия.
При проработке нескольких варианта (на стадии технического предложения) в пояснительной записке (или отчёте) приводят результаты сравнния этих вариантов, и указывают вариант, рекомендуемый к дальнейшей проработке. Результаты инженерных расчётов приводятся в табличном виде. При необходимости в тексте даются пояснения расчётных методов. При малом объёме текстового и графического материала результаты проведения научно-исследовательских и опытно-конструткорских работ на стадии технического проекта допускается оформлять в виде одного тома. Пояснительная записка в виде отчёта должна быть краткой, с чётко сформулированными пояснениями и выводами. В пояснительной записке не допускается приводить математические выкладки, связанные с инженерными расчётами. Должны приводиться лишь необходимые исходные данные и результаты этих расчётов. Состав пояснительной записки в отдельных случаях может быть расширен или сокращён по усмотрению исполнителя в зависимости от особенностей и сложности данного проекта.
5 причин не строить по эскизному проекту
Важность проекта в строительстве понимается большинством заказчиком, но многие не различают эскизный (архитектурный) и инженерный (рабочий) проект. В этой статье рассмотрим, чем эти проекты отличаются друг от друга и чем грозит использование «эскизника» в качестве рабочего документа.
Эскизный (рабочий) проект
Этот документ разрабатывается на начальной стадии работы с заказчиком. Основная цель составления этого документа состоит в том, чтобы решить все принципиальные вопросы: этажность, планировка, стилистические решения на фасадах, конструктивные решения основных элементов.
Часто готовые проекты, которые лежат в открытом доступе в интернете, являются именно архитектурными проектами. Некоторые компании, которые предлагают услуги по проектированию, выставляют эскизные проекты в качестве рекламы своих услуг. Заказчики и самостройщики, стремясь сэкономить на заказе рабочего проекта, скачивают эти документы и начинают строительство по ним.
Эскизный проект содержит следующие параметры.
Трехмерная визуализация внешнего вида дома
Примерный вид планировки дома 
Примерный вид плана участка с благоустройством
Два последних документа нужны для получения разрешения на строительства, поэтому их не будет в готовых проектах из интернета. Их требуется оформить для конкретного участка.
Рабочий (инженерный) проект
Разрабатывается, когда внешний вид здания и планировка согласованы, все разрешения на строительство получены. Как понятно из названия, от архитектора проект переходит к инженеру, который должен уже со знанием строительной физики расписать все узлы, собрать и рассчитать нагрузки. На разработку инженерного проекта может уйти больше времени, к тому же обычно такие работы стоят дороже, поэтому соблазн строить по «эскизнику» вполне объясним.
В инженерном проекте присутствуют следующие компоненты.
Теперь рассмотрим причины, по которым не стоит строить по эскизному проекту.
Сложность контроля
По эскизному проекту невозможно контролировать работу бригады, если заказчик сам не является строителем. Фактически у заказчика есть только архитектурный вид постройки и планировка, все сложность разработки узловых элементов ложится на прораба. От его опыта будет зависеть качество работы. Если не было сделано геологических исследований, то строительство фундамента в этом случае превращается в лотерею.
При работе по инженерному проекту часто есть возможность заказать авторский надзор, когда компания, которая составляла проект будет контролировать правильность его реализации.
При наличии инженерного проекта можно всегда сравнить результат с чертежом, а в эскизном проекте информации недостаточно.
Проблема с коммуникацией и поиском бригады
Без рабочего проекта надо не только найти бригаду, но еще и объяснить строителям, что вы хотите получить. Без чертежей понимание отдельных узлов может расходиться у строителей и заказчика, в результате получить желаемое будет сложно.
Строителям придется все время согласовывать отдельные узлы с заказчиком, это увеличивает время присутствия заказчика на объекте и потребует дополнительных обсуждений.
Некоторые строители не соглашаются работать по эскизному проекту, так как в дальнейшем могут возникать взаимные разногласия с клиентом.
В целом, работа по эскизному проекту неудобна как для строителя, так и для заказчика. Большое количество «белых пятен» создает «благоприятную почву» для дальнейших взаимных претензий.
Отсутствие точной сметы
Эскизный проект не позволяет точно подсчитать количество необходимых строительных материалов, а это не дает верного представления о конечной цене всего строительства. К тому же в случае работы по архитектурному проекту заказчик может слишком поздно осознать необходимость каких-либо материалов. Например, первую партию материала привезли, потом в ходе строительства выяснилось, что чего-то не хватает и нужно докупить. В результате вместо одной доставки заказывают две. Отсутствие сметы напрямую связано с логистическими накладками, которые повышают стоимость всего строительства.
Перепланировки во время строительства
Так как все инженерные проблемы решаются без плана, а по мере поступления, то в какой-то момент может оказаться, что нужно переделать предыдущие работы. Часто сложности возникают с коммуникациями, так как их важно продумывать заранее. В некоторых случаях коммуникации препятствуют выполнению дальнейших работ. Переделки увеличивают срок строительства и повышают затраты на доставку.
Перезаклады
Так как расчетов конструкций у строителей не будет, то они будут стараться сделать все элементы максимально надежными. В строительстве это явление называется перезакладами, когда отдельные части здания выполняются с избыточным запасом прочности, например, появляется большое количество железобетонных включений (перемычки в дверях и оконных проемах, бетонные пояса и др.). Перезаклады увеличивают расходы на материалы и часто приводят к росту теплопотерь.
Вывод
В конечном итоге экономия на инженерном проекте приводит к большому количеству сложностей в процессе самого строительства. При этом конечном итоге экономия на первом этапе может привести к росту общей стоимости работ.
Документирование по ГОСТ 34* — это просто
Что такое стандарты на документацию?
В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:
Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)
Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.
Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.
Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.
К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.
Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.
Минусы стандартов
Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:
5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.
Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.
«Видеокадр» — это тоже документ, который выводился на текстовый дисплей. Дисплеи не всегда поддерживали нужные символы и нужное количество символов по горизонтали и строк по вертикали (а графику вообще не поддерживали). Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов.
Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.
Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.
Что в стандарте хорошо
Любой стандарт хорош уже тем, что он позволяет заказчику и исполнителю говорить на одном языке и дает гарантию, что, по крайней мере, претензий «по форме» к передаваемым результатам у заказчика не будет.
А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.
Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.
Как читать и понимать стандарты документации по ГОСТ серии 34
Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»
Стадии создания АСУ
Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:
Технический проект описывает будущую систему со всех ракурсов. Документы стадии ТП должны после прочтения оставлять после себя полную ясность в предлагаемых подходах, методах, архитектурных и технических решениях. На следующей фазе уже поздно будет описывать подходы и обосновывать технические решения, так что фаза П является ключом к успешной сдаче работ, так как все многообразие требований ТЗ должно находить отражение в документах фазы П. На этапе П система может вообще не существовать.
Рабочая документация предназначена для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Это документы, содержащие совершенно конкретные сведения, описывающие физически существующие сущности, в отличие от фазы П, где описывается будущее великолепие.
Части (разделы) проектной документации по созданию АСУ
Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.
Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи, которая обрабатывает приходящую из разных источников информацию в соответствии с некими алгоритмами и выдает результаты обработки в виде документов, структур данных или управляющих воздействий. Примитивная модель простейшего автомата.
Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):
Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?
Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.
Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.
Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?
Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем.
Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.
В этом документе мы должны рассказать, при помощи каких программных средств выполняются алгоритмы, описанные в МО, обрабатывающие информацию, описанная в ИО. То есть, не нужно дублировать тут информацию из других разделов. Тут дается архитектура системы, обоснование выбранных программных технологий, их описание (всякие системные вещи: языки программирования, фреймворки, операционки и т.п.). Также в этом документе мы описываем как организованы средства обработки информации (очереди сообщений, хранилища, средства резервного копирования, решения по доступности, всякие пулы приложений и т.п.). В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист.
Техническое обеспечение (ТО). Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.
Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.
Не забывайте также, что комплекс стандартов качества подразумевает учет и хранение технических документов, и наши «книжицы» у заказчика могут разойтись по разным архивам, в зависимости от предмета описания. Это еще один аргумент в пользу дробления документации.
Организационное обеспечение (ОО). Подавив в себе нормальное для технаря желание проскочить этот раздел поскорее, наоборот, рассмотрю его более подробно. Так как, коллеги, в последнее время на проектах наметились нехорошие тенденции, которые требуют внесения ясности именно в этот раздел.
На стадии ТП раздел содержит всего один документ «Описание организационной структуры», в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.
На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.
Руководство пользователя. Комментарии излишни, я думаю.
Методика (технология) автоматизированного проектирования. В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.
Технологическая инструкция. В связи с модой на формализацию бизнес процессов, в этот документ ушлый заказчик иногда стремится запихнуть регламенты работы службы эксплуатации. Так вот, делать этого ни в коем случае не нужно.
Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы — все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.
Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим. Мы эти бизнес-процессы автоматизируем.
Об описанных граблях я еще напишу отдельно, с красочными примерами, так как это повторяется уже не первый раз и в разных отраслях «народного хозяйства».
Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция — для них. Что в нее писать в XXI веке — я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.
Общесистемные решения (ОР). Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала — менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.
А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.
Варианты использования ГОСТ 34
Заключение
Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.
Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).