56
Проектирование
Реализация
Тестирование
Версия 1
Версия 2
Версия 3
Разработка
требований
Ввод в действие
прототипов системы
Рис. 2.3 Спиральная модель ЖЦ ИС
В ранних проектах достаточно простых ИС каждое приложение
представляло собой единый, функционально и информационно независимый
блок. Для разработки такого типа приложений эффективным оказался каскадный
способ. Каждый этап завершался после полного выполнения и документального
оформления всех предусмотренных работ.
Каскадный подход хорошо зарекомендовал себя при создании
относительно простых ИС, когда в самом начале проекта можно очень точно и
обширно сформулировать нужные требования к системе. Главным недостатком
такого подходя можно назвать то, что процесс реального создания системы не
может полностью уложится в такую жесткую схему, постоянно есть потребность
в возвращении к предыдущим этапам и просмотре или изменении ранее принятых
решений. В итоге реальный процесс разработки ИС оказывается похож на
поэтапную модель с промежуточным контролем.
Выделяют следующие положительные стороны использования каскадного
подхода:
• Каждый этап включает в себя законченный набор проектной
документации, отвечающий критериям согласованности и полноты;
• Реализуемые в логической последовательности работы дают
возможность планировать сроки завершения всех работ и подсчитывать затраты.
Цикличная модель ЖЦ создавалась для преодоления вышеперечисленных
проблем. На этапах анализа и проектирования степень создания технических
решений и удовлетворенность потребностей заказчика оценивалась методикой
создания прототипов. Каждый цикл характеризовал создание работоспособного
57
фрагмента или версии программы. Такой подход позволял уточнить требования,
цели и параметры проекта, оценить качество разработки, выделить работы
следующего цикла. Таким образом, углубляются и оговариваются детали проекта,
и в результате применяется обоснованный вариант, удовлетворяющий всем
требованиям заказчика, который затем уже доводится до финальной реализации.
Но и такая схема не даст возможности оперативно учитывать возникающие
доработки и изменения требований к данной системе. Согласование параметров
разработки с пользователями делается только в отдельных точках, планируемых
после завершения некоторого объема работ, а общие требования к ИС отражены
в техническом задании на все время ее создания. Поэтому пользователи часто
получают систему, которая не полностью удовлетворяет их реальным
потребностям.
Итеративная разработка показывает объективно существующий цикл
разработки сложных систем. Она дает возможность переходить на следующий
этап, не дожидаясь окончательного завершения работы на текущем этапе и
решить главную задачу – оперативнее представить пользователям
работоспособный продукт, тем самым, заранее начиная процесс уточнения
корректировки требований.
Главная проблема спирального цикла является определение момента
перехода на другой этап. Для решения данной проблемы внедряются временные
ограничения на все этапы жизненного цикла, и переход производится в
соответствии с планом, даже если работы по прошлому этапу еще не завершены.
Планирование производится на основе статистических сведений, полученных при
проведении запуска других проектов, а также из личного опыта разработчиков.
Распространены несколько стандартов, описывающих жизненный цикл
информационной системы:
• ГОСТ 34.601-90 – стандарт распространяется на
автоматизированные системы, используемые в различных видах деятельности
(исследование, проектирование, управление и т.п.), включая их сочетания,
создаваемые в организациях. Стандарт устанавливает стадии и этапы создания
автоматизированной системы.
58
• ISO 12207 – стандарт применяется при приобретении систем,
программных продуктов и оказании соответствующих услуг (внедрение,
сопровождение). А также при поставке, разработке, эксплуатации и
сопровождении программных продуктов и программных компонентов
программно-аппаратных средств как в самой организации, так и вне нее.
• ISO 15288 – стандарт обеспечивает общие основы процессов,
составляющих жизненной цикл систем, созданных человеком. Этот жизненный
цикл охватывает концепции идей вплоть до снятия системы с эксплуатации. Он
обеспечивает процессы для приобретения и поставки системы.
• RUP (Rational Unified Process – рациональный унифицированный
процесс) – это методология разработки программного обеспечения, созданная и
распространяемая корпорацией Rational Software (www.rational.com). Она
описывает упорядоченный подход к распределению задач и обязанностей в
организации-разработчике [12].
• XP (eXtreme Programming) – методология содержит совершенно
иные базовые принципы, нежели RUP. Основными чертами являются
определение точных кратковременных планов (как правило, недельных),
постоянное перепланирование, тесное общение с заказчиком. Эта методология
больше подходит для полуисследовательских и инновационных проектов [13].
• MSF (Microsoft Solutions Framework – методология создания
программных решений) – В модели процессов приводится общее описание
организации работ над проектом по разработке и внедрению ИТ-решений.
Предлагаемая схема достаточно гибка и может применяться к самым разным
проектам в области информационных технологий. В версии 3.1 концепция была
расширена и теперь охватывает практически весь цикл создания решений –
начиная с их обсуждения и заканчивая внедрением [11].
• COBIT (Control Objectives for Information and Related Technology –
цели контроля для информационных и смежных технологий) – основная идея
стандарта COBIT выражается следующим образом: все ресурсы информационной
системы должны управляться набором естественно сгруппированных процессов
для обеспечения компании необходимой и надежной информацией [14].
59
• Oracle CDM (Custom Development Method – методика разработки ИС
под заказ) – позволяет стандартизировать процесс создания приложений. CDM
охватывает полный жизненный цикл разработки приложений, описывая
последовательность и взаимную зависимость задач, решаемых в процессе
разработки.
1 Для разработки системы управленческого учета будем использовать
стандарт ISO 12207-99, как наиболее подходящий для данного случая.
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Цель каждого вида деятельности - это выполнение одной или нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системы. На данном этапе
определяется потребность заказчика в информационной системе, происходит
выбор поставщика / разработчика и непосредственно управление заказом вплоть
до приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается
с подписания договора на поставку системы, далее определяются процедуры и
ресурсы, необходимые для обеспечения выполнения проекта. И заканчивается
поставкой готовой системы и подписанием актов выполненных работ(услуг).
За процесс разработки отвечает организация разработчик. Процесс
включает в себя работы по анализу требований, проектированию,
программированию, сборке, тестированию и вводу в действия программного
продукта.
60
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала,
ответственного за сопровождение программного продукта. Этот процесс
реализуется при модификациях программного продукта и документации к нему,
вызванных изменениями в связи с улучшением или устранением ошибок. Целью
процесса является изменение существующего программного продукта при
сохранении его целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета продаж
• Установка клиентских приложений системы учета продаж
61
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
Для рассматриваемого в данном дипломном проекте наиболее подходит
спиральная модель жизненного цикла информационной системы, так как:
• Разработка имеет небольшой объем;
• Требования к системе формализованы;
• Изменения функциональности не планируются.
В качестве стратегии внедрения ИС был выбран «Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться в
применимости и эффективности предлагаемой системы до окончательного
внедрения, обучить сотрудников компании работе с данной системой, а также
определить и спланировать организационные и технические мероприятия на этапе
промышленного внедрения. Пилотный проект позволяет уменьшить затраты и
ускорить полномасштабное внедрение.
62
Выбранная стратегия внедрения информационной системы на основании
того, что она наиболее часто используется российскими организациями. Этот
подход считается наиболее надежным и снижет риски.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Реализация разных сложных проектов, а особенно проект разработки
программного обеспечения, содержит в себе много неопределенных моментов,
которые могут тянуть за собой много рисков реализации проекта.
Раннее выявление рисков и разработка мер полностью предотвращающих
их возникновение или хотя бы снижающих их последствия входит в понятие
управление рисками.
На данный момент существует три основных стратегии управления
рисками:
• Избегание рисков – проект реализуется таким образом, чтобы
исключить возможность возникновения рисков;
• Делегирование рисков – проект реализуется таким образом, чтобы
переложить риски на третью сторону (заказчика, банки, вендора и т.п.);
• Принятие рисков – риски признаются в качестве неизбежной
составляющей проекта, проводится постоянный мониторинг симптомов их
наступления, постоянно корректируется план действий в случае наступления
рисков.
Различают две основные категории рисков – прямые и опосредованные. На
прямые риски проектная команда может каким-то образом повлиять, а
опосредованные риски команда контролировать не может в принципе.
Риски можно разделить на отдельные основные виды.
Ресурсные риски:
• Организация (делала ли организация ранее проекты такого масштаба,
есть ли формальный процесс создания ПО и т.п.);
• Инвестиции (достаточно ли денежных средств для развития проекта,
указана ли стоимость проекта или она еще находится в процессе обсуждения,
верно ли проведена оценка затрат и т.п.);
63
• Коллектив (хватает ли людей для выполнения проекта, имеют ли они
необходимые навыки и опыт, могли ли они участвовать в других проектах вместе
раньше и т.п.);
• Время (адекватен ли план проекта, как важна дата завершения
проекта и т.п.);
• Бизнес (что случится, если конкурент представит на рынке
аналогичный товар первым, прибыль, полученная от реализации проекта будет
выше, чем затраты на него, что случится, если основные поставщики не будут
соблюдать свои обязательства и т.п.).
Технические риски:
• Рамки действия проекта (могут ли быть отражены критерии
успешного окончания проекта, все требования конечны и отлично поняты, рамки
работы жестко фиксированы или поддерживают расширение в будущем и т.п.);
• Технологии (устойчива ли используемая технология или она только
недавно создана и т.п.);
• Внешние зависимости (связан ли проект ос другими параллельными
проектами, зависит ли успех проекта от сторонних поставщиков продуктов или
технологий и т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 2.1).
Таблица 2.1
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия в
проекте
Заказ
Неформализуемая задача
(невозможно автоматизировать
те или иные бизнес-процессы
или стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и предложить
комплекс мероприятий по их
реорганизации.
64
Проектирование
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов решения
поставленных задач;
- несоблюдение требований
заказчика при проектирование
будущей системы или
постоянное изменение
требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Заключить договор со
специализированной
организацией на выполнение
ею этих работ.
Недостаточно опыта у
персонала заказчика, который
будет эксплуатировать систему
Предоставить заказчику услуги
собственного специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность действий
персонала исполнителя и
сотрудников предметных
областей
- проведение обучения
персонала заказчика работы с
системой;
- составление плана внедрения
ИС
Также в процессе использования и сопровождения созданной ИС
возникают:
• технические риски;
• риски персонала.
Причинами технических рисков становятся:
• Ошибки в ПО, вызывающие остановку системы;
• Недоступность реализации требуемых действия, «зависание»
программы;
65
• Применение вредоносных программ (логические бомбы, вирусы,
трояны, черви, шифровальщики), активированные в корыстных целях внутри
найденных ошибок (дыр) в ПО,
• Перехват данных по сетям связи, воровство данных;
• Неправильная эксплуатация оборудования;
• Проблемы в работе третьего лица (к примеру, провайдера Интернет
услуг), что влечет за собой недоступность передачи отчетов из филиалов и
контроля работы филиалов;
• Расхождение функциональных возможностей системы текущим
бизнес-процессам в комплекс задач ввиду проведенных реорганизационных
изменений.
Минимизировать данные обстоятельства можно, соблюдая некоторые
моменты:
• Подробное тестирование и выявление ошибок на этапе создания
проекта;
• Устранение всех недочетов и ошибок в минимальные сроки силами
прошедших подготовку на этапе внедрения технических специалистов;
• Сам администратор сети обязан следить за безопасностью данных,
применять и вовремя обновлять антивирусное ПО, грамотно настроить FireWall,
разделяющий локальную и внешнюю сеть, давать работникам компании
возможность работы только с той информацией, которая им нужна для
реализации своих служебных обязанностей;
• Разделение клиентского и серверного оборудования, а также
привлечение обученного работе с системой опытного персонала;
• Доступность альтернативных средств выхода в Интернет или
наличие других способов отправки информации;
• Запись и фиксирование всех технических условий и их утверждение
со всеми основными участниками проекта;
• Обязательное утверждение проведенных изменений.
Факторами реализации риска персонала становится такие обстоятельства,
как: