28
Таблица 4
Сравнительный анализ программных продуктов
Критерий
Forecast
Now
Global
1C: Управление
небольшой
фирмой
Возможность ведения
документации
3
2
4
Возможность
отслеживания запасов
4
3
4
Расчет оптимальной
партии товаров
4
3
4
Управление поставками
4
4
4
Интерфейс
3
3
3
Системные требования
2
4
4
Стоимость
4
3
3
Итого
24
22
26
Результат анализа рассмотренного программного обеспечения
показал, что оно имеет свои преимущества: например, простоту управления
и безопасность. При этом самым главным критерием все-таки является
функциональность, которая показывает очень низкие оценки. Поэтому был
сделан вывод о том, что программное обеспечение, представленное на
рынке, не соответствует поставленной задаче.
1.3.2. Выбор и обоснование стратегии автоматизации задачи
Стратегия автоматизации бизнес-процессов организации
представляет собой подход и набор методов, согласно которым будет
осуществляться автоматизация выбранной задачи.
Существует несколько видов стратегий автоматизации [9]:
кусочная (хаотичная) автоматизация;
автоматизация по участкам;
автоматизация по направлениям;
комплексная автоматизация.
Стратегия полной автоматизации не подходит для рассматриваемой
задачи, поскольку будут автоматизированы не все бизнес-процессы
организации, а только процесс управления поставками.
29
Хаотичная стратегия автоматизации представляет собой процесс
автоматизации выделенной функции [14]. В результате чего
информационная инфраструктура организации представляет собой
совокупность разрозненных программных продуктов. Такая стратегия
применяется на начальном уровне зрелости организации. Чем выше уровень
зрелости организации, тем больше появляется потребность в единой
информационной базе, с поддержкой оперативного доступа к данным всех
сотрудников организации. Поскольку уровень зрелости рассматриваемой
организации не является начальным, такая стратегия автоматизации не
является подходящей.
Разница в стратегиях автоматизации по участкам и по направлениям
заключается в том, что в первом случае осуществляется автоматизация
деятельности отдельных структурных подразделений организации, которые
объединяются по функциональному признаку. Автоматизация по
направлениям представляет собой автоматизацию отдельных направлений
деятельности организации.
В рамках рассматриваемой задачи, более подходящей является
стратегия автоматизация по участкам, потому что неавтоматизированным
остается только участок управления поставками.
1.3.3. Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Рассмотрим существующие способы приобретения информационных
систем для автоматизации управления поставками. Приобретение
информационных систем может осуществляться одним из перечисленных
способов:
1. Покупка готовой специализированной ИС.
2. Разработка ИС своими силами.
3. Разработка ИС сторонней фирмой.
4. Покупка системы и её доработка.
30
Рассмотрим вариант покупки готовой информационной системы,
автоматизирующей бизнес-процесс управления поставками. Ранее были
рассмотрены программные системы, представленные на рынке, и был
сделан вывод о том, что они не в полной мере удовлетворяют потребностям
организации, поэтому покупка готовой информационной системы не
потребуется.
Рассмотрим вариант с покупкой системы и ее доработкой. Доработка
информационной системы под потребности организации является
трудоемкой и добавление необходимого информационных систем под
нужды компании потребует внесения значительных изменений исходного
кода и бизнес-логики. Поэтому оба варианта приобретения
информационной системы были отклонены.
Следующая группа вариантов приобретения информационных систем
подразумевает разработку информационной системы, удовлетворяющей
требованиям организации. В организации есть ИТ-отдел, специалисты
которого обладают необходимой квалификацией для разработки
программного обеспечения. Следовательно, подходящим будет являться
вариант разработки системы своими силами.
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
Рассмотрим состав и содержание входных и выходных документов
автоматизируемого бизнес-процесса. Входным документом является
Товарный отчет, который содержит данные о наименовании товаров и дате
их приема на складе организации. Товарный отчет является
унифицированным документом, поэтому оригинальное проектирование не
потребуется. Товарный отчет будет загружаться в информационную
систему, поэтому он должен быть представлен в виде файла в формате .xlsx,
.xls, .xml.
31
Выходным документом является журнал договоров, который
содержит данные о номере договора, контрагенте, дате заключения и дате
поставки товара. Журнал договоров является унифицированным
документом, поэтому оригинальное проектирование не требуется.
Документ должен иметь возможность печати и сохранения в форматах: .doc,
.docx, .xlsx, .xls для обеспечения удобства дальнейшей обработки.
В рассматриваемых документах не будут использованы
международные классификаторы. При этом в системе должны быть
предусмотрены следующие справочники:
1) Контрагент;
2) Сотрудники;
3) Договор.
Информационная база должна быть организована в виде
интегрированной базы данных с распределенной организацией для
обеспечения совместной работы нескольких специалистов. Для
организации базы данных будет использоваться реляционный подход,
который минимизирует избыточность данных и обеспечивает простоту
манипулирования ими.
1.4.2. Обоснование проектных решений по программному обеспечению
Информационные системы позволяют пользователям осуществлять
сбор и обработку данных. Для хранения данных используются базы данных.
Различают следующие виды баз данных [11]:
1. Иерархические.
2. Сетевые.
3. Реляционные.
В настоящее время широко применяются реляционные базы данных в
связи со следующими факторами [15]:
32
Они обладают простотой, поскольку в реляционной модели
данных существует всего одна информационная конструкция,
формализующая табличное представление данных.
Наличие теоретически обоснованных методов нормализации
отношений позволяет получать базу данных с заданными
характеристиками.
Независимость данных заключается в том, что при
необходимости внесения изменений в структуру реляционной базы данных,
требуется внесение минимальных изменений.
Помимо перечисленных достоинств, в организации уже используется
реляционная СУБД. Поэтому, с целью минимизации конфликтов в процессе
интеграции, для разработки информационной системы будет использована
реляционная база данных.
Для управления реляционной базой данных используется
реляционная СУБД. На рынке широко представлены как коммерческие, так
и бесплатные СУБД. Наиболее востребованными на рынке являются
следующие СУБД:
Microsoft SQL Server;
PosgreSQL;
IBM DB2;
Oracle database.
СУБД IBM DB2 является кроссплатформенной, обеспечивает
стабильную работу базы данных. Недостатками системы являются высокая
стоимость и низкая производительность. СУБД Microsoft SQL Server
обладает большим пакетом инструментов, стабильностью работы и низкими
затратами на администрирование. Недостаток системы заключается в том,
что она работает только на платформе Windows. СУБД Oracle обладает
высокой производительностью, легкостью интегрирования приложений и
устойчивостью к большим потокам данных. Недостатком является высокая
33
стоимость, необходимость приобретения мощного оборудования и
персонала для поддержки СУБД.
Ввиду перечисленных свойств реляционных СУБД был сделан выбор
в пользу СУБД Microsoft SQL Server, поскольку эта СУБД уже используется
в организации для функционирования ERP-системы.
Для разработки информационной системы будет использован
объектно-ориентированный подход к программированию, потому что он
позволяет осуществлять конструирование из компонентов, обладающих
простыми инструментами, что дает возможность абстрагироваться от
деталей реализации. При этом данные и операции вместе образуют
определенную сущность, и они не «размазываются» по всей программе, как
это нередко бывает в случае процедурного программирования.
Использование локализации программного кода и данных улучшает
наглядность и удобство сопровождения программного обеспечения.
Рассмотрим языки программирования Java и C++. Если программа
написана на C# и должна работать на машинах с операционной системой
Windows и Linux, тогда потребуются компиляторы для перечисленных
платформ и два разных исполняемых файла. В случае с языком
программирования Java, сгенерированный байт-код может выполняться на
любом компьютере, на котором установлена виртуальная Java-машина.
Гибкость языка отвечает за легкость добавления к разработанному
программному обеспечению новых функциональных возможностей,
использованию существующих библиотек. Язык программирования C#
обладает большим количеством библиотек, тогда как для языка Java
необходимо импортировать модули из стандартной библиотеки.
Важным критерием является время, которое необходимо затратить
для создания рабочей версии программы. Значение этого критерия зависит
от размера кода. Относительно этого критерия язык программирования C#
теоретически изучить легче, чем язык Java, соответственно объем кода на
нем будет меньше за одинаковое время.
34
На основании вышеперечисленных факторов, языком
программирования проекта был выбран язык программирования C#,
который обладает:
большей безопасностью по сравнению с другими языками;
возможностью писать обобщенный код с помощью шаблонов;
возможностью использования объектно-ориентированного
подхода;
управления ресурсами с помощью RAII;
упрощение программного кода за счет перегрузки функций и
операторов;
более простой обработки ошибок за счет исключений.
Разработка информационной системы будет осуществляться в среде
программирования MS Visual Studio, которая поддерживает выбранный
язык программирования.
Проектируемая система должна функционировать в среде
операционной системы Windows 10, поскольку эта операционная система
используется для работы сотрудников организации.
1.4.3. Обоснование проектных решений по техническому обеспечению
Проанализировав техническую архитектуру организации был сделан
вывод о том, что для решения поставленной задачи хватит имеющихся
ресурсов. Разрабатываемая система будет использоваться ежедневно в
рабочее время 5 сотрудниками. На основании этих данных был сделан
вывод о том, что уровень нагрузки на сетевую инфраструктуру составит
30%, а нагрузка сервера баз данных будет составлять 25%. Поэтому для
внедрения системы отсутствует необходимость в покупке
высокопроизводительного серверного оборудования.
Однако для хранения входной, оперативной и нормативно-
справочной информации потребуются дополнительные ресурсы. Поэтому
необходимо укомплектовать сервер организации дополнительным жестким
35
диском объемом не менее 1Тб. Проанализировав предложения на рынке,
был сделан выбор в пользу жесткого диска Seagate 5900 SkyHawk
[ST2000VX008] объемом 2 Тб и стоимостью 5900 рублей.
Характеристики ПК сотрудников организации имеют достаточный
уровень производительности для функционирования разрабатываемой
информационной системы, в связи с чем не подлежат модернизации.
36
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл программного продукта – это временной интервал,
который начинается с принятия решения о создании ПО и заканчивается
полным прекращением его эксплуатации [6].
Жизненный цикл программного обеспечения может иметь разные
структуры этапов, которые определяются моделью жизненного цикла.
Модель жизненного цикла является структурой, которая определяет
последовательность выполнения и взаимосвязи процессов, действий и задач
на протяжении жизненного цикла.
Разработка программного обеспечения, автоматизирующего какую-
либо функцию управления организацией, обладает большим комплексом
работ, которые могут включать в себя множество задач. Чем сложнее
структура работ, тем выше вероятность того, что ошибка, допущенная на
одном из этапов, повлияет на качество продукта в целом. Для того, чтобы
устранить негативное влияние на качество программного обеспечения были
созданы стандарты разработки программного обеспечения.
Несмотря на то, что назначение стандартов разработки программного
обеспечения (ПО) заключается в регламентировании процесса создания ПО,
современные стандарты не предписывают четких и однозначных схем
построения структуры жизненного цикла разрабатываемого продукта. В
международных стандартах регламентируется комплекс видов
деятельности, из которых должен состоять процесс разработки, и вводятся
структуры жизненного цикла разработки ПО.
Существуют стандарты, определяющие различные элементы в
структуре жизненных циклов ПО. Основу таких элементов составляют
технологические процессы – структурированные наборы деятельностей,
решающие некоторую общую задачу или совокупность задач, такие, как
процесс определения требований, процесс разработки, процесс
37
сопровождения ПО, процесс обеспечения качества, процесс разработки
документации, процесс тестирования и пр.
Отечественной является стандарт ГОСТ Р 57193-2016 «Системная и
программная инженерия. Процессы жизненного цикла систем» [1].
Согласно этому стандарту жизненный цикл процесса разработки АИС
делится на следующие этапы:
1. Формирование требований к АС.
2. Разработка концепции АС.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение АС.
В качестве модели жизненного цикла была выбрана итерационная
модель, схема которой представлена на рисунке 7.
Рисунок 7. Итерационная модель жизненного цикла
При использовании итерационной модели жизненного цикла
разработки программного обеспечения существует возможность
устранения недостатков проектирования и программирования на более
поздних стадиях при частичном возврате на предыдущие стадии. При этом
чем позже будет выявлена ошибка, тем дороже ее исправление. Если