63
этапы), а также для случаев "быстрой разработки" (Fast Track) или
"облегченного подхода", которые будут оптимальны в малых проектах.
• Rational Unified Process (RUP) включает в себя итеративную модель
разработки, имеющую четыре фазы: старт, анализ, создание и использование.
Все эти фазы могут быть разделены на этапы (итерации), по итогу которых
имеется версия для внутреннего или внешнего использования. Реализация
четырех основных фазы считается циклом разработки, и любой такой цикл
завершается созданием версии системы. В случае, если работа над проектом не
прекращается и после этого, полученный продукт продолжает оптимизироваться
и снова проходит те же фазы. Суть реализации в рамках RUP - это разработка и
сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) похож на RUP, так же имеет
четыре фазы: исследование, построение, создание, стабилизация, является
итерационным, включает в себя применение объектно-ориентированного
моделирования. MSF в отличии от RUP сильнее ориентирован на создание
бизнес-приложений.
• Extreme Programming (XP). Экстремальное программирование
(самая молодая среди остальных методологий) было реализовано в 1996 году. В
основе методологии лежит командная работа, четкая коммуникация между
исполнителем и заказчиком в течение всего срока проекта, а сама разработка
реализуется методом последовательной доработки прототипов.
• Стандарт ISO/IEC серии 15288.
В процессе подбора стандарта главным фактором становится полноценное
и подробное описание работ на этапах и стадиях разработки АИС.
Стандарт ISO/IEC 12207 не имеет полноценного описания работ на этапах
и стадиях создания АС.
Стандарт CDM применяется в проектах с Oracle технологиями, а в данном
проекте они не используются.
Стандарт MSF, исходя из описанного ранее, чаще всего ориентирован на
создание бизнес-приложений.
64
Стандарт XP относится к командной работе. В данном проекте
применяется ГОСТ 34.601-90, поскольку он включает описание работ на всех
этапах создания АС.
Главные этапы разработки ИС:
1. Подготовка требований к системе;
2. Подготовка концепции;
3. Написание ТЗ;
4. Подготовка проекта;
5. Создание документов;
6. Применение.
На стадии «Выведение требований к системе» делаются следующие
работы:
• Обследуется объект;
• Формируются требования пользователя;
• Обосновывается необходимость разработки.
В данном этапе задействованы следующие участники: IT-менеджер,
начальник отдела производства. После реализации всех задач составляется отчет
о проделанной работе – описание объекта автоматизации, требований к системе,
выражение затрат на создание, введение в эксплуатацию и поддержку,
ожидаемый эффект от внедрения и требуемые условия для нормальной работы
системы.
После выполнения этапа «Выведение требований к системе» создается
вариант концепции. Разрабатывают несколько вариантов концепции и плана
реализации, оценивают ресурсы, необходимые на реализацию ИС и ее
нормальную работу, оценивают недостатки и достоинства каждого метода,
сопоставляют требования пользователей и функциональности возможной
системы.
На этапе «Создание концепции» участвует только IT-менеджер. После
того, как работа выполнена, выбирается наиболее удачный из всех подходящих
вариантов, который полностью удовлетворяет всем требованиям.
65
После этапа «Создание концепции» составляется ТЗ проекта
автоматизации. По его завершению важно его утвердить и согласовать. На
данном этапе участвуют: IT-менеджер и начальник отдела делопроизводства. По
итогам данный пункт может определять - функции ИС и подсистем, состав
отдельных и комплексных задач, концепцию информационной базы, состав
системы управления БД, функции и параметры программных средств.
После утверждения ТЗ идет разработка проектного решения. IT-менеджер
и программист разрабатывают логическую и физическую модель БД, а также
определяют общую организацию данных.
После завершения этапа «Составление технического проекта» IT-
менеджер и программист оформляют рабочую документацию, которая включает:
технические и программные требования, руководство пользователя. После
завершения всех работ и написания документации остаётся только внедрить
систему.
Этап внедрения включает в себя: подготовку объекта автоматизации,
обучение сотрудников, проведение строительно–монтажных работ,
пусконаладочных работ, проведение испытаний, опытная эксплуатация и
приемочные испытания. В этом этапе участвуют: IT-менеджер, системный
администратор, начальник делопроизводства. После этого происходит анализ
испытаний ИС, проверка на соответствие ТЗ, устраняются неполадки или
подписываются все акты.
На этапе эксплуатации системы производится ее эксплуатация.
Для разрабатываемого проекта наиболее подойдет каскадная модель для
разработки приложения из-за возможности контроля промежуточных фаз.
Особое внимание всегда уделяется начальным этапам разработки –
проектированию и анализу, где все технические решения проверяются и
обосновываются посредством представления прототипов.
Стандартная каскадная модель, несмотря на последние негативные
отзывы, исправно помогала специалистам по программному инжинирингу много
лет. Понимание ее сильных и слабых сторон только улучшает оценочный анализ
66
других, чаще более эффективных моделей ЖЦ, которые также основаны на
данной модели.
Сама каскадная модель имеет множество преимуществ, но при условии
использования ее в проекте, приемлемом для нее. Ниже представлены ее
преимущества:
• Модель хорошо знакома потребителям, не имевшим никакого
отношения к созданию и эксплуатации программ, а также конечным
пользователям (часто используется другими компаниями для отслеживания
проектов, которые не связана с разработкой ПО);
• Она лучше справляется с трудностями и отлично срабатывает в тех
проектах, где все достаточно понятно, но трудноразрешимо;
• Она очень доступна для понимания, т.к. преследует простую цель –
выполнение необходимых действий;
• Она проста и удобно в использовании, т.к. процесс разработки идет
поэтапно.
Но в случае, если каскадная модель используется в проекте, не
предназначенном для нее, проявляются следующие ее недостатки:
• Основа модели – линейная последовательная структура, и в результате
попытки вернуться назад на одну-две фазы для исправления проблемы или
недостатка приходится жертвовать временем и срывать график работ и затрат;
• Она не может предотвращать итерация между фазами, которые очень
часто встречаются при создании ПО, поскольку сама модель строиться согласно
циклам аппаратного инжиниринга;
• Она не показывает главное свойство разработки ПО, которое
направлено на решение задачи. Отдельные фазы связаны определенными
действиями, что часто отличается от привычной работы коллектива или
персонала;
• Она создает ошибочное впечатление о работе с проектом. Указание, что
«35% выполнено» обычно не имеет какого-то смысла для менеджера проектов.
67
Исходя из недостатков каскадной модели, ее применение нужно
ограничивать ситуациями, в которых все требования для их разработки очень
точны и понятны.
Каскадная модель хороша в циклах разработки программного продукта,
где используется фиксированное определение продукта и есть понятные
технические методики.
Спиральная модель особое внимание уделяет начальным этапам
разработки – подготовке стратегии, проектированию и анализу, где все
применяемые технические решения проверяются и обосновываются методом
создания прототипов. Каждый виток спирали означает создание компонента или
версии ПО. В них можно уточнять цели и характеристики проекта, его качество,
а также выражаются работы на следующем витке. Таким образом, углубляются и
конкретизируются детали проекта, и в результате определяется обоснованный
вариант, который и реализуется.
Спиральная модель показывает в себе преимущества каскадной модели.
При этом она также имеет риски, а также имеет процессы поддержки и
менеджмента. Тут также имеется разработка ПО при использовании
прототипирования или быстрой разработки программ при помощи языков
программирования и средств разработки 4-го поколения.
Особые свойства спиральной модели – отказ от закрепления требований и
установки приоритетов пользовательским требованиям; создание
последовательных прототипов, начиная с наиболее высшего; определение и
анализ риска на каждом шаге; оценка результата по итогам каждой итерации и
планирование проведения следующей итерации.
Преимуществами спиральной модели можно назвать:
• Быстрая разработка (получение более раннего результата за счет
прототипа);
• Постоянное присутствие зхаказчика с процессе разработки;
• Разбиение большого проекта на малые части;
• Снижение рисков (более предсказуемое поведение системы).
68
Для нашего проекта больше всего подойдет каскадная модель для
создания приложения, т.к. она имеет возможность контроля промежуточных
значений, а также проект не слишком большой, что может повлиять на
отсутствие ее недостатков.
Затем производится выбор направления внедрения созданной системы.
Сегодня выделяют 4 стратегии внедрения ИС:
• Параллельная стратегия, которая подразумевает замену старой на
новую;
• Скачок – подразумевается резкий переход с одной системы сразу на
другую;
• Опытное использование пилотного проекта – та же тактика скачка,
только к некоторому количеству изделий, при этом очень успешна на малом
участке работы;
• Узкое место – внедрение узкого места план выполняется только для
него самого, и для сотрудников, которые там работают.
В итоге исходя из описаний и условий деятельности фирмы, а также из
характеристик создаваемой системы, в качестве стратегии выбирается «опытное
использование пилотного проекта», что позволяет установить всю систему сразу
же после ее подготовки. При этом прекращается использование ручного учета
данных, что позволяет значительно увеличивать скорость работы сотрудников
фирмы прямо с первого дня использования системы, и в таком случае само
внедрение пройдет безболезненно.
Далее произведем выбор стратегии внедрения разработанной системы. В
настоящий момент выделяется четыре стратегии внедрения информационной
системы:
Параллельная стратегия - для случая, когда старую работающую
систему необходимо заменить новой;
Скачок – эта стратегия подразумевает резкий переход от одной
системы автоматизации к другой;
69
Опытная эксплуатация "пилотного проекта - это тактика "скачка",
но применяемая к ограниченному числу изделий, наиболее успешна в малом
участке деятельности;
Узкое место - при внедрении "узкого места" план внедрения
выполняется только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также
особенностей разрабатываемой информационной системы, в качестве стратегии
внедрения была выбрана стратегия Опытная эксплуатация пилотного проекта,
так как в этом случае внедрение системы произойдет наиболее безболезненно.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект создания ИС взаимоотношений с клиентами, как и все остальные
проекты по созданию ПО, включает множество неопределенных моментов,
которые могут повлечь за собой риски срыва реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо
значительно уменьшат последствия.
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
Можно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот
косвенные риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
70
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений,
точно ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее,
выгода, полученная от осуществления проекта больше, чем затраты на него, что
случится, если ключевые поставщики в силах будут выполнить свои
обязательства и т.п.);
2) Технические риски:
• Область действия проекта (могут ли меняться критерии
правильного завершения проекта, требования понятны и стабильны, область
действия четко фиксирована или будет расширяться в будущем и т.п.);
• Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 2.1).
Таблица 2.1
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия в
проекте
71
Заказ
Неформализуемая задача
(невозможно автоматизировать
те или иные бизнес-процессы
или стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и предложить
комплекс мероприятий по их
реорганизации.
Проектирование
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов решения
поставленных задач;
- несоблюдение требований
заказчика при проектирование
будущей системы или
постоянное изменение
требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Заключить договор со
специализированной
организацией на выполнение
ею этих работ.
Недостаточно опыта у
персонала заказчика, который
будет эксплуатировать систему
Предоставить заказчику услуги
собственного специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность действий
персонала исполнителя и
сотрудников предметных
областей
- проведение обучения
персонала заказчика работы с
системой;
- составление плана внедрения
ИС
Кроме того, в процессе эксплуатации и сопровождения разработанной ИС
могут возникнуть:
технические риски;
риски персонала.
Причинами технических рисков становятся:
72
• Использование вредоносных программ (логические бомбы, вирусы,
трояны, черви, шифровальщики), активированные в корыстных целях внутри
найденных ошибок (дыр) в ПО,
• Перехват данных по сетям связи, воровство данных;
• Неправильная эксплуатация оборудования;
• Проблемы в работе третьего лица (к примеру, провайдера Интернет
услуг), что влечет за собой недоступность передачи отчетов из филиалов и
контроля работы филиалов;
• Расхождение функциональных возможностей системы текущим
бизнес-процессам в комплекс задач ввиду проведенных реорганизационных
изменений.
Минимизировать данные обстоятельства можно, соблюдая некоторые
моменты:
• Подробное тестирование и выявление ошибок на этапе создания
проекта;
• Устранение всех недочетов и ошибок в минимальные сроки силами
прошедших подготовку на этапе внедрения технических специалистов;
• Сам администратор сети обязан следить за безопасностью данных,
применять и вовремя обновлять антивирусное ПО, грамотно настроить FireWall,
разделяющий локальную и внешнюю сеть, давать работникам компании
возможность работы только с той информацией, которая им нужна для
реализации своих служебных обязанностей;
• Разделение клиентского и серверного оборудования, а также
привлечение обученного работе с системой опытного персонала;
• Доступность альтернативных средств выхода в Интернет или
наличие других способов отправки информации;
• Запись и фиксирование всех технических условий и их утверждение
со всеми основными участниками проекта;
• Обязательное утверждение проведенных изменений.
Факторами реализации риска персонала становится такие обстоятельства,
как: