подтверждение и проверку продукта. Она отражает, что проверка продукта
обсуждается, конкретизируется и планируется еще на ранних стадиях ЖЦ
разработки. План приемки продукта заказчиком пишется на этапе планирования,
а само испытание системы - на фазах разработки и анализа проекта и т.д. Такой
процесс создания планов испытания выделен пунктирной линией между
прямоугольниками V-образной модели
В процессе применения V-образной модели при создании проекта, для
которого она оптимально подходит, реализуется несколько преимуществ:
• Модель придает особое значение придается планированию,
направленному на подтверждения и проверки создаваемого ПО еще на начальных
стадиях его разработки. Этап модульного тестирования подтверждает
правильность детализированного проектирования. Этапы внедрения и проверки
описывают архитектурное проектирование или проектирование на высоком
уровне. Этап проверки системы подтверждает правильность выполнения этапа
требований к продукту и его параметров;
• Модель предусматривает аттестацию и подтверждение всех внешних
и внутренних полученных данных, а не только исходного ПО;
• V-образной модель выполняет определение требований перед
началом разработки проекта системы, а само проектирование ПО проходит перед
созданием компонентов;
• Модель определяет продукты, полученные в результате процесса
разработки, и все полученные данные подвергаются тестированию;
В процессе применения V-образной модели в работе над проектом, для
которого она не совсем подходит и недостаточно приемлема, проявляются ее
недостатки:
• Этой модели непросто справиться с параллельными событиями;
• В ней не учитываются итерации между фазами;
• В ней нет внесенных требований динамических изменений на разных
этапах ЖЦ;
• Проверка требований в ЖЦ реализуется слишком поздно, поэтому
невозможно внести корректировки, не повлияв при этом на сроки выполнения
проекта;
• Модель не включает действия, направленные на анализ рисков.
Как и каскадная модель, V-образная модель также лучше срабатывает
тогда, когда вся информация о требованиях заранее известна.
Общераспространенная модификация V-образной модели, направленная на
преодоление ее недостатков, включает в себя внесение итерационных циклов для
разрешения изменения в требованиях за рамками фазы анализа.
Применение модели эффективно тогда, когда доступными являются
данные о методе разработки решения и технология, а персонал обладает всеми
умениями и опытом в работе с используемой технологией.
Отличительной чертой RAD становится короткое время перехода от
выявления требований до разработки полной системы. Метод базируется на
совокупности итераций эволюционной системы или прототипов, критический
анализ которых утверждается у заказчика. Во время такого анализа составляются
требования к продукту.
Создание каждого внедренного продукта ограничивается четко
выделенным периодом времени, который обычно составляет 60 дней и носит
название «временной блок».
Инкрементная разработка включает в себя процесс частичного создания
всей системы и неторопливого наращивания функциональных возможностей.
Подобный подход дает возможность минимизировать затраты, понесенные до
момента достижения уровня установленной производительности. При помощи
такой модели убыстряется процесс разработки действующей системы. Этому
способствует используемый принцип сочетания из стандартных блоков, который
позволяет обеспечить контроль над процессом внедрения указанных требований.
Спиральная модель включает в себя положительные стороны каскадной
модели. При этом она также включает анализ рисков, может управлять ими, а
также имеет процессы поддержки и менеджмента. В ней также предусмотрено
создание программного продукта при помощи метода прототипирования или
быстрой разработки приложений с применением языков программирования и
средств разработки 4 поколения и выше.
На основании описания моделей разработки выбираем спиральную модель.
Ниже приведено описание основных стандартов жизненного цикла:
ГОСТ 34.601-90 – стандарт распространяется на автоматизированные
системы и определяет стадии и этапы их создания [3]. Также в стандарте
содержится описание состава работ по каждому этапу.
ISO 12207 – стандарт устанавливает общую структуру процессов
жизненного цикла [2]. Так же определяет процессы, работы и задачи, которые
используются: при приобретении системы в целом или отдельного программного
продукта; при оказании программной услуги, а также при поставке, разработке,
эксплуатации и сопровождении программных продуктов.
Oracle CDM (Custom Development Method) - стандарт по разработке
прикладных ИС, детализированный до уровня заготовки проектной
документации. Стандарт применяется при разработке с применением Oracle и
рекомендуется в случае малых проектов.
RUP (Rational Unified Process) – предполагает итеративную модель
разработки согласно четырем фазам: начало, исследование, построение и
внедрение. Каждая фаза может подразделяться на этапы, в результате
выполнения которых выпускается версия для внутреннего или внешнего
использования.
MSF (Microsoft Solution Framework) – стандарт, сходный с RUP. Включает
в себя четыре фазы: анализ, проектирование, разработка и стабилизация. Также
как и RUP предполагает итеративную модель с использованием объектно-
ориентированного моделирования. MSF в отличии от RUP ориентирована более
на разработку бизнес-приложений.
XP (Extreme Programming) – стандарт «экстремальное программирование»
разработан в 1996 года, в его основе лежат следующие принципы: командная
работа, эффективная коммуникация между заказчиком и исполнителем и также
ведение разработок с использованием последовательно дорабатываемых
прототипов.
Для реализации проектного решения, необходимо первоначально выделить
основные этапы жизненного цикла будущей системы. Из всех имеющихся
стандартов, наиболее оптимальным будет ISO 12207 -99. Выбор пал именно на
этот стандарт, в связи со следующими факторами: Во-первых, стандарт четкое не
регламентирует последовательность процессов в каждом этапе, что позволяет
самостоятельно выбирать подходящие для себя процессы. Во-вторых, стандарт
охватывает все этапы более полно, нежели остальные стандарты. В-третьих, ISO
12207-99 не указывает на этапы, а лишь регламентирует их, что позволит
разработчику самостоятельно управлять жизненным циклом.
Стандарт ISO 12207 включает всего 16 процессов, которые объединяются в
3 группы.
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит
выбор поставщика / разработчика и непосредственно управление заказом вплоть
до приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается
с подписания договора на поставку системы, продолжается определением
процедур и ресурсов, необходимых для обеспечения выполнения проекта. И
заканчивается поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс
включает в себя работы по анализу требований, проектированию,
программированию, сборке, тестированию и вводу в действия программного
продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала,
ответственного за сопровождение программного продукта. Этот процесс
реализуется при модификациях программного продукта и документации к нему,
вызванных изменениями в связи с улучшением или устранением ошибок. Целью
процесса является изменение существующего программного продукта при
сохранении его целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета продаж
• Установка клиентских приложений системы учета продаж
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
план проекта. После документального оформления начинается непосредственно
сам процесс разработки. Создается база данных, отчетные формы, пишется
программный код по сбору, обработке и хранению информации, создаются
процедуры фильтрации. После разработки системы, проходит этап тестирования.
По завершению тестирования готовится план эксплуатации и документация для
внедрения, а так же различная пользовательская документация. Процесс будет
происходить следующим образом. Так как в организации уже существует ЛВС и
стабильно функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета продаж, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета продаж
и СУБД. Тестируется работоспособность, проводится демонстрация работы
системы для руководства и персонала. Последней стадией будет проведение
семинаров для сотрудников компании. Необходимо связать всех сотрудников,
отвечающих за обработку документов в единую информационную сеть. Для этого
клиентские приложения будут устанавливаться в четкой последовательности по
определенным отделам.
Этап реализации концепции – есть риск подготовки концепции, которую не
в силах будет реализовать. В концепции важно описать главные функции
создаваемой ИС, выделить основу, и в дальнейшем уже улучшать созданную ИС.
Для минимизации рисков на этапе генерации концепции, нужно явно
понимать свои возможности. Чтобы не переоценить свои силы, важно
подготовить сначала общую концепцию, где уже будут иметься базовые функции
системы. И в рамках продолжения реализации можно увеличивать и некие доп.
функции.
Этап планирования может иметь риск неверной планировки, реализации
завышенных планов проекта, когда фирма не сможет уложиться, что повлечет за
собой рост длительности разработки, его удорожание. К этапу планирования
важно отнестись очень внимательно, контролировать каждый шаг и понимать
реализм результата.
Для уменьшения риска в рамках планирования важно заложить в график
поправки на отдельные задержки в реализации конкретных работ. Так нужно
создать такой гибкий график, который не изменялся бы из-за опережений и
задержек.
Этап создания включает в себя риск того, что создание отдельного модуля
будет связана со сложностями, а некая функция будет мешать ходу работ. В
данном случае важно изначально понять сложный модуль или функцию и
максимально ее упростить, поставить на ее место другую или удалить из проекта
вообще.
Для минимизации риска разработки проблемного модуля, есть ряд
решений: разбить модуль на несколько и решать все задачи в отдельном порядке,
а также можно упростить модуль, если это становится единственным вариантом
минимизации риска.
Этап тестирования включает в себя определение множества ошибок в
программном коде, что ведет к глобальным расходам на доработку и устранение
всех найденных ошибок. Нельзя заранее знать, сколько ошибок обнаружится и
как много времени уйдет на их устранение.
Для уменьшения риска на этапе тестирования важно для данного этапа
оставить больше всего времени, которое суммарно дается на реализацию системы,
т.к. в зависимости от того, насколько грамотно будет создан продукт, будет
зависеть, примет ли заказчик его или же нет.
Этап внедрения часто тоже бывает продолжителен, если заказчик не может
сразу остаться довольным продуктом, да и сами сотрудники компании-заказчика
могут с недоверием отнестись к новому ПО.
Для сокращения рисков в данной ситуации проводят качественное
обучение сотрудников еще до периода эксплуатации, готовят отдел
сопровождения и поддержки, понимают, что может произойти в процессе
эксплуатации и как можно найти верное решению. Иметь возможность ответить
на возникающие вопросы или открыть горячую линию для решения поступающих
проблем.
За эксплуатацию готовой системы, будет отвечать администратор системы.
В его задачу будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.
2. Получение и документирование сведений о возникающих проблемах, их
решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
3. Тестирование системе в эксплуатационной среде, кооперация со службой
сопровождения для устранения возникших проблем и модернизации системы.
4. Поддержка и консультация пользователей.
В соответствии с выбранной моделью основными этапами разработки
будут являться:
Формирование требований
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация пилотного проекта.
Параллельная стратегия не подходит, так как компания не располагает
достаточными ресурсами для ведения учета одновременно в автоматизированном
и ручном вариантах. Стратегия скачка не позволяет плавно перейти на
использование разработки, узкое место больше подходит для использования в
крупных компаниях. Поэтому в качестве стратегии внедрения ИС была выбрана
«Опытная эксплуатация пилотного проекта».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На всех этапах жизненного цикла информационной системы встречаются
различные риски [21]. Они могут приводить как к серьезным неустойкам во
времени разработки системы, так и в ее функциональных качествах.
Ниже представлены риски в зависимости от этапов жизненного цикла, а
также приведены методы их предотвращения [11]:
1. Этап подготовки проекта:
Риск персонала:
• Набор необученного персонала к выполнению проекта;
• Набор в состав разработчиков «случайных» сотрудников, а не
главных участников автоматизируемых бизнес процессов;
• Неимение выработанной стратегии автоматизации№
• Отсутствие общих целей и задач проекта;
• Отсутствие мотивационных поощрений сотрудникам;
• Нежелание персонала участвовать в проекте;
• Хаотичный план ведения работ.
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и консультантов;
• Четкая формулировка целей и задач;
• Выработка единой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки проекта.
Риск ведения проекта
• Ошибочное определение рамок и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методов решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
• Поддержка стабильности границ проекта, которые выделяются еще
на начальном этапе и неизменны вплоть до финала проекта;
• Точное планирование выполняемых работ;
• Включение в проект необходимых ресурсов;
• Согласованное и утвержденное проектное решение;
• Высокий порог принятия изменений.
Риск неверного планирования
• Неэффективный план организации разработки системы;
• Несоблюдение сроков выполнения работ по этапам.
Методики предотвращения:
• В начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
• Описание и сохранение всех проведенных работ и открытый доступ
к этим данным для всех участников проекта.
2. Этап разработки
Риск персонала:
• Увольнение сотрудников, которые отвечают за проведение
разработки;
• Несогласованность действий между участниками проекта из-за
плохой системы коммуникации;