26776

Многомерные задачи оптимизации

Домашняя работа

Математика и математический анализ

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

Русский

2013-08-18

271.5 KB

2 чел.

Многомерные задачи оптимизации

Под минимизацией (максимизацией) функции n переменных f(x)=f(x1, ... ,xn) на заданном множестве U n-мерного векторного пространства En понимается определение хотя бы одной из точек минимума (максимума) этой функции на множестве U, а также, если это необходимо, и минимального (максимального) на U значения f(x).

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

f(x) -> min (max),    x принадлежит U,

где f(x) - целевая функция, а U - допустимое множество, заданное ограничениями на управляемые переменные.

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

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

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

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

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

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

Рис. 1. Построение сетки с шагом h и выбор "пробных" точек в узлах сетки для приближенного определения наименьшего значения функции двух переменных.

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

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

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

Действительно, предположим, что целевая функция зависит от пяти переменных, а область определения является пятимерным кубом, каждую сторону которого при построении сетки мы делим на 40 частей. Тогда общее число узлов сетки будет равно 415~108. Пусть вычисление значения функции в одной точке требует 1000 арифметических операций (это немного для функции пяти переменных). В таком случае, общее число операций составит 1011. Если в нашем распоряжении имеется ЭВМ с быстродействием 1 млн. операций в секунду, то для решения задачи с помощью данного метода потребуется 105 секунд, что превышает сутки непрерывной работы. Добавление еще одной независимой переменной увеличит это время в 40 раз.

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

Классификация информационных систем

  1.  Классификация по масштабу: одиночные, групповые, корпоративные.

Одиночные ИС реализуются, как правило, на автономных ПК (сеть не используется). Такая ИС может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих одно рабочее место. Подобные приложения создают с помощью так называемых настольных (локальных) СУБД. Наиболее популярные локальные СУБД : Clarion, Clipper, FoxPro, Paradox, dBase, Microsoft Access.

Групповые ИС ориентированы на коллективное использование информации и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используют серверы БД ( SQL -серверы). Наиболее популярные SQL -серверы: Oracle , DB 2 , Microsoft SQL Server , InterBase , Sybase , Informix.

Корпоративные ИС ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для них характерна архитектура клиент-сервер со специализацией серверов или многоуровневая архитектура. При разработке таких ИС можно использовать те же серверы БД, что и при разработке групповых ИС. Однако в крупных корпоративных ИС наибольшее распространение получили серверы Oracle , DB 2 и Microsoft SQL Server.

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

  1.  Классификация по сфере применения: системы обработки транзакций, системы принятия решений, информационно-справочные системы, офисные системы.

Транзакция – это последовательность операций над базой данных, рассматриваемых СУБД как единое целое.

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

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

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

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

3. Классификация по способу организации групповые и корпоративные ИС подразделяются на следующие классы: системы на основе архитектуры клиент-сервер, на основе многоуровневой архитектуры, на основе Интернет/интранет-технологий.

Нормализация данных

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

  •  первая нормальная форма (1NF);
  •  вторая нормальная форма (2NF);
  •  третья нормальная форма (3NF);
  •  нормальная форма Бойса— Кодда (BCNF);
  •  четвертая нормальная форма (4NF);
  •  пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

Основные свойства нормальных форм:

  •  каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;
  •  при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

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

При выполнении эквивалентных преобразований сохраняется множество исходных фундаментальных функциональных зависимостей между атрибутами отношений.

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

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

Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.

Отношение находится в нормальной форме Болса—Кодла, если оно находится в третьей нормальной форме и каждый детерминант отношения является возможным ключом отношения.

Управление проектом ПО

Управление разработкой программных систем (software management) — это деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков программного обеспечения (ПО), на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПО, выполнения сроков и бюджета разработки ПО. Часто эту деятельность называют также управлением программным проектом (software project management). Здесь под программным проектом (software project) понимают всю совокупность работ, связанную с разработкой ПО, а ход выполнения этих работ называют развитием программного проекта (software project progress).

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

Хотя виды деятельности по управлению разработкой ПО могут быть весьма разнообразными, в зависимости от специфики разрабатываемого ПО и организации работ по его созданию можно выделить некоторые общие процессы (виды деятельности) по управлению разработкой ПО:

  •  составление плана-проспекта по разработке ПО;
  •  планирование и составление расписаний по разработке ПО;
  •  управление издержками по разработке ПО;
  •  текущий контроль и документирование деятельности коллектива по разработке ПО;
  •  подбор и оценка персонала коллектива разработчиков ПО.

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

· для внешнего заказчика;

· для других подразделений той же организации;

· является инициативной внутренней разработкой.

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

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

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

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

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

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

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

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

Различают два вида таких стандартов:

· стандарты ПО (программного продукта);

· стандарты процесса создания и использования ПО.

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

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

Структура управления разработкой программных средств

Разработка ПО обычно производится в организации, в которой одновременно могут вестись разработки ряда других программных средств. Для управления всеми этими программными проектами используется иерархическая структура управления (рис. 18.1).

Рис. 18.1. Структура управления разработкой программных средств

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

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

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

Менеджер проекта осуществляет планирование и составление расписаний работы бригад по разработке соответствующего программного средства.

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

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

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

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

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

Дублер ведущего программиста (backup programmer) также является квалифицированным и опытным программистом, способным выполнить любую работу ведущего программиста, но сам он эту работу не делает. Главная его обязанность — быть в курсе всего, что делает ведущий программист. Он выступает в роли оппонента ведущего программиста при обсуждении его идей и предложений, но решения по всем обсуждаемым вопросам принимает единолично ведущий программист.

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

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

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

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

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

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

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

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

Системы подготовки и принятия решений (СППР) на базе современных информационных технологий. Стандарты MRP II, ERP, Balanced Score Card

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

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

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

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

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

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

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

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

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

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

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

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

В условиях повсеместной информатизации управленческих Л-У процессов технологический комплекс решения функциональных задач и подготовки управленческих решений выполняется ИС, основу которой составляет ИТ.

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

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

Рассматривая ИС в технологическом аспекте, можно выделить аппарат управления (АУ). Оставшиеся компоненты — информационная технология (ИТ), информационная система решения функциональных задач (ИСФЗ) и система поддержки принятия решений (СППР) — информационно и технологически взаимоувязаны и составляют основу архитектуры ИС (рис. 2.1).

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

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

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

MRP (Material Requirements Planning) – [Автоматизированное планирование потребности сырья и материалов для производства].Методология планирования потребности в материальных ресурсах, заключающаяся в определении конечной потребности в ресурсах по данным объемно-календарного плана производства. Ключевым понятием методологии является понятие "разузлование", т.е. приведение древовидного состава изделия к линейному списку (Bill of Materials), по которому планируется потребность и осуществляется заказ комплектующих. Ее усовершенствованная версия,Closed Loop MRP (планирование потребности в материалах в замкнутом цикле), позволила динамически корректировать планы закупок при возникновении нештатных отклонений от них.

MRPII (Manufacturing Resources Planning) – [Планирование и управление всеми производственными ресурсами предприятия: сырьем, материалами, оборудованием, трудозатратами]. Планирование производства. Интегрированная методология, включающая MRP/CRP и, как правило, MPS и FRP. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана.

ERP (Enterprise Resources Planning) – [Управление корпоративными ресурсами. К свойствам MRPII добавилось управление финансовыми ресурсами, маркетинг. ERP концепция – первая направленная на управление бизнесом, а не только производства, как MRP]. Концепциябизнес-планирования. Под ERP подразумевается "интегрированная" система, выполняющая функции, предусмотренные концепциями MPS-MRP/CRP-FRP. Важным отличием от методологии MRPII является возможность "динамического анализа" и "динамического изменения плана" по всей цепочке планирования. Конкретные возможности методологии ERP существенно зависят от программной реализации. Концепция ERP более "размыта", чем MRPII. Если MRPII имеет явно выраженную направленность на производственные компании, то методология ERP оказывается применимой и в торговле, и в сфере услуг, и в финансовой сфере. 

Сбалансированная система показателей (ССП) (Balanced Scorecard) — концепция переноса и декомпозиции стратегических целей для планирования операционной деятельности и контроль их достижения. По сути ССП - это механизм взаимосвязи стратегических замыслов и решений с ежедневными задачами, способ направить деятельность всей компании (или группы) на их достижение. На уровне бизнес-процессов контроль стратегической деятельности осуществляется через так называемые ключевые показатели эффективностиKPI являются измерителями достижимости целей, а также характеристиками эффективности бизнес-процессов и работы каждого отдельного сотрудника. В этом контексте, ССП является инструментом не только стратегического, но и оперативного управления.

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

Согласно позиции авторов-разработчиков системы, ССП это:

  •  Новая система управления компанией.
  •  Механизм реализации стратегии и её корректировки.
  •  Инструмент перевода стратегии в плоскость конкретных целей, показателей и задач.
  •  Надежный инструмент контроля показателей будущего.
  •  Система мотивации персонала.
  •  Система обратной связи, обучения и постоянного развития.

Диагностика маршрута (tracеrоute) с использованием протокола UDP и ICMP

Traceroute — это служебная компьютерная программа, предназначенная для определения маршрутов следования данных в сетях TCP/IP. Traceroute может использовать разные протоколы передачи данных в зависимости от операционной системы устройства. Такими протоколами могут быть UDP, TCP, ICMP или GRE. Компьютеры, с установленной операционной системой Windows используют ICMP протокол, при этом маршрутизаторы Cisco - протокол UDP.

Traceroute входит в поставку большинства современных сетевых операционных систем. В системах Microsoft Windows эта программа носит название tracert, а в системах GNU/LinuxCisco IOS и Mac OS— traceroute.

Рассмотрим пример работы программы в операционной системе Windоws. Программа tracert выполняет отправку данных указанному узлу сети, при этом отображая сведения о всех промежуточных маршрутизаторах, через которые прошли данные на пути к целевому узлу. В случае проблем при доставке данных до какого-либо узла программа позволяет определить, на каком именно участке сети возникли неполадки. Здесь хочется отметить, что программа работает только в направлении от источника пакетов и является весьма грубым инструментом для выявления неполадок в сети. В силу особенностей работы протоколов маршрутизации в сети Интернет, обратные маршруты часто не совпадают с прямыми, причем это справедливо для всех промежуточных узлов в трейсе. Поэтому ICMP ответ от каждого промежуточного узла может идти своим собственным маршрутом, затеряться или прийти с большой задержкой, хотя в реальности с пакетами которые адресованы конечному узлу этого не происходит. Кроме того, на промежуточных маршрутизаторах часто стоит ограничение числа ответов ICMP в единицу времени, что приводит к появлению ложных потерь.


 

А также другие работы, которые могут Вас заинтересовать

65170. «Закон», «обычай», «традиция» средневековых монголов в «Книге о тартарах» 81 KB
  Книга о тартарах Иоанна де Плано Карпини имеет большую ценность для исследователей права средневековых монголов поскольку в ней представлен взгляд европейского современника который к тому же побывал в Монгольской империи в эпоху преобразований.
65171. Золотоордынские ярлыки Русской Церкви как пример правоотношений светской и духовной власти на государственном и надгосударственном уровне 50 KB
  Ярлыки русской церкви представляют собой в общемто весьма распространенный тип ярлыков выдававшихся и в Монгольской империи и в ее отдельных улусах. Надо полагать что выдача ярлыков русской церкви осуществлялась всеми золотоордынскими ханами начиная с самых первых за исключением...
65172. К вопросу о судебной реформе крымского хана Мурад-Гирея (по сведениям «Семи планет» Сейида Мухаммеда Ризы) 29 KB
  Дальнейшая политика Мурад Гирея свидетельствовала о его лояльности: он постоянно являлся в Стамбул активно участвовал в войнах империи. На наш взгляд действия Мурад Гирея являлись популистской акцией попыткой укрепления собственного имиджа в глазах подданных.
65173. ОБРАЗ МАМАЯ В РУССКОМ ЛЕТОПИСАНИИ КАК СРЕДСТВО ДЕЛЕГИТИМИЗАЦИИ ВЛАСТИ ОРДЫНСКОГО ХАНА 132 KB
  В отечественной историографии правитель Золотой Орды Мамай удостоился самых отрицательных отзывов какими только характеризовались враги России. Эти характеристики могут быть отнесены к проводимой им в отношении Руси политики но некоторые источники...
65174. ОБЫЧАЙ И ЗАКОН В ПРАВЕ КОЧЕВНИКОВ ЦЕНТРАЛЬНОЙ АЗИИ (ПОСЛЕ ИМПЕРИИ ЧИНГИС-ХАНА) 78 KB
  Другие же ногайские орды казахские узбекские монгольские сибирские ханства по мнению исследователей сделали в своем развитии шаг назад и из государств трансформировались в вождества; соответственно развитая система писанного права существовавшая...
65175. Математик, которого я знаю – Ньютон Исаак 235 KB
  Исаак Ньютон появился на свет в небольшой деревушке в семье мелкого фермера, умершего за три месяца до рождения сына. Младенец был недоношенным, бытует легенда, что он был так мал, что его поместили в овчинную рукавицу, лежавшую на лавке, из которой он однажды выпал и сильно ударился головкой об пол.
65176. Математик, которого я знаю – Франсуа Виет 77.7 KB
  Франсуа Виет 1540-1603 Родился в 1540 году на юге Франции в небольшом городке Фантенеле Конт французской провинции Пуату Шарант в 60 км от Ла Рошели. Его отец Этьен Виет прокурор. Благодаря связям матери Маргариты Дюпон и браку своей ученицы с принцем...
65178. Математик, которого я знаю – Фалес Милетский 214.65 KB
  Фалес Милетский жил в самом конце 7 первой половине 6 в до н. Фалес Милетский был уроженцем греческого торгового города Милета расположенного в Малой Азии на берегу Эгейского моря.