3.1.Системный подход

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

5. Разработка системы классификации объектов учета и управ­ ления и идентификации их параметров. Словари описывают основные понятия предметной области системы, необходимые для разработки стандартных алгоритмов обработки данных. Классификаторы опи­ сывают структуру объекта (подразделения, сотрудники, должности), внешней среды (клиенты, районы, пункты погрузки/разгрузки), характеристики материальных потоков (партии, фонды, единицы измерения, показатели качества, типы цен, виды оплаты). Типовые операции описывают алгоритмы управления (обработки инфор­ мации).

6.Разработка инфологической модели системы (проекти­ рование структур данных и их связей).

7.Синтез структуры программного обеспечения (агрегирование системы). При объединении отдельных функций управления в программные модули необходимо стремиться к высокой “прочности”

ислабому “сцеплению” модулей. Прочность и сцепление модуля являются, соответственно, мерами его внутренних и внешних связей. В зависимости от назначения модулей необходимо стремиться либо

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

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

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

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

10.Программирование модулей на выбранных инструменталь­ ных средствах программирования. При программировании необхо­ димо помнить, что текст программы нужен для людей, а не для вычислительной машины. Важность этого утверждения станет оче­ видна, когда наступит этап сопровождения системы. Для повышения надежности программного обеспечения следует использовать метод взаимного недоверия модулей, т.е. каждый модуль системы должен относиться с определенной долей недоверия (в разумных пределах)

кполученным входным данным и проверять их перед обработкой.

11.Интеграция (сборка) системы в соответствии с выбранным методом и ее тестирование. Этапы тестирования: автономное тести­ рование, т.е. контроль отдельного программного модуля изолированно от других модулей; тестирование сопряжений, т.е. контроль сопря­ жений между частями системы; тестирование функций, т.е. контроль выполнения системой автоматизируемых функций управления; комплексное тестирование, т.е. испытание поведения системы по отношению к исходным целям; тестирование приемлемости, т.е. проверка соответствия системы требованиям пользователей. Тести­ рование это процесс выполнения программы с целью найти в ней ошибки. Существует два подхода к проектированию тестов - тести­ рование по отношению к спецификациям (не заботясь о тексте про­ граммы) и тестирование по отношению к тексту программы (не заботясь о спецификациях). Разумный компромисс лежит где-то посе­ редине, смещаясь в ту или другую сторону в зависимости от функций, выполняемых конкретным модулем. Следует отметить, что стоимость этапа тестирования составляет до 25% от общей стоимости затрат на разработку автоматизированной системы управления.

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

13.Внедрение системы на объекте.

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

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

Проектирование автоматизированных систем является творческим процессом. Конкретные способы проектирования могут существенно различаться. Одним из основных аспектов проектиро­ вания СУ является увязывание частных задач в сквозную технологи­ ческую схему разработки автоматизированной системы. Только на этой основе можно согласовать различные точки зрения всех участни­ ков проекта, рационально использовать специалистов-разработчиков и эффективно контролировать получаемые проектные решения. Для успешного проектирования СУ необходимо разработать план по обеспечению ресурсами наиболее эффективных проектов, приме­ няющих прогрессивные технологии. Планированию проектирования автоматизированных системы должно предшествовать исследование основных направлений деятельности организации, в результате которого определяются главные задачи и способы реализации тех или иных функций. Характер основной деятельности организации в значительной степени определяет подход, применяемый при плани­ ровании проектирования СУ. Естественно, различны подходы при проектировании системы для конкретной организации, для группы однотипных организаций, для объединения нескольких различных организаций с несколькими сферами деятельности и организаций, предоставляющих сервисные услуги. Общим для всех подходов к проектированию и функционированию СУ является то, что выбор моделей программно-технических средств должен производиться только с учетом требований пользователей.

Постановка задачи предполагает формулирование основных задач проектирования АС и создание группы разработчиков (проек­ тировщиков) СУ, имеющих навыки анализа, проектирования и внедрения систем.

Постановка задачи на проектирование решает следующие задачи:

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

-анализ существующей системы;

-определение требований к новой системе (определение ключевых факторов эффективности).

Определение области применения'системы и планирование операций

Определение области применения системы и планирование операций осуществляется совместно с руководителями организации -заказчикаСУ и пользователями проектируемой автоматизированной системы. При определении области применения необходимо вы­ яснить:

-идеи и планы пользователей планируемой СУ;

-в каких подразделениях будет внедряться СУ;

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

-сможет ли планируемая система обеспечить решение требу­

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

подразделении.

Кроме того, следует определить все отрицательные стороны планируемой автоматизируемой системы.

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

Анализ существующей системы

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

-определение численности персонала, работающего с сущес­ твующей системой;

-определение численности обслуживающего персонала;

-определение типов оборудования, применяемого в сущес­ твующей системе.

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

Осуществляется сбор информации о структуре затрат, имеющих место в организации заказчика. К основной информации о структуре затрат относятся:

-заработная плата персонала, работающего с существующей системой;

-затраты на приобретение и обслуживание оборудования;

-эксплуатационные затраты.

В процессе анализа следует выявить сильные и слабые стороны деятельности организации, а именно:

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

-недостатки или достоинства в вопросах защиты данных в существующей системе;

-юридические и финансовые особенности функционирования организации, требования к ним;

-недостатки в производственных и внутрипроизводственных

связях.

Анализ реализуемости решений при проектировании системы управления (рис.3.1) включает в себя:

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

-предварительный вы­ бор поставщика оборудова­ ния и программных средств;

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

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

-завершение анализа реализуемости новой систе­ мы управления;

-утверждение отчета о реализуемости новой систе­ мы управления.

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

техническая составляющая, то первая альтернатива возни­ кает при выборе технических решений.

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

зависит от следующих факторов:

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

-анализ действующих (функционирующих) технических

средств;

-анализ “функция - данные - время”;

-логическое распределение данных и функций в сущест­

вующей системе;

-обработка данных (сбор, хранение, обработка и передача данных);

-экономические решения и условия;

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

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

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

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

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

-выбор поставщика, проведение предварительных пере­ говоров, выработка условий контракта.

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

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

-по основным функциям обработки информационных потоков;

-по входным и выходным данным;

-по логическим файлам существующей системы;

-по средствам защиты;

-по обеспечению непротиворечивости данных;

-по степени распределения обработки данных;

-по требованиям к техническим средствам;

-по средствам к программному обеспечению;

-по требованию к квалификации персонала.

Исследование и формирование альтернативных вариантов включают в себя:

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

-оценку стоимости рассматриваемых альтернативных вари­ антов эскизных проектов;

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

-исследование транзакций данных.

Сравнение альтернативных вариантов решений производится по следующим критериям:

-соответствие назначению;

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

-влияние представленных альтернативных решений на другие (существующие) системы;

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

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

-требования к квалификации персонала;

-требования к ресурсам вычислительной техники;

-требования к испытанию и тестированию;

-требования к переходу на новые технические средства;

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

-влияние на другие (существующие) СУ;

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

-стоимость эксплуатации;

-необходимость и тип используемых систем управления базами данных (СУБД), операционных систем (ОС) и прикладного программного обеспечения (ППО);

-гибкость при переконфигурации системы.

Выбор предпочтительного варианта альтернативного решения производится только в тесном сотрудничестве с пользователем (заказ­ чиком) системы управления и исходя из анализа “затраты - эффек­ тивность”.

Затраты при проектирование АСУ, включают в себя:

1)расходы на разработку:

-заработная плата сотрудников группы разработчиков си­

стемы;

-аренда (при необходимости) машинного времени для написания, отладки и тестирования программного обеспечения;

-прочие расходы на разработку системы (транспортные, снаб­ женческие и другие);

2)эксплуатационные затраты:

-заработная плата обслуживающего персонала;

-аренда помещений, линий (каналов) связи;

-передача данных;

-обслуживание оборудования;

-обслуживание программного обеспечения;

-сопровождение автоматизированной системы.

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

Планирование последующих фаз проектирования системы управ­ ления производится на основе:

-уточнения требований к ресурсам системы;

-координации планов разработки СУ с другими разра­ ботчиками смежных систем;

-анализа кадровых ресурсов пользователя (заказчика) си­

стемы;

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

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

Завершение анализа реализуемости новой (проектируемой) системы заключается в составлении итогового отчета. Основные разделы итогового отчета включают:

1)введение;

2)распределение полномочий между пользователями (заказ­ чиками) и разработчиками, а также между членами группы раз­ работчиков СУ;

3)описание существующей системы:

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

-определение и анализ ключевых факторов эффективности существующей системы;

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

4)описание предлагаемой системы:

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

-описание имеющих место ограничений для новой системы;

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

-описание, необходимого для новой СУ, программного и технического обеспечения;

-описание методов и необходимых программно-технических средств, при защите и контроле данных.

5) план разработки;

6) ожидаемые затраты на проектирование СУ и расчет времени окупаемости системы (определение опосредованной прибыли);

7) анализ всех альтернативных вариантов проектирования системы управления;

8) заключение и рекомендации для проектирования СУ;

9) приложения.

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

4. РАЗРАБОТКА ЭСКИЗНОГО ПРОЕКТА СИСТЕМ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ

И ПРОИЗВОДСТВАМИ

Разработка эскизного npoeicra является одной из наиболее важ­ ных стадий проектирования системы управления. В результате ана­ лиза реализуемости разработки системы определяется один из альтернативных вариантов новой СУ. Именно этот вариант и берется за основу разработки эскизного проекта.

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

Стадия разработки эскизного проекта включает решение следу­ ющих задач:

-определение различных логических решений;

-разработка операционных диаграмм;

-определение границ автоматизации;

-исследование стоимости реализуемых решений;

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

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

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

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

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