Состав разделов проектной документации[править | править исходный текст]

В соответствии с Постановлением Правительства Российской Федерации от 16.02.2008 № 87 «О составе разделов проектной документации и требованиях к их содержанию» (в редакции от 02.08.2012)^[4] проектная документация на объекты капитального строительства производственного и непроизводственного назначения состоит из следующих разделов (в скобках приведены шифры разделов в соответствии с ГОСТ Р 21.1101-2009):

• раздел 1 «Пояснительная записка» (ПЗ);

• раздел 2 «Схема планировочной организации земельного участка» (ПЗУ);

• раздел 3 «Архитектурные решения» (АР);

• раздел 4 «Конструктивные и объемно-планировочные решения» (КР);

• раздел 5 «Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений» (ИОС):

• а) подраздел «Система электроснабжения» (ИОС1);

• б) подраздел «Система водоснабжения» (ИОС2);

• в) подраздел «Система водоотведения» (ИОС3);

• г) подраздел «Отопление, вентиляция и кондиционирование воздуха, тепловые сети» (ИОС4);

• д) подраздел «Сети связи» (ИОС5);

• е) подраздел «Система газоснабжения» (ИОС6);

• ж) подраздел «Технологические решения» (ИОС7);

• раздел 6 «Проект организации строительства» (ПОС);

• раздел 7 «Проект организации работ по сносу или демонтажу объектов капитального строительства» (при необходимости сноса или демонтажа) (ПОД);

• раздел 8 «Перечень мероприятий по охране окружающей среды» (ООС);

• раздел 9 «Мероприятия по обеспечению пожарной безопасности» (ПБ);

• раздел 10 «Мероприятия по обеспечению доступа инвалидов» (ОДИ);

• раздел 10(1) «Перечень мероприятий по обеспечению соблюдения требований энергетической эффективности и требований оснащенности зданий, строений, сооружений приборами учета используемых энергетических ресурсов»;

• раздел 11 «Смета на строительство объектов капитального строительства» (СМ);

• раздел 12 «Иная документация в случаях, предусмотренных федеральными законами».

В то же время состав разделов проектной документации, установленный ГСК РФ в редакции от 30.12.2012, несколько отличается от приведённого. В соответствии с ч. 12 ст. 48 ГСК РФ перечень мероприятий по обеспечению соблюдения требований энергетической эффективности предусматривается пунктом 11.1, в то время как п. 10.1 называет раздел «требования к обеспечению безопасной эксплуатации объектов капитального строительства», который указанным Постановлением не предусмотрен.

Проектная документация на линейные объекты[править | править исходный текст]

Проектная документация на линейные объекты капитального строительства состоит из 10 разделов:

• раздел 1 «Пояснительная записка»;

• раздел 2 «Проект полосы отвода»;

• раздел 3 «Технологические и конструктивные решения линейного объекта. Искусственные сооружения»;

• раздел 4 «Здания, строения и сооружения, входящие в инфраструктуру линейного объекта»;

• раздел 5 «Проект организации строительства»;

• раздел 6 «Проект организации работ по сносу (демонтажу) линейного объекта»;

• раздел 7 «Мероприятия по охране окружающей среды»;

• раздел 8 «Мероприятия по обеспечению пожарной безопасности»;

• раздел 9 «Смета на строительство»;

• раздел 10 «Иная документация в случаях, предусмотренных федеральными законами».

Экспертиза проектной документации[править | править исходный текст]

Основная статья: Экспертиза

Проектная документация объектов капитального строительства и результаты инженерных изысканий, выполняемых для подготовки такой проектной документации, подлежат экспертизе, за исключением оговорённых случаев (проектирование несложных объектов, для которых не требуется получения разрешения на строительство и др.). С 01.04.2012 экспертиза проектной документации и (или) экспертиза результатов инженерных изысканий проводятся в форме государственной экспертизы либо в форме негосударственной экспертизы. Заключение негосударственной экспертизы должно приниматьсяРостехнадзором наравне с заключением государственной экспертизы.

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

Результатом экспертизы является заключение о соответствии (положительное заключение) или несоответствии (отрицательное заключение) проектной документации требованиям технических регламентов и результатам инженерных изысканий, требованиям к содержанию разделов проектной документации, а также о соответствии результатов инженерных изысканий требованиям технических регламентов (ч. 9 ст. 49 ГСК РФ).

Государственная экспертиза проводится органом исполнительной власти субъекта РФ или подведомственным ему государственным учреждением по месту нахождения земельного участка. Порядок организации и проведения в Российской Федерации государственной экспертизы проектной документации и результатов инженерных изысканий, порядок определения размера платы за проведение государственной экспертизы, а также порядок взимания этой платы определяется Положением^[5], утверждённым Постановлением Правительства РФ от 05.03.2007 № 145.

Негосударственная экспертиза проводится юридическими лицами, соответствующими требованиям, установленным ст. 50 ГСК РФ. Порядок аттестации физических лиц на право подготовки заключений экспертизы, а также порядок аккредитации юридических лиц на право проведения негосударственной экспертизы устанавливаются соответственно ст. ст. 49.1 и 50 ГСК РФ.

4. Требования к проектируемой информационной системе.

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

Требования к функциональным характеристикам

В этом разделе должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных. При выборе между объектными и структурными методами следует использовать принцип концептуальной общности, который предполагает следование единой философии на всех этапах ЖЦ.  Если предполагается использовать структурное программирование, то и на этапе анализа следует использовать структурный подход, а в случае использования объектно-ориентированных языков разработки - объектный анализ и объектное проектирование. При необходимости структурный и объектный подходы могут использоваться одновременно.

Требования к надежности

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

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

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

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

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

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

5. Основные компоненты технологии проектирования ИС

Проектирование ИС предполагает использование различных средств проектирования как на традиционных так и на машинных носителях, в их числе:

- нормативно-правовые документы (стандарты, руководящие документы)

- системы классификации и кодирования информации

- системы проектной документации

- модели ИС и их компонентов

- методики анализа и принятия проектных решений

- программные средства (общие и специальные программные средства)

Сочетание различных методов и средств проектирования обуславливает выделение 2-х классов технологии проектирования:

1) Каноническое проектирование – соответствующее определенному канону, правилу.

2) Индустриальное проектирование

2.1) Автоматизированная технология проектирования

2.2) Типовая технология проектирования

2.2.1) Типовая параметрически-ориентированная технология

2.2.2) Типовая модельно-оринтированная технология.

Класс и подкласс технологии проектирования	Методы проектирования АИС
	По степени автоматизации проектных решений	По степени типизации проектных решений	По степени адаптивности проектных решений
Каноническое проектирование	Ручное проектирование	Оригинальное проектирование	Реконструкция
Индустриальное типовое проектирование	Ручное проектирование; автоматизированное  проектирование	Типовое  проектирование	Параметризация; реструктуризация модели (конфигурации АИС)
Индустриальное автоматизированное проектирование	Автоматизированное  проектирование	Оригинальное проектирование; типовое  проектирование	Реструктуризация модели (генерация АИС)

Выбор технологии проектирования осуществляется с учетом следующих требований:

1.          возможность обеспечения соответствия создаваемого с помощью конкретной технологии проекта  требованиям заказчика;

2.          способность выбираемой технологии обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;

3.          создание условий для повышения производительности труда проектировщика;

4.          обеспечение надежности процесса проектирования и эксплуатации проекта;

5.          простота ведения проектной документации.

6. Краткая характеристика применяемых технологий проектирования ИС. Выбор технологии проектирования ИС.

1.          Характеристики современных проектов. Определение проектирования. Объект проектирования. Основные особенности современных проектов ИС. Этапы создания ИС: формирование требований, концептуальное проектирование, спецификация приложений, разработка моделей, интеграция и тестирование информационной системы. Методы программной инженерии в проектировании ИС.

Проектирование (от латинского projectus, что означает “брошенный вперед”) – это процесс составления описания, необходимого для создания в заданных условиях еще не существующего объекта по первичному описанию этого объекта путем его детализации, дополнения, расчетов и оптимизации.

Описание объекта может быть задано по-разному: в виде текста, алгоритма, программы, чертежа, таблицы или, что чаще всего, комбинировано в традиционно бумажном или электронном виде.

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

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

Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;

• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

• требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

• требуемой пропускной способности системы;

• требуемого времени реакции системы на запрос;

• безотказной работы системы;

• необходимого уровня безопасности;

• простоты эксплуатации и поддержки системы.

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

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

Электронные методологии и технологии (и поддерживающие их CASE-средства) составляют ядро комплекса согласованных инструментальных средств среды разработки ИС.

 

Методология DATARUN опирается на две модели или на два представления:

• модель организации;

• модель ИС.

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

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

 

Инструментальное средство SE Companion [27] является средой, в которой реализован электронный вариант методологии DATARUN. Оно позволяет:

• создать гипертекстовое описание методологии в виде иерархии описания стадий, этапов и операций разработки;

• создать гипертекстовое описание всех методов и методик реализации процессов ЖЦ ПО;

• выделить из гипертекстового описания иерархию процессов ЖЦ ПО для планирования и управления процессом создания ПО (иерархию работ);

• изменять гипертекстовые описания ЖЦ и методов так, как это необходимо разработчику, иными словами, производить авторизацию методологии и отслеживать эти изменения в иерархии работ, предназначенной для управления проектом;

• привязать к процессам ЖЦ инструментальные средства поддержки этих процессов и обеспечить вызов инструментальных средств из соответствующих экранов гипертекстового справочника;

• обеспечить просмотр гипертекстовых экранов описания используемых методов из инструментальных средств;

• обеспечить поддержку процесса управления разработкой, в частности, за счет взаимодействия со средством планирования работ MS Project, оценивания трудоемкости проекта, отслеживания выполнения работ, создания графиков работ, и др.