Такой задачей является задача формирования так называемого титульного списка задач АСОИУ (ТСЗ) и распределения ресурсов между этими задачами.

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

Формальная постановка этой задачи в простейшем варианте за­ключается в следующем: максимизировать линейную форму

при ограничениях:

где           

общее число задач;  - количество видов ресурсов;  - сум­марное количество ресурса  -го типа, выделенного на создание АСОИУ;  - общая потребность  -й задачи в ресурсе  -го типа; - ожидаемый эффект от внедрения  -й задачи. При формировании ТСЗ на начальных этапах разработки АСОИУ рассматриваются, как правило, ресурсы одного вида - стоимостные. При этом задача пишется в виде

                    (1)

                                      (2)

где  - общее количество стоимостного ресурса, выделенного на создание АСОИУ;

  - общая потребность  –й  задачи в стоимостном ресурсе.

Задача (1) - (2) является известной в линейном целочисленном программировании "задачей о ранце", одним из наиболее эффективных методов решения которой является метод динамического программиро­вания. Решение этой задачи позволит сформировать ТСЗ АСОИУ.

После определения ТСЗ возникает задача оптимального распре­деления ресурсов между различными задачами титульного списка.

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

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

- минимизация времени реализации всех задач АСОИУ;

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

- максимизация суммарного эффекта задач, получаемого в период разработки АСОИУ.

Рассмотрим более подробно последнюю задачу. Ее математичес­кая постановка может быть записана в следующем виде:

максимизи­ровать линейную форму

                                                                         (3)                                                        

при ограничениях:

                  (4)

 

                       (5)

Здесь:

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

- = - момент окончания разработки  –й задачи;

- п - число задач титульного списка;

- ожидаемый эффект в единицу времени от внедрения  –й задачи;

- Т- заданное время разработки и внедрения АСОИУ;

-  - количество видов ресурсов;

-  - поток  -го ресурса, поступающий для раз­работки и внедрения АСОИУ;

-  - поток ресурса  -го вида, тре­буемый для разшботки  -й задачи;

 -  - общая потребность  -й задачи в ресурсе  -го типа.

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

                          (6)

где  - множество задач, предшествующих  -й задаче ( ).

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

Целевая функция характеризует эффект, получаемый от внедре­ния задач АСУ еще в период ее разработки, т.е. до момента окон­чания директивного срока разработки Т.

Действительно, - эффект, получаемый от  -й задачи с момента до момента Т, Ограничение  (4) - мгновенное ограничение на ресурсы  -го вида в момент времени  . Ограничение (5) - интег­ральное ограничение на ресурсы  -го вида, поступающие для ре­шения i-й задачи.

Если принять допущения о возможности суммирования по всем j для каждого момента t используемых ресурсов за счет введения соответствующих коэффициентов, то, как показано в работе [2] , в этом случае справедливо следующее утверждение:

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

Обозначим через  некоторый чисто последова­тельный план. Здесь - номер задачи, выполняемой в первую очередь; - номер следующей выполняемой задачи и т.д.

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

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

Организационное обеспечение АСОИУ представляет собой совокупность средств и методов, предназначенных для проведения:

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

2)  выбора и постановки задач автоматизации управления;

3)  организации процесса функционирования объекта управления в условиях АСОИУ.

Оно необходимо для обеспечения взаимодействия персонала АСОИУ с техническими средствами и между собой в процессе решения задач управления. Структура организационного обеспечения на примере АСУ ВД представлена на рис. 3.15.

Рис. 3.15. Схема структуры организационного обеспечения АСОИУ

 

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

- порядок взаимодействия работников предприятия с АСОИУ и ее разработчиками,

- изменять порядок прохождения доку­ментов и принятия решений на предприятии,

- определять статус элек­тронной информации и документов,

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

- стимулировать персонал к эффективной и безошибочной работе с системой,

- защищать систему от ошибочных действий персонала.

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

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

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

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

Структура правового обеспечения АСОИУ дана на рис. 3.16.

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

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

Диалоговое обеспечение - это совокупность средств (визуаль­ных, сенсомоторных и др.) и принципов организации обмена информацией  между пользователями и АСОИУ. Проектирование диалогово­го обеспечения включает в себя:

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

- разработку сценариев диалога различных пользователей с под­системами АСОИУ,

 

Рис. 3.16. Схема структуры правового обеспечения АСУ

 

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

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

В большинстве случаев диалог пользователя с системой проекти­руется в соответствии с требованиями общепринятого стандарта CUI (Common User Interface) пользователей персональных компьютеров, разработанного фирмой IBM. Этот стандарт поддерживается боль­шинством инструментальных средств для разработки пользователь­ских приложений.

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

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

 

 

Рис. 3.17. Схема структуры лингвистического обеспечения АСОИУ

 

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

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

Для административно-организационных АСОИУ эргономическое обеспе­чение обычно сводится к выбору мебели (столов, кресел), грамотному подбору н размещению компьютерных мониторов, организации осве­щения. регламентированию режима труда и отдыха персонала.

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

Метрологическое обеспечение - это комплекс мер и техниче­ских средств, обеспечивающих заданное качество взаимодействия АСОИУ с объектом управления. Это взаимодействие включает в себя регистрацию и преобразование первичной информации об объекте управления, формирование управляющей информации и ее передачу исполнительным механизмам. Данный вид обеспечения характерен, прежде всего, для управляющих систем. В него входят требования к точности измерений параметров и к метрологическим характеристи­кам измерительных каналов, обеспечение метрологической совмести­мости технических средств системы, метрологическое обеспечение технических и программных средств, описание порядка выполнения метрологической аттестации с указанием организаций, проводящих ее.

Между всеми видами обеспечений АСОИУ существует логическая и содержательная связь, что представлено на рис. 3.18.

 

Лекция 13

3.2.2. Функциональные подсистемы АСОИУ

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

Доступ каждого пользователя к «своей» функциональной подсис­теме осуществляется через автоматизированное рабочее место (АРМ) - программно-технический комплекс, ориентированный на оп­ределенный вид деятельности (например, АРМ технолога, АРМ бух­галтера и др.).

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

 

Объект управления

Рис 3.18. Виды обеспечения АСОИУ и их взаимосвязь

Современная западная концепция управления предприятием бе­рет свое начало в I960-х годов. Первым шагом в ее развитии стал но­вый подход к планированию потребностей в материалах (MRP - Ma­terial Requirements Planning). Основная идея системы управления MRP состоит в том, что любые материалы и комплектующие, необходимые для выполнения заказа, должны быть в наличии в нужное время и в нужном количестве. Данная задача носит как учетный, так и оптими­зационный характер.

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

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

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

Развитием подхода MRP-II явилось вовлечение в процесс управ­ления ресурсами еще одной задачи - управления финансами. Управ­ленческим подходом следующего поколения стало планирование де­нежных средств (MRP-III - Money Resource Planning), направленное на анализ и прогнозирование возможности реализации производст­венного плана с точки зрения наличных и предполагаемых денежных средств. В современных системах управления подсистема управления финансами охватывает чрезвычайно широкий диапазон задач, таких как учет прямых и косвенных затрат в различных разрезах, составле­ние бюджета и финансового плана предприятия, учет финансовых средств и управление платежными операциями, оценка финансового риска, планирование инвестиций, составление финансовой н налого­вой отчетности и др.

Описанные выше MRP-подходы были обобщены и объединены в единую концепцию планирования ресурсов предприятия (ERP - Enterprise Resource Planning), являющуюся сегодня де-факто западным стандартом системы управления предприятием. Помимо MRP-функ­ций система управления EFJP включает в себя:

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

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

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

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

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

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

управление формированием производственной структуры;

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

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

управление транспортным процессом;

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

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

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

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

 управление финансами и денежными средствами.

 Подавляющее большинство готовых западных систем автомати­зации, предлагаемых для внедрения на предприятиях различного раз­мера и направленности, ориентированы на ERP-концепцию управле­ния. Такие системы носят название ERP-систем. К их числу относятся не только лидеры мирового рынка SAP R/3, Baan, Oracle Applications, Axapta, но и десятки других систем среднего и малого класса, в том числе и отечественных.

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

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

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

 - разработка аналитических средств поддержки решений,

 - внедрение средств обеспечения качества продукции и услуг,

 - развитие средств взаимодействия с потребителями.

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

В то же время успешное функционирование и, главное, развитие предприятия немыслимы без обобщенной оценки его дея­тельности. анализа долгосрочных трендов и принятия перспективных стратегических решений. На этой почве сегодня возникло расширение ERP-систем, называемое интеллектуальным управлением (BI - Busi­ness Intelligence, бизнес-аналитика) и предназначенное для анализа информациии принятия решений по управлению предприятием.

Основными технологиями в области интеллектуального управле­ния стали организация хранилищ данных (Data Warehouse) и системы интеллектуального анализа данных (OLAP - On-line Analytical Process­ing).

Сегодня большинство известных ERP-систем снабжаются анали­тическими модулями управления эффективностью предприятия (кор­порации) (СРМ - Corporate Performance Management). Наряду с этим широко известны специализированные аналитические системы, такие как пакет статистического анализа SAS, системы семейства Hyperion и Cognos и др.

Предпосылками второго направления расширения функ­циональных возможностей ERP-систем стало появление еще в 50-60-е годы концепции непрерывного усовершенствования производствен­ных процессов (CPI - Continuous Process Improvement) и общего управления качествомпроизводимой продукции и услуг (TQM - Total Quality Management). Позднее оба этих подхода легли в основу повсе­местно используемых сегодня стандартов серии ISO9000.

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

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

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

Модули управления качеством сегодня являются составной ча­стью крупных ERP-систем, таких как SAP R/3.

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

Предпосылкой этого стало появление концепции планирования ресурсов, скоординированного с клиентами (CSRP - Customer Syn­chronized Resource Planning), ставящей запросы потребителей как на производственное, так и на сервисное обслуживание во главу угла производственного планирования. В соответствии с этой концепцией весь цикл производства продукции - от оформления технического за­дания и проектирования до гарантийного и сервисного обслуживания проданных изделий - должен осуществляться с учетом требований, а возможно, и с участием заказчика.

Для реализации этой концепции ERP-системы были дополнены новой функцией управления взаимодействием с клиентами (CRM - Customer Relationships Management), реализующей не только учет кли­ентов и их обращений, но н анализ структуры их запросов, прогнози­рование конъюнктуры рынка, маркетинговые и рекламные функции и т.п. Как правило, основой взаимодействия с клиентами сегодня явля­ется Web-технология, на использование которой в последнее время ориентируется подавляющее большинство ERP-систем. Что касается гарантийного обслуживанияпроданных изделий, то в большинстве ERP-систем эта функция либо входит в модуль управления техническим обслуживанием и ремонтом оборудования, либо объединяется с ним в единую подсистему сервиса.

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

По­мимо перечисленных выше функций и подходов к управлению в со­временной литературе по автоматизации предприятий встречаются и другие управленческие технологии, такие как управление содержа­тельной деятельностью предприятия (EСМ - Enterprise Content Man­agement), управление информацией предприятия (корпоративной ин­формацией) (ЕIM - Enterprise Information Management), управление жизненным циклом продукции (PLM - Product Lifecycle Management), управление данными об изделии (PDM - Product Data Management), расширенное производственное планирование (APS - Advanced Man­ning and Scheduling), управление знаниями (КМ- Knowledge Management) и т.п.

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

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

Появление клиент-серверных технологий породило еще один вид приложений - клиентские приложения. Конечно, с этой точки зрения любой компонент АСОИУ (в том числе и сама система) является приложением.

 

 

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

 

В качестве иллюстрации функционального состава АСОИУ рас­смотрим несколько наиболее известных и популярных на рынке сис­тем. Эти системы поставляются в виде совокупности готовых моду­лей, настраиваемых «под конкретное предприятие».

Система Baan . Система реализована в открытой трехуровневой архитектуре «клиент-сервер», поддерживает технологии СОRВА, OLE, поддержи­вает операционные системы Unix, Windows, OS/390, работает с базами

данных Oracle, Informix, MS SQL Server, DB2 BaanBase, поддержива­ет работу пользователей через Интернет. Структурно система состоит из модулей, объединенных в семь интегрированных функциональных подсистем:

финансы - учет и анализ финансовой информации, управление денежными средствами и платежами, финансовое планирование,

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

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

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

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

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

сервис - планирование периодического технического обслужива­ния и ремонта оборудования как внутри, так и вне предприятия.

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

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

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

Система Axapta . Система, имеющая полное название - Microsoft Business Solution - Axapta, предназначена для автоматизации предпри­ятий среднего размера и имеет очень богатый опыт внедрения в Рос­сии и странах Восточной Европы. Ориентирована на легкую и пище­вую промышленность, металлургию и металлообработку, нефтегазо­вую и химическую промышленность, электроэнергетику, торговлю, транспорт и связь.

Система реализована в открытой трехуровневой архитектуре «клиент-сервер», поддерживает объектно-ориентированный подход, динамически масштабируема, работает с базами данных Oracle, MS SQL, Server. Поддерживает операционнуюсистему Windows, поддерживает доступ через Интернет, имеет модуль электронной тор­говли, имеет специальный встроенный язык объектно-ориентированного програм­мирования Х++, интегрируется с внешними приложениями.

Модули системы: главная книга (с подсистемами финансы, ва­люта. налоги), банковские операции, заказы, расчеты с клиентами, закупки, расчеты с поставщиками, управление запасами, управление складом, спецификации, маршруты, рабочие центры, производствен­ные заказы, сводное планирование, персонал, проекты, управление знаниями, управление связями с клиентам.

Лекция 14

3.2.3. Архитектура АСОИУ

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

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

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

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

С точки зрения структурной централизация в историческом раз­витииАСОИУ в нашей стране можно выделить три этапа (см. рис. 3.20)

Первый этап - от появления первых АСОИУ (начало-середина 70-х годов) до распространения персональных ЭВМ (конец 80-х - на­чало 90-х годов). Для этого этапа характерны системы с жестко ней­трализованной архитектурой.

Центральным звеном большинства АСОИУ этого поколения была одна или две большихЭВМ (в основном, класса ЕС ЭВМ), в которых сосредоточены все ресурсы - от дис­ковой памяти до дисплейных рабочих мест, управляемые единым цен­тральным процессором. Автоматизированные дисплейные рабочие места пользователей такой системы, как правило, не обладали собст­венными вычислительными ресурсами и являлись, по сути, выносными терминалами большой ЭВМ. Помимо диалогового режима работы та­кие системы предусматривали множество функций, выполнявшихся в пакетном режиме. Необходимо отметить, что централизация вычисли­тельных ресурсов вовсе не гарантировала централизованного выпол­нения функций. Это больше зависело от культуры разработчиков сис­темы и степени унификации применяемых технологий разработки.

Появление в 80-е годы ЭВМ с архитектурой типа «общая шина» наметило тенденцию к частичной децентрализации АСОИУ. Однако серьезного развития эта тенденция получить не успела.

Второй этап был полностью спровоцирован массовым рас­пространением персональных ЭВМ и продолжался до середины 90-х годов. АСОИУ этого периода создавались с децентрализованной архи­тектурой как совокупность одноуровневых самостоятельных АРМ, связанных между собой локальной сетью (рис. 3.20,а) (так называемая «лоскутная» или «островковая» автоматизация). С функциональной точки зрения каждый АРМ является автономной функциональной сис­темой (функциональной подсистемой АСОИУ), обеспечивающей пол­ный цикл решения некоторой управленческой задачи (например, бух­галтерский учет, планово-экономические расчетыи др.), включая реа­лизацию функций хранения, обработки и представления информации.

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

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

 

Рис. 3.20. Жизненный цикл АСОИУ

 

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

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

Началом третьего этапа можно считать середину 1990-х годов. Характерной особенностью этого этапа стал постепенный воз­врат к централизованной архитектуре. Первым шагом стало появление клиент-серверных технологий создания баз данных, позволяющих реализовать двухуровневую частично централизованную архитектуру с централи­зованным хранениемданных («единым информационным пространст­вом») (рис. 3.20,б). При такой архитектуре вся информация, используемая в процессе решения различных управленческих задач, структурирует­ся в соответствии с единой информационно-логической (концептуаль­ной) моделью и сводится в одно место - сервер данных. Сервер дан­ных ничего не знает о том, как используются хранящиесяна нем данные, его задача - реализовать структуру, логику и взаимосвязи между этими данными, обеспечить их целостность и безопасность. Данные, поступающие на сервер, должны быть «очищены» и нормализованы.

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

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

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

Такая архитектура получила название трехуровневой частично централизованной архитектуры с централизованным хранением и обработкой данных (рис. 3.20,в).

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

При трехуровневой архитектуре АРМ пользователя обеспечивает лишь

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

Заметим, что при трехуровневой архитектуре АРМ все еще обла­дают собственной функциональностью - они реализуют интерфейс.

 Совершенно иной принцип применяется в web-технологиях. С помо­щью таких технологий пользовательский интерфейс кодируется в виде html-файлов, которые помещаются на web-cepвеp. Эти файлы в любой момент по сети могут быть пересланы в компьютер пользователя и активизированы с помощью стандартной программы-проводника.

Использование этого принципа позволяет реализовать четырехуровневую полностью централизованную архитектуру АСОИУ (рис. 3.20,г), в которой корпоративный интернет- и/или интернет-сервер, взаи­модействуя с сервером приложений, обеспечивает диалог со всеми пользователями по сети с помощью стандартного протокола TCP/IP и стандартной программы-проводника. АРМ пользователя в этом случае превращается в простой удаленный терминал и называется «тонким клиентом». Такая архитектура позволяет любому работ­нику предприятия, находящемуся, например, в отпуске или в коман­дировке в любом месте земного шара, превратить любой компьютер, имеющий выход в интернет, в свой профессиональный АРМ и вклю­читься в решение срочных производственных задач.

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

Особенность портала состоит еще и в том, что пользователями системы становятся не только сотрудники и руководители предпри­ятия, но и его партнеры. Где бы они не находились, они могут сделать заказ, который не останется на Web-странице предприятия (как это было бы при традиционном портале), а автоматически поступит в со­ответствующую подсистему АСОИУ, инициирующую его исполне­ние. При этом заказчик через тот же портал может отслеживать со­стояние своего заказа и его прохождение по внутренним структурным подразделения и предприятия.

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

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

Лекция 14

3.3. Порядок и этапы разработки АСОИУ

 

Чрезвычайно важно при разработке АСОИУ соблюдать определен­ный порядок этой разработки, отражающий многочисленный на­копленный опыт.

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

Операция (0) (1). Как правило, разработка АСОИУ начинается с предварительного ознакомления с существующей на данном объ­екте системой управления. Целью этого ознакомления является определение целесообразности разработки АСОИУ на данном объек­те. Эту работу выполняет группа (4—5 системотехников высшей квалификации). На этом этапе в самом общем виде формулиру­ются цели предполагаемой АСОИУ и намечаются возможные пути по­вышения эффективности управления за счет автоматизации. Ра­бота заканчивается предоставлением докладной записки руко­водству организациям заказчика и разработчика. Этот этап может отсутствовать, если имеется директивное решение вышестоящей организации (министерства, ведомства, фирмы и т. п.).

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

 

Рис. 3.21. Укрупненный сетевой график разработки АСОИУ

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

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

Операция (2)  (3) — детальный анализ существующей систе­мы управления. Работа выполняется рядовым составом системо­техников.

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

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

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

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

Операция (4)  (5) — эскизное проектирование системы. Этот этап имеет место только при проектировании систем, не имеющих аналогов. Основные цели эскизного проектирования:

- проинформировать руководство о возможных проектных реше­ниях,

- подготовить сотрудников организации заказчика к пере­обучению,

- уточнить требования к структуре системы и ее обеспе­чивающим подсистемам.

 Наличие альтернативных вариантов при эскизном проектировании обязательно.

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

Операция (4)  (7) обоснование и выбор комплекса техни­ческих средств.

Операция (4)  (8) — предварительный расчет экономичес­кой эффективности.

Событие (9) — работа всех групп сводится к выпуску техничес­кого проекта, его корректировке, согласованию, утверждению.

Операция (9) (10) — разработка и отладка рабочих про­грамм.

Операция (10)  (11) — связная отладка комплексов программ по задачам.

Операция (9)  (12) — разработка и выпуск инструкций по эксплуатации технических средств.

Операция (9) (13) — разработка и выпуск рабочих инструк­ций персоналу автоматизированной системы.

Операция (9)  (14) — уточненный расчет экономической эф­фективности.

Событие (11) — выпуск рабочего проекта.

Операция (11)  (15). Если технические средства были подго­товлены заранее, то проводится опытная эксплуатация системы, если нет, то операция (11) (16)- монтаж и отладка технических средств.

Операция (16) (17) — опытная эксплуатация системы на под­готовленных средствах.

Операция (17)  (18) — передача в промышленную эксплуата­цию.

Операция (18)  (0)— возможна частичная модернизация и доработка системы.

Если рассматривать процесс создания системы еще более укрупненно, то можно выделить четыре этапа (стадии) согласно ГОСТ:

1-я стадия — предпроектная  (ее еще называют стадией ТЗ), здесь два крупных направления работ — это обследование и вы­пуск ТЗ.

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

3-я стадия — рабочее проектирование. Основные работы: программирование, отладка программ, выпуск комплекта про­граммной документации, выпуск инструкций по эксплуатации технических средств, выпуск должностных инструкций, уточнен­ный расчет экономической эффективности.

4-я стадия — внедрение. Здесь проводится опытная эксплуа­тация системы совместно с разработчиками этой системы. Затем промышленная эксплуатация, выполняемая силами работников объекта автоматизации.

Более подробно об этом мы будем говорить на третьем курсе в дисциплине «Проектирование АСОИУ».

Лекция 15

3.4. Среда создания АСОИУ

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

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

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

Для упрощения изложения предполагается следующее:

 а) все участники процесса созда­ния АСОИУ являются юридическими лицами;

б) в качестве заказчика выступает уполномоченный сотрудник объекта автоматизации;

 в) заказчик самостоя­тельно финансирует разработку из собственных средств;

г) разработчик вы­полняет все работы без привлечения соисполнителей.

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

 

 

 

Рис. 3.22. Среда создания АСОИУ: 1 — финансирование; 2 - техническое предложение; 3 - техническое задание; 4 - договорная документация; 5 -результаты разработки; 6 - организационно-распорядительная документация; 7 - требования пользователей, варианты решений, оценки качества; 8 - обучение; 9 — обсуждение проблем и формулирование рекомендаций по их устранению; 10 - консультации; 11 — обновление программного обеспечения и документации; 12 - открытая информация об аналогах и прототипах; 13 — покупные инструментальные средства и лицензии на их использование; 14 - фирменные информационные технологии; 15 - информация о характеристиках компонент; 16 —покупные изделия; 17 —расходные материалы; 18 — оцениваемые материалы и экспертные заключения.

 

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

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

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

За исключением начальных этапов фазы обоснования создания АСОИУ, отношения между разработчиком и заказчиком строятся на возмездной основе, закладываемой договором на создание (внедрение) научно- технической продукции, соответствующим требованиям (часть вторая Гражданского кодекса Российской федерации.[Электронный ресурс] URL: http://www.garant.ru/main/10064072-000.htm). Финансовые отношения между основными участниками процес­са создания АСОИУ, а также между ними и сторонними контрагентами пока­заны на рис. 2.10 связью (1).

На фазе обоснования создания АСОИУ отношения между заказчиком и разработчиком заключаются в формулировании и обсуждении техниче­ского предложения о создании системы (связь 2 на рис. 2.10), составле­нии и согласовании технического задания (3) и договорной документа­ции (4).

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

На фазе внедрения АСОИУ разработчик совместно с заказчиком организо­вывает, проводит и документирует испытания системы, а также составляет и оформляет организационно-распорядительную документацию (6).

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

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

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

Отношения между представителями разработчика и эксплуатационным персоналом АСОИУ поддерживаются на фазе эксплуатации системы. В частности, на стадии авторского надзора разработчик обсуждает с представителями сервисных служб системы возникающие проблемы и форму­лирует рекомендации по их устранению или - в гарантийных случаях - самостоятельно принимает меры по их ликвидации (9).

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

Наряду с разработчиком и заказчиком, в процессе создания АСОИУ при­нимают косвенное участие партнеры (контрагенты) - предприятия и организации, поддерживающие деятельность основных участников или снабжающие их необходимыми ресурсами. Среди таких партнеров можно выделить:

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

 Поставщики инструментальных средств разработки приложе­ний — для автоматизации предпроектного обследования и повышения эффективности проектирования, а также для разработки оригиналь­ных проектных решений в области программного и машинного ин­формационного обеспечения разработчик приобретает необходимые инструментальные средства (системы программирования, CASE- и/или RAD-средства, системы проектирования баз данных и т. п.) и лицензии на их использование у фирм-разработчиков этих продуктов либо у их законных представителей - дилеров или дистрибьюторов (13); при согласовании условий соответствующих лицензионных со­глашений необходимо обращать особое внимание на срок действия лицензии (неограниченный или ограниченный), а также на условия применения продукта - в рассматриваемой ситуации (создание АС для стороннего заказчика) лицензия должна разрешать разработку продуктов для коммерческого распространения.

 Поставщики технологий — для использования в АСОИУ апробированных фирменных решений, предлагаемых ведущими компаниями - произ­водителями интегрированных систем и программного обеспечения, разработчик должен приобрести технологии реализации этих решений (14); в таком случае наряду с необходимыми инструментальными средствами покупатель получает детальное описание методики вы­полнения всех необходимых проектных и внедренческих действий, готовые решения по организационной структуре объекта автоматиза­ции, алгоритмы и технологические схемы обработки информации, об­разцы входных и выходных документов и видеокадров и другие эле­менты высокой степени готовности; довольно часто сотрудникам раз­работчика предоставляется возможность пройти обучение (повысить профессиональную квалификацию) в фирменном учебном центре по­ставщика технологии и получить соответствующий сертификат, что существенно повышает статус специалиста на рынке ИТ-услуг.

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

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

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

Представленная на рис. 3.22. наиболее общая схема может модифици­роваться в зависимости от конкретной ситуации, в которой создается АСОИУ. Наиболее часты изменения в направлениях финансовых и материальных потоков. В частности, если разработчик не заинтересован в многократном использовании СУБД и других инструментальных средств разработки и коммерческого тиражирования приложений, то он может предложить заказчику приобрести их напрямую на условиях однократного применения.

Оборудование может приобретаться заказчиком не только по прямым договорам в соответствии с рекомендациями разработчика, но и на конкурсной (тендерной) основе. Если в качестве разработчика выступает компания – системный интегратор, то технические средства могут поставляться разработчиком в комплексе с программным обеспечением и другими компонентами АСОИУ.

Системный интегратор — это предприятие, занимающееся созданием и комплексной поставкой АСОИУ «под ключ», включая все компоненты про­граммного и технического обеспечения.

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

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

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

3.5. Нормативная база проектирования АСОИУ

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

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

Нормативная база создания АСОИУ обла­дает следующими свойствами:

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

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

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

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

- однозначность - положения нормативной базы не допускают различ­ных толкований и одинаково интерпретируются всеми участниками процесса создания АСОИУ;

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

Нормативная база создания автоматизированных систем имеет шес­тиуровневую иерархическую структуру, представленную в табл. 2.1.

3.6. Типы моделей жизненного цикла АСОИУ

 

Прежде, чем рассматривать наиболее извест­ные и распространенные типы жизненных циклов АСОИУ введем понятия стратегия и траектория проектирования АСОИУ.

Стратегия проектирования АСОИУ определяется по­следовательностью и глубиной реализации задач автоматизации пред­приятия. Известны две стратегии 1) метод шахт, 2) метод пластов.

Траекторияпроектирования АСОИУ зависит от необ­ходимости внесения в процессе проектирования системы каких-либо изменений в организацию и функционирование автоматизируемого предприятия. Основными точками, через которые проходит траекто­рия проектирования АСОИУ, являются 1) «жесткий» реинжиниринг предприятия, 2) «легкий» реинжиниринг предприятия, 3) реинжини­ринг, обусловленный автоматизацией.

Таблица 2.1. Иерархия нормативной базы создания АСОИУ

 

	№ п/п	Уровень принятия документа	Вид докумен­та	Характер документа
	I	Государст­венная Дума РФ	Закон РФ	Основополагающий документ, закладываю­щий принципы и направления государствен­ной политики в области информационных и коммуникационных технологий и смежных аспектах деятельности
	II	Правитель­ство РФ	Постановле­ние, распоря­жение, поло­жение и т. д.	Подзаконные акты, формирующие основы реализации государственной политики в об­ласти информационных и коммуникационных технологий и смежных аспектах деятельности, а также регламентирующие создание межго­сударственных и государственных АСОИУ
	III	Министер­ство, государствен­ный коми­тет, феде­ральное агентство	Стандарт, руководящий документ, инструктивное письмо и т. д.	Документы прямого действия, устанавливаю­щие или конкретизирующие практику приме­нения законодательства и подзаконных актов по наиболее важным аспектам создания АСОИУ, а также регламентирующие создание отрасле­вых систем
	IV	Отраслевое ведомство, холдинг, корпорация	Отраслевой стандарт, ру­ководящий документ, приказ, инструктивное письмо и т. д.	Документы прямого действия, дополняющие или детализирующие практику применения документов государственного уровня в мас­штабе предприятий и организаций ведомст­венной подчиненности, а также регламенти­рующие создание ведомственных (корпора­тивных) АСОИУ
	V	Участники создания АСОИУ	Договор- ная документация	Документы, закрепляющие отношения между участниками создания конкретной АСОИУ и уста­навливающие их права, обязанности и ответственность по отношению к предмету догово­ра
	VI	Руковод-ство предприя­тия-участ­ника созда­ния АСОИУ	Приказ, распоряжение, инструкция	Документы, распределяющие полномочия, обязанности, ответственность и ресурсы меж­ду работниками, привлеченными к созданию АСОИУ

 

Исходя из введенной систематики, рассмотрим наиболее известные типы моделей жизненных циклов АСОИУ (см. рис. 3.23).

Каскадная модель предполагает последовательную одно­кратнуюреализацию этапов проектирования АСОИУ с переходом на следующий этап после полного окончания работ по предыдущему этапу (рис. 3.23,а). Каскадный подход хорошо зарекомендовал себя при построении систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту кате­горию попадают сложные расчетные системы, системы реального времени и другие подобные системы. К положительным сторонам применениякаскадного подхода относятся следующие:

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

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

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

Инкрементная модель (increment - приращение, нарас­тание). Реально в процессе создания АСОИУ постоянно возни­кает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений. В этом случае процесс создания АСОИУ принимает итерационный вид с циклами обратной связи ме­жду этапами (рис. 3.23.б). Такой тип жизненного цикла иногда называют запланированным усовершенствованием системы.

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

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

 

Рис. 3.23. Модели жизненного цикла АСОИУ:

а) каскадная, б) инкрементальная, в) эволюционная

 

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

Такой подход называется также «продолжающимся проектирова­нием» или «быстрым прототипинированием» (rapid prototyping approach). В нашей стране он известен еще и под названием «пилотное проекти­рование». Спиральная модель обладает следующими преимуществами:

- в процессе проектирования АСОИУ неоднократно подвергается модификации, отражающей развитие объекта автоматизации.

- снижение объемов и трудоемкости каждого этапа позволяет уменьшить риск и издержки в процессе проектирования.

Однако применение таких методов наряду с быстрым эффектом дает снижение управляемости проектом в целом и стыкуемости раз­личных фрагментов АСОИУ.

Рассмотренные модели жизненного цикла определяют общую ор­ганизацию процесса проектирования и внедрения АСОИУ. Содержа­тельная сторона этого процесса зависит от того, какова номенклатура этапов, принятая проектировщиками.

Лекция 16

Глава 4. АСОИУ на примере АСДО кафедры

4.1. Общие положения

Современная система образования все активнее использует информационные технологии и компьютерные телекоммуникации.

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

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

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

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

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

Также одним из главных достоинств электронного методического пособия является компактность – намного вместительнее обычного учебного пособия и может содержать огромное количество информации.

При разработке АСДО был проведен системотехнический анализ процесса функционирования ЭУМК, выявлены недостатки в структуре и работоспособности текущей версии системы. Была обоснована необходимость разработки подсистемы визуализации учебных материалов в новой версии АСДО, сформулированы задачи их визуализации, составлены алгоритмы выполнения задач визуализации и разработано информационное обеспечение системы.

4.2. Выбор вида представления учебного материала

Существует 3 основных вида представления учебного материала в электронном виде:

Линейный текст.

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

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

---

Дата добавления: 2019-01-14; просмотров: 465; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!