46
Из рассматриваемых моделей жизненного цикла программных систем
наиболее подходящей моделью для проектируемой системы является
итерационная модель жизненного цикла, поскольку она обладает рядом
достоинств по сравнению с другими моделями:
1. Снижение возможности возникновения ошибок или искажений
информации при разработке системных требований, что приводит к созданию
более качественного конечного продукта.
2. Возможность внесения в процесс разработки новых или
неожиданных требований пользователей, что является необходимым, поскольку
реальное положение дел может отличаться концептуальной модели предметной
области.
3. Модель представляет собой формальную спецификацию,
воплощенную в рабочую модель жизненного цикла предметной области.
4. Модель позволяет выполнить гибкое проектирование и разработку,
включая несколько итераций на всех фазах жизненного цикла.
5. Возможность возникновения разногласий при общении заказчиков с
разработчиками минимизирована.
6. Качество программного продукта определяется при активном
участии пользователя в процессе разработки на ранних фазах проекта.
После того как был сделан выбор стандарта разработки программного
продукта и модели жизненного цикла, необходимо осуществить выбор стратегии
внедрения. Выделяют 4 стратегии внедрения программного обеспечения:
«Параллельная стратегия» - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
«Скачок». Эта стратегия представляет собой резкий переход от
использования старой информационной системы к новой без каких-либо
дополнительных проверок и с полным отказом от старой системы.
«Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
47
деятельности. Такой подход снижает риск и наиболее надежен. Практически все
предприятия применяют эту тактику сегодня.
«Узкое место». «Узкое место» - это малая часть производственного
процесса. При использовании похода «узкое место» план внедрения выполняется
только для «узкого места» и для людей, работающих в нем. Точность данных
повышается только для изделий в этом «узком месте»; переподготовка - только
для людей, работающих в нем; анализ эффект-затрат делается только для него и
т.д.
Для проектируемой системы была выбрана стратегия «пилотный проект»
поскольку система будет автоматизировать только процесс приема и обработки
заявок для технической поддержки. В качестве модели жизненного цикла была
выбрана итерационная модель. Стандартом разработки программного
обеспечения будет ГОСТ Р ИСО/МЭК 12207-2010.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В процессе планирования проекта по разработке системы необходимо
проанализировать риски и разработать план реагирования на риски. Выявим
риски, которые могут быть выявлены на этапах жизненного цикла системы.
Рисками этапа разработки стратегии автоматизации являются [24]:
недостаточное определение свойств проектируемой системы,
которые требуются для решения задачи;
неверный выбор процессов автоматизации.
Последствиями этих рисков может стать необходимость доработки
системы, выявленная на этапе опытной эксплуатации, что повлечет за собой
дополнительные финансовые затраты.
Предотвратить перечисленные риски возможно с помощью применения
CASE-средств при моделировании бизнес-процессов на этапе выявления
требований пользователей.
Основным риском этапа анализа предметной области является
неправильное определение функций системы. Вследствие этого может
возникнуть риск неправильного выбора способа приобретения системы.
48
Предотвращение риска возможно с помощью проведения тщательного анализа
всех способов приобретения системы.
Если риск все-таки осуществился, необходимо провести повторный анализ
вариантов выбора системы. Предыдущий риск взаимосвязан с риском
неправильного определения функций системы и стратегии автоматизации.
Устранение этого риска возможно с помощью применения CASE-средств в
процессе анализа предметной области.
Рассмотрим риски этапа проектирования системы. Одним из рисков этого
этапа является разработка неэффективного плана-графика проекта, которое
заключается в использовании лишних ресурсов или в дефиците ресурсов. Этот
риск является финансовым, его устранение возможно с помощью использования
программного обеспечения, автоматизирующего процесс планирования проекта
по разработке системы (например, MS Project). Повторное появление этого риска
устраняется с помощью повторной корректировкой плана-графика работ.
Рисками этапа разработки информационного обеспечения задачи являются
разработка неправильной информационной модели и неудобных для
пользователя прототипов экранных форм. Этот риск можно предотвратить с
помощью согласования прототипов экранных форм с пользователями системы.
Устранение риска осуществляется при помощи доработки экранных форм.
На этапе подготовки к разработке системы основным риском является
неправильный расчет показателей. Этот риск можно устранить на этапе
тестирования системы.
На этапе разработки системы основным риском является некорректная
разработка программы. Этот риск устраняется на этапе согласования
технического задания. Каждый раздел технического задания должен быть
разъяснен заказчику и только после полного согласования технического задания
стоит приступать к разработке системы.
На этапе внедрения существует риск некорректного тестирования
технического обеспечения программных модулей. Этот риск предотвращается с
помощью использования лицензионного стендового оборудования, а его
устранение осуществляется с помощью дополнительного процессе тестирования.
49
Рисками этапа сопровождения являются поломка оборудования, моральное
устаревание программного обеспечения и программных средств. Поломку
оборудования можно предотвратить при помощи регулярного мониторинга
состояния оборудования. Риск морального устаревания можно предотвратить с
помощью гибко разработанной системы и своевременного осуществления
доработки программной архитектуры системы.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Рассмотрим аспекты реализации информационной безопасности для
поставленной задачи. Защита системы от внутренних угроз предполагает
добавление в существующую Политику безопасности организации раздела о
разграничении прав доступа к разрабатываемой системе [10].
Пользователями системы учета спроса на товары организации будет только
руководитель производственного отдела, поэтому доступ к ней возможен только
для этого сотрудника. Все изменения в системе должны протоколироваться для
выявления неправомерных действий [12].
При этом в системе должен бить администратор, который будет отвечать за
ее функционирование, резервное копирование, заполнение справочников и
удаление записей.
Определим правила разграничения доступа к разрабатываемой системе.
Для того, чтобы определить правила разграничения доступа, выделим группы
пользователей, которые будут работать с разрабатываемой системой:
1. Руководитель производственного отдела.
2. Сотрудник, уполномоченный руководителем производственного
отдела вести учет спроса на товары.
3. Администратор системы.
Затем составим список разделов системы и опишем права доступа для
каждой категории пользователей. Права доступа представлены в таблице 5.
50
Таблица 5
Разграничение прав доступа
Раздел
Руководитель
производственного
отдела
Администратор
системы
Сотрудник
Справочники
Просмотр,
редактирование
Создание,
редактирование,
Удаление
Просмотр
Учет спроса
Просмотр, загрузка
данных
Загрузка
данных,
Редактирование,
Удаление
Просмотр,
загрузка
данных
Отчет
Просмотр
Просмотр
Просмотр
Управление
пользователями
Создание,
редактирование,
удаление
Создание,
редактирование,
удаление
-
Защита системы от внешних угроз будет реализована с помощью текущей
Политики безопасности организации: на серверное оборудование компании не
установлены сторонние средства удаленного администрирования. Доступ к
серверу осуществляется с помощью «Remote desktop protocol», в том числе и
сервер приложений и СУБД, где будет установлена серверная версия
разрабатываемой информационной системы. Доступ к серверу осуществляется
только авторизованный.
Для каждого пользователя системы необходима процедура авторизации для
защиты от внутренних угроз информационной безопасности [25]. Ежеквартально
система должно запрашивать изменение пароля при авторизации для каждого
пользователя, при этом необходимо осуществлять проверку того, не ввел ли
пользователь пароль, который уже им использовался для доступа к системе.
Для защиты от внешних угроз необходимо хранение паролей в
зашифрованном виде и обеспечить надежность каналов связи для того, чтобы
избежать перехвата информации.
Также необходимо обеспечить следующие механизмы обеспечения
информационной безопасности:
защиту базы данных;
систему резервного копирования.
Защита базы данных обеспечивается использованием алгоритмов
шифрования данных. Резервное копирование осуществляется созданием
51
резервных копий системы лицом, ответственным за обеспечение
информационной безопасности.
Защиту от хищения данных злоумышленниками обеспечивает пропускная
система контроля доступа в служебные помещения организации. Защита от порчи
данных регламентируется Политикой информационной безопасности, которая
принята в организации.
На основании вышеперечисленного можно заключить, что в компании
использованы все возможные методы защиты информации, так как нет
уникального одного метода, который смог бы обеспечить полную
информационную безопасность, а сочетание всех методов позволяет реализовать
максимальную информационную безопасность.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и ее описание
Поскольку с помощью проектируемого программного обеспечения
произойдет реорганизация существующих бизнес-процессов, необходимо
описать новую организацию информационного обеспечения рассматриваемой
задачи. С этой целью создается информационная модель, которая представляет
собой новый вариант организации информационной системы, которая будет
автоматизировать выбранный процесс [19]. Информационная модель
представлена на рисунке 16.
На информационной модели перечислены справочники и таблицы с
оперативной информацией. К справочникам относятся:
Сотрудник;
Группа товара;
Товар;
Единица измерения.
К таблицам с оперативной информацией относятся:
Пользователь
Право доступа.
К таблицам с входной информацией относятся таблица «Спрос».
52
ИС
Спр. Товар
Спр. Единица
измерения
Спр. Группа
товара
Сотрудник
Форма
загрузки
данных
Форма
отчета
Т. Спрос
Спр.
Сотрудник*
Форма
справочников
Т.
Спрос*
Спр. Единица
измерения*
Т.
Пользователь*
Т. Право
доступа*
Отчет по заявкам
Администратор
Руководитель
производственного отдела
Т.
Пользователь
Т. Право
доступа
Спр.
Товар*
Сотрудник
Администратор
Форма
управления
пользователями
Руководитель
производственного отдела
Спр.
Сотрудник
Спр. Группа
товара*
Рисунок 16. Информационная модель
53
В информационной системе должны быть формы следующих видов:
Форма справочников;
Форма заявки;
Форма отчета;
Форма управления пользователями.
В результате ввода данных в информационную систему будет сформирован
отчет по спросу на продукцию.
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Входная информация процесса учета спроса на товары организации
представляет собой данные о заказах оптовых и розничных покупателей. Эти
данные представляют собой перечень товаров организации, сгруппированных по
виду товара, с указанием количества заказанного товара за заданный
пользователем период времени. Входная информация не вводится пользователем
системы вручную. Она загружается из системы SAP. Поэтому форма для входной
информации будет отражать результаты загруженных данных о спросе на товары
организации за заданный пользователем период времени. Для этого форма должна
содержать следующие объекты:
1. Поля для ввода данных о временном периоде.
2. Поля для вывода данных о спросе: наименовании товара и его
количестве.
3. Кнопку для обработки данных.
На основании описания формы входной информации системы был создан
макет экранной формы. Поскольку система создается с целью учета спроса и
данные учета будут составлять ее основу, они будут выводиться на главной форме
приложения. Макет формы представлен на рисунке 17.
Оперативные данные системы представляют собой учетные данные
пользователя. Для их ввода в системе должны быть разработаны две формы:
1. Форма авторизации.
2. Форма управления пользователями.
54
Рисунок 17. Макет формы вывода входной информации
На форме авторизации пользователь будет вводить данные для авторизации
и получения доступа к системе. Для этого форма должна содержать следующие
объекты:
1. Поля для ввода учетных данных.
2. Кнопку для обработки данных.
На основании описания формы оперативной информации был создан макет
экранной формы. Макет формы авторизации представлен на рисунке 18.
Рисунок 18. Макет формы авторизации пользователя в системе
55
На форме управления пользователями администратор системы будет
создавать учетные данные для каждого пользователя и управлять их правами в
системе. Макет формы управления пользователями представлен на рисунке 19.
Рисунок 19. Макет экранной формы управления пользователями
Также в системе должны быть формы для ввода нормативно-справочной
информации. Нормативно справочная информация представляет собой данные о
сотрудниках, которым предоставлен доступ к системе, группах товара, товарах и
единицах измерения спроса на товары. Нормативно-справочная информация
будет храниться в системе в виде справочников, характеристика которых
представлена в таблице 7.
Таблица 7
Характеристика справочников
Характеристика
Сотрудник
Единица
измерения
Группа
товаров
Товар
Ответственный
за ведение
Администратор системы
Руководитель
производственного отдела
Объем
справочника в
записях
10
3
3
2000
Частота
актуализации
По мере необходимости
При создании нового
товара
Объем
актуализации
1 запись
1 запись
1 запись
1-10
записей
Реквизитный
состав
Фамилия
Наименован
ие
Наименован
ие
Наименован
ие
Имя
Отчество
Теперь, когда была дана характеристика справочников, разработаем макеты
экранных форм для ввода нормативно-справочной информации. Для хранения