книги / Проектирование систем управления технологическими процессами и производствами

Рис. 4.7. Блок-схема алгоритма проработки проекта новой СУ

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

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

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

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

4.5. Структурное проектирование

Структурное проектирование систем (рис. 4.8) является связую­ щим звеном между структурным (системным) анализом и проектиро­ ванием программно-технического комплекса системы управления.

Структурное проектирование отражает административно-управ­ ленческие и программно-технические аспекты функционирования системы управления и включает в свой состав логическое проектиро­ вание, физическое проектирование и прочие (сопутствующие) аспекты проектирования.

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

Сложность струюурного проектирования обусловлена тем, что программисты и технические специалисты, участвующие в проек­

Рис.4.9. Блок-схема алгоритма этапа структурного проектирования СУ

Логическое проектирование

Логическое проектирование СУ включает в себя декомпозицию

ипостроение логической модели.

Декомпозиция данных

После изучения системной спецификации приступают к анализу

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

При декомпозиции данных системы необходимо решить сле­ дующие подзадачи:

-выявление входных данных;

-выявление выходных данных;

-анализ хранимых данных;

-определение связей между хранимыми данными;

-анализ взаимосвязанных данных;

-сопоставление хранимых и входных данных;

-сопоставление выходных данных с хранимыми и входными данными.

Декомпозиция процессов

По завершении анализа данных проводится анализ требований

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

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

итем самым обеспечить гибкость для дальнейших этапов про­

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

При декомпозиции процессов необходимо выполнить следующие операции:

- ввести процессы идентификации и документации входных данных системы, с учетом “жизненного цикла” каждого входного данного;

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

-сопоставить хранимые и входные данные для процессов;

-идентифицировать элементы данных, не выявленные при

сопоставлении;

-идентифицировать и перечислить ограничения и перспективные потребности;

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

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

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

Физическое проектирование системы

Физическое проектирование СУ включает в себя уточнение технических деталей проекта, выявление ограничений и оценку времени работы автоматизированной системы.

Уточнение технических деталей

Уточнение технических деталей сводится к модификации логического проекта в соответствии с ограничениями, накладыва­

емыми возможностями использования программно-технических средств. Техническая реализация системы обычно не совпадает с логическим проектом (который представляет собой идеальный про­ ект), но должна к нему стремиться. Нередко существуют несколько альтернативных вариантов проекта, каждый из которых имеет право на реализацию. Разработчик должен помнить правило: “чем проще, тем лучше”.

Уточнение технических деталей представляет собой итератив­ ный процесс (то есть оно должно продолжаться до тех пор, пока не будут выполнены все технические требования) и включает следующие операции:

-документирование и утверждение ограничений;

-выбор способа физической реализации процедур и файлов;

-ввод процедур сортировки данных и управления доступом;

-оценка объемно-временных характеристик информационной системы.

Выявление ограничений

Ограничения следует разделить на внешние и внутренние. К внешним ограничениям относят:

-стоимость разработки;

-эксплуатационные расходы;

-стоимость комплекса программно-технических средств.

К внутренним ограничениям относят, в первую очередь, воз­ можности предприятия (финансово-экономические и кадровые).

Оценка времени работы информационной системы

Оценка времени работы системы определяется по времени работы каждой компоненты СУ, которое зависит от следующих факторов:

-приоритет выполнения заданий;

-число заданий;

-размер записей;

-число записей;

-использование каналов передачи данных;

-время, требуемое процессору для обработки заданий;

-время обращения к файлам;

-объем необходимой оперативной и дисковой памяти.

4.6. Исследование стоимости разработки систем управления технологическими процессами

и производствами

Исследование стоимости разработки системы проводится на основе отчета об анализе реализуемости разработки системы. Анализ проводится по принципу “затраты - эффективность”

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

-определение годовой экономии от внедрения системы управ­

ления;

-ежегодный экономический эффект от внедрения;

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

-общие затраты на проектирование и создание системы управ­

ления;

-срок окупаемости проектируемой системы.

Годовая экономия от внедрения системы определяется по формуле

где Н - ежегодный экономический эффект;

R - приведенные к одному АРМ затраты на приобретение средств вычислительной техники и системы передачи данных и т.д.

Ежегодный экономический эффект определяется по формуле

X К -С (Р - Ш )

(4.3)

100

где X - число ИТР и служащих, пользующихся одним АРМ (обычно

2 - 4 );

К- средневзвешенное число смен (1 - 2,5);

С- средние ежегодные затраты на одного сотрудника;

Р- относительная средняя производительность сотрудника, пользующегося АРМ (от 140 до 350%).

где Ci3- основная и дополнительная зарплата с отчислениями едино­ го социального налога, амортизация, ремонт (3- 4% от стои­ мости ВТ), затраты на аренду каналов связи, прочие расходы (принимаются в размере 0,7 - 1 % от стоимости ВТ) и т.д.

Коэффициент эффективности:

£ = 1 / 5 (4.11) Разработчик совместно с заказчиком подвергают структурный проект системы управления критическому анализу и сопоставляют его с общим планом разработки системы. Оцениваются технические характеристики системы и ресурсы, используемые совместно с дру­ гими системами. Проверяются обоснованность принятых решений и их качество. Если заказчик положительно оценивает результаты решения задачи, то подготавливается документация по плану проектирования новой автоматизированной системы и осущес­

твляется подготовка спецификации СУ.

Типовые расходы на внедрение автоматизированных систем

Общая стоимость внедрения автоматизированной системы (рис. 4.10) складывается, во-первых, из стоимости предпроектного обсле­ дования и разработки организационно-эксплуатационной схемы функционирования системы на конкретном предприятии; во-вторых, из стоимости лицензий на программные средства, входящие в состав системы; в-третьих, обучения персонала; в-четвертых, услуг по вы­ полнению пусконаладочных работ и максимально быстрому переводу системы в режим промышленной эксплуатации. Если стоимость лицензии на программные средства принять за 100%, то стоимость предпроектного обследования и разработки схемы функционирования составит примерно 30%, обучение персонала 20%, пусконаладочные работы 80%. Таким образом, общая стоимость внедрения для предприятия будет примерно в 2,2 - 2,3 раза больше, чем стоимость самой системы.

Суммарные затраты на разработку стратегии автоматизации, по экспертным оценкам, могут составить 5 - 1 0 тыс. долларов для предприятия численностью около 500 человек. Потери при отсутствии стратегии составляют от 100 тыс. до 800 - 900 тыс. долларов.