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

Главная

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

Характеристика основных методов проектирования: в SADT, UML. Техническое задание на информационную систему. Создание модели в стандарте SADT (IDEF0). Декомпозиция родительской модели. Создание таблиц базы данных и связей между ними, бизнес логики.


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


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


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


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


Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Департамент образования города Москвы
государственное бюджетное профессиональное
Образовательное учреждение города Москвы
имени Героя Советского Союза М.Ф. Панова»
Специальность: 090204 Информационные системы (по отраслям)
Диаграмма 1 Опрос населения «наиболее острые проблемы здравоохранения» ( I - II квартал 2015 г.) URL: http://o-gorod.net/news/352096/ С сайта «Открытый город» (Дата обращения 10.10.2016)
Как видно из диаграммы 1 наиболее недовольно население проблемами (1 место) платны х услуг в медицине и проблема ми очередей в медицинских учреждениях, (2 место) д лительное ожидание сроков оказания медицинской помощи , (3 место) д ефицит диагностического оборудования . Одна из причин возникновения данных проблем - не рациональное использование бюджета исходя из того, что процессы управления расходными материалами недостаточно проработаны . Стоит сделать пояснение, что в данном проекте мы будем рассматривать как государ ственные, так и частные медицинские учреждения, данная проблема возникает и в государственных учреждениях и частных. Исходя из этого возникает потребность в создании информационной системы, которая поможет более эффективно проводить учёт возникающих проблем, что в свою очередь уменьшит их воздействие.
Цель работы: разработка информационной системы учета расходных материалов в медицинских учреждениях, для оптимизации учета , минимизации расходов и контроля над оборотом материалов .
Для достижения данной цели мне необходимо решить следующие з адачи:
1. Провести анализ особенности учёта медицинского расходного материала
2. На основе анализа выявить проблемы учёта
3. Спроектировать информационную систему учета медицинских расходных материалов.
4. Смоделировать информационную систему учета медицинских расходных материалов.
5. Р азработать информационную систему
Объект исследования - с истема учёта медицинских расходных материалов
Предмет исследования : - моделирование и р азработка информационной системы учёта медицинских расходных материалов.
Практическая значимость данной работы обусловлена разработкой информационной системы, которая позволит систематизировать и максимально автоматизировать учёт меди цинского оборудования и снизить риск возникновения, проблем, которые были рассмотрены в аннотации к данной работе.
Методология и методика работы: Методологическую основу курсовой работы составляли такие методы, как обобщение, классификация, аналогия и моделирование. Практическая часть выполнена благодаря методам сравнения, анализа и описания.
Теоретическую основу курсовой работы составили авторы : В.В. Персианов, Е. И. Логвинова, Кибиткин А. И., Дрождинина А. И., Мухомедзянова Е. В., Скотаренко О. В.
Теор е тическая и практическая значимость работы: заключается в возможности использования, содержащихся в курсовой работе выводов и предложений для совершенствования учёта расходных материалов в медицинских учреждениях.
Структура работы. Работа состоит из введения, трех глав и за ключения.
В первой главе описана предметная область анализа, технико-экономическое обоснование проекта, и инструменты проектирования и моделирования информационной системы учета медицинских расходных материалов медицинского центра.
Во второй главе описан о техническое задание на информационную систему и процесс моделирования информационной системы с использованием инструментов моделирования SADT и UML .
В третьей главе описана охрана труда во время работы над проектом и описан процесс разработки информационной системы с пояснением выбора инструмента разработки и описанием макросов, которые были написаны для создаваемой программы.
В заключение описаны выводы о поставленной цели.
Рисунок 1 Связь между пациентами и персоналом
Так как направление моего курсового проекта «Учет расходных материалов медицинского центра», то, следовательно, связь пациентов нам следует убрать из рассмотрения. Пациенты в нашей разрабатываемо й информационной системе не будут играть ключевой роли. Разберем, какие виды персонала могут работать в медицинском учреждении . Персонал медицинского центра состоит из нескольких направлений:
1. Специалисты - сотрудники, оказывающие услуги в медицинском центре (медсестры, врачи, лаборанты)
2. Управление - сотрудники, занимающиеся в основном управлением персоналом, так же являющиеся специалистами (Главный врач, зам. Главного врача) .
3. Сторонний персонал - сотрудники, не имеющие отношения к медицинской деятельности, но работающие в медицинском центре ( кладовщик )
Выделив три эти три направления, мы обозначили субъектов, которые будут взаимодействовать с нашей информационной системой. Следующим шагом мы должны перейти в область учета расходно-материальных средств.
Мы уже определили субъектов, которые будут взаимодействовать с нашей информационной системой (рис.2), но еще не по нятно, как должно проходить учет, какие обязанности будут у каждого из субъектов, и какая ответственность.
Рисунок 2 Субъекты информационной системы
Согласно книге [ 5 ], в основе организации учета материально-производственных запасов на складе и в бухгалтерии лежат следующие принципы:
Ш организация учета по местам хранения или нахождения материально-производственных запасов;
Ш организация учета по каждому материально-ответственному лицу;
Ш определение способа аналитического учета материально-производственных запасов на складах и в бухгалтерии.
Бухгалтерию в этой информационной системе мы рассматривать не будем, для нас первостепенной задачей является рассмотреть количественный учет расходно-материальных средств.
По первому принципу все достаточно просто, это необходимость наличия площади, на которой будет хранится материально производственные запасы, то есть это складское помещение, отдельное здание или пристройка в которой будет хранится запасы.
Второй принцип это, то что мы можем отразить в нашей информационной системе. Из второго принципа следует, то, что каждый сотрудник использующий материальные запасы является материально ответственным лицом Согласно постановлению Минтруда от 31 декабря 2002 г. N 85 , из этого следует, что в информационной системе необходимо реализовать функцию отслеживания передачи материальных запасов.
Третий принцип выходит из второго принципа и определ яет способ аналитического учета. С пособом учет будет лист учета , с е го помощь можно отслеживать материально производственные запасы по каждому артикулу с описанием того куда был выдан данный материал и его текущий остаток.
Определение обязанностей начнем с определения обязанностей кладовщика. В обязанности кладовщика в обязательном порядке входит:
Ш Проверка сопроводительных документов на соответствие получаемой поставке
Ш Организация и проведение инвентаризации
Это самые основные обязанности кладовщика, касающиеся учета материальных средств, разница в обязанностях может варьироваться в зависимости от специфики медицинского центра.
На основе этого списка можно выделить основные функции кладовщика в нашей информационной системе:
ь Учет принимаемых материальных средств на склад
ь Учет распределенных материальных средств со склада
ь Учет материальных средств после инвентаризации
ь Списание материала на основе срока годности или невозможности дальнейшего использования
В обязанности направления управления может входить бесконечно много вариантов, мы остановимся на том, что в эти обязанности будет входить функции распределения доступа к базе данных, и составление отчетной документации в медицинском центре.
ь Добавление сотрудника в базу данных
ь Определение доступа в базу данных по должности
ь Доступ к составлению отчетной документации
Обязанности специалистов так же могут варьироваться в зависимости от должности, в нашей базе данных они могут делать заказ оборудования и просматривать оборудование которое, в данный момент у них должно быть.
ь Просмотр текущего количества материала
На этом этапе мы определили, изучили и выделили необходимы функции сотрудников медицинского центра. Для дальнейшей разработки информационной системы нам необходимо изучить и разобрать методологии, инструменты разработки и построить более конкретные модели информационной системы на основе языка SADT .
Диаграмма 2 Использование операционных систем за 2016 год (в %) http://gs.statcounter.com/os-market-share/desktop/russian-federation/2016 (дата обращения 20.11.2016)
Затраты на производство будут происходить из расчета наличия оборудования у заказчика, наличия программного обеспечения, использования платформы для разработки программного обеспечения, времени затрачиваемое на производство и ср еднерыночной стоимости человеко-часа получаемой за время разработки программного обеспечения.
Исходя из того, что разработка нашей информационной системы будет проходить, на основе Microsoft Office рынок выбираемого нами оборудования сокращается в разы . Так как Microsoft Office программа офисного предназначения мощность оборудования необходимая для работы этого набора программ очень маленькая.
В итоге рабочая единица оборудования , котор ая минимально необходима, варьируется от 15 тыс. рублей до 2 3 тыс. рублей.
В дополнение к этому в рабочее пространство должен входить сервер, ведь наше приложение будет работать на клиент-серверной архитектуре.
Стоимость маленького сервера варьируется от 14 т. р. До 25 т. р.
Пакет офисных программ от компании Microsoft обойдется нам в 3 т. р. за компьютер. Плюс сама операционная система будет стоить около 4,5 т. р.
Время на разработку программного обеспечения - 3 мес яца (октябрь, ноябрь, декабрь). Время, которое будет уделяться для разработки составляет 3 часа в день по рабочим дням в течении 3 месяцев. Итого общее время разработки планируется: (3 х 5 х 4 х 3 = 180ч). Из вычисленных сто сорок четыре часа (144 ч.) отводятся для проектирования, моделирования и разработки информационной системы, а тридцать шесть часов (36 ч.) отводятся для тестирования информационной системы.
Формулы для расчета заработной платы на основе человека - часа мы будем считать стоимость разработки на основе времени работы по 8 часовому графику с занятостью 5 дней в неделю.
По формуле стоимость часа разработки рассчитывается на основе заработной платы разработчика поделенной 160 (4 недели по 40 часов) . За основу заработной платы мы возьмём среднюю зарплату junior VBA программиста. Средняя зарплата junior VBA программиста по Москве составляет 27 т. р. Расчеты заработной платы на разработку представлены в таблице № 1.
Таблица 1 Расчеты затрат на разработку
Итоговая сумма затрат на разработку будет составлять 30375 рублей.
Показатель итоговой стоимости будет переведен в формулу для простоты расчетов.
Первое, что мы должны вычислить цену на оборудование и программное обеспечение к нему:
· PriceHW - цена за комплект оборудования;
Возьмём за количественный показатель сотрудников, которые будут взаимодействовать с нашей информационной системой за 100 человек.
Минимальная итоговая стоимость будет составлять:
100(15000+ 7500) + 14000+30375 = 2 . 294 . 375 руб.
Максимальная итоговая стоимость будет составлять:
100(23000+25000) + 25000 + 30375 = 4.855.375 руб.
Данные расчеты будут валидны в случаи, если медицинское учреждение будет открываться с нуля, или если оно будет проводить замену компьютерного оборудования.
Но, как в этом случаи наше медицинское учреждение существует, и оборудование уже закуплено стоимость будет равняться стоимость разработки нашей информационной системы.
1) Каскадная модель - последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
2) Поэтапная модель с промежуточным контролем (водопадная модель ). Разработка ИС ведётся итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
3) Спиральная модель - н а каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.
4) V -образная модель является н аследником каскадной модели с той же последовательностью действий. Отличием от каскадной модели является то, что фазы процесса разработки информационной системы базируются на комплексном подходе.
Особое внимание следует уделять начальным этап ам разработки - анализу и проектированию, которые позволяют с помощью создания макета проекта описать разрабатываемую информационную систему.
В этой работе мы будем придерживаться каскадн ой модель разработки информационной системы. Каскадный подход хорошо подходит при построении малых информационных систем, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жёсткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем.
Во время всего жизненного цикла автор будет руководствоваться стандартами:
1. ГОСТ 34.601-90 - устанавливает стадии и этапы создания автоматизированных информационных систем. Стандарт описывает содержание работ на каждом этапе. Стадии и этапы работы, закреплённые в стандарте, степени соответствуют каскадной модели жизненного цикла.
2. ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды программного обеспечения. Стандарт не содержит описания фаз, стадий и этапов.
В соответствии с базовым международным стандартом ISO/IEC 12207 все процес сы жизненного цикла программного обеспечения делятся на три группы:
a. от общего к частному (нисходящее проектирование)
b. от частного к общему (восходящее проектирования)
Метод проектирования, общее название которому «сверху-вниз». Проектирование происходит, начиная с обобщенной модели верхнего уровня описывающий только общий функционал. И на каждом последующем уровне модели, ее функциональные особенности будут уточнятся. Примером данного моделирования можно описать использования стека инструментов.
Метод моделирования «снизу-вверх». Моделирование по этому методу начинается с описания самых функций нижнего уровня, по мере повышения программа складывается из подфункций в функции, функции обретают классы, классы в свою очередь связываются между собой и обретают полноценный интерфейс. Стек инструментов в этом методе используется только UML .
Определяя, какой из методов проектирования необходимо использовать, первое, что необходимо понять, что мы знаем о том, как работает медицинское учреждение внутри. В начале мы разбирали, чем является медицина и что такое медицинское учреждение, этот метод проектирования является от общего к частному поэтому мы также дальше будем продолжать использовать его.
Рисунок 4 Принцип проектирования SADT
Метод SАDT представляет собой совокупность правил и функций , предназначенных для создание систематизированной функциональной модели объекта какой-либо предметной области. Функциональная модель SАDT отображает единую функциональную структуру объекта, т.е. производимые им действия и зависимости между этими действиями. Основные элементы этого метода основываются на следующих концепциях:
1. Графическое представление блочного моделирования.
3. Отделение организаций от функции, то есть исключение влияние административной структуры организации на функциональную модель.
Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы - диаграммы наиболее абстрактного уровня (верхнего уровня) описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что находится внутри системы , а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут главным образом влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна отвечать . Другими словами, в начале необходимо определить область для создания модели. Описание области как системы в целом, так и ее компонентов является главным и наиболее существенным шагом построения модели. В ходе моделирования область возможно от корректировать, но она должна быть сформулирована в основе , поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является законченной . При определении глубины системы необходимо помнить об ограничениях времени - затраты на труд при построения модели раст ут в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему. Строится набор диаграмм, последовательно детализирующих процессы функционирования объекта управления.
Общий вид блока диаграммы, построенной согласно методологии IDEF0 (IDEF0-диаграммы, или IDEF0 - модели).
Рисунок 5 Состав функциональной модели URL: http://math.sgu.ru/users/oryol/files/proj1.pdf. (дата обращения 20.11.2016)
Одной из наиболее значимы особенностей метода SАDT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Каждый компонент SАDT-модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме. Диаграмма представлена в приложении 4
Построение SАDT-модели заключается в выполнении следующих действий:
Ш сбор информации об объекте, определение его границ;
Ш определение цели и точки зрения модели;
Ш построение, обобщение и декомпозиция диаграмм;
Ш критическая оценка, рецензирование и комментирование.
Построение диаграмм начинается с представления всей системы в виде единственного компонента -- блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок отражает систему как единое целое, имя, указанное в блоке, является общим.
Это верно и для интерфейсных дуг -- они также соответствуют полному набору внешних интерфейсов системы в целом.
После этого блок, который представляет систему в качестве единого модуля, декомпозируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки определяют основные подфункции исходной функции.
Данная декомпозиция выявляет полный набор подфункций, каждая из которых показана как блок, границы которого определены дугами. Каждая из этих функций может быть разбита на подфункции в целях большей детализации.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в функцию выше уровня . Кроме того, модель не может опустить какие-либо элементы, родительский блок и его интерфейсы обеспечивают контекст.
К функции нельзя ничего добавить лишнего , и из нее не может быть ничего удалено непосредственно входящее . Модель SАDT предс тавляет собой серию диаграмм с документацией, поясняющей созданную модель , разбивающи е сложный объект на составные части, которые изображены в виде блоков.
На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной д иаграммы. На SАDT-диаграммах не указаны явно последовательность и время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений.
Для создания информационной системы, необходимо понять, как работает медицинский центр и как его автоматизировать. Управляющий хорошо знает работу в общем, но не может более точно знать детали каждого сотрудника. Сотрудник знает, что твориться на его рабочем месте, но может не знать, какие конкретно цели выполняют коллеги. Поэтому для описания работы медицинского центра необходимо построить модель, которая будет содержать в себе знания всех процессов участников организации.
В IDEF0 реализованы три базовых принципа моделирования процессов:
· принцип функциональной декомпозиции;
Принцип функциональной декомпозиции:
Способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть ее структуру и состав.
При работе с IDEF0 диаграммами главным условием является их разборчивости и удобочитаемости. Главный смысл принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Соблюдение этого правила приводит к тому, что функции, представленные в виде IDEF0, хорошо структурированы, достаточно понятны и легко анализируемы.
Создание модели делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается единственный блок - главная бизнес-функция системы. Если речь идет о создании модели целого подразделения, главная бизнес-функция не может быть сформулирована как, например, "продавать продукцию". Главная бизнес-функция системы - это «суть» системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии.
Диаграмма прецедентов (диаграмма вариантов использования) в UML - диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов , позволяющей описать систему на концептуальном уровне.
Проектируемая система представляется в виде множества сущностей или актёров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актёром (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актёром. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актёров c системой.
Прецедент -- возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат.
Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе.
Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру (поля, методы…) и типы отношений (наследование, реализация интерфейсов…).
На данной диаграмме Диаграмма классов представлена в приложении №1 не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. На этом этапе принципиально знание ООП подхода и паттернов проектирования.
Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия.
Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приёма сообщений между объектами используется диаграмма последовательности.
Взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений.
Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Диаграмма последовательности представлена в приложении №2
На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации.
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определённые роли во взаимодействии.
Рисунок 7 Диаграмма кооперации Рисунок взят с сайта Habrahabr URL: https://habrahabr.ru/post/74330/ (дата обращения 16.11.2016)
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы.
Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код.
Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ.
Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Главное предназначение этой диаграммы -- описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
В этой главе бы ло рассмотрено и проанализирована предметная область нашей информационной системы. Рассмотрены инструменты проектирования и моделирования нашей информационной системы, которые мы будем использовать для описания в графическом виде перед конечным созданием информационной системы. И было дано обоснование экономической выгоды нашего проекта.
1. Поддержка сетевого взаимодействия между несколькими пользователями;
2. Разделение прав доступа между пользователями;
3. Автономное добавление новых пользователей;
4. Специалисты заказывают расходный материал со склада;
5. Пользователи «Склад» отслеживают заказываемый материал;
6. Количественное о тслеживание хра нимого материала на складе ;
7. Количественное отслеживание прихода;
8. Количественное отслеживание взятого материала сотрудниками;
9. Отслеживание движение материала в медицинском центре (списание, выдача);
10. Инвентаризация расходного материала;
11. Хранение результатов инвентаризации;
Руководствуясь выданным техническим заданием, мы будем моделировать нашу информационную систему. Стадии моделирования будут описаны ниже.
Ш Список прихода: для того чтобы использовать материал, он должен быть получен от поставщиков. Входные данные описывают поступление материала в том числе дату и количество.
Ш Список выданного материла: по выданному материалу необходимо проводить учет. В особенности это должно касаться специфичных материалов и материалов проходящие по срокам годности. Входные данные описывают сотрудника, которому был выдан материал его количество и дату получения.
Ш Список списания: как было сказано выше , материал специфичного назначения и материал к которому применимы сроки годности должен проводиться строгий учет. Входные данные описываю списанный материал его количество, дату списания и специалиста у которого списывался материал.
Ш Список остатка на складе: наиболее важная информация в любых бизнес-процессах. Отслеживание количества материалов позволит не оказываться в ситуациях отсутствия необходимых ресурсов для работы. Входные данные описывают количество материалов, оставшихся в запасе.
Ш Расхождение по инвентаризации: вторая наиболее важная информация в бизнес-процессах. В любой деятельности нельзя отменять человеческий фактор. Ошиблись в расчетах дали слишком много или слишком мало, недобросовестный сотрудник приворовывает со склада или сколь угодно любые случаи, инвентаризация позволит отследить расхождения в количестве. Входные данные описываю разницу количества материалов и дату проведения инвентаризации.
Ш Отчеты: обмен информацией по вертикали власти с далеких времен происходит посредством предоставления информации в бумажном виде. Отчеты выполняют эту функцию. Выходные данные представляют собой информацию на бумажном носителе, представленной в едином стандарте предприятия (информацией в отчете будут входные данные бизнес-процессов).
Ш Использование материала: предназначение материала в первую очередь, это возможность его использовать , но мы рассматриваем его переходные состояния до или после использования . Выходные данные представляют собой изменения состояния материала (приход, списание, передача сотруднику) .
Ш Законодательство: регулирует процессы работы и использования ресурсов, правила трудоустройства, необходимую квалификацию для выполнения работ и многое другое. Пример: Федеральный закон от 05.04.2013 N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд".
Ш Внутренние правила: опираясь на законодательство регулирует правила работы внутри компании, такие как время работы, штрафы, премии и т.д.
Ш ГОСТ: стандарты, о
Проектирование, моделирование и разработка информационной системы: учёт расходных материалов медицинского центра курсовая работа. Программирование, компьютеры и кибернетика.
Практическое задание по теме Защита информации
Реферат: Mice Of Men Essay Research Paper Justin
Реферат: Дольмены. Скачать бесплатно и без регистрации
Реферат: Choosing Destiny Essay Research Paper Throughout life
Любовь В Драме Гроза Сочинение
Урок Практическая Работа По Химии
Курсовая работа по теме Вербальные и невербальные средства педагогического общения
Учебное пособие: Учебно-методическое пособие для студентов гуманитарных специальностей вузов Втрех частях
Курсовая работа: Учет затрат по строительству объектов
Реферат На Тему Економічні Теорії Й. Шумпетера
Реферат: Сила трения 2
Практическая Работа По Построению Сечений Тетраэдра
Курсовая работа по теме Ярославская губерния в 1905 году
Реферат История Футбола Кратко
Курсовая работа по теме Комплексная модель работы строительной фирмы
На Какую Тему Можно Написать Реферат
2 Психолого Педагогическая Компетентность Современного Педагога Эссе
Особенности Гуманитарного Знания Реферат
Информационная Защита Реферат
Дипломная работа по теме Разработка популярной модели, женского летнего платья для повседневной носки
Международная миграция капитала - Международные отношения и мировая экономика курсовая работа
Формирование кадрового потенциала - Менеджмент и трудовые отношения курсовая работа
Учетная политика ЗАО "Элкон-СВЛ" - Бухгалтерский учет и аудит дипломная работа