Помощь в написании студенческих работ
Антистрессовый сервис

Oracle Unified Method

Реферат: Oracle Unified Method
РефератПомощь в написанииУзнать стоимостьмоей работы

Внедрение и тестирование программных компонентов. Конечные пользователи оценивают соответствие требованиям и указывают на недостатки. Хотя компоненты спроектированы и разработаны, могут быть определены новые бизнес-процессы. Тогда модель бизнес-процессов изменяется. Oracle Unified Method (OUM) — комплекс методов, который охватывает большую часть стадий ЖЦИС. Каждый проект в методологии OUM… Читать ещё >

Oracle Unified Method (реферат, курсовая, диплом, контрольная)

Oracle Unified Method (OUM) — комплекс методов, который охватывает большую часть стадий ЖЦИС. Каждый проект в методологии OUM состоит из пяти фаз:

  • • начальная фаза (Inception);
  • • проектирование (Elaboration);
  • • разработка (Construction);
  • • переход к эксплуатации {Transition)-,
  • • эксплуатация {Production).

Каждая фаза может включать до 15 процессов. Сами процессы и их интенсивность на каждой из фаз отражены на рис. 7.251.

Несмотря на видимую схожесть с RUP, данный подход не является итерационным, он пошаговый.

Начальная фаза. Цели. Каждая фаза OUM преследует достижение какихлибо целей. Для начальной фазы выделяют следующие цели:

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

Процессы. Процессы для начальной фазы OUM приведены в табл. 7.20.

Таблица 7.20

Процессы начальной фазы OUM2

Процесс.

Описание.

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

Определение функциональных требований заказчика (на основе MoSCoW[1][2]).

Определение нефункциональных требований заказчика (на основе MoSCoW).

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

Создание модели прецедентов, которая отражает основные бизнес-требования заказчика в виде прецедентов.

Внедрение.

Моделирование концептуального прототипа системы (иллюстрирует интерфейс, функциональные возможности ИС).

Проработка ключевых технических вопросов для проверки выполнимости требований заказчика.

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

Определение начальных требований к тестам.

Фазы и процессы Oracle Unified Method.

Рис. 7.25. Фазы и процессы Oracle Unified Method

Процесс.

Описание.

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

Определение, разработка и выполнение шагов по контролю производительности.

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

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

Ознакомление с принципами работы эталонного варианта архитектуры предприятия заказчика.

Сбор информации о требованиях к разрабатываемой архитектуре и ее компонентам.

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

Определение компонентов и объектов с данными для переноса. Определение требований, но конвертации данных.

Определение методов загрузки данных в систему.

Выбор технологии для переноса.

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

Определение набора требований к документации. Разработка стратегии документирования.

Обучение.

Разработка плана обучения проектной группы.

Проектирование. Цели. Фаза проектирования преследует достижение следующих целей:

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

Процессы. Процессы для фазы проектирования OUM приведены в табл. 7.21.

Таблица 7.21

Процессы фазы проектирования OUM

Процесс.

Описание для фазы.

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

Разработка спецификации программных требований (в соответствии с методом MoSCoW).

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

Выявление путей снижения рисков.

Анализ того, какие прецеденты не могут быть автоматизированы на основе стандартной функциональности.

Анализ потребности в дополнительной разработке.

Анализ.

Анализ прецедентов и структуризация с помощью схематической объектной модели (модель анализа).

Разработка.

Разработка класса архитектуры, программных компонентов и их интерфейсов.

Проектирование баз данных.

Процесс.

Описание для фазы.

Внедрение.

Разработка функционального прототипа (на основе самых важных прецедентов).

Разработка архитектурного прототипа (на основе архитектурно значимых прецедентов).

Разработка прототипа пользовательского интерфейса (определяется стандартами пользовательских интерфейсов в приложениях).

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

Разработка стратегии тестирования. Планирование тестов.

Разработка сценариев тестирования.

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

Определение требований к контролю производительности (и стратегии контроля производительности).

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

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

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

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

Разработка стратегии конвертации и переноса данных. Сортировка и упорядочивание данных (в методологии OUM выполняется заказчиком).

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

Разработка стандартов и процедур документирования.

Обучение.

Обучение проектной команды.

Подготовка организации к внедрению И С.

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

Разработка стратегии перехода по одному из методов. Последовательный метод (отключение элементов старой ИС и ввод новых).

Параллельный метод (работа новой и старой ИС одновременно). Метод замещения (полная остановка старой ИС и запуск новой).

Разработка. Цели. Фаза разработки преследует достижение следующих целей:

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

Таблица 722

Процессы фазы разработки OUM.

Процесс.

Описание.

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

Могут быть выявлены новые требования, которые нужно учесть.

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

Хотя компоненты спроектированы и разработаны, могут быть определены новые бизнес-процессы. Тогда модель бизнес-процессов изменяется.

Анализ.

Совершенствуются результаты, полученные на фазе проектирования.

Разработка.

Настройка ИС для соответствия функциональным и нефункционал ьн ы м гребован ия м.

Разработка оставшихся прецедентов.

Внедрение.

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

Система внедряется на основе исходных кодов, скриптов, исполняемых файлов.

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

Тестирование компонентов ИС и всей ИС. Тестирование нефункциональных требований.

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

Разработка компонентов, необходимых для проведения тестирования производительности.

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

Создание руководства по управлению системой. Тестирование систем резервного копирования и восстановления.

Определение заключительной платформы и сетевой архитектуры.

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

При необходимости производится повтор действий из фазы проектирования.

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

Публикуется документация И С и интерактивный справочник.

Обучение.

Подготовка к проведению тренингов по обучению конечных пользователей И С.

Проведение учебных тренингов.

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

Усовершенствование стратегии перехода. Разработка плана установки новой ИС.

Процессы, Процессы для фазы перехода к эксплуатации OUM приведены в табл. 7.23.

Процессы фазы перехода к эксплуатации OUM

Процесс.

Описание для фазы.

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

Проведение приемо-сдаточных испытаний (с привлечением дополнительных пользователей со стороны заказчика). Рекомендуется использовать конвертированные данные.

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

Проведение настройки и конфигурирования ИС для достижения соответствия требованиям.

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

Проверка правильности конвертации и переноса данных.

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

Документация обновляется в случае изменения ИС.

Обучение.

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

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

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

Эксплуатация. Цели. Фаза эксплуатации преследует достижение следующих целей:

  • • выполнить обязательства гарантийного периода;
  • • мониторить производительность И С и устранять недостатки;
  • • создать журнал регистрации ошибок и вносить исправления;
  • • оценить эффективность внедренного решения;
  • • разработать план расширения ИС.

Процессы. Процессы для фазы эксплуатации OUM приведены в табл. 7.24.

Таблица 7.24

Процессы фазы эксплуатации OUM

Процесс.

Описание.

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

Проведение промышленного контроля производительности.

Эксплуатация и но/шержка.

Разработка списка расширений ИС (на основе метода MoSCoW).

Оценка соответствия ИС требованиям к производительности. Контроль внесения изменений в ИС.

  • [1] Девятов С. Методология Oracle Unified Method // Блог С. Девятова. 2011. 20 нояб. URL: http://stanlslav.blogspot.ru/2011/11/oracle-unified-method.html (дата обращения:07.10.2016).
  • [2] MoSCoW (от англ. Must have, Should have, Could have, Won’t have) — метод приорити-зации требований, в котором каждому требованию присваивается один из четырех уровнейприоритета.
Показать весь текст
Заполнить форму текущей работой

Сессия? Спокойно!