Эскизный и технический проекты

По опыту выполнения реальных проектов этап работ 5.1 «Разработка проектных решений по системе и ее частям» стадии 5 «Техническое проектирование» (см. табл. 5.1) может быть представлен в виде двух групп относительно самостоятельных шагов, как показано в табл. 9.4.

Важнейшим шагом этапа 5.1 «Разработка проектных решенийпо системе и ее частям» стадии 5 «Техническое проектирование» является разработка функциональной архитектуры ИС.

Синтез функциональной архитектуры системы заключаетсяв определении (указании, задании, выделении) подсистем, каждаяиз которых реализует некоторый набор решаемых задач, и связеймежду ними

Разработка архитектуры ИС осуществляется несколько раз. Вопросы, связанные с задачами и подсистемами, уже упоминались:

1) при разработке ТЭО: на этапе работ 2.4 «Оформление отчетао выполненной работе (разработка и утверждение ТЭО)» стадии«Разработка концепции ИС» (см. «Ориентировочное содержаниеТЭО»);

2) при разработке ТЗ на стадии 3 «Техническое задание» (см. пояснения к составу работ этапа 3.1 «Разработка и утверждение технического задания на создание ИС»);

3) при выполнении этапа работ 4.1 «Разработка предварительныхпроектных решений по системе и ее частям» стадии 4 «Эскизныйпроект».

Таблица 9.4 – Группы и шаги работ этапа 5.1 «Разработка проектных решений по системе и ее частям стадии 5 «Техническое проектирование»

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

Функциональная архитектура синтезируется на основе одного из следующих принципов:

- предметный;

- функциональный;

- предметно-функциональный (смешанный).

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

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

- тестируемость (возможность установления факта правильного функционирования);

- диагностируемость (возможность нахождения неисправной части ИС);

- ремонтопригодность (возможность восстановления работоспособности за минимальное время при экономически оправданной стоимости ремонта);

- надежность (способность длительное время работать без восстановлений;

- простота обслуживания и эксплуатации (минимальные требования к квалификации и дополнительному обучению эксплуатирующего персонала);

- безопасность (соответствие требованиям промышленной безопасности и технике безопасности;

- защищенность системы от вандалов и неквалифицированных пользователей. Во многих языках эта защищенность обозначается японским выражением пока-ёкэ – «защита от ошибки»; употребляется также созвучное выражение бака-ёкэ – «защита от дурака» и английское выражение mistake-proofing;

- экономичность (экономическая эффективность в процессе работы ИС;

- модифицируемость (возможность перенастройки для работы с другими технологическими процессами;

- функциональная расширяемость (возможность ввода в систему дополнительных функциональных возможностей, не предусмотренных в ТЗ;

- наращиваемость (возможность увеличения размера ИС при увеличении размера объекта автоматизации;

- открытость. Признаками открытых систем являются:

ü модульность;

ü платформенная независимость;

ü взаимозаменяемость с компонентами других производителей;

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

ü масштабируемость;

- возможность переконфигурирования системы при переходе на новую программно-аппаратную платформу;

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

- минимальное время на монтаж и пусконаладочные работы (развертывание) системы.

Стадия технического проектирования повторяет и практическиокончательно уточняет не только вопросы, связанные с разработкойархитектуры ИС. На всех предыдущих стадиях в той или иной формеразрабатываются аппаратное, организационное, информационноеи программное обеспечения, а также планируется внедрение создаваемой ИС. Технический проект завершает создание всех указанныхбазовых обеспечений, кроме программного, разработка которого завершается на следующей стадии рабочего проектирования. Завершение разработки базовых обеспечений ИС обусловливает особыйстатус стадии «Техническое проектирование».

Особую важность среди локальных проектных решений стадии«Техническое проектирование» имеет разработка постановок задачдля каждой подсистемы. «Постановка задачи» – это основа разработки важнейших обеспечений ИС: информационного и программного. Как документ «Постановка задачи» состоит из трех разделовпредставленных в табл. 9.5.

Таблица 9.5 – Структура документа «Постановка задачи»

«Цель автоматизации задачи» – это формулировка ожидаемых положительных эффектов, обычно одного или нескольких, из следующих:

- получение экономического эффекта в области управления процессами объекта автоматизации;

- снижение финансовых и (или) трудовых затрат на процедуры обработки информации;

- повышение достоверности информации, используемой на предприятии;

- сокращение времени обработки информации;

- упрощение процедуры обработки информации.

«Экономическая сущность задачи» – это перечень экономических показателей, вычисляемых в процессе решения задачи.

Здесь же, частично дублируя сведения из последующих разделов указываются:

- исходные показатели (данные), необходимые для вычислений;

- перечень документов, из которых извлекаются исходные показатели;

- перечень документов, в которые помещаются вычисленные (результатные) показатели.

«Организационная сущность задачи» – описание порядка решения задачи (с частичным дублированием сведений последующих разделов), включая следующее:

- организационные формы решения задачи (кто решает, где, в какое время, с использованием какого оборудования);

- способ получения и ввода исходных данных

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

«Алгоритм решения задач» – это обычное описание алгоритма, содержащее следующие обязательные элементы:

- спецификация исходных данных и результатов вычислений – ихсимволических обозначений (идентификаторов) и семантики (названия входных и результатных показателей);

- формальное представление алгоритма – блок-схема или псевдокод, или диаграмма Насси–Шнейдермана (N-S-диаграмма, структурограмма).

Рисунок 9.2. Схема связи задачи «Расчет технико-экономических

показателейс другими задачами:

УТПП – задача «Управление технической подготовкой производства»;

БУ – задача«Бухгалтерский учет»;

ТЭП – задача «Технико-экономические показатели»; УК – задача «Учет и контроль»

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

«Связь с другими задачами» наряду с текстовыми формулировками может содержать схему, подобную схеме, приведенной на рис. 9.2.

Семантика связей такова.

Входящие связи:

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

i2 – данные о трудовых затратах на производственную программу для расчета плановой численности рабочих;

i3 – данные о численности рабочих по должностям для планирования численности рабочих на производственную программу;

i4 – данные о наличии рабочих для выявления отклонений от плановой численности на производственную программу.

Исходящие связи:

o1 – данные о величине планируемого фонда заработной платы для корректировки базового фонда;

o2 – данные об оптимальном плане производства для расчета трудоемкости работ на производство изделий;

o3 – данные о плановом количестве рабочих, занятых изготовлением изделий, для учета и контроля движения кадров.

Структура документа «Технический проект» представлена в табл. 9.6.

Таблица 9.6 – Структура документа «Технический проект»

Продолжение таблицы 9.6

Продолжение таблицы 9.6

Рабочий проект

ГОСТ 34.601–90 алогичен в формулировках. Стадия рабочего проектирования называется «6. Рабочая документация»; первый этап работ – «6.1. Разработка рабочей документации на систему и ее части»; второй этап – «6.2. Разработка или адаптация программ» (выпадает из процессов документирования).

В практике реального создания ИС рабочее проектирование, естественно, начинается с реализации проектных решений, принятых на стадии технического проектирования, а заканчивается разработкой документации, называемой «Рабочий проект». Наиболее важной работой стадии рабочего проектирования является кодирование [5], или реализация программного обеспечения. Для осуществления кодирования в прошлом активно использовалась парадигма структурного программирования, практически полностью вытесненная парадигмой объектно-ориентированного программирования к концу 1990-х гг.

Непосредственно в процессе кодирования и сразу же по его завершении осуществляется составление программной документации, состав которой определяется ГОСТ 19.101–77 «Единая система программной документации: Виды программ и программных документов» [6] и ГОСТ 19.105–78 «Единая система программной документации: Общие требования к программным документам [7].

Наиболее часто оформляются следующие документы:

- спецификация программы;

- контрольные примеры;

- руководство пользователя;

- руководство оператора;

- руководство системного программиста.

Эффективность использования созданной ИС во многом определяется качеством оформления технологической документации, которая традиционно включается в состав рабочей документации и предназначена для применения пользователями системы на их рабочих местах. Разработку технологической документации регламентирует ГОСТ 3.11.09–82 «Система технологической документации. Термины и определения основных понятий» [8].

На этапе рабочего проектирования разрабатывается комплектдокументов, называемых правовыми инструкциями и образующихбазовую часть правового обеспечения ИС. Таким образом, «Рабочийпроект» как документ содержит следующие разделы.

1. Программная документация.

2. Технологическая документация.

3. Правовая документация.