Ключевые слова: АСУ, проектная документация, проектирование.
Сокращения, термины, определения
УГО — условное графическое обозначение.
Проект — продукт деятельности проектирования [1].
Проектирование — перефразируя [2], опережающее отражение действительности, при котором создается прообраз (прототип) предполагаемого явления, процесса или системы посредством специальных средств и методов.
Предметная область проекта — класс (множество) всех объектов и связей между ними, рассматриваемых в пределах данного проекта.
Сущность — реальный или абстрактный объект предметной области проекта, связь между объектами предметной области проекта.
Класс сущностей — сущности предметной области проекта, для которых некоторая характеристика является общей.
Атрибут сущности — элемент данных, хранящий в себе значение некоторого свойства сущности; значение атрибута есть значение свойства сущности.
Перечисление — набор значений атрибутов конкретной сущности
Проектная документация —документация, содержащая материалы в текстовой форме и в виде карт (схем) и определяющая архитектурные, функционально-технологические, конструктивные и инженерно-технические решения для обеспечения строительства, реконструкции объектов капитального строительства, их частей, капитального ремонта, если при его проведении затрагиваются конструктивные и другие характеристики надежности и безопасности объектов капитального строительства. [3, Ст.48].
Проектные решения — решения, которые отражают замысел проекта и которые описаны в проектной документации.
Исходные данные для проектирования — данные об объектах и данные о связях между объектами предметной области проекта, т. е. данные о сущностях.
Содержание проекта — все сущности проекта.
Форма проекта — представления сущностей и описания проектных решений.
Представления сущностей — таблицы содержания и УГО сущностей.
Таблица содержания — набор перечислений.
УГО сущности — набор графических примитивов, как визуальное представление сущности.
Описания проектных решений (схемы) — наборы УГО сущностей.
Введение
Цель разработки методики — формализация принципов функционирования и объемов реализуемых функций среды разработки проектной документации автоматизированных систем управления.
Методика применима к разработке проектной документации автоматизированных систем управления, указанных в области применения [4].
Основная часть
Общие положения
Исходя из терминов и определений предлагаемой методики, проект — это совокупность содержания и формы. Содержание проекта — это совокупность всех сущностей проекта, иными словами — совокупность всех элементов и связей между ними [4, п.2.5]. Форма проекта — это таблицы содержания (в которых описываются свойства элементов и связей), УГО элементов и связей (которые являются их графическими представлениями), схемы (в которых описываются проектные решения и которые являются совокупностью УГО элементов и связей). Таким образом, на содержательном уровне элементы и связи между ними — это содержание проекта, на формальном уровне элементы и связи между ними — это схемы.
Процедуры методики
Предлагаемая методика выделяет следующие процедуры в разработке проектной документации:
1. Разработка таблиц содержания.
2. Заполнение таблиц содержания.
3. Разработка УГО сущностей.
4. Разработка совокупности схем.
5. Выпуск комплекта проектной документации.
Разработка таблицы содержания сводится к формированию наборов атрибутов, описывающих некоторый класс сущностей. Атрибуты данного набора есть поля таблицы содержания.
Заполнение таблицы содержания сводится к формированию набора перечислений. Перечисления данного набора есть записи таблицы содержания.
Графическим представлением сущности является её условное графическое обозначение. Описание УГО сущности — это набор графических примитивов (линий, окружностей, статического текста и т. д.) и динамического текста. Динамический текст — это ссылка на атрибут из набора атрибутов сущности (на поле таблицы содержания). Для сущности может существовать неограниченное количество описаний УГО. Каждое описание УГО создается только для одного класса сущностей. Вхождение УГО сущности в схему привязано к перечислению (к конкретной записи таблицы содержания). Динамический текст данного вхождения заполняется значением из связанного атрибута перечисления. Изменение значений атрибута приводит к изменению динамического текста. Допустимо, но не обязательно, что изменение динамического текста приводит к изменению значения связанного атрибута.
Разработка совокупности схем является процессом описания проектных решений. Схема — это набор вхождений УГО сущностей (элементов и связей между ними в формальном понимании). В схеме должны присутствовать только вхождения УГО сущностей и поясняющие комментарии. Надо отметить, что понятие «текстового документа» [5, п.3.1.2] не противоречит предложенному понятию «схема», поскольку на объемы текста, хранящемуся в атрибутах перечислений, не накладывается ограничений. Поэтому вхождения УГО сущностей могут состоять только из динамического текста неограниченного размера в виде сплошного текста или в виде текста, разбитого на графы.
Выпуск комплекта проектной документации сводится к оформлению разработанных документов либо в электронном виде [6, п.3.1.1], либо в сброшюрованном виде [7, п.8.1].
Практическое применение методики
Этапы разработки проектной документации удобно изображать в виде спирали, применяя принципы спиральной модели Боэма [9]. Как видно из рисунка 1, в разработке проектной документации можно выделить четыре основных этапа:
1. Этап определения требований, получения исходных данных и анализа.
2. Этап принятия проектных решений.
3. Этап описания проектных решений.
4. Этап согласования и передачи проектной документации.
Рис. 1. Спиральная модель этапов разработки проектной документации
Требования заказчика, предъявляемые к проектируемой системе, а также к проектной документации на данную систему, передаются проектировщику в задании на проектирование, которое оформляется в виде технического задания или документа его заменяющем. Вместе с утвержденным заданием на проектирование заказчик передает проектировщику исходные данные, необходимые для разработки проектной документации. Перечень исходных данных определяется спецификой предметной области проекта. Порядок разработки задания на проектирование, а также порядок сбора и подготовки исходных данных не описываются в предлагаемой методике.
Этап 1. Полученные проектировщиком задание на проектирование и исходные данные анализируются. Затем выполняются процедуры 1, 2, 3: разрабатываются таблицы содержания, таблицы содержания заполняются полученными исходными данными, разрабатываются УГО сущностей.
Этапы 2,3. Этапы принятия и описания проектных решений тесно связаны. На основании имеющихся требований и исходных данных принимаются общие решения, которые описываться в виде схем, т. е. выполняется процедура 4. В процессе разработки схем решения конкретизируются, уточняются и могут корректироваться.
Этап 4. На последнем этапе разработанные документы преобразуются в файлы электронных копий, либо распечатываются и брошюруются в тома и передаются заказчику (процедура 5). Заказчик их рассматривает и, в случае согласования, документы считаются переданными. Если у заказчика имеются обоснованные замечания к полученной документации — цикл разработки повторяется: уточняются требования или исходные данные, принимаются и описываются уточненные проектные решения, документы соответствующим образом оформляются и передаются заказчику на повторное согласование.
Спиральная модель может применяться как к разработке полного комплекта проектной документации, так и к отдельным его документам. Это дает возможность выполнять проектные работы в ситуации, когда проектировщику переданы неполные исходные данные, которые в дальнейшем уточняются и дополняются. Завершение работ над отдельными документами комплекта на каждом этапе позволяет переходить на следующий, не дожидаясь на текущем этапе полного завершения работ над документами всего комплекта. Работу над оставшимися документами комплекта можно будет выполнить на следующей итерации, когда необходимые исходные данные будут уточнены или дополнены. Главная задача — как можно быстрее передать заказчику хотя бы часть документации, тем самым активизируя процесс уточнения и дополнения требований.
Рисунок 1 показывает качественную зависимость стоимости проектных работ от количества итераций разработки проектной документации. Передача проектировщику выверенных требований, а также полных и неизменных исходных данных является одним из способов снижения стоимости проектных работ, поскольку в этом случае количество итераций уменьшается, а в идеальном случае сводится к одной итерации.
Заключение
Предлагаемая методика не применима для разработки проектной документации, требующей многоитерационных и/или сложных/объемных вычислений. Для решения подобных задач необходимо применять системы автоматизированного проектирования. Поэтому предлагаемая методика применима для проектной документации, разрабатываемой на основании больших объемов изменяющихся исходных данных, описывающих большое количество взаимосвязанных объектов, связи между которыми, меняются при изменении исходных данных.
Используя предлагаемую методику можно сформировать среду разработки проектной документации с помощью существующих программных продуктов, которая должна в себя включать:
- систему управления базой данных (СУБД), как инструмент, реализующий разработку таблиц содержания;
- графический редактор, имеющий, как минимум, одностороннюю связь от СУБД к данному редактору, и используемый как инструмент, реализующий разработку УГО и схем.
Однако наибольшая эффективность, надежность и производительность разработки и выпуска проектной документации может быть достигнута при комплексной реализации описанных процедур в составе единой среды разработки.
Литература:
1. Новая философская энциклопедия: В 4 тт. М.: Мысль. Под редакцией В. С. Стёпина. 2001.
2. Российская социологическая энциклопедия. — М.: НОРМА-ИНФРА-М. Г. В. Осипов. 1999.
3. Градостроительный кодекс РФ (в ред. Федерального закона от 18.07.2011 № 243-ФЗ).
4. РД 50–680–88. Методические указания. Автоматизированные системы. Основные положения.
5. ГОСТ Р 21.1002–2008. СПДС. Нормоконтроль проектной и рабочей документации
6. ГОСТ Р 21.1003–2009. СПДС. Учет и хранение проектной документации.
7. ГОСТ Р 21.1101–2009. СПДС. Основные требования к проектной и рабочей документации
8. ГОСТ 34.320–96. Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы.
9. Boehm B. A. Spiral Model of Software Development and Enhancement. IEEE Computer, 21 (5), 1988. — pp. 61–72
