57
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
план проекта. После документального оформления начинается непосредственно
сам процесс разработки. Создается база данных, отчетные формы, пишется
программный код по сбору, обработке и хранению информации, создаются
процедуры фильтрации. После разработки системы, проходит этап тестирования.
По завершению тестирования готовится план эксплуатации и документация для
внедрения, а так же различная пользовательская документация. Процесс будет
происходить следующим образом. Так как в организации уже существует ЛВС и
стабильно функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета продаж, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета продаж и
СУБД. Тестируется работоспособность, проводится демонстрация работы
системы для руководства и персонала. Последней стадией будет проведение
семинаров для сотрудников компании. Необходимо связать всех сотрудников,
отвечающих за обработку документов в единую информационную сеть. Для этого
клиентские приложения будут устанавливаться в четкой последовательности по
определенным отделам
За эксплуатацию готовой системы, будет отвечать оператор. В его задачу
будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.
2. Получение и документирование сведений о возникающих проблемах, их
решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
58
3. Тестирование системе в эксплуатационной среде, кооперация со службой
сопровождения для устранения возникших проблем и модернизации системы.
4. Поддержка и консультация пользователей.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий, случающихся
с системой с момента ее внедрения и до окончания использования.
Модель ЖЦ отражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее окончательного
вывода из эксплуатации. Модель жизненного цикла представлена некой
структурой, которая содержит процессы, действия и задачи, реализуемые в ходе
создания, работы и сопровождения ПО в течение всей жизни системы, от
выявления требований до окончания ее использования.
Сегодня известны и применимы следующие модели жизненного цикла:
• Каскадная модель включает в себя последовательную реализацию
всех этапов проекта в заранее определенном порядке. Начало следующего этапа
говорит о полном завершении работ на предыдущем этапе.
• Поэтапная модель с периодичным контролем. Создание ИС
реализовано в виде итераций с циклами обратной связи между этапами.
Межэтапные проверки позволяют учесть реально существующее взаимовлияние
итогов разработки на различных этапах; ЖЦ каждого из этапов продлевается на
весь срок разработки.
• Спиральная модель. На любом витке спирали выполняется генерация
очередной версии продукта, корректируются требования проекта, выражается его
качество и планируются работы уже следующего витка. Особое внимание при
этом обращается на начальные этапы разработки - анализ и проектирование, где
возможность создания тех или иных технических решений обосновывается и
проверяется благодаря построению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с большой
точностью и полнотой составить все требования к системе. Главным недостатком
такого подхода является то, что основной процесс разработки системы не может
полностью уложится в такие жесткие рамки, постоянно есть потребность в
возврате к уже завершенным этапам для уточнения или изменения ранее принятых
59
решений. В итоге реальный процесс разработки ИС становится соответствующим
поэтапной модели с периодичным контролем.
На настоящий момент существуют такие модели жизненного цикла, как
каскадная, поэтапная с промежуточным контролем, спиральная.
В спиральной модели особое внимание уделяется начальным этапам
разработки – выработке стратегии, анализу и проектированию, где реализуемость
тех или иных технических решений проверяется и обосновывается посредством
создания прототипов (макетирования). Каждый виток спирали предполагает
создание фрагмента (компонента) или версии программного продукта. На них
уточняются цели и характеристики проекта, определяется его качество и
планируются работы следующего витка спирали. Таким образом углубляются и
последовательно конкретизируются детали проекта и в результате выбирается
обоснованный вариант, который доводится до реализации.
Для разрабатываемого проекта наиболее подойдет каскадная модель для
разработки приложения из-за возможности контроля промежуточных фаз.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация "пилотного проекта.
Параллельная стратегия не подходит , так как компания не располагает
достаточными ресурсами для ведения учета одновременно в автоматизированном
и ручном вариантах. Стратегия Скачек не позволяет плавно перейти на
использование разработки, узкое место больше подходит для использования в
крупных компаниях. Поэтому в качестве стратегии внедрения ИС была выбрана
«Опытная эксплуатация пилотного проекта».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На каждом этапе жизненного цикла ИС есть различные риски. Они
приводят как к серьезным неустойкам во в процессе разработки системы, так и в
ее функциональных возможностях.
60
Далее будут представлены риски в зависимости от процессов ЖЦ, а также
возможные методы их предотвращения.
Процесс подготовки проекта
Риск персонала
Риски:
• Набор необученного персонала к выполнению проекта;
• Набор в группу разработчиков «случайных» сотрудников, а не
главных участников автоматизируемых процессов производства;
• Неимение выработанной стратегии автоматизации;
• Несогласованность в общих целях и задачах проекта;
• Отсутствие мотивационных поощрений сотрудникам;
• Нежелание персонала участвовать в проекте;
• Хаотичный план ведения работ.
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и консультантов;
• Четкая формулировка целей и задач;
• Выработка определённой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки проекта.
Риск ведения проекта
Риски:
• Ошибочная установка границ и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методологий решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
• Поддержка стабильности границ проекта, которые выделяются еще
на начальном этапе и неизменны вплоть до финала проекта;
• Точное планирование выполняемых работ;
• Включение в проект необходимых ресурсов;
• Согласованное и утвержденное проектное решение;
61
• Высокий порог принятия изменений.
Риск неверного планирования
Риски:
• Малоэффективный план организации разработки системы;
• Несоблюдение сроков реализации работ по этапам.
Методики предотвращения:
• В начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
• Описание и сохранение всех проведенных работ и открытый доступ
к этим данным для всех участников проекта.
Процесс разработки
Риск персонала
Риски:
• Увольнение сотрудников, которые отвечают за проведение
разработки;
• Несогласованность действий между участниками проекта из-за
плохой системы коммуникации;
• Ошибочное представление задачи проектирования;
• Набор разработчиком без опыта работы с подобными системами.
Методики предотвращения:
• Грамотный набор сотрудников, участвующих в проекте;
• Реализация четкой системы взаимодействия между сотрудниками,
полное документирование изменений в системе.
Технические риски
Риски:
• Остановка разработки из-за ошибок в применяемом ПО;
• Пользовательская документация состоит из описания лишь
некоторых функций системы.
Методики предотвращения:
• Работа только с проверенным лицензионным ПО, регулярное
резервное копирование данных;
• Отслеживание полноты сведений во всех документах.
62
Процесс внедрения
Риск персонала
Риски:
• Разрозненность деятельности разработчиков и экспертов предметной
области;
• Отсутствие желания у сотрудников использовать новую систему и
связанные с этим сложности их обучения;
• Безучастность руководства.
Методики предотвращения:
• Обучение пользователей со стороны заказчика методики работы с
системой;
• Подготовка плана внедрения системы;
• Обоснование важности и нужности автоматизации персоналу;
• Привлечение руководящего персонала в проект и активное
взаимодействие с ним во время проведения всего проекта.
Технические риски
Риски:
• Утрата информации при внедрении системы.
Методики предотвращения:
• Наем квалифицированных сотрудников, которые имеют опыт
разработки подобных систем.
Процесс эксплуатации и сопровождения
Технические риски
Риски:
• Баги и ошибки ПО, приводящие к невозможности использования
системы;
• Неправильное использование оборудования;
• Отсутствие функциональных возможностей системы из-за
реорганизации предприятия.
Методики предотвращения:
• Полноценное тестирование и дополнение во время разработки
системы;
63
• Описание и занесение в документы всех технических условий и их
согласование.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе включает
в себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.1.
Таблица 2.1
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авторизация»
Модуль «Учет»
Модуль
«Ввод»
Модуль
«Отчеты»
Сотрудник
Чтение
Нет
Нет
Ограничен
Администратор
системы
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
использованием программно-аппаратных комплексов защиты от
несанкционированного доступа;
разработкой и соблюдение политик безопасности;
использованием антивирусных средств;
физической защитой помещений с наиболее ценной информацией.
Также в компании разработана политика безопасности, включающая себя
следующие частные документы:
1. Правила парольной защиты;
2. Правила защиты от вирусов и злонамеренного программного
обеспечения;
3. Требования по контролю за физического доступом;
4. Инструкция по безопасному уничтожению информации или
оборудования;
64
5. Правила осуществления удаленного доступа;
6. Требования резервного сохранения информации;
7. Требование мониторинга доступа и использования систем и ведения
лог файлов;
8. Требования при обращении с носителями данных;
9. Требования при регистрации пользователей;
10. Требования по проверке прав пользователей;
11. Требования по контролю доступа в операционную систему;
12. Требование к процедуре входа в систему (log on);
13. Правила использования системных утилит;
14. Правила удаленной работы мобильных пользователей;
15. Требование распределения ответственности при обеспечении
безопасности;
16. Правила безопасности при выборе персонала;
17. Требования контроля оперативных изменений;
18. Требования к применению криптографических средств управления;
19. Требования по контролю доступа к исходным текстам программ и
библиотек;
20. Требования контроля вносимых изменений;
21. Ограничения на изменения прикладного ПО.
Сама политика безопасности позволяет определить направление развития в
области информационной безопасности, а также уровень внимания и суммарную
величину ресурсов, которые целесообразно выделить руководство компании.
Политика безопасности базируется на основе результатов анализа рисков,
которые получаются реальными для ИС компании. После того, как проведен
анализ рисков и выявлена стратегия защиты, строиться программа, которая
должна обеспечить информационную безопасность. Для этой программы даются
ресурсы, определяются ответственные лица, а также определяется срок контроля
работы этой программы.
Политика безопасности фирмы должна предусматривать структуру легкого,
адекватного для понимания документа высокоуровневой политики, который в
65
свою очередь поддерживается специализированными политиками других
процедур безопасности.
Высокоуровневая политика ИБ должна время от времени пересматриваться,
что гарантирует своевременный учет потребностей компании. Все документ
политики должны составляться таким образом, чтобы она была независима от
конкретных технологии, лишь тогда документы не придется менять очень часто.
Для ознакомления с базовыми понятиями политики безопасности стоит
рассмотреть в качестве примера гипотетическую ЛВС, которая принадлежит
некоторой организации, и ассоциировать с ней политику безопасности.
Политика безопасности чаще всего оформляется в виде документа, который
включает такие разделы, как описание проблемы, сфера применения, позиция
компании, распределение обязанностей и ролей, возможные санкции и т.д.
Данные, перемещающиеся в рамках ЛВС, являются критически важными.
Локальная сеть дает возможность совместного доступа пользователей к
программам и данным, что также увеличивает угрозу безопасности. Именно
поэтому каждая рабочая станция, входящая в сеть, нуждается в хорошей защите.
Такие высокие меры безопасности и являются основной темой этого документа,
который признан показать сотрудникам компании важность сохранения
безопасности сетевой среды, а также выделить их роль с системе безопасности и
распределить точные обязанности по защите данных, находящихся внутри сети.
Область использования. В сферу действия такой политики могут попасть
все программные, аппаратные и информационные ресурсы, которые входят в ЛВС
компании. Подобные меры ориентированы на людей, которые работают с сетью,
в т. ч. на пользователей, подрядчиков и поставщиков.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области. Кроме
того, она объясняет, на основе каких входных документов и какой нормативно-
справочной информации происходит выполнение функций по обработке данных
и формирование конкретных выходных документов.
66
Для создания схемы информационной модели, предварительно определим
несколько реквизитов, составляющих нашу ИС.
Информационные объекты необходимые для работы системы состоят из:
- администратора системы;
- менеджера.
- Экранных форм:
а) для администратора: экранные формы ввода информации в справочники
системы, получения отчетов;,
в) для менеджера: экранные формы учета поступления, учета продаж.
Администратор, в свою очередь, заполняет справочник товаров через
экранную форму, задает им реквизиты и в процессе работы фирмы меняет их,
вносит информацию о наличии товаров в магазине, и увеличивает или уменьшает
их число на сайте. Он использует информацию о наличии на складе, по
предоставляемым документам об отпуске или поступлении товаров, или из
программы 1С.
Покупатель принимает информацию из каталога товаров, внесенных
менеджером, об их наименовании и ценах. Затем он принимает решение, о
покупке, выделяя товары и их кол-во, в экранной форме заказа товара. После
совершения заказа покупатель получает печатный счет к оплате. Заказ добавляется
в таблицу заказов. В то же время менеджер замечает добавление нового заказа в
экранной форме-списке заказов. Он просматривает содержимое заказа, и
реквизиты. Печатает его из печатной формы и отправляет заказ на склад для
резервирования необходимого количества товаров.
Информационная модель включает в себя четыре области:
Область выходной информации
Область справочников системы
Область обработки информации
Область входной информации
На модели приведены следующие входные документы:
сведения о пользователях, поступающие от отдела кадров;
прайс-лист, поступающий из отдела продаж;
перечень магазинов, поступающий из бухгалтерии.