36
II ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл программного обеспечения – это период времени,
начиная с принятия решения о создании продукта, заканчивая моментом
полного его вывода из эксплуатации
Жизненный цикл программного обеспечения (ЖЦПО) делится на шесть
фаз:
Анализ требований (АТ)
Проектирование
Реализация (eng. coding)
Тестирование и отладка (eng. testing and debug)
Внедрение (eng. deployment)
Сопровождение (eng. support) [12]
Анализ требований – это сбор требований к ПО, их систематизация,
выявление противоречий, недостающей информации и т.п. Анализ требований
делится на три фазы: сбор, анализ и документирование.
Проектирование – подразумевает собой описание свойств будущей
системы, на основе анализа требований – результата предыдущего этапа
Реализация – это непосредственно кодирование (или программирование)
– процесс написания программного кода на определённом языке
программирования, с целью реализации алгоритмов, определённых на
предыдущем этапе – проектировании
Тестирование – проверка и испытание законченного продукта на предмет
его качества: устойчивости к нагрузкам, дружественности к пользователю
(юзабилити), безопасности (устойчивости к взломам), соответствию
требованиям и т.п.
37
Внедрение – это процесс установки и настройки программного продукта,
для конкретных условий использования. Также, под внедрением
подразумевают обучение пользователей работе с данным продуктом
Сопровождение – процесс поддержки программного продукта. На данном
этапе устраняются ошибки («баги»), вносятся изменения с целью улучшить
продукт. Эта стадия в жизненном цикле, как правило, занимает большую часть
времени
Существует три основных модели жизненного цикла ПО: каскадная
модель, спиральная модель, итерационная модель
Каскадная (водопадная) модель
Согласно этой модели, разработчики идут от стадии к стадии строго
последовательно. Сначала полностью завершается этап Анализ требований,
затем Проектирование и т.д. Каскадная модель подразумевает, что переход от
одной стадии разработки к другой происходит только после полного и
успешного завершения предыдущей фазы, и что переходов назад либо вперёд
или перекрытия фаз — не происходит. Таким образом, каскадная модель имеет
существенный недостаток — очень низкую гибкость
Итерационная модель
Суть модели состоит в выполнении работ параллельно с непрерывным
анализом полученных результатов и корректировкой предыдущих этапов
работы. При таком подходе в каждой фазе проходит повторяющийся цикл:
Планирование — Реализация — Проверка — Оценка. Основными
преимуществами такого подхода являются снижение рисков и организация
эффективной обратной связи с потребителем [16].
Спиральная модель
Основная задача данной модели является как можно быстрее показать
работоспособный продукт, тем самым активизируя процесс уточнения и
дополнения требований. Основная проблема спиральной модели —
определение момента перехода на следующий этап. Для ее решения
необходимо ввести временные ограничения на каждый из этапов жизненного
38
цикла. Переход осуществляется в соответствии с планом, даже если не вся
запланированная работа закончена. План составляется на основе
статистических данных, полученных в предыдущих проектах, и личного опыта
разработчиков. Одним из возможных подходов к разработке программного
обеспечения в рамках спиральной модели жизненного цикла является
получившая в последнее время широкое распространение методология быстрой
разработки приложений RAD (Rapid Application Development)
На каждом витке спирали могут применяться разные модели процесса
разработки ПО. Разработка итерациями отражает объективно существующий
спиральный цикл создания системы. Неполное завершение работ на каждом
этапе позволяет переходить на следующий этап, не дожидаясь полного
завершения работы на текущем. При итеративном способе разработки
недостающую работу можно будет выполнить на следующей итерации
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Таблица 1 - Характеристики дефектов программного продукта
Этапы возникновения рисков
Типы первичных рисков
программного средства и
документации
Разработка требований к ПО
Риски исходных требований
заказчика
Планирование работ
Проектирование архитектуры
системы
Риски, обусловленные реальной
сложностью проекта
Ошибки планирования и системного
проектирования программного
средства
Детальное проектирование ПО
Системные и алгоритмические
проблемы проекта
Кодирование ПО
Программные проблемы компонентов
и документов программного средства
Тестирование ПО
Программные и алгоритмические
проблемы программного средства и
документации
Разработка документации
Риски обобщающих документов
39
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В соответствии с положениями ст. 11 Федерального закона от 27 июля
2006 г. N 149-ФЗ «Об информации, информационных технологиях и о защите
информации»[1] законодательством Российской Федерации или соглашением
сторон могут быть установлены требования к документированию информации.
В федеральных органах исполнительной власти документирование
Новеллой российского законодательства в информационной сфере,
несомненно, является Доктрина информационной безопасности Российской
Федерации, утвержденная 5 декабря 2016 года Указом Президента Российской
Федерации[2].
Существования любой организации происходит под угрозой
информационной безопасности, промышленный шпионаж, хакерские атаки,
недоработки системы, ошибки и техническая неграмотность пользователей и
администраторов автоматизированной системы все это может привести к
порче, краже и удалению информационных активов. Иными словами под
информационной безопасностью понимают защищенность информации от
незаконного ознакомления, преобразования и уничтожения.
В условиях угрозы информационной безопасности целесообразно
использование локальной вычислительной сети с централизованным
управлением, т.е. политика безопасности общая для всех пользователей.
Для осуществления безопасности в локальных вычислительных сетях
необходимо обеспечить следующее:
При определении порядка доступа к защищаемым информационным
ресурсам применяется «принцип недоверия», который означает, что все
полномочия по доступу являются персональными, указаны явно и проверены
перед предоставлением доступа, а также «принцип минимума полномочий»,
означающий, что по запросу на доступ к информационным ресурсам
40
предоставляются полномочия, минимально необходимые для реализации этого
запроса.
Полномочия сотрудников по доступу к информационным ресурсам
должны быть установлены таким образом, чтобы в руках одного сотрудника не
концентрировались права, позволяющие ему создавать, копировать, искажать и
уничтожать защищаемые информационные ресурсы.
Для защиты от несанкционированного доступа в информационную
структуру, каждому сотруднику предприятия, присваивается учетная запись, в
зависимости от занимаемой должности определяются права для работы с
автоматизированной системой. Учетная запись содержит сведения
необходимые для:
идентификации - логин, в процессе доступа сотрудник указывает
свой логин, и система проверяет его наличие в своей базе;
аутентификации - пароль, проверка подлинности пользователя;
и авторизации, т.е. предоставление доступа.
Минимальные требования к паролю: пароль должен быть персональным,
длиною не менее восьми символов, должны входить цифры и буквы в верхнем
и нижнем регистрах, пароль не должен включать в себя легко вычисляемые
сочетания символов (имена, фамилии и т.п.), а также общепринятые
сокращения.
Резервные копии паролей хранятся у администратора информационной
безопасности предприятия.
Должна быть исключена возможность несанкционированного
подключения технических средств к неиспользуемым портам. Для этого
неиспользуемые устройства ввода - вывода информации и коммуникационные
порты опечатываются любым доступным способом, например: специальными
наклейками с голографическим слоем, проволокой со свинцовой пломбой и
т.д., либо устройства ввода - вывода информации изымаются из тех
компьютеров, где в них нет необходимости, также возможно использования
программных средств блокировки.
41
Для обеспечения информационной безопасности необходимо отдельное
размещение серверной и пользовательской инфраструктуры. В качестве
серверной желательно отдельное помещение с контролем доступа,
видеонаблюдением, автоматической системами пожаротушения и климат -
контроля.
Защита от вредоносного программного кода и атак из внешних сетей
[24]:
Использование межсетевого экрана.
Ограничение и контроль доступа во внешние сети из локальной
сети организации и из внешних сетей в локальную сеть организации.
Применение в информационной системе специального
антивирусного программного обеспечения, оснащенного сетевым центром
управления.
Своевременно обновлять сигнатурные базы антивирусных
программ, операционную систему и программное обеспечение.
Предусмотреть процедуры резервного копирования и
восстановления данных, а также обеспечить регулярность проведения этих
действий.
Обеспечение этих минимальных требований мер позволит добиться
информационной безопасности локальных сетей на предприятии.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
В настоящий период реляционные модификации являются наиболее
известными.
При применении наиболее полезных физиологических модификаций
информации, используя единственный либо иной инструмент с целью опции
модификации к установленной БД улучшается нее рабочие свойства.
42
Модель Суть-Взаимосвязанность (ER-форма) (entity-relationship model
(ERM) — форма информации, дозволяющая охарактеризовать
мировозренческие схемы [22].
Предоставляет собою графичную нотацию, основанную в блоках и
объединяющих их направлениях, с поддержкой каких допускается
характеризовать предметы и взаимоотношения меж ними какой-либо-или иной
модификации информации. В данном значении ER-модель представляется
метамоделью информации, в таком случае принимать орудием отображения
модификаций информации. ER-модель удобна при прототипном
(проектировании) информационных систем, баз данных, архитектур
компьютерных приложений, и других систем (далее, моделей).
С ее поддержкой допускается особо отметить основные сути,
находящиеся там в модификации, и отметить взаимоотношения, что имеют все
шансы вводиться между данными сущностями. ER-форма представляется
одной с наиболее элементарных зрительных модификаций информации
(графичных нотаций). Она дает возможность отметить текстуру «крупными
мазками», в единых чертах. Данное всеобщее представление текстуры
именуется ER-диаграммой либо онтологией избранной предметной сферы
(область of interest).
На этапе перехода к реализации данной ER-диаграммы в виде реальной
информационной системы или программы, происходит отображение ER-
модели в более детальную модель данных реляционной (объектной, сетевой,
логической, или др.) базы данных, которая называется даталогической моделью
данных по отношению к исходной ER-диаграмме.
ER модель разрабатываемой БД изображена на рисунок 4.
43
Рисунок 4 - ER-модель разрабатываемой БД
В ER–диаграмме сущности изображаются обозначенными
прямоугольниками, ассоциации - обозначенными ромбами или
шестиугольниками, атрибуты - обозначенными овалами, а связку между ними -
ненаправленными ребрами, над которыми может проставляться степень связи
(1 или «много») и необходимое объяснение.
Между двумя сущностям, например, А и В возможные четыре вида
связей.
а) связь ОДИН-К-ОДНОМУ: в каждый момент времени каждому
представителю (экземпляру) сущности А отвечает 1 или 0 представителей
сущности В. б) связь ОДИН-КО-МНОГИМ: одному представителю сущности А
отвечают 0, 1 или немного представителей сущности В;
44
Из-за того, что между двумя сущностями возможные связки в обоих
направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ и
МНОГИЕ-КО-МНОГИМ.
Характер связей между сущностями не ограничивается перечисленными.
Существуют и более сложные связи.
Проектирование базы данных базируется на нормализованной
Концептуальной логической модели и являет собой превращение логической
модели в физическую модель базы данных, то есть проектирование на основе
разработанных на предыдущих стадиях проектирования описаний процессов,
диаграмм потоков данных и ER диаграмм.
Это превращение включает:
определение первичных источников;
отображение сущностей в таблице;
отображение атрибутов сущностей к колонкам;
отображение отношений к внешним источникам;
описание структур таблиц;
создание скриптов (файлов формата SQL с описанием таблиц) и
генерацию за ними физических таблиц базы данных;
описание триггеров;
создание при необходимости серверных процедур и оглядел
пользователя.
Результатом этого этапа проектирования является создание серверной
части информационной системы - физической базы данных. Первым этапом
проектирования реляционной базы данных является инфологическое
моделирование, целью которого является обеспечение наиболее естественных
для человека способов сбора и представления той информации, которая
предусматривается хранить в создаваемой базе данных.
Следовательно, инфологическую форму информации создают согласно
аналогии с непосредственным стилем (завершающий никак не способен
45
применен в чистейшем варианте при помощи трудности компьютерной
обработки текстов и неоднозначности естественного языка). Главными
полезными компонентами инфологических модификаций представляется
сущности, связки между ними и их атрибутов (свойства).
Для раскрытия взаимосвязей меж сущностями следует, равно как
минимум, установить по сути. Однако данное не элементарное поручение,
благодаря тому, что в различных настоящих сферах этот ведь предмет способен
являться сутью, атрибутом либо ассоциацией.
2.2.2. Характеристика нормативно-справочной, входной и
оперативной информации
Создаваемая информационная система менеджера должна будет
выполнять следующие функции:
вывод информации о клиентах;
вывод информации о продажах;
ведение различной справочной информации;
ведение оперативного учета в области продаж товара;
учёт оказания дополнительных услуг.
2.2.3. Характеристика результатной информации
Результатной информацией являются готовые к печати документы,
которые формируются в процессе работы с программой:
1. счет
2. договор
3. список счетов
4. работа с клиентами
5. отчеты по платежам