59
компонентами и дальнейшее их уточнение с точки зрения облегчения
технического проектирования. Архитектура программного объекта должна быть
документально оформлена.
Разработчик должен разработать и документально оформить общий
(эскизный) проект внешних интерфейсов программного объекта и интерфейсов
между компонентами объекта; проект базы данных; предварительные версии
документации пользователя; требования к испытаниям (тестированию)
программного объекта и график сборки программного продукта.
o техническое проектирование программных средств;
Разработчик должен разработать технический проект для каждого
компонента программного объекта. Компоненты программного объекта должны
быть уточнены на уровне программных модулей, которые можно
программировать (кодировать), компилировать и тестировать независимо.
Должно быть обеспечено распределение технических требований к компонентам
программного объекта между программными модулями. Технический проект
должен быть документально оформлен.
o программирование и тестирование программных средств;
Разработчик должен разработать и документально оформить
каждый программный модуль и базу данных
o сборка программных средств;
Разработчик должен разработать план сборки для объединения
программных модулей и компонентов в программный объект. План должен
включать требования к испытаниям (тестированию), процедуры тестирования,
контрольные данные, обязанности исполнителя и программу испытаний. План
должен быть документально оформлен.
Разработчик должен собрать программные модули и компоненты и
протестировать их как продукты, разработанные в соответствии с планом
сборки. Результаты сборки и тестирования должны быть документально
оформлены.
o квалификационные испытания программных средств;
Разработчик должен проводить квалификационные испытания
(тестирование) на соответствие квалификационным требованиям к
60
программному продукту. При проведении испытаний должно быть обеспечено,
чтобы реализация каждого установленного требования к программному объекту
была проверена на соответствие. Результаты квалификационных испытаний
должны быть документально оформлены.
Разработчик, при необходимости, должен уточнить документацию
пользователя.
o ввод в действие программных средств. Основной задачей этого
этапа является выбор стратегии внедрения информационной системы.
Разрабатываемая система будет внедряться по стратегии пилотного проекта, т.е.
первоначальное использование системы будет проводиться лишь для некоторых
предметов школьной программы, недельная нагрузка которых составляет 1-2
учебных часа в неделю (география, экономика, МХК и др.). Это позволит
учителю-предметнику сократить нагрузку на тиражирование и проверку
контрольно-измерительных материалов. Кроме того, уже на первоначальных
этапах использования можно будет судить о достоверности выдаваемых
системой результатах, при этом, не оказывая существенного влияния на процесс
выставления итоговых оценок учащимся по наиболее значимым предметам
(русский язык, математика, алгебра).
Разработчик должен разработать план по вводу в действие
программного продукта в среде эксплуатации. Должны быть определены и
иметься в наличии ресурсы и информация, необходимые для ввода в действие
программного продукта. Разработчик должен провести работы по установке
(инсталляции) программного продукта.
Разработчик должен ввести в действие программный продукт, в
соответствии с планом по вводу его в действие.
o обеспечение приемки программных средств.
Разработчик должен обеспечить проведение оценки готовности к
приемке и приемочным испытаниям программного продукта.
Этап эксплуатации состоит из работ и задач оператора. Этап
охватывает эксплуатацию программного продукта и поддержку пользователей в
процессе эксплуатации.
Данный этап состоит из следующих работ:
61
o подготовка процесса;
Оператор должен разработать план эксплуатации и определить
набор стандартов по эксплуатации для выполнения работ и задач данного
процесса. План должен быть документально оформлен и выполнен.
Оператор должен установить процедуры для: получения и
документирования сведений о возникающих проблемах; решения и контроля
проблем и обеспечения обратной связи с пользователем. Всякий раз, когда
возникают проблемы, они должны быть документально оформлены и введены в
процесс решения проблем.
Оператор должен установить процедуры для: тестирования
программного продукта в эксплуатационной среде; ввода сообщений о
проблемах и предложений об изменениях в процесс сопровождения; ввода
программного продукта в эксплуатацию.
o эксплуатационные испытания;
Для введенного в опытную эксплуатацию программного продукта
оператор должен провести эксплуатационные испытания и при соответствии
результатов испытаний установленным требованиям ввести программный
продукт в промышленную эксплуатацию.
Оператор должен обеспечить, чтобы программы и базы данных
устанавливались в исходное состояние (инициализировались), выполнялись
(эксплуатировались) и завершались в соответствии с планом эксплуатации.
o эксплуатация системы;
Система должна эксплуатироваться в установленной для нее
эксплуатационной среде в соответствии с документацией пользователя.
o поддержка пользователя.
Оператор должен обеспечить помощь и консультации
пользователям в установленном порядке. Запросы пользователей и последующие
ответные действия должны быть документально оформлены и контролируемы.
Оператор должен, при необходимости, направлять запросы
пользователя для анализа и ответа в процесс сопровождения. Данные запросы
должны быть приняты, а ответы по планируемым и выполняемым ответным
62
действиям должны быть направлены инициаторам запросов. Все принимаемые
решения должны контролироваться вплоть до их выполнения.
Если поставленная проблема имеет промежуточное (временное)
решение, то инициатору поставленной проблемы должны быть предложены
варианты ее временного решения. Принятые окончательные поправки и
изменения, содержащие ранее пропущенные функции или средства, а также
усовершенствования системы должны вноситься в эксплуатируемый
программный продукт с использованием процесса сопровождения.
Этап сопровождения состоит из работ и задач, выполняемых
персоналом сопровождения. Данный этап реализуется при изменениях
(модификациях) программного продукта и соответствующей документации,
вызванных возникшими проблемами или потребностями в модернизации или
настройке. Целью этапа является изменение существующего программного
продукта при сохранении его целостности. Данный этап охватывает вопросы
переносимости и снятия программного продукта с эксплуатации. Заканчивается
этап снятием программного продукта с эксплуатации.
Данный этап состоит из следующих работ:
o подготовительный;
Персонал сопровождения должен разработать, документально
оформить и выполнить планы и процедуры для проведения работ и задач
процесса сопровождения.
Персонал сопровождения должен определить процедуры для:
получения, документирования и контроля сообщений о возникающих проблемах
и заявок на внесение изменений от пользователей; обеспечения обратной связи с
пользователями. Всякий раз, когда возникают проблемы, они должны быть
документально оформлены и введены в процесс решения проблем.
o анализ проблем и изменений;
Персонал сопровождения должен проанализировать сообщение о
проблеме или заявку.
Персонал сопровождения должен продублировать или
верифицировать возникшую проблему.
63
На основе проведенного анализа персонал сопровождения должен
разработать варианты изменений.
Персонал сопровождения должен документально оформить:
сообщение о проблеме или заявку на внесение изменений; результаты их анализа
и варианты реализации изменений.
o внесение изменений;
Персонал сопровождения должен провести анализ и определить,
какие документы, программные модули или их версии требуют изменения.
Полученные результаты должны быть документально оформлены.
o снятие с эксплуатации.
Должен быть разработан, документально оформлен и реализован
план снятия с эксплуатации при прекращении активной поддержки объекта
эксплуатирующими и сопровождающими организациями. К запланированным
работам должны привлекаться пользователи.
Пользователи должны получить уведомление о планах и работах по
снятию с эксплуатации программного обеспечения.
Рассмотрим модель жизненного цикла разрабатываемого программного
обеспечения для автоматизации учета операций ООО «Золотой век». Наиболее
походящей для реализации функций разрабатываемой системы является
каскадная модель. Это обусловлено следующими ее преимуществами:
на каждом этапе формируется законченный набор проектной
документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют
планировать сроки завершения всех работ и соответствующие затраты.
Представим модель жизненного цикла разрабатываемой системы в виде
ряда последовательно выполняемых этапов. Среди этих этапов обычно
выделяются следующие:
– определение потребностей;
– исследование и описание основных концепций;
– проектирование и разработка;
– испытания системы;
– создание и производство;
64
– внедрение;
– распространение и продажа;
– эксплуатация;
– сопровождение и мониторинг;
– снятие с эксплуатации (утилизация).
Проведенный анализ характеристик компании ООО «Золотой век» и
основных бизнес-процессов однозначно определяет потребность в такой
автоматизированной системе.
Бизнес-процессы в рассматриваемой компании связаны с движением
материальных средств, и неправильный учет, которых может привести к
материальным потерям и другим существенным недостаткам. Поэтому
разработка системы заканчивается проведением этапа испытаний разработанной
автоматизированной системы ООО «Золотой век».
Таким образом, каскадная модель жизненного цикла более всего подходит
к конкретной разработке.
Процесс внедрения — трансформация описания разработки программного
проекта в программный продукт, а также создание исходного кода, баз данных и
документации независимо от того, были ли эти программные продукты
разработаны, приобретены либо имеют смешанное происхождение.
На сегодняшний день существуют следующие основные стратегии
внедрения системы.
1. Параллельная стратегия. При этой стратегии одновременно работают
старая (ручная) и новая система, и их выходные документы сравниваются. Если
они согласуются длительное время, осуществляется переход на новую систему.
2. «Скачок». При такой стратегии происходит моментальный переход на
работу с новой системой. Эта стратегия привлекательна, но не рекомендуется.
3. «Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически все
предприятия применяют эту тактику сегодня
65
4. «Узкое место». «Узкое место» - это малая часть производственного
процесса. При использовании подхода «узкое место» план внедрения
выполняется только для «узкого места» и для людей, работающих в нем.
Точность данных повышается только для изделий в этом «узком месте";
переподготовка - только для людей, работающих в нем, анализ эффект - затрат
делается только для него и т.д.
В качестве стратегии внедрения ИС был выбран пилотный проект. Данная
стратегия внедрения информационной системы была выбрана, так как при ней
автоматизируется ограниченное число процессов и поэтому риски сведены к
минимуму.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В процессе жизненного цикла разрабатываемой информационной системы
всегда существует вероятность возникновения различного рода рисков,
влияющих, как и на процесс разработки, так и на функционирование школы.
Рассмотрим ожидаемые риски по этапам жизненного цикла подробнее:
Этапы разработки и внедрения.
o Риск нарушения методологии ведения проекта. Причиной
возникновения данного риска может служить необдуманное описание и
утверждение документов, содержащих информацию о состоянии проекта.
Меры предотвращения этому может послужить:
четкое определение прав и обязанностей рабочей группы;
обучение рабочей группы и ключевых пользователей;
документирование и согласование технических условий проекта;
документальное подтверждение вносимых изменений в проект;
o Риск ведения проекта:
неправильное определение рамок и масштабов проекта;
проектирование ошибочных функций и интерфейсов будущей
системы;
66
выбор неправильных технологий и методов решения поставленных
задач;
несоблюдение требований при проектирование будущей системы
или постоянное изменение требований.
В качестве мер предотвращения обозначенных выше моментом можно
назвать:
обеспечение стабильности границ проекта, определенных на
начальном этапе;
качественное планирование работ;
обеспечение проекта необходимыми ресурсами;
обязательное утверждение и согласование по проектным решениям;
дополнительный анализ функций и целей проекта, тщательная
формулировка концепции;
o Риск неверного планирования:
плохая проработка плана внедрения системы;
срыв сроков выполнения;
Мерами предотвращения данных обстоятельств может служить
следующее:
укомплектование проектной команды наиболее талантливыми и
квалифицированными проектировщиками;
распределение работ соответственно способностям членов
проектной команды;
документирование всех работ на этапе проектирования и
обеспечение доступности данных для всех участников проекта;
o Технический и программный риски вызывают:
частичную или полную приостановку этапа разработки из-за
ошибок в используемом программном обеспечении;
частичная или полная потеря программного кода;
контрольный пример не учитывает всех особенностей системы, то
есть недостаточно проработан;
документация по системе не включает в себя подробного описания
всего функционала системы.
67
Этого можно избежать следующим образом:
использовать лицензионного программное обеспечение;
производить регулярное резервное копирование данных;
проводить многократные проверки и прогоны работоспособности
системы для выявления малейших неисправностей в ходе работы;
проверка документации перед передачей системы в эксплуатацию.
Этапы эксплуатации:
o Риск персонала;
трудности с обучением персонала из-за нежелания работать с новой
системой;
отсутствие поддержки внедрения ИС со стороны отдельных
ключевых участников проекта;
неучастие руководителей высшего звена в проекте;
нарушение информационной безопасности в процессе работы
системы.
Этого можно избежать, путем реализации следующих идей:
проведение обучения персонала работы с системой;
составление плана внедрения ИС;
доведение до персонала смысла внедрения автоматизированной
системы;
активное вовлечение высшего руководства;
организация системы поощрений использующего систему
персонала заказчика.
o Технический риск:
потеря данных при внедрении ИС;
возможный отказ технического оборудования при внедрении ИС;
ошибки в программе вызывающие простой системы;
невозможность осуществления требуемых действия, «зависание»
программы;
использование вредоносных программ (вирусы, черви, трояны,
логические бомбы), использование в корыстных целях найденных ошибок;
68
приостановка деятельности третьего лица (например, провайдера
Интернет услуг);
Мерами предупреждения этого служит:
использование пилотного, поэтапного -подхода к организации
внедрения;
тщательное тестирование и выявление ошибок на этапе разработки;
устранять в кратчайшие сроки ошибки;
наличие альтернативных средств доступа в Интернет или других
способов передачи данных;
обязательное утверждение любых изменений системы.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для обеспечения информационной безопасности и защиты информации
необходимо реализовывать следующие меры обеспечения информационной
безопасности:
Законодательные (законы, нормативные акты и т.д.);
Административные (действия общего характера, предпринимаемые
руководством);
Процедурные (конкретные меры безопасности, принимаемые
сотрудниками);
Программно-технические.
В ООО «Золотой век» используются следующие законодательные и
нормативно-технические акты в области информационной безопасности:
Закон «Об информации, информатизации и защите информации»;
Закон «О государственной тайне»
статьи Уголовного кодекса РФ (глава 28: статья 272 «Неправомерный
доступ к компьютерной информации», статья 273 «Создание,
использование и распространение вредоносных программ для ЭВМ»,
статья 274 «Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их
сети»).