68
Представим календарный план с использованием средств среды MS
Prоject (см. рис.2.1).
Рис.2.1 Календарный план проекта автоматизации
Дата начала разработки проекта 01.07.2019, завершение проекта
планируется на 22.10.2019, термин выполнения проекта 82 дня.
На рисунке 2.2 представлен график проекта с определенными ресурсами,
которые потом добавляются к представленным задачам, с указанием
необходимого количества и их начальной стоимости. Данные настройки
позволяют определить предварительную стоимость проекта.
69
Рис.2.2 График проекта с указанием ресурсов
Представленный календарь позволит контролировать выполнение задач по
датам, тем самым снижая риск несвоевременного выполнения проекта.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их
описание
На этапе инициализации необходимо определить перечень рисков. Под
риском следует понимать неопределенное событие или условие, наступление
которого отрицательно или положительно сказывается на целях проекта. На
начальном этапе, когда нет необходимых данных для проведения детального
анализа, часто ограничиваются качественной оценкой общего уровня рисков:
низкий, средний, высокий [2,11].
Определим источники получения информации для организации процессов
планирования рисков проектов:
1. Факторы внешней среды предприятия. Рынком сбыта данного проекта
является предприятие ЛОГП «Ленфарм», также могут быть другие торговые
предприятия, которые занимаются продажей товаров различной направленности.
70
2. К сожалению, шаблонов по управлению рисками в данной предметной
области нет, но исходят из опыта похожих разработок, имеет смысл учесть риск
выхода из строя компьютерной техники и уделить внимание здоровью
исполнителей, рассмотреть варианты расширения рынка сбыта.
3. Идентифицируем риски. Риски, которые могут повлиять на проект по
разработке системы учета спроса на продукты сети аптек являются
следующими:
– экономические риски – возможно увеличение стоимости проекта;
– риск неполучения ожидаемой прибыли – возможен отказ от системы и
возврат к существующей системе, которая используется в данный момент на
предприятии;
– административный риск – возможен вариант не принятия системы
вышестоящим руководством предприятия;
– риск не выполнения запланированных работ по организационным или
иным причинам [12].
4. Определим ответственных лиц за управление рисками:
– руководитель проекта – управляет тремя видами риска –
административным – проводит консультации с руководством предприятия, с
целью уменьшения негативного влияние на принятие системы учета спроса на
продуктовый ассортимент сети аптек. Риск неполучения планируемой прибыли
– продвигает продукт по большому количеству клиентов, заключает контракты
на внедрение не только с ЛОГП «Ленфарм», но и осуществляет продвижение на
других торговых предприятиях. Риск не выполнения запланированных работ в
срок – постоянный мониторинг выполнения этапов работы, анализ критических
точек, коррекция плана, привлечение других исполнителей.
– проектировщик – управляет риском не выполнения запланированных
работ в срок, путем контроля за закрепленными за ним этапами;
– заказчик – влияет на административный риск – путем обучения
персонала, который будет работать с системой для получения знаний
эксплуатации системы, что будет способствовать эффективному использованию,
и позволит выявить и быстро исправить недостатки;
71
– программист – управляет риском не выполнения запланированных
работ в срок, путем написания отчетов по выполненным работам и
предоставления готового программного кода в установленный срок.
5.Определим риски, которые наиболее влияют на проект: наиболее
потенциальным влиянием на проект на разработку системы автоматизации учета
спроса на продуктовый ассортимент сети аптек является риск не выполнения
запланированных работ по организационным или иным причинам.
6. Планирование реагирования на риски. Руководитель проекта должен
реагировать следующим образом:
– на административные риски следующим образом – усилить
консультации с руководством ЛОГП «Ленфарм»;
– на риск не выполнения запланированных работ по организационным
или иным причинам – найти более квалифицированных и дисциплинированных
исполнителей, купить новую технику или отремонтировать имеющуюся в
расположении;
– на риск неполучения ожидаемой прибыли, предусмотреть реализацию
системы на разных предприятиях и компаниях.
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Представим средства ИБ и ЗИ, в соответствии с классификацией.
1. Защита от внутренних угроз, настраивается для разграничения прав
пользователей, чтобы предотвратить использование запрещенных или
ограниченных ресурсов пользователями.
Для формирования прав доступа необходимо определить пользователей
разрабатываемой системы и функции, которые на них возлагаются [24].
Представим пользователей и их функции по отношению к разрабатываемой
системе.
72
а) менеджер предприятия, фактически в его функции входит полное
администрирование и управление сетью аптек, перечислим его основные
функции:
– заказ товара у производителей;
– прием товара от поставщиков;
– хранение товара на складах;
– перемещение товара в торговые точки.
б) продавец сети аптек, к типовым операциям данной категории
пользователей относится операция продажа товара.
Выполним проектирование работы каждой подсистемы. Для подсистемы
«Менеджер» необходимо разработать механизмы, которые выполняют все его
операции. На рисунке 2.3 представлена диаграмма процесса «Заказ товара у
производителей».
Рис.2.3 Процесс «Заказ товара у производителей»
Данный процесс представляет собой следующую последовательность:
– директор по работе с контрагентами определяет количество конечных
остатков по имеющимся медицинским товарам, для этого он формирует запрос к
БД системы и получает конечное число;
73
– определяет требования к товару (продукции) производителей – цена,
качество, термин хранения и т.п.;
– осуществляет поиск необходимых производителей;
– после этого с производителями необходимо связаться;
– если уже с производителем работали, то его данные есть в БД системы,
иначе данные по новому производителю необходимо занести в БД;
– после этого выполняется заказ товар;
– данные о заказе сохраняются в БД системы.
На рисунке 2.4 представлен процесс «Прием товара у поставщика
(производителя)».
Рис.2.4 Процесс «Прием товара у поставщика»
На рисунке представлена следующая последовательность данного
процесса:
– директор по работе с контрагентами передает информацию о заказе на
склад (главному менеджеру по хранению продукции);
74
– поставщик (производитель) доставляет свою продукцию на склад;
– менеджер проверяет соответствие доставленного товара и заказанного;
– если заказ и доставленный товар не совпадают, тогда осуществляется
возврат – данная функция представлена подпроцессом, потому что выполняется
ряд действий со стороны поставщика, однако эти действия не оказывают
влияния на информационную систему;
– если заказ соответствует товару, что был доставлен осуществляется его
прием;
– при приеме товара формируется приходная накладная, она заполняется
и данные этого документа сохраняются в БД системы.
На рисунке 2.5 представлен процесс «Хранение товара на складе».
Рис.2.5 Процесс «Хранение на складе»
Процесс представляет собой следующую последовательность:
– менеджеру по хранению продукции необходимо узнать, сколько товара
хранится на складе;
– формируется отчет «Остатки товара»;
75
– выдается распоряжение о физическом подсчете товара на складе, это
действие выполняет кладовщик;
– после подсчета кладовщик передает информацию менеджеру;
– результаты сравниваются, если находятся разбежности, принимаются
меры по выравниванию остатков – списание, штрафные санкции, возмещение и
т.п.
На рисунке 2.6 представлен процесс «Перемещение товара на торговые
точки».
Рис.2.6 Процесс «Перемещение товара на торговые точки»
Данный процесс представляет собой следующую последовательность:
– директор по работе торговыми точками обрабатывает заявки на
поставку товару из торговых точек;
– формирует накладную на перемещение;
76
– данная накладная передается главному менеджеру по хранению
продукции;
– менеджер проверяет накладную, определяет есть такой товар и
необходимое количество;
– если необходимого товара нет или нет нужного количества,
формируется заявка на дозаказ и выполняется процесс «Заказ»;
– если все есть, тогда выполняется отгрузка товара, заполняется
накладная на перемещение;
– накладная сохраняется в БД системы.
На рисунке 2.7 представлен алгоритм работы подсистемы «Продавец» при
выполнении его основной операции – продажа товара.
Рис.2.7 Процесс «Продажа товара клиентам»
Данный процесс представлен последовательностью:
– формирование ассортимента торговой точки (аптеки);
– клиенты посещают аптечные пункты;
– выбирают необходимый товар;
77
– обслуживание клиентов;
– проверка есть необходимый товар, который заказал клиент;
– если нет, буде предложен аналог;
– если есть формируется чек;
– если аналог клиенту не подходит он покидает аптеку;
– если подходит - формируется чек;
– на основании чека формируется расходная накладная;
– накладная сохраняется в БД системы;
– клиент получает информацию по оплате;
– оплачивает покупку;
– выходит из аптеки.
Как было определено ранее подсистема «Продавец» имеет значительно
меньше прав.
В соответствии с этим сформируем таблицу доступа к ресурсам
разрабатываемой системы учета посещений клиентов (см. таб. 2.1) [9].
Таблица 2.1
Данные доступа к ресурсам системы
Группы
пользователей
Справочники
системы
Документы
системы
Отчеты
системы
Журналы
документо
в
Доступ в
Internet
Менеджер
Чтение/
создание/
удаление
Чтение/
создание
Формиров
ание
Чтение/
Добавлени
е записи/
Удаление
записи
Не
ограничен
Продавец
Чтение
Чтение/
создание
Доступ к
отчету
«Остатки
товаров»,
к
остальным
нет
доступа
Чтение
Ограничен
2. Защита от внешних угроз является не менее важным аспектом защиты
данных, чем защита от внутренних угроз. В таблице 2.2 представлены элементы
защиты, которые используются в проектируемой системе.