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