44
- готовые решения, как правило, соответствуют стандартным
технологиям работы специалистов;
- приобретение лицензионного ПО предполагает возможность
технической поддержки конечных пользователей, доработки ПО в
соответствии с изменениями законодательства.
Также в настоящее время возможно приобретение «облачных»
решений, что предполагает аренду ПО, развернутого на удаленном
сервере. При этом не требуется временных затрат на установку и
обслуживание ПО, но имеются риски, связанные со стабильностью
каналов связи, а также с нахождением данных организации на сервере
сторонней фирмы. При этом в случае возникновения проблемных
ситуаций возможна блокировка доступа к ресурсам.
К недостаткам готовых решений относят необходимость адаптации
под специфику организации, зачастую наличие неиспользуемого
функционала. Риски, связанные с зависимостью от фирмы-разработчика.
Также возможно использование стратегии ПО, связанной с покупкой
и доработкой существующих решений. В этом случае приобретается ядро
системы (например, в бухгалтерии это проводки), а остальной функционал
дорабатывается.
К преимуществам данной стратегии можно отнести [6]:
• покупаемое ядро является отлаженным и законченным
компонентом;
• возможная доработка именно требуемой функциональности;
• не надо платить за то, что компании не нужно.
К недостаткам:
• необходимость наличия в штате фирмы отдела
информационных технологий;
• эффективность данной схемы можно достичь при
относительно небольших объемах доработок
45
• доработки возможны только в рамках реализованного ядра
готовой системы.
Стратегия собственной разработки программного обеспечения имеет
преимущества:
• возможность адаптации к предъявляемым требованиям;
• индивидуализация проекта;
• возможность реализации изменений под требования
организации.
Недостатки данной стратегии [10]:
• необходимость создания команды, либо создания
дополнительной нагрузки на специалистов ИТ отдела;
• отсутствие профессиональных постановщиков задач может
вносить ошибки в бизнес-логику уже на стадии технического задания;
• проект может захлебнуться:
– из-за недостаточной квалификации разработчиков и
специалистов профильных отделов;
– из-за ухода ведущих специалистов;
– из-за нехватки внутренних ресурсов;
– смена руководства компании может привести к решению о
закрытии проекта.
• часто плохая документированность системы.
В данном случае оптимален способ автоматизации путем покупки
ядра системы и ее последующей доработки.
В результате рассмотрения параметров основных стратегий
автоматизации было принято решение о разработке собственной
автоматизированной системы, учитывающей особенности бизнеса
предприятия, так как в рассмотренных выше существующих разработках
отсутствует интегрированное решение всех поставленных задач, а если
покупать готовые решения разных производителей, ориентирующиеся на
46
решение отдельных задач, тогда получим недостатки, характерные для
хаотичной автоматизации. Кроме того, руководством ООО
«Республиканский аптечный слад» было принято решение о рассмотрении
возможности снижения расходов на приобретение программного
обеспечения.
1.4.3. Обоснование стратегии автоматизации задачи
Далее определим стратегию автоматизации технологии работы ООО
«Республиканский аптечный слад».
В настоящее время принята классификация стратегий автоматизации
на следующие виды [11]:
хаотичная (кусочная) автоматизация;
автоматизация по участкам;
автоматизация по направлениям;
полная автоматизация.
Проведем более подробный анализ данных стратегий.
Хаотичная стратегия автоматизации подразумевает отсутствие
единой стратегии функционирования информационной системы
предприятия. Каждый специалист, либо группа специалистов в рамках
данной стратегии принимает решение о внедрении той или иной
информационной системы, что приводит к полному отсутствию
управляемости системой, сложностям в администрировании и
невозможности интеграции различных направлений работы специалистов.
Такая стратегия автоматизации характерна для малых предприятий,
зачастую не имеющих в штате ИТ-специалистов, когда каждый специалист
устанавливает себе системное, офисное, антивирусное ПО, а также
отвечает за функционал прикладного ПО. Например, бухгалтер
самостоятельно выбирает более удобную с его точки зрения программу, не
согласовывая свои действия, например, с кадровой службой, которая также
47
имеет свой функционал, например, при учете сотрудников или табелей
рабочего времени. Такая стратегия автоматизации является
неэффективной, ведет к росту расходов на программное обеспечение,
увеличивает трудозатраты в случае необходимости интеграции различных
участков работы, значительно повышает уязвимость системы и усложняет
администрирование.
Стратегия автоматизации «по участкам» предполагает единый
подход при внедрении программного обеспечения в рамках выполнения
единого функционала. Так, в данном случае, например, в технологии учета
заработной платы, единое ПО уже будут использовать бухгалтер и
специалист по кадрам, что позволит объединить функционал данных
специалистов в единую технологическую цепочку. При этом и в данном
случае остается ряд недостатков, характерных для хаотичной
автоматизации, так как не предполагается единый подход к использованию
информационных ресурсов системы (так как в данном случае не
используется единая СУБД, аппаратная платформа, системное ПО, что
также увеличивает расходы на использование системы) [13].
Стратегия автоматизации «по направлениям» предполагает единые
подходы к внедрению информационных систем согласно направлениям
деятельности предприятия. Например, блок бухгалтерии при данной
стратегии будет использовать базу «1С: Комплексная автоматизация», в
которой реализован функционал всего бухучета – учета заработной платы,
основных средств, оперативного, складского учета и при этом все это
объединено в единую базу и позволяет получать сводную информацию о
состоянии данного объекта управления. При этом в рамках единого ПО
отражена вся технологическая цепочка подразделения (от ввода первичных
данных до формирования отчетности и электронного документооборота).
Стратегия полной автоматизации предполагает автоматизацию всех
направлений деятельности на единой платформе управления. Подобный
48
тип автоматизации является оптимальным, хотя встречается довольно
редко в крупных компаниях, так как требует наличия собственного штата
разработчиков ПО [14].
Основываясь на том, что нам необходимо автоматизировать бизнес
процесс поддержки принятия решений, целесообразно выбрать стратегию
автоматизации «по направлениям». Так как организация документооборота
представляет собой целостную технологическую цепочку, целесообразна
её полная автоматизация.
1.5. Обоснование проектных решений
Обоснование проектных решений по информационному обеспечению
Информационное обеспечение – совокупность проектных решений
по объемам, размещению, формам организации информации (единой
системы классификации и кодирования информации унифицированных
систем документации, схем информационных потоков), циркулирующей в
организации, а также методология построения баз данных. [8]
Информационное обеспечение можно разделить на два типа:
внемашинное и внутримашинное.
Внемашинное информационное обеспечение включает:
показатели, необходимые для решения управленческих задач;
их объемно-временные характеристики и информационные
связи;
различные классификаторы и коды;
унифицированную систему документации для отражения
показателей;
формы вывода результатов обработки.
Автоматизация управленческих операций требует приведения всего
множества показателей в единую, целостную систему, установления их
49
содержательного и терминологического единства (однозначности), а также
четких взаимодействий между ними.
В процессе проектирования экспертной системы ООО
«Республиканский аптечный склад» потребуется использование ряда
классификаторов:
локальный классификатор видов медикаментов;
локальный классификатор поставщиков;
справочник лекарственных препаратов;
справочник лекарственных форм.
В качестве входных документов информационной системы
используются:
рецепт на приобретение медикаментов;
приобретение медикаментов
Выходной информацией будет являться сформированная
отчетность по:
динамике выручки по датам;
отчёт по продажам.
В большинстве случаев, использование унифицированных форм в
управлении системой документооборота не представляется возможным,
так как такие формы отсутствуют.
1.5.2 Обоснование проектных решений по программному обеспечению
Программное обеспечение - совокупность программ системы
обработки информации и программных документов, необходимых для
эксплуатации этих программ. [6]
В таблице 9 приведен перечень проектных решений по видам
программного обеспечения, используемых в данной работе.
Таким образом, при расчете требований к параметрам технического
обеспечения необходимо учитывать системные требования для
50
обеспечения функционирования всего комплекса программного
обеспечения, используемого в условиях ООО «Республиканский аптечный
склад».
Таблица 9.
Перечень программного обеспечения, используемого в проекте
автоматизации документооборота ООО «Республиканский аптечный
склад»
Тип ПО
Наименование ПО
Назначение ПО
Системное ПО
Microsoft Windows
2012 Server Standart
Управление ресурсами вычислительной
сети администрации, контроль учетных
записей, использование
административных политик
Офисное ПО
OpenOffice.org 4.1,
Microsoft Office 2010
и 2016.
Работа по подготовке документов,
электронных таблиц, отчетности
различного типа, вывод данных из
внешних приложений
Инструментальное
ПО
1С: Предприятие 8.3
Разработка приложения для
автоматизации технологии работы
специалистов
СУБД
Microsoft SQL Server
2014 Std
Работа с базами данных прикладных
программных комплексов
Прикладное ПО
1С: Предприятие 8.3
Работа специалистов по кадрам,
бухгалтерскому учету, расчёта
заработной платы, ведения кадрового
учёта
ПО для обеспечения
информационной
безопасности
Kaspersky EndPoint
Security 11,
360 Total Security
Обеспечение антивирусной защиты
1.5.3 Обоснование проектных решений по техническому
обеспечению
Под техническим (аппаратным) обеспечением информационной
системы понимается весь комплекс электронных, электрических и
механических устройств, входящих в состав системы и/или сети, исключая
программное обеспечение и хранимую информацию. В этот комплекс
входят: компьютеры, периферийные устройства ввода/вывода и хранения
информации, а также сетевое оборудование различных типов и
энергетическое оборудование (батареи и аккумуляторы) [3].
51
Требования к техническому обеспечению формировались исходя из
аппаратных требований используемого программного обеспечения, и
представлены в таблице 9.
Параметры аппаратного обеспечения серверной части определены
согласно требованиям к СУБД, требования к рабочей станции – по оценке
нагрузки на рабочую станцию приложения для автоматизации системы
документооборота.
Таблица 9.
Аппаратные требования информационной системы
Сервер
Клиент
Процессор
2,9 ГГц (с архитектурой x64).
Оптимальное число ядер – от 2.
От 2,6 ГГц
ОЗУ
От 4ГБ
От 2ГБ
Видеокарта и
монитор
монитор SVGA (с минимальным разрешением 1024х768 точек)
Жесткий диск
120 Гб
Для работы программы
необходимо от 100 МБ
Оптический
привод
DVD-RW
-
Устройства ввода
клавиатура и мышь
ЛВС
Пропускная способность 1GB/c
100 MB/s
Анализ аппаратных требований дает основание утверждать, что
существующих средств технического обеспечения для функционирования
создаваемой информационной системы аптечной сети достаточно,
необходимость в модернизации и замене отсутствует.
52
II. Проектная часть
Основные этапы жизненного цикла информационной системы
Этапы жизненного цикла проекта автоматизации
Проведем выбор концепции жизненного цикла в рамках
проектирование экспертной системы автоматизированного управления.
Понятие «жизненный цикл проекта» можно интерпретировать как
период времени от зарождения идеи проекта до его завершения, который
можно разделить на соответствующие фазы или этапы [8]:
стадия замысла;
стадия разработки;
стадия производства;
стадия применения;
стадия поддержки применения;
стадия прекращения применения и списания.
Не бывает одного оптимального способа определить наиболее
подходящий жизненный цикл и структуру проекта. У некоторых
организаций существуют принятые принципы, согласно которым для
каждого проекта подразумевается один и тот же жизненный цикл, в то
время как остальные организации позволяют команде управления
проектом самим выбирать жизненный цикл, наиболее подходящий для
проекта.
Модель жизненного цикла программного обеспечения - структура,
определяющая последовательность выполнения и взаимосвязи процессов,
действий и задач на протяжении жизненного цикла. Модель жизненного
цикла зависит от специфики, масштаба и сложности проекта и специфики
условий, в которых система создается и функционирует.
Модели жизненного цикла:
53
Каскадная модель - подразумевает последовательное
выполнение всех этапов проекта в строго определенном порядке. Переход
на следующий этап выполняется только после полного завершения работ
на предыдущем.
Итерационная модель - подразумевает разделение жизненного
цикла проекта на определенную последовательность итераций,
напоминающих «мини-проект», каждый из которых включает все
процессы разработки в применении к созданию меньших фрагментов
функциональности, по сравнению с проектом в целом. Цель каждой
итерации - получение работающей версии программного продукта,
включающей функциональность, определённую интегрированным
содержанием всех предыдущих, и текущей итерации. Результат финальной
итерации содержит всю требуемую функциональность продукта.
Спиральная модель - складывается из нескольких итераций
(витков спирали) путем создания прототипов (черновых версий
программы). Каждая итерация соответствует созданию фрагмента или
версии программного обеспечения, на ней уточняются цели и
характеристики проекта, оценивается качество полученных результатов и
планируются работы следующей итерации.
Для разработки требуемого приложения автоматизации
документооборота выбрана спиральная модель, представленная на рисунке
18. Структура модели жизненного цикла программного обеспечения
приведена в соответствии со стандартом ГОСТ 34.601-90.
Информационная технология. Процессы жизненного цикла программных
средств [14, с.90].
Концепция спиральной модели, разработанная Барри Боэмом в 1986
году, применяется в рамках разработки большого количества
информационных систем [8]. Она выступает в роли технологии разработки
программного обеспечения, сочетающей в себе как стадии