Разработка программного обеспечения для автоматизации процесса закупок необходимых материалов для ООО "Звезда Востока и Японии" - Программирование, компьютеры и кибернетика дипломная работа

Главная

Программирование, компьютеры и кибернетика
Разработка программного обеспечения для автоматизации процесса закупок необходимых материалов для ООО "Звезда Востока и Японии"

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


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

В настоящее время происходит автоматизация большинства предприятий нашей страны.
Актуальность данной темы очень высока на сегодняшний день так как необходимо повышать качество выполняемых работ и уменьшения трудовых затрат. Задача планирования потребностей в материалах (Materials Requirements Planning, MRP) оказалась той первой задачей, которая привела к созданию целой индустрии программного обеспечения для управления предприятием.
Методология MRP-планирования потребностей в материалах предназначена для использования на производственных предприятиях, имеющих дискретный тип производства - серийное, сборка и изготовление на заказ или склад, то есть когда имеется ведомость необходимых материалов и комплектующих изделий для изготовления конечного продукта.
Целью данного дипломного проекта является разработка программного обеспечения для автоматизации процесса закупок необходимых материалов для ООО "Звезда Востока и Японии", г. Краснодар.
За редким исключением, планирование отдельно рассматриваемых материалов и ресурсов не вызывает принципиальных проблем, но, как правило, требует выполнения достаточного большого объема вычислений, и всегда - исключительной точности и аккуратности. Чем больше планируемых ресурсов и показателей у предприятия, тем больше требуется вычислительных операций. Формирование же общего согласованного плана является итерационным процессом, при котором проводятся корректировки ранее полученных результатов и объемы вычислений увеличиваются в несколько раз. Если дополнительно принять во внимание необходимость периодических корректировок утвержденных планов, то целесообразность применения компьютерной техники в задачах планирования становится достаточно очевидной.
Для автоматизированного планирования деятельности предприятия по производству продукции необходимо наличие:
· формализованных описаний процессов изготовления деталей и узлов, их взаимных связей и зависимостей;
· формализованных описаний необходимых материалов, ресурсов и их количественных потребностей для отдельных операций применительно к конкретным изделиям;
· справочников и классификаторов, отражающих основные хозяйственные операции, движение материальных и денежных средств, сведения о контрагентах и другую информацию;
· методов и алгоритмов планирования, реализованных в виде программ и программных систем.
Таким образом, до внедрения системы автоматизированного планирования на предприятии должны быть проведены работы по регламентации и стандартизации производственных и хозяйственных процессов, нормированию расхода и использования каждого ресурса дифференцированно для всех производимых изделий и оказываемых услуг. Разработка формализованных описаний процессов деятельности предприятия и нормирование потребления материальных ресурсов является, как правило, не простой и достаточно трудоемкой задачей, к решению которой приходится привлекать внешних консультантов и исполнителей.
К настоящему времени разработан ряд методологий, таких как MRP, MRP II, ERP, применяемых для идентификации и эффективного планирования ресурсов предприятия при осуществлении закупок материалов и комплектующих, производства и продаж готовых изделий. Развитие методологий планирования прошло путь от планирования материалов - Material Requirements Planning (MRP), до планирования ресурсов предприятия в целом - Enterprise Resource Planning (ERP)[1].
Каждое предприятие является уникальным и требует индивидуального подхода при определении возможной и необходимой степени автоматизации процессов планирования исходя из его стратегических целей, финансовых возможностей, технической оснащенности и квалификации сотрудников, отраслевых особенностей ведения бизнеса. MRP система на нашем предприятии будет выглядеть так. Рисунок 1.1
Рисунок 1.1 - Структура MRP системы
Далее приводятся описания основных функций и компонентов систем классов MRP и ERP, а также общие сведения о системе CALS.
Методология Material Requirements Planning (MRP) - планирования потребностей в материалах (под материалами здесь понимаются как непосредственно материалы, так и сырье, комплектующие изделия, детали, узлы и все остальное, что необходимо для производства продукции), разрабатывалась и предназначена для использования на производственных предприятиях, имеющих дискретный тип производства - серийное, сборка и изготовление на заказ или склад, то есть когда имеется ведомость необходимых материалов и комплектующих изделий для изготовления конечного продукта [2].
В MRP различают независимый и зависимый спрос на материалы, детали и конечные изделия.
Независимый спрос - это потребности в материалах, деталях, узлах и изделиях внешних заказчиков. Эти потребности определяются заказами и договорами с клиентами, а также прогнозом их спроса на планируемый период времени и составляют основной план производства предприятия.
Зависимый спрос - это потребности, в материалах, деталях и узлах, необходимых для выполнения плана производства и поставок. Эти потребности определяются основным планом производства предприятия. Они не прогнозируются, а рассчитываются MRP системой.
Концепция MRP системы, фактически, сводится к двум основным принципам:
· если есть потребность в конечном изделии, то есть потребность во всех составляющих его компонентах, то есть MRP системы ориентированы на удовлетворение зависимого спроса;
· обеспечивать производство требующимися компонентами нужно как можно позднее, чтобы сократить уровень запасов с целью сокращения складских расходов и эффективного использования активов предприятия.
Главной задачей MRP системы является гарантированное обеспечение производства материалами и комплектующими изделиями в планируемый период времени.
Элементы MRP системы можно разделить на следующие составляющие:
· элементы, содержащие входную информацию для планирования потребностей в материалах. Такими элементами являются основной производственный план - Master Production Shedule, перечни компонентов производимых в соответствии с основным производственным планом изделий - Bills of Material, и описание наличия или отсутствия необходимых для производства компонентов - Inventory Status File;
· программная реализация алгоритмов планирования потребностей в материалах, то есть, собственно MRP;
· результаты работы MRP системы: план-график заказов материалов - Planned Order Schedule, изменения плана-графика заказов - Changes in Planned Orders, ряд отчетов для контроля и управления процессом снабжения [2].
Рассмотрим подробней входную информацию для MRP системы.
Основной производственный план (Master Production Shedule) является оптимизированным календарным графиком производства партии готовой продукции. Разработка производственного плана, как правило, является итерационным процессом. Первоначально формируется черновой вариант производственного плана для оценки возможности его реализации по имеющимся производственным мощностям. После проведения необходимых итераций план утверждается как действующий, и его данные поступают на вход системы планирования.
Перечень компонентов и состава изделий (Bills of Material) представляет собой номенклатурный перечень материалов, комплектующих деталей и узлов и их количеств, необходимых для изготовления отдельных сборочных единиц и изделия в целом. Эта информация хранится в системе в виде таблиц базы данных. При изменении состава изделий таблицы должны быть своевременно скорректированы.
Описание состояния запасов (Inventory Status File) отражается в соответствующих таблицах базы данных. Для каждой номенклатурной единицы должен быть указан её статус - передана ли она в производство, находится на складе, заказана или её заказ только планируется, а также множество других параметров и характеристик, отражающих её уникальность: код, обозначение, описание, тип, размер, вес, единица запаса, единица хранения, основной поставщик, цена и другие. При изменении статуса учетной единицы соответствующие записи базы данных обновляются.
На основании входных данных MRP система выполняет следующие действия:
· определяет количественный состав готовых изделий для каждого планируемого интервала времени;
· к составу готовых изделий добавляет необходимое количество запасных частей и принадлежностей, определенных документацией на изделия и не включенных в план производства;
· определяет общую потребность в материалах с распределением по периодам планирования;
· общая потребность материалов корректируется с учетом состояния запасов для каждого периода планирования;
· формирует заказы на пополнение запасов с учетом времени опережения, определяемого особенностями сроков поставки по каждому типу материалов [2].
Результатом выполнения этих действий является план-график заказов (Planned Order Schedule), определяющий, какое количество каждой номенклатурной единицы в какое время должно быть заказано. План-график заказов является руководством для отдела снабжения по работе с поставщиками и может также определять производственную программу собственного производства комплектующих изделий, если таковые изготавливаются самим предприятием.
Изменения плана-графика заказов (Changes in Planned Orders) являются корректировками к ранее спланированным заказам, которые могут быть по каким-либо причинам изменены.
В качестве дополнительных результатов работы MRP системы можно отметить:
исполнительный отчет (Performance Report), задачей которого является формирование сообщений о критических ситуациях в процессе планирования и ошибках, возникающих в процессе работы системы;
отчет об "узких местах" (Exception Report), предназначенный для информирования о временных промежутках внутри интервала планирования, требующих особого внимания и, возможно, дополнительного внешнего вмешательства в автоматизированный процесс;
отчет о прогнозах (Planning Report), представляющий информацию о возможном будущем изменении объемов выпускаемой продукции на основании анализа текущего состояния производства и отчетов о продажах.
С целью увеличения эффективности планирования MRP систем была предложена идея организовывать их работу по замкнутому циклу (closed loop). Суть идеи заключается во введении в рассмотрение более широкого спектра факторов при проведении планирования и добавлении в систему дополнительных функций, таких как контроль соответствия количества произведенной продукции количеству использованных материальных ресурсов, составление периодических отчетов о задержках заказов, об объемах и динамике продаж и других. Дополнительные функции осуществляют обратную связь в MRP системе, обеспечивая возможность анализировать и контролировать текущее состояние снабжения и производства и повышая гибкость планирования относительно изменений внешних факторов, например, увеличения или снижения прогнозируемого уровня спроса на готовые изделия.
Обзор аналогичных программных продуктов
Программа формирует потребность предприятия в производимых (деталь, сборочная единица) и закупаемых номенклатурных позициях (сырье, материалы, инструмент), выраженную в виде календарного плана.
При разработке программы использовалась методология планирования потребности в материалах MRP (Material Requirements Planning).
Программа не ориентирована на выполнение заказов. Программа ориентирована на выполнение производственной программы. Т.е. не учитываются остатки готовой продукции на складе.
Потребность отображается в натуральном и в стоимостном выражении.
С помощью программы можно отслеживать остатки товарно-материальных запасов на складе, производственных участках, подрядных организациях. Списание товарно-материальных запасов с производственных участков происходит автоматически согласно спецификации при поступлении готовой продукции или полуфабриката на склад.
При расчете потребности с учетом остатков во внимание принимаются только остатки, находящиеся на складе (место хранения - СКЛАД). Вы можете переименовать это место хранения, например, Материально-техническая база, склад сырья и др.
Программа может использоваться локально или по сети. Сетевой вариант использования хорош тем, что разные пользователи ведут узкое направление, а информацией могут пользоваться все. Например, кладовщик учитывает товарно-материальные ценности на складе, конструктор или технолог составляет спецификации и определяет нормы расхода, экономист, бухгалтер или менеджер вводит цену приобретаемых ценностей, руководитель или начальник производства - план производства. В итоге служба снабжения и руководитель получают расчетную чистую потребность предприятия в производимых (деталь, сборочная единица) и закупаемых номенклатурных позициях (сырье, материалы, инструмент), выраженную в виде календарного плана. Также сетевое использование программы позволяет с разных рабочих мест получить общедоступную информацию: текущие остатки на складе, телефоны фирм, спецификации изделий (нормы расхода). Это позволит более оперативно принимать решения.
Результаты, рассчитанные программой, носят рекомендательный характер для руководителя предприятия, для службы снабжения.
Более подробное описание, инструкции и рекомендации по работе с программой находятся в ней самой.
Программа написана на Microsoft Access 2003, оптимизирована для разрешения экрана 1024х768, распространяется бесплатно с закрытым исходным кодом.
Даже несмотря на бесплатное распространение, использование данной программы на ОАО «Тайфун» невозможно, т.к. все данные хранятся не в Microsoft Access, а в базах данных ORACLE.
В последние годы системы планирования в интеграции с модулем финансового планирования FRP (Finance Requirements Planning) получили название систем бизнес-планирования ERP (Enterprise Requirements Planning), которые позволяют наиболее эффективно планировать всю коммерческую деятельность современного предприятия, в том числе финансовые затраты на проекты обновления оборудования и инвестиции в производство новой линейки изделий. В Российской практике, целесообразность применения систем подобного класса обуславливается, кроме того, необходимостью управлять бизнес процессами в условиях инфляции, а также жесткого налогового прессинга, поэтому, системы ERP необходимы не только для крупных предприятий, но и для небольших фирм, ведущих активный бизнес [3]. На рисунке 1.2 представлена модель системы планирования ресурсов производственного предприятия.
Рисунок 1.2 - Модель системы планирования ресурсов предприятия
2. Анализ требований к программному обеспечению
В настоящее время расчеты потребности в материалах ведутся плановым бюро ОМТС с помощью калькулятора на основании представленных ОГТ специфицированных норм расхода материалов на одну единицу изделия. На каждый материал заведена карточка, в которой ведутся расчеты на материал под каждый запуск в производство. По мере необходимости оплаты финансовым отделом завода по установленным правилам ОМТС оформляет заявку на оплату. Планируемые суммы ежеквартально с разбивкой по месяцам передаются в группу бюджетирования для включения в бюджет. Контроль ведется по мере поступления и выдачи материалов в производство.
Одной из задач управления предприятием, которую выполняет служба ОМТС, является задача управления запасами. Для учета и управления запасами, который в н.в. выполняется вручную, применяются карточки складского учета, в которых указывается поступление материалов на склад, их отпуск со склада, а также их остаток. Аналогично информация с карточек дублируется в книгах учета в ОМТС. Кроме того, в ОМТС ведется карточка на материал, в которой вручную заносится потребность под запуск, лимит для выдачи материалов в цеха. При использовании карточного метода задача пополнения запасов реализуется простым (с точки зрения трудозатрат персонала) и очень неэффективным (с точки зрения достижения основных целей предприятия) способом: когда какой-нибудь материал был полностью израсходован, формируется заказ поставщику. В этом случае (поскольку поставка не всегда могла происходить моментально) в течение некоторого времени необходимый материал просто отсутствовал на складе.
Логичным решением, исключающим такую ситуацию, установление некоторого минимального уровня запасов на складах, по достижении которого формируется заказ на пополнение. Т.е, как только реальное количество материала на складе опускалось ниже определенного уровня, называемого точкой перезеказа, значение которой зависело от времени реализации потребности, величина заказываемой партии и некоторых других параметров, происходило оформление нового заказа на поставку этого материала.
ОМТС из компьютерной системы получает информацию о необходимом к закупке количестве материалов (брутто-потребность). Все необходимые расчеты выполняет БМТН предприятия на каждый запуск производства. Плановое бюро ОМТС группирует все рассчитанные потребности ПО ЗАКАЗУ и ПО ЗАВОДУ, в случае необходимости потребность корректируется на допустимые замены согласно таблице замен или оформляется карта отклонений.
2. Заявки на заказ поставщику (ответственные ОМТС)
1. Просмотр необходимых к закупке материалов
2. Формирование заказов на закупку и уведомление финансового отдела о необходимости оплаты в установленном на предприятии порядке
3. Отслеживание заказов поставщикам и уведомление финансового отдела об оплате в соответствии с договором (заявкой на поставку).
1. Заказы поставщикам (ожидаемые приходы-даты, количество)
2. Уведомления о необходимости оплаты - заявка на оплату и счет со стороны поставщика для оплаты
При расчете MRP потребности необходимо учесть разрешенные замены согласно СТП и карты отклонений, т.е. если отдел закупок, просмотрев потребность, должен установить связку товар-поставщик, т.е. связать с материалом поставщиков. Если такого материала нет, тогда ищут альтернативу и вводят карту отклонений.
Последовательность выполняемых действий:
1. Выбор режима расчета MRP потребности:
3. Расчет MRP потребности с учетом замен.
4. Привязка поставщиков. Если есть таблица поставщиков (т.е. связь материалов и поставщиков)
5. Связка поставщик - материал, по поставщику договор и сроки поставки. Не исключено, что по одному материалу имеется несколько поставщиков.
6. Далее дать возможность посмотреть уже сформированные заказы. Т.к каталоги на один и тот же заказ или разные пополняются, то нужно все время проверять общую потребность к закупке с уже сформированными заказами и формировать новые.
3. Техническое задание на разработку
Основание для создания автоматизированной системы.
Разработка данной системы осуществляется на основании задания на дипломную работу.
Система предназначена для обеспечения оперативности работы предприятия и доступа к необходимой информации с целью улучшения качества и экономической выгоды предприятия. Разрабатываемый программный продукт должен обеспечивать создание информационной базы, и должны быть разработаны и включены такие компоненты как:
управление доступом на основе ролей;
Задачей дипломной работы является составление проекта по разработке автоматизированной системы управления предприятием, которая включает:
Порядок хранения товара на складе и отслеживание его внутреннего перемещения;
Оформление продаж товара, выдача необходимой для этого документации;
Пользователи автоматизированной системы.
Пользователями автоматизированной системы будут:
Требования к функциональным характеристикам.
1. Программа должна обеспечить возможность выполнения следующих функций:
Система должна обладать набором удобных возможностей по вводу информации в систему;
Система должна вести учет, иметь удобный и достаточный набор информации;
Система должна иметь удобный интерфейс;
формирование необходимой сопроводительной документации;
Предусмотреть контроль вводимой информации.
Предусмотреть блокировку некорректных действий пользователя при работе и системой.
Обеспечить целостность вводимой информации.
Требования к составу и параметрам технических средств.
Система должна работать на IBM совместимых персональных компьютеров.
Объём оперативного занимаемого устройства 256 Mb и больше.
Требования к информационной программной совместимости.
Система должна работать под управлением семейства операционных систем Win 32 (Windows XP/Vista/7 и т.д.).
4. Выбор метода разработки программного обеспечения
В данный момент нет необходимости разрабатывать методологию разработки программного обеспечения (ПО) "с нуля". Существует широкий выбор готовых методологий на все случаи жизни. И, хотя, практически каждый достаточно опытный руководитель разработки программного обеспечения со временем находит свои, более удобные для решаемых задач, методы, все же за основу берется одна из стандартных, общепризнанных методологий. В нашем случае была выбрана обычная каскадная модель, она включает 6 основных этапов:
Планирование программного проекта - в зависимости от потребностей и выбранной методологии разработки может либо вообще отсутствовать, либо занимать достаточно большую часть разработки. На этом этапе определяются основные задачи, которые должны быть решены в рамках разработки ПО, производится оценка необходимого функционала, техническое обследование объекта автоматизации, оценка финансовых, временных, человеческих, технических и других ресурсов, необходимых для осуществления разработки. Так же определятся, какие будут использованы методы разработки и тестирования. Могут быть построены временные графики, составлен бюджет, план работ и прочие документы.
Составление требований заказчика - на этом этапе происходит сбор, анализ и формализация требований к разрабатываемому ПО со стороны заказчика. Этап служит для выработки максимального взаимопонимания между заказчиком и исполнителем. Обсуждаются форма предоставления информации, необходимый функционал, проблемы и ограничения, которые могут возникнуть при разработке. Составленные требования могут быть протестированы.
Проектирование программного продукта - на этом этапе происходит разработка и детализация модели разрабатываемого программного продукта. На основании построенной модели определяется структура и архитектура ПО, организация и взаимодействие модулей и интерфейсов, структура базы данных, строится диаграмма классов и т.д.. Процесс проектирования проводится с учетом методологии, выбранной на этапе планирования. Может быть составлен прототип разматываемого ПО.
Разработка программного обеспечения - единственный этап, которые не может быть пропущен, вне зависимости от выбранной методологии. На этом этапе происходит преобразования результатов проектирования системы в программный код на используемом языке программирования в соответствии с используемыми стандартами кодирования. На этом же этапе разработчики предоставляют информацию инженерам по тестированию для разработки комплекса тестов, разрабатывают техническую документацию и производят планирование интеграции ПО.
Тестирование программного обеспечения - этап, не имеющий четко определенного начала. Может начаться еще на этапе составления требований. Чем раньше начнется тестирование тем выше вероятность, что программное обеспечение будет в точности соответствовать требованиям и потребностям заказчика, тем раньше будут выявлены критические ошибки проектирования и разработки и тем дешевле обойдется их исправление. Тестирование может проводиться в ручном или автоматическом режиме. По результатам тестов составляется отчет. Методы и виды тестирования подробно описаны на странице тестирование программного обеспечения.
Сопровождение программного обеспечения - на этом этапе основное внимание уделяется внесению изменений в программное обеспечение. Изменения могут быть связаны с доработками по желанию заказчика, устранением ошибок, изменением функционала или среды окружения. Так же осуществляется консультация, обучение и поддержка пользователей.
Программный комплекс предназначен для уменьшения трудоемкости работы сотрудников отдела материально-технического снабжения ОАО «Тайфун» при планировании закупок необходимых материалов.
Комплекс разрабатывается для автоматизации планирования процесса закупок.
Программный комплекс состоит из клиентской части, выполненной в среде программирования Delphi, и серверной части, выполненной в виде базы данных Oracle, хранимой на сервере и состоящий из таблиц, хранимых процедур и других компонентов базы данных.
Идентификация и проверка подлинности пользователей или аутентификация - основное средство защиты информационных систем от постороннего вмешательства.
Под идентификацией обычно понимается процедура, посредством которой пользователь или процесс сообщает сведения о себе. Проверка подлинности, или аутентификация - это процедура проверки достоверности предъявленных данных. Как правило, большинству пользователей требуется доступ ко многим сервисам, предоставляемым системами. В то же время ни им, ни системным администраторам не хочется размножать регистрационную информацию и особым образом входить в каждый сервер.
Выход из этой ситуации заключается в создании специального сервера проверки подлинности, услугами которого будут пользоваться другие серверы и клиенты информационной системы. Выделение особого сервера аутентификации позволяет реализовать собственные прикладные комплексы со своей системой понятий, но со стандартной процедурой проверки подлинности, что существенно облегчает управление правами доступа пользователей.
Для данных целей подсистема использует модуль UnitM4Server, который содержит все необходимые функции. Проверку подлинности осуществляет функция User_Connect. Входные параметры: login - имя пользователя, password - пароль. Данная функция принимает имя пользователя и пароль и при правильном вводе, подключает пользователя к базе. Окно ввода имени пользователя и пароля представлено на рисунке 5.1.
Рисунок 5.1 - Окно проверки доступа
TMainF.SocketConnection1AfterConnect:
Procedure TMainF.SocketConnection1AfterConnect(Sender: TObject);
M4Server:=IM4ServerDisp(IDispatch(SocketConnection1.appServer));
raise exception.Create(M4Server.Error_Message);
us_n:=UpperCase(IniParameters.UserName);
us_n:=LeftStr(UsNamePass,pos('@',UsNamePass)-1);
us_p:=midStr(UsNamePass,length(us_n)+2,Length(UsNamePass)-2);
if M4Server.User_Connect(us_n,us_p,us_fio) > -1 then
StatusBar1.Panels[0].Text := us_fio;
ShowMessage('Неправильное имя пользователя или пароль!');
//raise exception.Create('Соединение невозможно!');
Компоненты и процессы авторизации позволяют предоставлять пользователям разрешения на доступ к ресурсам и управлять этими разрешениями.
Сотрудники завода, имеющие доступ к информационным ресурсам, получают идентификатор. Чтобы обеспечить управление доступом к управляемым ресурсам, например, базам данных и приложениям, для идентификаторов назначаются роли.
Роль - это ключевой компонент функции управления доступом на основе ролей. Роли создаются в соответствии с тем, что требуется сотрудникам для эффективного предоставления доступа к нужному инструментарию [7].
Политика предоставления доступа задает связь между сотрудниками, принадлежащими к различным ролям в организации, и службами, которые соответствуют различным ресурсам, а также определяет, какие права будут предоставлены этим сотрудникам при доступе к службам.
Реализуемая политика предоставления доступа отражает политику управления идентификацией, соответствующую плану обеспечения защиты.
Политика предоставления доступа представляет собой ключевой компонент каркаса автоматизации управления жизненным циклом идентификаторов.
Предоставляемое право определяет, какие службы связаны с правилом политики и какие условия применимы к предоставляемому праву. Например, предоставляемое право может указывать, есть ли у связанной с ним роли доступ ко всем экземплярам службы, или только к какому-то одному экземпляру этой службы. С предоставляемыми правами также связаны рабочие потоки, которые позволяют реализовать процедуры утверждения при предоставлении доступа к службам.
5.1.3 Управление доступом на основе ролей
Управление доступом на основе ролей существенно сокращает затраты и сложность администрирования пользователей за счет реализации комплексного, основанного на правилах политики, решения по предоставлению пользователям доступа к ресурсам в соответствии с действующим на заводе требованиями к защите.
Функция управления доступом на основе ролей использует роли и правила политики предоставления доступа, чтобы оценивать, проверять и применять бизнес-процессы и правила для предоставления доступа пользователям. Главные администраторы создают правила политики предоставления доступа и назначают пользователям роли, для которых заданы наборы предоставляемых прав, определяющих разрешения на доступ к ресурсам. Роль, назначенная пользователю, отражает круг его обязанностей и сферу его деятельности в организации [7].
Функция управления доступом на основе ролей оценивает изменения в информации о пользователях, чтобы определить, влияют ли эти изменения на назначение пользователю той или иной роли. Если возникает такая необходимость, правила политики пересматриваются и сразу же вносятся изменения в предоставляемые права. И аналогично, изменение в наборе ресурсов, с которым связано правило политики, может инициировать изменение в соответствующих предоставляемых правах.
Управление доступом на основе ролей включает в себя следующие возможности:
§ Обязательные и дополнительные предоставляемые права; дополнительные права не предоставляются автоматически, но пользователь в группе может затребовать такие права.
§ Обязательные службы, доступ к которым должен предоставляться до того, как будут заданы те или иные права доступа. Например, права доступа к Windows NT (R) должны предоставляться до предоставления прав на доступ к Microsoft Outlook (R) .
§ Права могут предоставляться по умолчанию, а также могут применяться ограничения предоставляемых прав, когда каждой характеристике предоставляемого права присваивается значение по умолчанию или, в зависимости от возможностей предоставляемого права, ограничивается область его действия.
§ Можно создать одну учетную запись с несколькими разрешениями, управляемыми разными правилами политики.
§ Можно соз
Разработка программного обеспечения для автоматизации процесса закупок необходимых материалов для ООО "Звезда Востока и Японии" дипломная работа. Программирование, компьютеры и кибернетика.
Курсовая работа по теме Интернальность и мотивация как вероятность достижения успеха студента в учебной деятельности
Реферат: Тема: Культура, экономика и политика Индонезии во второй половине 20 века
Дипломная работа по теме Особенности конькобежного спорта
Лабораторная работа: Инвестиционный проект производства строительных материалов
Курсовая работа: Аналіз соціально-економічного розвитку міста Рівне
Когда Солнце Растопило Зернистый Снег Сочинение
Курсовые Работы На Дому
Курсовая работа: Эволюции реалистического метода в творчестве Диккенса на примере романов "Приключения Оливера Твиста" и "Большие надежды". Скачать бесплатно и без регистрации
Реферат: Влияние крещения Руси на милосердную практику
Куплю Дипломную Работу Цена
Дипломная работа: Разработка предложения по совершенствованию деятельности ОГУ БелИФ на основе технологи
Курсовая работа по теме Оценка финансового менеджмента в Банке ВТБ 24
Реферат по теме Чем держалось единство России?
Реферат: Cancer In Detail Essay Research Paper Discuss
Сочинение: Маркетинг на рынке ценных бумаг
Реферат по теме Двигатель ЗиЛ-130
Дипломная работа: Показатели возможной экономической эффективности инвестиций
Дипломная Рамка
Методы Разведения Сх Животных Курсовая
Курсовая Работа На Тему Состав Расходов Бюджета На Государственную Поддержку Отраслей Материального Производства
Подагра. Болезнь Рейтера - Медицина презентация
Вияв неореалістичних та неоромантичних рис у творах В. Винниченка - Литература статья
Основания прекращения Арбитражным судом производства по делу - Государство и право контрольная работа