61
Сегодня известны и активно применяются такие модели жизненного
цикла, как:
• Каскадная модель, предусматривающая последовательное
выполнение всех этапов проекта в заранее определенной последовательности.
Переход на другой этап говорит о полном завершении всех работ на текущем
этапе.
• Поэтапная модель с дополнительным контролем. Создание ИС
построено на итерациях с циклами обратной связи между этапами. Поэтапные
корректировки дают возможность отследить реально существующее взаимные
влияния результатов разработки на разных этапах; а время жизни любого этапа
продлевается на всю продолжительность разработки.
• Спиральная модель. Каждый виток спирали включает в себя
создание очередной версии продукта, определяются и дорабатываются
требования проекта, выражается его качество и устанавливаются работы
следующего витка. Главное внимание уделяется первым этапам разработки —
проектированию и анализу, где необходимость создания тех или иных
технических решений заранее обосновывается и проверяется методом создания
прототипов и макетов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда изначально можно очень точно и полно указать
все требования к системе. Главным недостатком подобного подхода становится
то, что реальный процесс разработки системы не сможет полностью уложится в
такую сложную схему, поскольку всегда будет потребность в возврате к уже
завершенным этапам для уточнения или пересмотра ранее определенных
решений. Поэтому реальный процесс разработки ИС соответствует поэтапной
модели с поэтапным контролем.
Любая из стадий разработки системы включает в себя реализацию
некоторого объема работ, которые отображаются в виде процессов ЖЦ. Процесс
описывается в виде совокупности взаимосвязанных действий, изменяющих
исходные данные в выходные. Описание каждого отдельного процесса состоит
из перечня решаемых задач, заданных данных и результатов.
62
Есть целый ряд стандартов, определяющих ЖЦ ПО, а иногда даже и
процессы разработки.
Среди наиболее известных стандартов можно выделить:
• ГОСТ 34.601-90 - распространяется на АИС и отражает в себе
стадии и этапы их создания. Также в нем есть описание содержания работ на
всех этапах. Стадии и этапы работы, показанные в стандарте, зачастую
соответствуют каскадной модели ЖЦ.
• ISO/IEC 12207:1995 - стандарт на процессы и реализацию ЖЦ.
Используется во всех видах заказного ПО. Стандарт не включает в себя
описания стадий, фаз и этапов.
• Custom Development Method (CDM) по разработке прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных
документов, рассчитанных на применение в проектах совместно с Oracle.
Применяется CDM для типовой модели ЖЦ (имеются все работы/задачи и
этапы), а также в проектах с "быстрой разработкой" (Fast Track) или
"облегченным подходом", которые являются самыми доступными в малых
проектах.
• Rational Unified Process (RUP) включает в себя итеративную модель
разработки, имеющую четыре фазы: старт, анализ, создание и использование.
Все эти фазы могут быть разделены на этапы (итерации), по итогу которых
имеется версия для внутреннего или внешнего использования. Реализация
четырех основных фазы считается циклом разработки, и любой такой цикл
завершается созданием версии системы. В случае, если работа над проектом не
прекращается и после этого, полученный продукт продолжает оптимизироваться
и снова проходит те же фазы. Суть реализации в рамках RUP - это разработка и
сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) похож на RUP, так же имеет
четыре фазы: исследование, построение, создание, стабилизация, является
итерационным, включает в себя применение объектно-ориентированного
моделирования. MSF в отличии от RUP в сильнее ориентирован на создание
бизнес-приложений.
63
• Extreme Programming (XP). Экстремальное программирование
(самая молодая среди остальных методологий) реализовалось в 1996 году. В
основе методологии состоит командная работа, четкая коммуникация между
исполнителем и заказчиком за все время ведения проекта, а сама разработка
построена на методах последовательной доработки прототипов.
• Стандарт ISO/IEC серии 15288.
В связи с небольшим объемом разрабатываемой автоматизированной
системы, ее назначением, характером необходимо использовать именно этот
стандарт - ISO/IEC серии 15288. Для создаваемой системы актуален следующий
перечень стадий реализации проекта
• Формирование концепции
• Разработка
• Реализация
• Эксплуатация
• Поддержка
• Снятие с эксплуатации
Задача внедрения информационной системы включает в себя создание
(адаптацию) и запуск в продуктивную эксплуатацию элементов
информационной системы. Так как разработка информационной системы будет
осуществляться своими силами, то и внедрение будет происходить без
привлечения посторонних специалистов.
Этап внедрения планируется разбить на следующие подэтапы:
1. Предпроектное рассмотрение. В ходе рассмотрения находятся основные
информационные потоки в компании и проверяется база основной нормативно-
справочной документации. Базовыми требованием в таком случае становятся
наличие всех нужных для работы корпоративных ИС справочников и
классификаторов, а также соответствие принципов их реализации с
требованиями системы. В процессе исполнения этапа важно проанализировать
на полноту все корпоративные стандарты учета и отчетности. Этот этап
включает также проведение диагностирования проблем, которые могут иметь
место при внедрении, а также согласовывается и выполняется настройка
справочников и классификаторов системы в строгом соответствии с указанными
64
требованиями. В случае необходимости принимается решение о перемене
внедренных практик учета или функциональных моделей. По итогам этапа
составляется подписываемый всеми участниками проекта внедрения документ,
описывающий все установленные недостатки и намечает пути их решения.
2. Реализация информационно-функциональной модели работы
предприятия, оптимизация и описание процессов, которые подлежат
автоматизации. Моделирование должно осуществляться хорошо обученными
сотрудниками исследуемой компании с привлечением опытных консультантов и
с привязкой построенной модели к стандартам бизнеса и к только что
спроектированной системе.
3. Адаптация ИС внутри компании. В ходе этапа реализуется настройка
системы тестирование ключевых модулей и функций группой внедрения. Этот
этап также требует наличия корпоративных стандартов, поскольку именно они
составляют основу настроек системы.
4. Опытная эксплуатация ИС. Реализуется для тестирования четкого
соответствия функциональности, полученной в процессе отладки системы,
требованиям компании. На этом этапе присутствует двойной ввод данных в
новую и старую системы. В процессе опытной эксплуатации: создаются
стандартные отчеты (при помощи ИС и стандартными способами) и реализуется
проверка данных; система шаг за шагом вводится в эксплуатацию по каждому
участку учета; документируются инструкции по обслуживанию рабочих мест и
дополняются должностные инструкции всех членов учетного процесса. В
отдельных подразделениях компании в систему добавляются фактические
данные (в минимальном объеме) и последовательно проверяются бизнес—
функции при помощи моделирования реальных ситуаций работы компании (в
максимально приближенных к действительности условиях). Оттачивается
слаженная работа подразделений на базе тестовых пилотных примеров.
Конечные пользователи (сотрудники IT-отдела) проходят обучение с
настроенной системой только на своих рабочих местах. По завершению
обучения конечных пользователей реализуется встроенный пилотный пример и
полностью моделируется работа компании. Основываясь на результатах
65
реализации пилотного примера руководство компании принимает решение о
переводе ИС в повседневную эксплуатацию.
Этап эксплуатации подразумевает под собой непосредственное
использование информационной системы для выполнения ею тех функций, для
которых она предназначена.
Для внедрения системы выбираем стратегию Пилотный проект.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две
группы: плановые и неплановые.
К плановым работам будут относятся такие работы, как:
• инсталляция программного обеспечения;
• базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
• устранение недостатков в конфигурации системы;
• проверка надежности работы системы;
• окончательная донастройка.
Данные работы будут выполнять специалисты отдела ИТ.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На всех этапах жизненного цикла информационной системы встречаются
различные риски. Они могут приводить как к серьезным неустойкам во времени
разработки системы, так и в ее функциональных качествах [3].
Ниже представлены риски в зависимости от этапов жизненного цикла, а
также приведены методы их предотвращения.
Этап подготовки проекта
Риск персонала
Риски:
• Набор необученного персонала к выполнению проекта;
• Набор в состав разработчиков «случайных» сотрудников, а не
главных участников автоматизируемых бизнес процессов;
• Неимение выработанной стратегии автоматизации;
• Отсутствие общих целей и задач проекта;
66
• Отсутствие мотивационных поощрений сотрудникам;
• Нежелание персонала участвовать в проекте;
• Хаотичный план ведения работ.
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и консультантов;
• Четкая формулировка целей и задач;
• Выработка единой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки проекта.
Риск ведения проекта
Риски:
• Ошибочное определение рамок и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методов решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
• Поддержка стабильности границ проекта, которые выделяются еще
на начальном этапе и неизменны вплоть до финала проекта;
• Точное планирование выполняемых работ;
• Включение в проект необходимых ресурсов;
• Согласованное и утвержденное проектное решение;
• Высокий порог принятия изменений.
Риск неверного планирования
Риски:
• Неэффективный план организации разработки системы;
• Несоблюдение сроков выполнения работ по этапам.
Методики предотвращения:
• В начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
• Описание и сохранение всех проведенных работ и открытый доступ
к этим данным для всех участников проекта.
67
Этап разработки
Риск персонала
Риски:
• Увольнение сотрудников, которые отвечают за проведение
разработки;
• Несогласованность действий между участниками проекта из-за
плохой системы коммуникации;
• Ошибочное представление задачи проектирования;
• Набор разработчиком без опыта работы с подобными системами.
Методики предотвращения:
• Грамотный набор сотрудников, участвующих в проекте;
• Реализация четкой системы коммуникации между сотрудниками,
постоянное документирование изменений в системе.
Технические риски
Риски:
• Остановка разработки из-за ошибок в применяемом ПО;
• Пользовательская документация включает в себя описание не всех
функции системы.
Методики предотвращения:
• Работа только с проверенным лицензионным ПО, регулярное
резервное копирование данных;
• Отслеживание полноты сведений во всех документах.
Этап внедрения
Риск персонала
Риски:
• Разрозненность деятельности разработчика и специалистов
предметной области;
• Отсутствие желания у сотрудников использовать новую систему и
связанные с этим трудности их обучения;
• Безучастность руководства.
Методики предотвращения:
68
• Обучение пользователей со стороны заказчика методики работы с
системой;
• Подготовка плана внедрения системы;
• Обоснование важности и нужности автоматизации персоналу;
• Привлечение руководящего персонала в проект и активное
взаимодействие с ним во время проведения всего проекта.
Технические риски
Риски:
• Утрата информации при внедрении системы.
Методики предотвращения:
• Наем квалифицированных сотрудников, имеющих опыт разработки
подобных систем.
Этап эксплуатации и сопровождения
Технические риски
Риски:
• Баги и ошибки ПО, приводящие к невозможности использования
системы;
• Неправильное использование оборудования;
• Отсутствие функциональных возможностей системы из-за
реорганизации предприятия.
Методики предотвращения:
• Функциональное тестирование и исправление ошибок во время
разработки системы;
• Описание в документации всех технических условий, и их
согласование.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе
включает в себя следующие аспекты:
• защита информации непосредственно в информационной системе
от внутренних угроз;
69
• защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.1.
Таблица 2.1
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авторизация»
Модуль «Расчет
стоимости
услуг»
Модуль
«Ввод
данных»
Модуль
«Отчеты»
Сотрудник
Чтение
Нет
Нет
Ограничен
Администратор
системы
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
• использованием программно-аппаратных комплексов защиты от
несанкционированного доступа;
• разработкой и соблюдение политик безопасности;
• использованием антивирусных средств;
• физической защитой помещений с наиболее ценной информацией.
В качестве основного средства защиты от проникновений используется
Система контроля и управления доступом (СКУД) «Elsys».
Также в компании разработана политика безопасности, включающая себя
следующие частные документы:
1. Правила парольной защиты;
2. Правила защиты от вирусов и злонамеренного программного
обеспечения;
3. Требования по контролю за физического доступом;
4. Инструкция по безопасному уничтожению информации на
бумажных и электронных носителях;
5. Требования к безопасности при осуществлении удаленного доступа;
6. Требования резервного копирования важной информации;
7. Требование мониторинга доступа и использования систем, и
ведения журнала доступа;
8. Требования при обращении с носителями данных;
70
9. Требования при регистрации пользователей;
10. Требования по проверке прав пользователей;
11. Требование к процедуре входа в систему (log on);
12. Правила использования системных утилит;
13. Требование распределения ответственности при обеспечении
безопасности;
14. Правила безопасности при выборе персонала;
15. Требования контроля оперативных изменений;
16. Требования к применению криптографических средств защиты
информации;
17. Требования по контролю доступа к исходным текстам программ и
библиотек;
18. Требования контроля вносимых изменений;
19. Ограничения на изменения прикладного ПО.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Рисунок информационной модели приведен на рисунке 2.1.