56
Рисунок 17. Модель жизненного цикла Oracle CDM
Прохождение процесса разработки через четыре этапа называют циклом
разработки [18]. Каждый цикл разработки завершается генерацией версии системы.
Если после версия системы не удовлетворяет требованиям пользователя, то
разработанный продукт продолжает свое развитие и проходит те же этапы
разработки. Этапы модели жизненного цикла RUP представлены на рисунке 18.
Рисунок 18. Модель жизненного цикла RUP
Модель жизненного цикла «Microsoft Solution Framework» (MSF) похожа на
модель «RUP» тем, что в ней процесс разработки программного обеспечения
делится на следующие фазы [18]:
Анализ;
57
Проектирование;
Разработка;
Стабилизация.
Эта модель является итерационной, что предполагает использование
объектно-ориентированного подхода при моделировании системы. Модель MSF, по
сравнению с моделью RUP, больше ориентирована для разработки бизнес-
приложений. Модель жизненного цикла представлена на рисунке 19.
Рисунок 19. Модель жизненного цикла MSF
Модель жизненного цикла «Extreme Programming» (XP) была разработана в
1996 году[19]. В ее основе лежит командная работа с организацией эффективной
коммуникацией между заказчиком и разработчиков во время всей разработки ПО.
При этом разработка программного продукта проводится с использованием
последовательно разрабатываемых прототипов. Модель XP представлена на рисунке
20.
58
Рисунок 20. Модель жизненного цикла XP
Для разработки информационной системы, автоматизирующей процесс учета
и анализа ассортимента интернет магазина была выбрана модель жизненного цикла
XP, поскольку из всех рассмотренных моделей она является наиболее гибкой и
делает акцент на взаимодействии с заказчиком на всех этапах разработки ПО.
Выделяют 4 стратегии внедрения программного обеспечения [25]:
«Параллельная стратегия» - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
«Скачок». Эта стратегия представляет собой резкий переход от
использования старой информационной системы к новой без каких-либо
дополнительных проверок и с полным отказом от старой системы.
«Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному числу
процессов. Область применения стратегии - небольшой участок деятельности. Такой
подход снижает риск и наиболее надежен. Практически все предприятия применяют
эту тактику сегодня.
«Узкое место». «Узкое место» - это малая часть производственного
процесса. При использовании похода «узкое место» план внедрения выполняется
только для «узкого места» и для людей, работающих в нем. Точность данных
повышается только для изделий в этом «узком месте»; переподготовка - только для
людей, работающих в нем; анализ эффект-затрат делается только для него и т.д.
59
Для проектируемой системы была выбрана стратегия «пилотный проект»
поскольку система будет автоматизировать только процесс учета и анализа
ассортимента интернет-магазина.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Согласно модели жизненного цикла «XP», процесс разработки программного
обеспечения будет включать в себя следующие этапы:
1. Планирование проекта.
2. Проектирование программного обеспечения.
3. Разработка программного обеспечения.
4. Тестирование программного обеспечения.
5. Ввод в эксплуатацию.
В процессе планирования любого проекта, даже не связанного с разработкой
программного обеспечения, осуществляется оценка рисков проекта. Риски проекта
связаны с ограничениями в ресурсах, которые могут быть:
1. Временными.
2. Финансовыми.
3. Человеческими.
Все перечисленные ресурсы являются взаимосвязанными и способны оказать
влияние друг на друга [16]. Чем тщательнее будут изучен риски, связанные со всеми
ресурсами, тем выше возможность их предотвращения. На этом этапе проекта
разрабатывается план реагирования на риски проекта, который содержит описание
действий, которые необходимы для минимизации последствий совершившегося
риска.
Рассмотрим риски, которые могут возникнуть на этапах разработки
информационной системы [21]:
1. Дефицит специалистов. Этот вид риска присутствует в любом проекте
по разработке программного обеспечения. В него включены такие непредвиденные
обстоятельства, как больничный или нетрудоспособность по другим причинам.
План реагирования на этот вид риска разрабатывается на стадии планирования
проекта. Полностью обезопасить проект от этого риска невозможно, однако,
60
необходимо осуществить заранее поиск специалистов, которые могут заменить
отсутствующего специалиста или заложить в бюджет проекта сумму на
сверхурочную работу существующей проектной команды.
2. Нереалистичные сроки и бюджет. При планировании проекта
необходимо осуществить расчет длительности проекта с помощью метода «Pert»,
который предполагает три вида длительности задач проекта: пессимистической,
ожидаемой и оптимистической. С помощью оценки вероятностей рассчитывается
длительность работ проекта. В срок выполнения проекта необходимо включать
запас, который может потребоваться при непредвиденных обстоятельствах. Бюджет
проекта рассчитывается по тому же принципу. В нем должен содержаться запас
денежных средств, которые могут понадобиться для покрытия последствий
осуществления того или иного риска.
3. Реализация несоответствующей функциональности. На этапе
планирования проекта необходимо составить техническое задание на создание
системы. Техническое задание должно составляться специалистами (системными
аналитиками) и быть согласовано с экспертами: разработчиками программного
обеспечения и программистами. Подписанное заказчиком и утвержденное
экспертной группой техническое задание поможет избежать риска
несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса. Требования
к пользовательскому интерфейсу необходимо описать в разделе «Эскизный проект»
технического задания, которое утверждается заказчиком. Все пожелания заказчика,
которые не входят в техническое задание реализуются дополнительно после сдачи
проекта системы.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и
оттачивание деталей. На каждом этапе проекта назначается ответственное лицо,
которое отвечает за качество работы на текущей стадии. Менеджер проекта
контролирует как промежуточные, так и итоговый результат каждого этапа.
6. Непрекращающийся поток изменений. На этапе составления
технического задания на создание системы должны быть учтены и зафиксированы
все требования к разрабатываемой системе. Все пожелания заказчика, которые не
61
входят в техническое задание реализуются дополнительно после сдачи проекта
системы.
7. Нехватка информации о внешних компонентах, определяющих
окружение системы или вовлечённых в интеграцию. Ответственность за неполноту
сведений, предоставленных на стадии планирования проекта несет заказчик проекта.
8. Недостатки в работах, выполняемых внешними (по отношению к
проекту) ресурсами. Этот риск должен учитываться на стадии планирования
проекта, поскольку могут потребоваться дополнительные временные ресурсы для
устранения выявленных недостатков.
9. Недостаточная производительность получаемой системы.
Производительность системы рассчитывается на этапе составления технического
задания, поэтому оно должно утверждаться не только заказчиком, но и экспертами
в области разработки программного обеспечения.
10. Разрыв между квалификацией специалистов и требованиями проекта.
Необходимо учитываться этот риск на этапе планирования проекта. И осуществлять
формирование проектной команды после формирования всех требований к проекту.
Иначе потребуется дополнительный бюджет и временные затраты на привлечение
специалистов в подходящей квалификацией.
Большая часть этих рисков связана с организационными и процессными
аспектами взаимодействия специалистов в проектной команде. Качество управления
рисками проекта зависит от квалификации менеджера проекта.
2.1.3. Организационно-правовые и программно-аппаратные средства обеспечения
информационной безопасности и защиты информации
Рассмотрим аспекты реализации информационной безопасности для
поставленной задачи. Защита системы от внутренних угроз предполагает
добавление в существующую Политику безопасности организации раздела о
разграничении прав доступа к разрабатываемой системе. Пользователями системы
будут кладовщики, специалисты отдела продаж и специалисты ИТ-отдела.
Следовательно, права доступа к реализуемой системе должны быть только у
следующих сотрудников:
62
1. Руководитель отдела продаж;
2. Кладовщик;
3. Комплектовщик заказов;
4. Контент-менеджер.
Права на создание документов должны быть не у всех пользователей системы,
а только у контент-менеджера, который осуществляет учет ассортимента и у
менеджера по продажам, который осуществляет формирование сопроводительных
документов.
Поскольку каждый из сотрудников выполняет свои обязанности по учету и
анализу ассортимента, права на редактирование документа должны быть только у
того сотрудника, который является его создателем или у начальника отдела т.е. у
сотрудников отдела продаж и ИТ-отдела. Права на удаление документов должны
быть только у начальника финансового отдела и главного контент-менеджера. Все
изменения в системе должны протоколироваться для возможности выявления лица,
нарушившего Политику безопасности.
Определим правила разграничения доступа к разрабатываемой системе. Для
того, чтобы определить правила разграничения доступа, выделим группы
пользователей, которые будут работать с разрабатываемой системой:
1. Руководитель отдела продаж.
2. Кладовщик.
3. Комплектовщик заказов.
4. Главный контент-менеджер.
5. Контент-менеджер.
Затем составим список разделов системы и опишем права доступа для каждой
категории пользователей. Права доступа представлены в таблице 7.
Таблица 7
Разграничение прав доступа
Раздел
Руководитель
отдела
продаж
Кладовщик
Комплектов
щик
заказов
Главный
контент-
менеджер
Контент-
менеджер
Справочники
Просмотр
Удаление,
редактиро
вание
Редактиро
вание
Карточки
товара
Раздел
Руководител
ь отдела
продаж
Кладовщик
Комплектов
щик заказов
Главный
контент-
менеджер
Контент-
менеджер
63
Документы
Редактирова
ние,
удаление
Редактирова
ние
Просмотр
Отчеты
Просмотр
Защита системы от внешних угроз будет реализована с помощью текущей
Политики безопасности организации: на серверное оборудование компании не
установлены сторонние средства удаленного администрирования. Доступ к серверу
осуществляется с помощью «Remote desktop protocol», в том числе и сервер
приложений и СУБД, где будет установлена серверная версия разрабатываемой
информационной системы. Доступ к серверу осуществляется только
авторизованный.
Для каждого пользователя системы необходима процедура авторизации для
защиты от внутренних угроз информационной безопасности. Ежеквартально
система должно запрашивать изменение пароля при авторизации для каждого
пользователя, при этом необходимо осуществлять проверку того, не ввел ли
пользователь пароль, который уже им использовался для доступа к системе.
Для защиты от внешних угроз необходимо хранение паролей в
зашифрованном виде и обеспечить надежность каналов связи для того, чтобы
избежать перехвата информации.
Для обеспечения информационной безопасности в организации используется
программное обеспечение, встроенное в операционную систему, обеспечивающее
защиту от вредоносного программного обеспечения и фильтрацию сетевого трафика
благодаря встроенному брандмауэру.
Также необходимо обеспечить следующие механизмы обеспечения
информационной безопасности:
защиту базы данных;
систему резервного копирования.
Защита базы данных обеспечивается использованием алгоритмов
шифрования данных. Резервное копирование осуществляется созданием резервных
копий системы лицом, ответственным за обеспечение информационной
безопасности.
Защиту от хищения данных злоумышленниками обеспечивает пропускная
система контроля доступа в служебные помещения организации. Защита от порчи
64
данных регламентируется Политикой информационной безопасности, которая
принята в организации.
На основании вышеперечисленного можно заключить, что в компании
использованы все возможные методы защиты информации, так как нет уникального
одного метода, который смог бы обеспечить полную информационную
безопасность, а сочетание всех методов позволяет реализовать максимальную
информационную безопасность.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Для разработки информационной модели необходимо осуществить
моделирование нового варианта организации информационной системы предметной
области, в которую входят:
полный состав информации, которая необходима для решения
комплекса задач;
отражение этой информации на всех типах носителей;
описание процесса преобразования информации, от получения
первичной переменной и условно-постоянной информации, и заканчивая
получением файлов с результатной информацией и выдачей ее пользователю;
состав исходных первичных документов и распределение их по
задачам;
источники и способы получения первичной информации;
состав файлов с первичной, условно-постоянной, промежуточной и
результатной информацией;
информационная потребность для каждой задачи комплекса;
адресаты выдачи и получения результатной информации.
Информационная модель представлена на рисунке 21.
65
ИС
Спр. Товары
Спр. Склады
Спр.
Контрагенты
Спр.
Менеджеры
Контент-менеджер
Форма
документа
Форма
сохранения
документа
Спр. Клиенты
Спр.
Товары*
Спр.
Менеджеры*
Форма
редактирования
справочников
Спр.
Контрагент*
Спр.
Клиент*
Спр.
Склад*
Форма
загрузки
документа
Спр. Договоры
Товарный чек
Спр.
Договор*
Товарный
чек*
Заказ*
Заказ
Руководитель отдела продаж
Отчет по
остаткам товара
на складе
Отчет по
продажам
Кладовщик
Рисунок 21. Информационная модель
Ввод данных в разрабатываемую информационную систему будет
осуществляться двумя сотрудниками:
1. Контент-менеджером, который отвечает за ведение справочников и
актуализацию данных о наличии товара.
2. Кладовщиком, который отвечает за ввод актуальной информации о
наличии товара.
Информационная система будет хранить и обрабатывать данные,
распределенные по следующим таблицам базы данных: