Технический проект

не нужно болеть.

Это понятно, но лучше народ не путать - самим же потом расхлёбывать Три сотни экспертиз уже сказались на здоровье не самым лучшим образом

Не ПЗ, а П2, пардон-те

Прошу прощения, но в данном случае имелось ввиду только сокращеное наименование пояснительной записки - ПЗ, а не код документа по ГОСТ 34.201 - "П цифра три".

Не ПЗ, а П2, пардон-те

РД 50-34.698-90
1.5. Документы, при необходимости, сброшюровывают в книги или тома, к которым составляют описи.
Лучше все-таки сделать 2 тома.

Справедливое замечание. Попробую ответить.
РД 50-34.698-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ:
1.1. Требования к содержанию документов, разрабатываемых. при создании АС, установлены настоящими указаниями, а также соответствующими государственными стандартами Единой системы программной документации (ЕСПД), Единой системы конструкторской документации (ЕСКД), Системы проектной документации для строительства (СПДС) и ГОСТ 34.602.
Виды и комплектность документов регламентированы ГОСТ 34.201.
1.2. Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов, в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы.
1.3. Содержание каждого документа, разрабатываемого при проектировании АС согласно ГОСТ 34.201, определяет разработчик в зависимости от объекта проектирования (системы, подсистема и т.д.).

Резюме из вышеизложенного. Пояснительная записка (ПЗ) к техническому проекту на АС должна разрабатываться по РД 50-34.698-90. Состав приложений к ПЗ данным документом не регламентирован и при этом допускается включать в документы (ПЗ к ТП) дополнительные разделы и сведения (п.1.2 РД).
Поэтому я и поддержал предложение о включении в приложение к ПЗ дополнительных материалов, что не противоречит требованиям ЕСКД (п.1.1 РД), приведенным в ГОСТ 2.120, а только усиливает их.

Не готов щас листать ГОСТы, но нет в душе уверенности, что применение ГОСТ 2.120 к АС правомерно. ЕСКД ведь ориентирована на изделия, а не на АС. ЕСКД применима для изделий, входящих в состав АС, но сама-то АС и всякие правила оформления регламентированы ГОСТ 34 и РД 50-34.698-90.

Короче, не помню, чтобы из ГОСТ 34 были ссылки конкретно на ГОСТ 2.120.

ГОСТ 2.120-73 ЕСКД. ТЕХНИЧЕСКИЙ ПРОЕКТ:
"2.4. В приложении к пояснительной записке приводят:
- копию технического задания, а также, при необходимости, данные (технические требования, правила приемки, методы контроля и другие сведения), подлежащие включению в технические условия, если последние на данной стадии не разрабатывались;
- перечень работ, которые следует провести на стадии разработки рабочей документации;
- уточнение или разработку сетевого графика по дальнейшей разработке и внедрению в промышленное производство разрабатываемого изделия;
- перечень использованной литературы и т.п.;
- перечень документов, используемых при разработке технического проекта и получаемых разработчиком изделия от других предприятий и организаций (авторские свидетельства, экспертное заключение о патентной чистоте, справка потребителя о необходимом объеме производства разрабатываемых изделий и т.п.); при этом документы в приложении к пояснительной записке не включают, но в пояснительной записке могут быть приведены необходимые сведения из этих документов (например, предмет изобретения, потребные количества изделий на квартал, на год, на пятилетку), а также номер и дата документа или сопроводительного письма."

Получается, что прикладывать копию ТЗ и различные документы (заключения, отчеты) можно.
Само ТЗ надо переплести и хранить отдельно.

По моему лучше сделать 2 альбома.

Разбиение по томам, получается что у вас один документ только большой. Формировать альбомы проще.

Я сделала 2 тома.

1 том
содержит описанное выше

2 том

Например, Ведомость оборудования и материалов
и локальный сметный расчет

И еще вопрос можно ли прикладывать ТЗ, отчет к ТП в виде приложения?

В целом данное содержание ТП можно принять за основу. Несколько замечаний и дополнений:
1. Если проект включает только пояснительную записку, то ведомость ТП можно сделать на одной странице и вставить ее после листа согласований. Если есть дополнительные документы (ведомости, сметный расчет и др.), то ведомость ТП лучше сделать отдельно.
2. В второй раздел добавить описание деятельности без системы защиты информации (СЗИ), а затем описать деятельность при наличии СЗИ и раскрыть общие требования к системе ИБ АС.
3. Описание автоматизированных функций и описание ПО можно включить разделами в пояснительную записку.

Ведомость к ТП должнва быть, ведь в неё включены все документы по проекту

Можно ли применить такое содержание к Техническому проекту?

Лист утверждения
Титульный лист
Ведомость к техническому проекту (или она вообще не будет включаться?)
Пояснительная записка с Титульним своим листом и Содержанием:
1. Общие положения
- наименование проектируемой АС и наименования документов, их номера и дату утверждения, на основании которых ведут проектирование АС;
- перечень организаций, участвующих в разработке системы, сроки выполнения стадий;
- цели, назначение и области использования АС;
- подтверждение соответствия проектных решений действующим нормам и правилам техники безопасности, пожаро- и взрывобезопасности и т. п.;
- сведения об использованных при проектировании нормативно-технических документах;
- сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта;
- очередность создания системы и объем каждой очереди.
2. Описание объекта защиты
Описать общие требования к системе ИБ АС
3. Описание процесса деятельности
Формирую требования к организации работ в условиях функционирования АС.
4. Основные технические решения
Структура системы и описание ее по фрагментно (куда входит и описание ПО)
5. "Мероприятия по подготовке объекта автоматизации к вводу системы в действие" и также организационные мероприятия
6. Различные определения включая термины и сокращения
7. Лист регистрации изменений

Что еще включить?
Документ такой как Описание автоматизируемых функций ведь очень схож с разделом в пояснительной записке, да и документ Описание программного обеспечения тоже схож

Завтра буду думать над составлением Технического проекта)) как чтото надумаю сразу расскажу

прочитала, полный бред у них оказывается

Понятно. Приемка идет по формальному признаку, на технические решения мало кто смотрит.

Система 50 на 50. 50 процентов договорных денег идет на работу, а остальное возвращается Заказчику. Цифра отката, конечно, может изменяться.

Бывает и от 150 до 200 Приемка - да, по пунктикам функциональной полноты, степени автоматизации и т.п.

Крупные, с могучей крышей, обеспечены заказами всегда в силу того, что генералы в них приходят от заказчика. Проекты почти не закрываются, но появляются все новые и новые. На одного РП вешают до десятка новых работ. Мелкие - не знаю, не работал на них.

Побоялся бы причислить ТЗ такого объема к ТЗ среднего качества
В целом, конечно, все зависит от отрасли. В энергетике проекты худо-бедно закрываются (принимаются), а IT порой не закрываются вообще

Объем ТЗ сильно зависит от Заказчика и от размеров системы (комплекса). Раньше (лет 15-20 назад) по ТЗ в 30-40 страниц сдавались большие АС. А теперь на АСКУЭ пишут 100-120, поэтому приемка проводится формально.

На что тогда живут IT-компании, если проекты не закрываются и нет денег?

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

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

Это ссылка на техническую документацию вполне модно за образец взять

Ни в коем случае! Обнаружил ссылку на МЭРТовские проекты еще недели две назад, подобного бреда давно не встречал, поэтому даже не стал публиковать ссылку, а так, укусил чуток - см. http://forum.philosoft.ru/cgi-bin/forum/ikonboard.cgi?s=a3906d633c3a2dcf27abd8512bd1e5f2;act=ST;f=7;t=327

http://projects.economy.gov.ru/pms/public/PublicWorkProducts.aspx?projectid=5f0a1a97-8e2f-4458-8bcb-691022536897

Это ссылка на техническую документацию вполне модно за образец взять

Дык, нам, исполнителям - и карты в руки Может, и не обратит внимание на упоминание ГОСТ в Договоре

А вот это бабушка надвое сказала См. Ваш Выбор? Часть II

16. Описание организационной структуры

я ведь могу соединить с п.4 Пояснительной записки "Организационные мероприятия по обеспечению безопасности информации"

Потому что у меня будет все направленно в разработку системы защиты информации для АСУ

Заказчик, читающий ГОСТы, это сейчас такая большая редкость.

Согласен с Вами. Любой документ, подписанный Заказчиком, в будущем значительно облегчает жизнь Разработчика. Особенно в период проведения приемочных испытаний.

До тех пор, пока они не прописаны в Договоре между Заказчиком и Исполнителем

Но не забудьте оформить все документально, лучше допсоглашением к Договору.

У меня пока более простая задача, я разрабатываю шаблон для утверждения его руководством, пока нужно набрасать содержание, что должно включаться вообще в Технический проект.
Например:
Лист утверждения
Титульный лист
Содержание
1. Общие положения
2. Назначение системы защиты
3. Цели и задачи защиты информации
4. Описание объекта защиты и т.д.

вот хочу узнать какие же все таки разделы должны быть

то есть исключить никак нельзя?

Чтобы не было недоразумений с Заказчиком сначала подготовьте план-проспект технического проекта. В план-проспект включите перечень разрабатываемых Вами документов (не больше пяти) и согласуйте его с Заказчиком.
После этого можно смело приступать к разработке технического проекта на АС.

Хороший вариант, я сейчас помозгую и напишу как у меня получилось

то есть исключить никак нельзя?

Ведомость технического проекта отдельно. Затем пояснительная записка (П2). После пояснительной записки остальные документы (описания и ведомости).
Но сейчас так редко кто делает, ведь ГОСТы не являются обязательными для исполнения. Поэтому можно предложить промежуточный вариант:
1. Ведомость ТП.
2. Пояснительная записка к ТП.
3. Ведомость покупных изделий.
4. Локальный сметный расчет.
Оставшиеся документы включить в пояснительную записку к ТП.

Возможно, в ГОСТ 34.201-89 прописано, какой из документов в какой можно включать - в таблице 2.

Это облегчело дело. но так и хочиться чего нибудь исключить и что-то с чем то соединить. А такое возможно?

Можно все в одну книгу, тогда вместо названия каждого документа будет название соответствующего раздела.

тогда получаеться следующие 19 документов(это для Автоматизированных систем)
1. Ведомость технического проекта

2. Ведомость покупных изделий

3. Перечень входных сигналов и данных

4. Перечень выходных сигналов (документов)

5. Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы

6. Пояснительная записка
• 1) общие положения;
• 2) описание процесса деятельности;
• 3) основные технические решения;
• 4) мероприятия по подготовке объекта автоматизации к вводу системы в действие.

7. Описание автоматизируемых функций

• 1) исходные данные;
• 2) цели АС и автоматизированные функции;
• 3) характеристика функциональной структуры;
• 4) типовые решения (при наличии).
8. Описание постановки задач (комплекса задач)
• 1) характеристики комплекса задач;
• 2) выходная информация;
• 3) входная информация.
9. Описание информационного обеспечения системы
• 1)состав информационного обеспечения;
• 2) организация информационного обеспечения;
• 3) организация сбора и передачи информации;
• 4) построение системы классификации и кодирования;
• 5) организация внутримашинной информационной базы;
• 6) организация внемашинной информационной базы.
10. Описание организации информационной базы
• 1) описание внутримашинной информационной базы;
o 1) логическая структура;
o 2) физическая структура (для внутримашинной информационной базы);
o 3) организация ведения информационной базы.
o
• 2) описание внемашинной информационной базы.
o 1) логическая структура;
o 2) физическая структура (для внутримашинной информационной базы);
o 3) организация ведения информационной базы.
•
11. Описание систем классификации и кодирования
Документ содержит перечень применяемых в АС зарегистрированных классификаторов всех категорий по каждому классифицируемому объекту, описание метода кодирования, структуры и длины кода, указания о системе классификации и другие сведения по усмотрению разработчика.
12. Описание массива информации
• 1) наименование массива;
• 2) обозначение массива;
• 3) наименование носителей информации;
• 4) перечень реквизитов в порядке их следования в записях массива с указанием по каждому реквизиту, обозначения алфавита, длины в знаках и диапазона изменения (при необходимости), логических и семантических связей с другими реквизитами данной записи и другими записями массива;
• 5) оценку объема массива;
• 6) другие характеристики массива (при необходимости).
13. Описание комплекса технических средств
• 1) общие положения;
• 2) структура комплекса технических средств;
• 3) средства вычислительной техники;
• 4) аппаратура передачи данных.
14. Описание программного обеспечения
• 1) структура программного обеспечения;
• 2) функции частей программного обеспечения;
• 3) методы и средства разработки программного обеспечения;
• 4) операционная система;
• 5) средства, расширяющие возможности операционной системы.
15. Описание алгоритма (проектной процедуры)
• 1) назначение и характеристика;
• 2) используемая информация;
• 3) результаты решения;
• 4) математическое описание;
• 5) алгоритм решения.
16. Описание организационной структуры
• 1) изменения в организационной структуре управления объектом;
• 2) организация подразделений;
• 3) реорганизация существующих подразделений управления.
17. План расположения
План расположения средств технического обеспечения, выполняемый при разработке технического проекта, должен определять расположение пунктов управления и средств технического обеспечения, требующих специальных помещений или отдельных площадей для размещения,
Документ допускается включать в раздел "Структура комплекса технических средств" документа "Описание комплекса технических средств". (НУ ЭТО Я ОБЪЕДЕНЮ)
18. Ведомость оборудования и материалов
Ведомость должна содержать сведения, необходимые для составления смет на приобретение и монтаж средств технического обеспечения системы, соответствовать утвержденным в установленном порядке требованиям по составлению заказных спецификаций и ведомостей к проектам АС.
19. Локальный сметный расчет
Локальная смета и локальный сметный расчет содержат сведения о сметной стоимости работ, выполняемых при создании АС, и сметной стоимости объектов, сооружаемых при создании АС, в соответствии с требованиями СНиП 1.02.01 и других документов по определению стоимости АС и ее составных частей.
Примечание. При изменении сметной стоимости работ и объектов по сравнению с запланированной уточняют экономическую эффективность АС.

Можно ли хоть что-то счем либо объединить?

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

А вот если объединить, разделы такие как "Общие сведения" их как описывать

а я то думаю куда их засунуть ))))

Вариантов много - одной книжкой под общей обложкой, отдельными книгами - все это допускается. Ведомости, насколько помню, всегда отдельно