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