48
II ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1.Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла ПО – это структура, содержащая разные
процессы действия, а также и задачи, которые часто осуществляются в ходе
процесса разработки, использования или сопровождения программного
продукта.
Такие модели можно разделять на 3 главных группы:
–
с учетом специфики задач;
–
инженерный подход;
–
современные технологии для быстрой разработки.
Рассмотрим существующие непосредственно модели (подклассы) и
также оценим их недостатки и преимущества.
Модель устранения и кодирования ошибок – это совершенно простая
модель, которая характерна для студентов ВУЗов.
По этой модели именно большинство студентов разрабатывают самые
простые проекты.
Данная модель имеет такой алгоритм:[2, с.212]
–
постановка задачи;
–
выполнение задачи;
–
проверка результата задачи;
–
при необходимости возврат к первому пункту.
Данная модель является устаревшей. Она характерна для 60-70 гг. 20
столетия, поэтому преимуществ перед другими моделями практически не имеет,
к тому же недостатки – на лицо.
Каскадная модель ЖЦ – это процесс разбиение всей разработки
программного средства на этапы, причем все переходы с одного этапа к
следующему происходят только после того, как полностью будет завершена
работа на текущем этапе.
49
цикла:
Рисунок 21. Схема каскадной модели ЖЦ
Рассмотрим положительные стороны каскадной модели жизненного
–
на каждом этапе создается законченный набор всей проектной
документации;
–
выполняемые в нужной последовательности этапы всех работ
позволяют спланировать сроки окончания работ и соответствующие им затраты.
Рассматриваемый подход хорошо показал себя при проектирования
автоматизированных систем, для которых можно в самом начале разработки
достаточно полно и точно формулировать все необходимые требования.
Из этой категории выпадают сверхсложные расчетные системы, а также
системы реального времени с другими подобными задачами.
Однако в процессе создания программного средства постоянно возникает
необходимость возврата к предыдущим этапам, пересмотре или уточнении ранее
принятых решений по работе.
Реальный процесс формирования программного средства принимает
такой внешний вид (рис.22):
50
Рисунок 22. Реальный процесс выполнения каскадной модели Одно
из применяемых в западной литературе названий этой схемы
организации ЖЦ – "водопадная модель" или waterfall model.
Главным недостатком каскадного подхода есть существенное
запаздывание при содержании результата.
Функциональные и информационные модели автоматизируемого объекта
могут устаревать одновременно при их утверждении.
Следующий недостаток – такое проектирование программного средства
ведет к примитивной его автоматизации или механизации существующих
действий работников.
Для преодоления появившихся проблем, связанных с применением
пользованием каскадной модели, в середине 1970-х годов предложена
спиральная модель.
В спиральной модели ЖЦ рассматривается упор на аналогичные
начальные этапы ЖЦ:
–
анализ;
51
–
проектирование.
Сама реализация технических решений выполняется при помощи
прототипов (Рисунок 23).[14]
Рисунок 23. Спиралевидная модель
Ее принципиальная особенность в том, что прикладное программное
средство создается не сразу, по примеру каскадного подхода, а по составным
частям с применением метода прототипирования.
Прототип – это действующий программный компонент, который
реализует отдельные функции, а также внешние интерфейсы разрабатываемого
программного средства.
Создание прототипов также осуществляется за пару итераций, или
специальных витков спирали.
52
Все итерации соответствуют созданию фрагмента, или же версии
программного продукта, в ней уточняются все цели и характеристики
программного проекта, оценивается общее качество полученных результатов,
планируется работа уже следующей итерации.
Для каждой итерации выполняется тщательная оценка разного рода риска
превышения сроков, стоимости проекта для определения необходимости
применения еще одной итерации, их степени точности и полноты понимания
требований для системы, а также целесообразности закрытия проекта.
Спиральная модель (рис. 23) избавляет разработчиков и пользователей
программного средства от полного, точного формулирования всех требований к
системе на исходной стадии, поскольку они могут уточняться на каждой новой
итерации. [4,с.23]
Таким образом, последовательно конкретизируются и углубляются
детали проекта, в результате выбирается также обоснованный вариант, что
доводится до реализации.
Непосредственная разработка итерациями может отражать объективно
существующий спиральный проход создания системы, позволяя перейти на
следующую стадию, так и не дожидаясь полного прекращения работы на данной
стадии, поскольку при таком способе разработки всю недостающую работу
выполняют на следующей итерации.
Основная задача такой разработки – это как можно быстрее показать
пользователям полностью работоспособный продукт, и тем самым активизируя
процессы уточнения требований.
Спиральная модель вовсе не исключает применение каскадного подхода
на последних стадиях проекта тогда, когда требования к полученной системе
полностью определены.
Основная проблема для спирального цикла – это определение момента
перехода в следующую стадию.
53
Для решения такой проблемы необходимо ввести временные или
частичные ограничения на все из стадий ЖЦ.
Переход осуществляется при соответствии с планом, если даже не вся
запланированная функциональность выполнена. План составляется на примере
статистических данных, которые получены в предыдущих проектах, личного
опыта разработчиков.
Спиральная модель также обладает следующими достоинствами:
–
заказчики имеют возможность увидеть разрабатываемый продукт на
ранних стадиях;
–
заказчики принимают участие в разработке средства;
–
в модели воплощены все преимущества каскадной, а также
многопроходной модели.
Главные недостатки спиральной модели: каждый виток спирали может
продолжаться просто до бесконечности, поскольку каждая ответная реакция
заказчиков может породить дальнейший цикл.
Рисунок 24. Улучшенная спиральная модель
54
В качестве модели ЖЦ разработки программного средства большое
распространение получила новая улучшенная спиральная модель, которая
показана на рисунке 24.
В отличии от рассмотренной ранее спиральной модели указанная модель
применяет каскадный подход на последних этапах разработки программного
средства.[7, с.96]
Использование спиральной модели является целесообразным, если
существует одна из таких причин:
–
целесообразно создание прототипа;
–
выполнение организации обладает навыками, что требуются для
адаптации модели;
–
нужно выполнять проекты для средней и высокой степени риска;
–
пользователи не уверены в потребностях;
–
все требования слишком сложные.
В результате анализа моделей ЖЦ и их этапов, для разработки ИС
расчетов с поставщиками будет применяться каскадная модель, поскольку она
имеет большой уровень жесткости и полностью подходит для разработки.
2.1.2. Ожидаемые риски на этапах жизненного цикла
Основной риск на первом этапе – недостаточное определение основных
свойств проектируемой ИС, что требуются для решения задачи, а также
неправильный выбор исходных задач проектирования.
Заметим, что это может потребовать на следующих этапах,
дополнительной доработки программы или хранилища данных, что приведет к
возрастанию финансового риска.
Риск можно предотвратить использованием популярных CASE-средств
при построении модели бизнес-процессов. При непосредственном
возникновении риска проводится дополнительный процесс моделирования с
использованием указанных выше CASE-средств.
55
На практике чаще всего CASE-средства используются для создания
схемы базы данных в виде ER-диаграмм и генерации структур баз данных для
конкретной СУБД. После получения от заказчика изменений разработчики
вносят соответствующие исправления в диаграмму "сущность – связь" и заново
генерируют структуры баз данных.
При определении функций ИС, а также стратегий автоматизации
большой риск вызывает неправильное определение функций системы и
стратегии автоматизации.
Этот риск предотвращается основательным системным анализом всех
имеющихся вариантов.
В случае непосредственного возникновения, риск устраняется
реализацией повторного анализа варианта выбора ИС.
Риск взаимосвязан также с риском неправильного определения основных
функций ИС, а также стратегии автоматизации. Этот риск устраняется и
предотвращается использование CASE-средств.
Риски на этапе «Разработка проекта автоматизации» состоит в разработке
неэффективного плана-графика процесса автоматизации: применение лишних
ресурсов или же недостаточность ресурсов.
Этот риск является финансовым, а также его можно предотвратить с
использованием современных средств проектирования и устранить повторной
корректировкой плана автоматизации.
На этапе «Разработка программного обеспечения» главный риск кроется
в некорректной разработке создаваемой программы. Риск устраняется при
использовании модульного тестирования ПО.
Риск при внедрении – некорректное тестирование аппаратного
обеспечения программных модулей.
Кроме этого, риск предотвращается применением лицензионного
стендового оборудования, устраняется двойным тестированием.
56
При выполнении сопровождения ПО основные риски состоят в поломке
оборудования, морального его устаревании.
Первый риск предотвращается периодическим мониторингом состояния
оборудования.
Другой – с применением гибкости разработанной ИС, а также
своевременной доработкой программной структуры.
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
К организационно-правовым средствам обеспечения информационной
безопасности на уровне информационной системы относят:
–
применение пароля на платформе 1С:Предприятие 8.3;
–
применение пароля используя возможности операционной системы
Windows 10;
–
применение паролей на вход в компьютерную сеть компании “Steak
at home”.
К данным средствам можно отнести разграничение уровня доступа
между несколькими подсистемами конфигурации:
–
бухгалтерия;
–
отдел организации поставок;
–
транспортный отдел;
имеет доступ только к тем объектам конфигурации, которые можно
указать при разработке.
К аппаратным методам защиты относятся такие инструменты:
–
блоки непрерывного питания;
–
брандмауэры и другие технические устройства.
К программным средствам защиты информации относится возможность
ввода паролей для пользователей.
57
Кроме этого, для защиты ИС от внешних угроз есть возможность
применения ролей и привилегий [11].
Полномочия ролей рассматриваются на рисунках 25, 26:
Рисунок 25. Установка прав Администратора
Рисунок 26. Определение прав персонала (пользователя)
Рассмотрим таблицу разграничения прав доступа (таблица 4).