Методология Oracle Unified Method

   Данная статья описывает основные концепции методологии Oracle Unified Method 5.5 (далее OUM).

1. О методологии

   Компания Oracle развивает методологию Oracle Unified Method для поддержки всего жизненного цикла информационных технологий на предприятии, включая поддержку внедрения продуктов и технологий Oracle. Данная методология универсальна и явно не привязанна к конкрентым продуктам и технологиям, что даёт возможность её адаптации под другие типы ИТ-проектов (не обязательно Oracle-овые). Она включает набор готовых шаблонов, руководство и структуру работ, а так же содержит программные инструменты для управления рисками, связанными с проектами. OUM включает в себя полный пакет законченных решений, таких как:

• Service Oriented Architecture Suite;
• Requirements-Driven Application Implementation;
• Solution-Driven Application Implementation;
• Software Upgrade;
• Technology Full Lifecycle;
• Business Intelligence (BI) and Enterprise Performance Management (EPM) Implementation;
• Business Intelligence and Analytics Custom Development;
• WebCenter;
• Implement Core Workflow;
• Implement models.

   Данная методология состоит из трёх областей:

• Управление (Manage) - управления программами (Program Management Method, PGM) и проектами (Project Management Method, PJM);
• Представление (Envision) - поддержка ИТ-архитектуры на уровне предприятия, её стратегия развития и управления, а так же выявление и создание специфических проектов;
• Реализация (Implement) - реализация проектов.

   Состоит из 5 фаз проектов:

• Начальная фаза (Inception);
• Проектирование системы (Elaboration);
• Разработка системы (Construction);
• Переход к эксплуатации системы (Transition);
• Эксплуатация системы (Production).

   Каждая фаза может содержать до 15 процессов:

• Управление проектом;
• Бизнес-требования;
• Анализ требований;
• Анализ;
• Проектирование;
• Разработка;
• Тестирование;
• Контроль производительности;
• Техническая архитектура;
• Конвертация и перенос данных;
• Документация;
• Управление изменениями;
• Обучение;
• Переход к эксплуатации;
• Эксплуатация и поддержка.

2. Начальная фаза (Inception)

Начальная фаза включает в себя:

• Анализ стратегических направлений бизнеса заказчика;
• Утверждение, документирование и определение бизнес-требований и рисков проекта, а также расположение их в соответствии с приоритетами.

   Во время этого фазы формируется проектная команда и разрабатывается первоначальный план проекта.

2.1. Цели

• Добиться чёткого понимания того, какой результат должен быть достигнут в ходе проекта и выбрать наиболее подходящее решение или технологию;
• Определить масштабы проекта, по возможности разбить его на составляющие и расположить их в соответствии с приоритетами;
• Определить и измерить основные риски, расположить их в соответствии с их приоритетами, разработать стратегию управления рисками;
• В компании заказчика определить лицо, ответственное за проект внедрения системы (руководитель проекта в организации заказчика);
• Определить пользователей заказчика, которые будут вовлечены в проект во время его разработки и внедрения;
• Разработать первоначальный план проекта;
• Обучить всех участников проекта подходу OUM, объяснить организационное влияние выбора данного подхода, а также определить их роли и ответственность в проекте;
• Сформировать проектную команду специалистов, знакомых с методологией OUM или провести семинар по данной методологии;
• Начать формирование проектной группы разработчиков, которые непосредственно будут заниматься внедрением, а также определить пользователей организации заказчика, которые будут участвовать в тестировании разрабатываемой системы;
• Определить, задокументировать и выделить бизнес-требования заказчика, расположить их в соответствии с их приоритетами;
• Разработать концептуальный прототип, содержащий функциональные требования;
• Разработать первоначальные требования к тестам производительности и системы в общем;
• Разработать набор требований к документации и стратегию документирования;
• Разработать план обучения проектной группы, если требуется.

2.2. Процессы

   В данном разделе описываются основные процессы, входящие в Начальную фазу. В него также включены советы и комментарии по каждому процессу.

2.2.1. Определение бизнес-требований

Результатом работы данного процесса на Начальной фазе должно быть:

• Определение функциональных требований заказчика к разрабатываемой/внедняемой системе;
• Определение нефункциональных требований заказчика к разрабатываемой/внедняемой системе.

   В ходе этого процесса также выделяются детальные алгоритмы, по которым происходит организация бизнес-деятельности заказчика в области, касающейся разрабатываемой/внедняемой системы. Для определения требований проводятся совещания с представителями заказчика (методология «наведения мостов»). В ходе сбора требований используется MoSCoW-метод, который применяется для достижения взаимопонимания между заказчиком и разработчиком. Согласно этому методу все функциональные требования разбиваются по четырем категориям:

• Must have this – необходимые требования, т.е. такие требования, без которых будет невозможно функционирование системы;
• Should have this if at all possible – рекомендуемые требования, т.е. такие требования, которые желательно включить в систему, если это возможно;
• Could have this if it does not affect anything else – важные дополнительные требования, т.е. такие требования, наличие которых не является жизненно важными для функционирования системы;
• Won’t have this time but WOULD like in the future – необязательные требования, т.е. такие требования, наличие которых необязательно в системе, однако при усовершенствовании системы в будущем эти требования могут понадобиться.

2.2.2. Анализ требований

   Во время этого процесса, полученные требования анализируются и разрабатывается детальная модель сценариев использования бизнес-процессов заказчика (use case model), которая затем детализируется до уровня конкретных функций, выполняемых системой для каждого шага бизнес-процесса. Представители организации заказчика должны быть вовлечены в процесс разработки этой модели, т.к. они могут помочь с пониманием требований заказчика.
   Во время Начальной фазы определяются совокупные бизнес-требования заказчика, однако впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность разрабатываемой/внедряемой системы.

2.2.3. Внедрение

   Основная работа по внедрению производится во время фазы Разработки, однако важно показать заказчику понимание бизнес-требований уже на раннем этапе работы, для этого осуществляется моделированием концептуального прототипа системы. Концептуальный прототип — это макет, который содержит функциональные бизнес-требования и может представлять собой презентации, иллюстрирующие пользовательский интерфейс, функциональные возможности приложения и т.п.
   В крупных проектах возможно потребуется создание нескольких прототипов (например, образцы, демонстрирующие работу каждой подсистемы).
   Так же на данной фазе потребуется проработка ключевых технических вопросов для проверки правильности выбора технических решений и выполнимости специальных требований.

2.2.4. Тестирование

   На Начальной фазе определяются требования к тестам (например, форма тестовых отчетов), затем они дополняются и совершенствуются на протяжении всех фаз.

2.2.5. Контроль производительности

   Целью данного процесса является определение, разработка и выполнение шагов по контролю производительности на протяжении всего этапа внедрения решения, чтобы гарантировать соответствие производительности системы и ее компонентов требованиям и ожиданиям заказчика.
   В ходе Начальной фазы необходимо определить требования к производительности критических бизнес-транзакций и систему показателей контроля производительности. Для этого проводится совещание с представителями организации заказчика.

2.2.6. Техническая архитектура

   В ходе этого процесса происходит построение технической архитектуры системы, а также

• Определяются ключевые параметры конфигурации, касающиеся архитектуры;
• Определяются требования к аппаратному, программному обеспечению и сетям, необходимые для стабильной работы с приемлемой производительностью.

   Техническая архитектура системы должна согласоваться со стратегическим направлением развития бизнеса заказчика и архитектурой в рамках предприятия. На Начальной фазе этот процесс включает в себя проведение совещания с представителями организации заказчика, чтобы познакомить его с принципами работы эталонной архитектуры и собрать информацию относительно требований к разрабатываемой архитектуре и ее компонентам (требований по интеграционной архитектуре, составлению отчетов, системам создания резервных копий и восстановления, системам безопасности и т.п.).

2.2.7. Конвертация и перенос данных

   Этот процесс охватывает задачи, связанные с переносом данных из существующих систем в разрабатываемую/внедряемую систему:

• Определяются компоненты и объекты, содержащие необходимые данные для переноса;
• Определяются требования по конвертации данных;
• Определяются методы загрузки этих данных в систему;
• Выбираются технологии/продукты или разрабатываются компоненты для переноса.

2.2.8. Документирование

   Процесс документирования проходит через все фазы внедрения решения. В Начальной фазе определяется набор требований к документации и разрабатывается стратегия документирования.
   Согласно методологии OUM cоздание качественной документации – один из важнейших факторов для успешного перехода к эксплуатации разрабатываемой/внедряемой системы, достижения одобрения пользователями организации заказчика проекта и поддержки бизнес-процессов заказчика.

2.2.9. Обучение

   Данный процесс состоит из двух частей:

• Обучение проектной группы;
• Обучение конечных пользователей.

В ходе Начальной фазы разрабатывается план обучения проектной группы.

2.3. Возможные проблемы и риски

• Наличие недокументированных бизнес-целей;
• Наличие недооцененных или не выявленных бизнес-требований;
• Отсутствие в компании заказчика лица, ответственного за проект внедрения системы;
• Описание масштабов проекта, проектных возможностей неверно или неточно. В этом случае возможно изменение сроков реализации проекта и его бюджета;

2.4. Факторы успеха

• Четкое понимание и следование подходу Oracle Unified Method;;
• Высокий уровень взаимодействия участников проекта;
• Наличие соглашения относительно возможностей проекта;
• Высокий уровень квалификации пользователей организации заказчика, участвующих в проекте;
• Высокий уровень квалификации разработчиков.

3. Проектирование (Elaboration)

   Целью фазы Проектирование является переход от определения масштабов проекта и бизнес-требований, полученных в ходе Начальной фазы, к детальному моделированию бизнес-требований, созданию спецификаций для дополнительной разработки, разбиению внедряемого решения на составляющие, созданию прототипа пользовательского интерфейса и технической архитектуры. Фаза Проектирование применяется для подтверждения понимания командой разработчиков бизнес-требований заказчика и для решения возможных проблем, возникающими во время разработки.

3.1. Цели

• Расположить в соответствии с приоритетами сценарии использования бизнес-процессов и дополнительные требования;
• Детализировать и уточнить бизнес-требования, провести их подробный анализ;
• Сформулировать бизнес-требования в виде сценариев использования бизнес-процессов;
• Согласовать вид пользовательского интерфейса;
• Согласовать участие представителей организации заказчика в проекте;
• Разработать исходную техническую модель и выделить ее компоненты;
• Разработать план устранения рисков;
• Убедиться, что спроектированный набор функциональных возможностей может быть переведен в следующую фазу (Разработка) проекта;

3.2. Процессы

   В данном разделе описываются основные процессы, входящие в фазу Проектирование. В него также включены советы и комментарии по каждому процессу.

3.2.1. Бизнес-требования

   Информация, касающаяся бизнес-требований, полученных в ходе Начальной фазы, служит исходными данными для разработки спецификации программных требований. Данные требования так же должны быть выполнены в соответствии с MoSCoW-методом.
   Одной из целей фазы Проектирование является создание надежной архитектуры приложения. Исходными данными для этого процесса являются результаты полученные в ходе анализа архитектуры приложения, проведенного на Начальной фазе.

3.2.2. Анализ требований

   На основе информации о бизнес-требованиях, полученных в ходе Начальной фазы, разрабатывается модель сценариев использования бизнес-процессов. Также определяется какие бизнес-процессы не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима. Одной из целей этого анализа является проектировка надежной архитектурной основы к концу фазы Проектирование, поэтому особенное влияние должно уделяться бизнес-процессам, которые оказывают наибольшее влияние на внедряемую архитектуру системы.
   Другой целью данного анализа является выявления путей ослабления существенных рисков, поэтому начинать следует с бизнес-процессов, с которыми связано наибольшее число рисков. Необходимо уже на раннем этапе детально исследовать существенные риски и разработать полный набор предварительных мер, которые можно принять для обеспечения возможности последующих действий по эффективному противодействию рискам в случае их материализации.
   Модели бизнес-процессов являются исходными данным для создания прототипа пользовательского интерфейса, и когда он готов производится его утверждение, в котором участвуют представители организации заказчика.

3.2.3. Анализ

   В данном процессе используются детализованные данные, полученные в ходе процесса анализа требований. В ходе фазы Проектирование следует сосредоточить внимание на тех бизнес-процессах, которые представляют особую важность и наиболее сложны при проектировании архитектуры системы. Производится анализ бизнес-процессов, структуризация их с помощью схематичной объектной модели, называемой моделью анализа.
   Модель анализа позволяет разработчикам понять требования и детали разрабатываемой системы. В качестве описания модели анализа используется язык разработчиков, тогда как анализ требований, описывающий функциональность системы, использует язык заказчика. Это способствует разработке надежной архитектуры и облегчает процесс глубокого и всестороннего исследования требований. Модель анализа используется в качестве исходных данных для модели проекта.

3.2.4. Разработка

   В ходе этого процесса разрабатывается система по ранее выявленным функциональным и нефункциональным требованиям. На фазе Проектирование на основе процесса анализа необходимо разработать классы архитектуры, программные компоненты и их интерфейсы. Также в этой фазе происходит проектирование базы данных.

3.2.5. Внедрение

В ходе фазы Проектирование выполняется разработка трех прототипов:

• Функциональный - прототип создающийся на основе наиболее важных бизнес-процессов;
• Архитектурный - прототип создающийся на основе бизнес-процессов наиболее влияющих на архитектуру системы;
• Прототип пользовательского интерфейса - прототип определяющийся стандартами пользовательских интерфейсов для приложений.

3.2.6. Тестирование

   Всегда есть искушение избежать подробного тестирования компонентов и модулей системы в целях ускорения внедрения решения. Однако это противоречит принципу, который гласит - «Процесс тестирования должен быть интегрирован на протяжении всех фазах внедрения». Игнорирование процесса тестирования может привести к дополнительным финансовым издержкам.
   Исследование исходного кода также входит в процесс тестирования и преследует следующие цели:

• Устранить очевидные дефекты кода;
• Гарантировать соответствие кода установленным стандартам.

На фазе Проектирование данный процесс включает:

• Разработку стратегии тестирования;
• Плана тестов;
• Cценариев тестов бизнес-процессов и системы в целом.

3.2.7. Контроль производительности

   При внедрении данного процесса можно определить является ли производительность приемлемой для данной задачи. В случае если результаты тестов производительности не удовлетворяют требуемым критериям, можно внести необходимые настройки системы или внести корректировки в архитектуру системы (т.к. процесс контроль производительности тесно связан с процессом разработки технической архитектуры), чтобы достичь нужной производительности.
   На фазе Проектирование данный процесс включает в себя:

• Определение требований контроля производительности и стратегии контроля производительности;
• Определение стратегии проведения тестов производительности;
• Определение моделей и сценариев проведения тестов производительности;
• Разработка программ проведения тестов производительности;
• Определение данных для проведения тестов производительности.

3.2.8. Техническая Архитектура

   На данной фазе процесс проектирования технической архитектуры включает в себя:

• Определение требований к архитектуре;
• Определение стратегий доступа к информации;
• Определение стратегий аварийного восстановления и создания резервных копий;
• Определение стратегий управления системой;
• Определение стратегий интеграции с существующими системами;
• Разработка стратегий безопасности и контроля.

3.2.9. Конвертация и перенос данных

   Для того чтобы избежать задержек и достигнуть лучшего качества данных, этот процесс должен быть запущен уже на ранних этапах проекта. Для определения объема работ по переносу данных на данном фазе необходимо исследовать состояние данных и сложность структуры хранения данных в существующих системах и приложениях. Поэтому на фазе Проектирование разрабатывается стратегия конвертации и переноса данных. В методологии OUM задачи сортировки и упорядочивания данных существующих систем ложится на специалистов заказчика.

3.2.10. Документация

   В данном процессе происходит переход от разработанных на Начальном фазе стратегии и требований к документированию к разработке стандартов и процедур документирования.

3.2.11. Обучение

   На фазе Проектирование происходит подготовка организации к внедрению системы. Чем более быстро заказчик сможет перенять новую технологию/продукт, тем более успешной и конкурентоспособной будет организация. На этой фазе проводится обучение проектной команды.

3.2.12. Переход

   Группа, отвечающая за переход к эксплуатации, должна вовлекать в этот процесс тех же самых пользователей заказчика, что привлекались на Начальной фазе.
   В ситуации, когда происходит замена старой системы, используется следующие способы:

• Последовательный метод;
• Параллельный метод;
• Метод замещения.

   Последовательный метод предусматривает ввод элементов новой системы при отключении соответствующих им элементов старой системы. Это позволяет осуществить плавный переход от старой системы к новой. Также в случае нарушения работы элементов новой системы произойдет остановка работы не всей системы в целом, а только ее части, т.е. небольшой группы работников заказчика. Еще одним преимуществом данного подхода является разбиение процесса конвертации и переноса данных на фазы. Недостатком данного решения является разработка временных модулей, отвечающих за совместимость новой системы со старой.
   Параллельный метод предусматривает одновременную работу новой и старой систем:

• Пользователь может работать в этих системах одновременно. Однако такая схема может привести к несогласованности данных в обоих системах. Эта проблема, как правило, решается путем установки старой системы в режим чтения.
• Другая схема работы параллельного метода предусматривает перевод группы пользователей на новую систему, тогда как остальные пользователи будут использовать старую систему. Недостатком такого подхода, как и в последовательном способе, является разработка нового интерфейса для связи новой и старой систем.

   Метод замещения предусматривает полную остановку старой системы и запуск новой. Однако данный вариант самый небезопасный, т.к. в случае нарушения работы происходит остановка всей системы. Также проблемой может стать необходимость конвертации и переноса всех данных сразу, а не по фазам.

4. Разработка

   В ходе фазы Разработка на основе детализованной модели требований, разработанных компонентов и результатов их тестов строится система и осуществляется подготовка к первому релизу, который называют бета-релизом. На данной фазе завершается разработка приложения, проводится проверка совместимости работы всех компонентов, и приложение подготавливается к приемосдатачным испытаниям.

4.1. Цели

• Подробно описать оставшиеся бизнес-процессы и усовершенствовать модель анализа и модель разработки, чтобы разработать такие компоненты решения и компоненты интерфейса, которые отвечают приоритетам бизнес-требований. Если необходимо, то возможно изменение описания архитектуры;

• Провести подготовку к фазе Переход к эксплуатации;
• Провести тестирование системы и инфраструктуры;
• Подготовить документацию;
• Подготовить процесс обучения конечных пользователей;

4.2. Процессы

В данном разделе описываются основные процессы, входящие в фазу Разработка. В него также включены советы и комментарии по каждому процессу.

4.2.1. Бизнес-Требования

   Бизнес-требования в соответствии с MoSCoW-методом и бизнес-процессы должны непрерывно контролироваться и поддерживаться менеджером проекта.
   В фазе Проектирование была определена большая часть бизнес-процессов, но при детализации этих процессов могут появиться либо новые требования, либо понадобится усовершенствование существующих требований. Однако необходимо помнить о масштабах проекта и не допустить его увеличения. Хотя наиболее важные для архитектуры системы бизнес-процессы были определены на фазе Проектирование и описана надежная архитектурная основы, возможно, появятся новые факторы или потребуется изменение уже существующих, которые могут повлиять на архитектуру. В этом случае необходимо включить эти факторы в анализ архитектуры приложения и разработать стратегию работы с этими факторами.

4.2.2. Анализ Требований

   Несмотря на то, что компоненты уже спроектированы и разработаны, можно определить новые бизнес-процессы. В этом случае модель бизнес-процессов должна быть изменена, чтобы отразить понимание новых требований и сделать модель более устойчивой.

4.2.3. Анализ

В процессе анализа работа, проделанная в результате фазы Проектирование, дополнительно совершенствуется в фазе Разработка.

4.2.4. Разработка

   Во время этого процесса происходит настройка системы на соответствие всем функциональным и нефункциональным требованиям и разработка оставшихся сценариев использования бизнес-процессов.

4.2.5. Внедрение

   Результат предыдущего процесса используется для внедрения системы на основе исходных кодов компонентов, скриптов, исполняемых файлов и т.д. Также внедряются и проводится тестирование программных компонентов. Конечные пользователи получают возможность оценить соответствие системы установленным требованиям. Во время такой проверки пользователи могут указать на недостатки разработанных компонентов и системы в целом.

4.2.6. Тестирование

   Планирование тестирования и разработка тестов основана на стратегии тестирования и требований тестирования, бизнес-процессах и архитектурной основе. Методология OUM подчеркивает необходимость проведения ранних тестов с использованием реальных данных заказчика, которые, как правило, конвертируются из старой системы. Такой подход облегчает работу пользователей во время проведения тестов, т.к. им приходится работать с уже известными данными, а также повышает эффективность данных тестов.
   На этой фазе проводится как тестирование отдельных компонентов системы, так и работы всей системы в целом. Также проверяется работа нефункциональных требований, таких как система аварийного восстановления, система создания резервных копий и восстановления.

4.2.7. Контроль производительности

   Целями процесса управления производительностью является определение, создание и внедрение эффективной системы управления производительностью для того, чтобы удостовериться в соответствии производительности системы и системных компонентов требованиям и ожиданиям заказчика.
   Во время фазы Проектирование были определены части системы, являющиеся критичными, и определены сценарии тестов производительности. На фазе Разработка необходимо разработать компоненты необходимые для проведения тестов производительности.

4.2.8. Техническая Архитектура

   На фазе Разработка создается “Руководство по управлению системой”, проводится тестирование систем резервного копирования и восстановления, а также определяется заключительная платформа и сетевая архитектура. Необязательным процессом данного фазы является проведение эксплуатационных тестов и тестов аварийного восстановления.

4.2.9. Конвертация и перенос данных

   На фазе Проектирование происходит согласование конвертации данных, которая имеет определенную значимость для бизнеса заказчика. Однако часто поля данных могут менять свое значение. Это может затруднить автоматическую конвертацию данных и потребовать ручного вмешательства (чистки данных). Трудно оценить необходимые размеры ручной чистки данных до завершения процесса Проектирование, поэтому иногда требуется провести один или несколько повторов на фазе Разработка.

4.2.10. Документирование

   Во время фазы Разработка публикуется документация системы и интерактивный справочник.

4.2.11. Обучение

   На фазе Разработка начинается подготовка к проведению тренингов по обучению пользователей организации заказчика работе с разрабатываемой/внедряемой системой. Этот процесс включает в себя уведомление пользователей, анализирование пользовательских потребностей, планирование учебного плана и проведение учебных тренингов.

4.2.12. Переход к эксплуатации системы

   На фазе Разработка необходимо усовершенствовать исходную стратегию перехода на новую систему и разработать план установки новой системы.

4.2.13. Оценка продолжительности

   Продолжительность внедрения проекта не является постоянной величиной. Для небольших проектов эта цифра может составлять 90 дней, но в зависимости от требований, потребностей заказчика, сложности стратегического направления его бизнеса, возможно увеличение срока внедрения проекта. Фаза Разработка является наиболее трудоемким по сравнению с другими фазами проекта.

5. Переход к эксплуатации

   Фаза Переход к эксплуатации включает в себя: установку разработанной системы с проведением приемосдаточных испытаний, завершение обучение конечных пользователей, производится конвертация данных и система вводится в эксплуатацию.

5.1. Цели

• Получить одобрение проекта (разработанной/внедряемой системы) заказчиком (лицо со стороны заказчика, ответственного за внедрение новой системы);
• Оказание поддержки пользователям заказчика при проведении приемосдаточных испытаниях и решение возникающих проблем и несоответствий;
• Удостовериться, что разработанная система соответствует требованиям заказчика;
• Подготовить промышленную среду;
• Завершить конвертацию данных существующей системы;
• Установить среду обслуживания требуемую для поддержки и управления узлом.

5.2. Процессы

   В данном разделе описываются основные процессы, входящие в фазу Переход к эксплуатации. В него также включены советы и комментарии по каждому процессу.

5.2.1. Тестирование

   Во время этой фазы проектная команда проводит приемосдаточные испытания. Во время проведения этих тестов привлекаются дополнительные пользователи организации заказчика. Предпочтительно проводить приемосдаточные испытания с данными, которые были подвержены конвертации из существующих систем.

5.2.2. Контроль производительности

   Во время этого процесса подготавливаются тесты производительности. Эти тесты являются итеративными, т.к. из-за строгих требований к производительности повышается их трудоемкость. Требуется настроить и переконфигурировать систему, возможно даже потребуется переписать часть исходного кода, чтобы получить соответствие требованиям. Поэтому важно еще на фазе Разработка следить за производительностью компонентов системы.

5.2.3. Конвертация и перенос данных

   Проверка правильности конвертации и переноса данных не менее важный процесс, чем проверка переноса программного обеспечения. Как правило, конвертация данных проводится с помощью специального программного обеспечения, которое не является постоянной частью новой системы, а используется как временный инструмент. Поэтому к этому программному обеспечению не применяются жесткие требования, как к другим элементам системы. Чем раньше будет решен вопрос конвертации данных, тем быстрее их можно будет использовать для проведения тестов работы бизнес-процессов.
   Во время этой фазы проводится конвертация данных и проведение тестов правильности перенесенных данных перед тем, как сделать их доступными для пользования. Если необходимо конвертировать данные из унаследованных систем и структура хранения этих данных отличается от структуры разработанной системы, то этот процесс является итеративным и к нему привлекаются пользователи заказчика с хорошим знанием унаследованной системы для проведения тестов правильности конвертации данных.

5.2.4. Документирование

   Во время фазы Переход к эксплуатации незначительные модификации или изменения программной системы могут привести к обновлению документации компонентов системы.

5.2.5. Обучение

   Во время фазы Переход к эксплуатации продолжается обучение конечных пользователей. Также проводится оценка эффективности для установления соответствия разработанной системы и ее производительности бизнес-целям, поставленным в начале проекта.

5.2.6. Переход

   В данном процессе происходит подготовка промышленной среды и система вводится в эксплуатацию.

5.2.7. Оценка продолжительности

   Фаза Переход к Эксплуатации является сравнительно коротким. Его продолжительность зависит от количества тестов контроля производительности и процесса конвертации и переноса данных.

6. Эксплуатация

   Фаза Эксплуатация включает:

• Мониторинг системы, выявление и исправление недостатков системы;;
• Разработка и внедрение требуемых обновлений;
• Оценка использования производительности;
• Разработка плана будущих расширений приложения.

6.1. Цели

• Выполнение обязательств гарантийного периода;
• Мониторинг производительности системы, устранение обнаруженных недостатков;
• Создание журнала регистрации ошибок и их исправление;
• Оценка эффективности внедренного решения;
• Разработка плана будущих расширений приложения.

6.2. Процессы

В данном разделе описываются основные процессы, входящие в фазу Эксплуатация. В него также включены советы и комментарии по каждому процессу.

6.2.1. Контроль производительности

   Промышленный контроль производительности – расширение методик контроля производительности и подходов, идентифицированных и осуществленных до промышленной эксплуатации. Показатели производительности должны регулярно собираться. По ним осуществляется обзор работы всех компонентов. При введении новых компонентов и модулей показатели производительности будут меняться, поэтому необходимо проводить своевременный анализ, чтобы избежать проблем, связанных потерей производительности.

6.2.2. Эксплуатация и поддержка

   Контракты большинства проектов разработки содержат пункт о предоставлении требуемого гарантийного периода. Гарантийный период – это период в течении которого проектная команда обязана оказать любую поддержку, касающуюся работы разработанной системы, обнаружить и устранить все возникающие проблемы и ошибки.
   Строгая процедура контроля внесения изменений – ключ к успеху процесса Эксплуатации и поддержки. Процедуры регистрации ошибок и оценки производительности должны быть явно определены. Руководитель проекта разработчика и руководитель проекта заказчика должны согласовать понимание определений системного дефекта, оценки производительности и расширение возможностей приложения.
   Некоторые заказчики требуют проведение аудита конфигурации системы. Как правило, аудит направлен на проверку проблем безопасности системы, таких как предотвращение несанкционированного доступа к данным.
   Также задачами данного процесса является оценка производительности системы на ее соответствие требованиям по производительности. Если проектная команда не встроила в приложение модули обработчика прерываний, чтобы фиксировать точное время ответа и операционные частоты, то эти задачи решаются путем сбора информации от пользователей системы.
   Также во время этого процесса разрабатывается новый список расширений MoSCoW. Этот список определяет те расширения, которые будут внедрены во время и после фазы Эксплуатации. Приложения OUM предусматривает частые обновления.