Деятельность в течение жизненного цикла

1. Введение
2. Деятельность на начальном этапе
3. Деятельность на этапе уточнения
4. Деятельность на этапе построения
5. Деятельность на этапе внедрения

Введение

Разработка на основании компонентов представляет собой разновидность общей разработки приложений, в которой:

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

На данной странице термин "компонент" используется для обозначения независимо разрабатываемого и размещаемого компонента. Однако, в других документах RUP мы будем использовать термин "компонент" в более общем смысле, как описано в Концепции: Компонент и при необходимости уточнять.

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

Деятельность на начальном этапе

Базовый поток операций для начального этапа применим со следующими исключениями и уточнениями.

Управление проектами

• Деятельность: Начало нового проекта

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

• Деятельность: Оценка рамок проекта и рисков

• Компонентный подход меняет старые риски и добавляет новые, а именно:

  • компоненты с исходным кодом вовне увеличивают риск, так как содержат важные элементы вне прямого контроля коллектива проекта
  • компоненты с исходным кодом вовне снижают время разработки, и таким образом снижают риски, связанные с ресурсами
  • компоненты с исходным кодом вовне могут изменять архитектуру системы, если они предполагают собственные архитектурные требования

• Деятельность: Планирование проекта

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

Требования

• Деятельность: Уточнение определения системы

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

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

• Деятельность: Определение миссии оценки

• Необходимо создать план тестирования, определяющий планируемое тестирование проекта, называемый "Главный план тестирования"

Среда

• Деятельность: Подготовка среды для проекта

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

Деятельность на этапе уточнения

Базовый поток операций для этапа уточнения применим со следующими исключениями и уточнениями:

Требования

• Деятельность: Уточнение определения системы

• Задача: Детализация программных требований также уделяет внимание техническим и не функциональным требованиям и ограничениям, наложенным на компоненты, которые создаются или покупаются. Специальные не функциональные требования это - размер, быстродействие, занимаемое место в памяти или на диске, аспекты лицензирования среды выполнения и подобные ограничения, которые влияют на выбор и создание компонентов.

Анализ и проектирование

• Деятельность: Определение архитектуры кандидата

• Задача: Архитектурный анализ использует структуру компонентов и технические и не функциональные требования для определения начальной архитектуры, включая начальную схему уровней и набор по умолчанию компонентов и служб, представленный как механизм анализа и проектирования. Задача: Анализ вариантов использования уделяет внимание определению архитектурно важных компонентов из архитектурно важных вариантов использования.

• Деятельность: Уточнение архитектуры

• Задача: Структурирование модели реализации устанавливает модель реализации, совместимую со структурой компонентов, а также структурой и функциями коллектива/ов разработчиков.

  Задача: Идентификация механизмов проектирования уточняет первичные механизмы проектирования для учета специальных структурных служб и компонентов.

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

  Задача: Объединение существующих элементов проектирования обеспечивает совместимость и согласованность идентифицированных компонентов с существующими компонентами, идентифицированными на ранних итерациях в структуре или во внешних источниках.

  Задача: Описание архитектуры среды выполнения описывает базовые процессы и потоки архитектуры структуры компонентов, а Задача: Описание распределения описывает распределенную среду обработки, в которой будут выполнятся компоненты приложения.

• Деятельность: Компоненты проектирования

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

• Деятельность: Проектирование базы данных

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

Реализация

• Деятельность: Реализация компонентов

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

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

• Деятельность: Определение миссии оценки, Проверка метода тестирования, Тестирование и оценка, Приемлемо выполнимая Задача, Улучшение тестовых активов

  Тестирование при уточнении имеет дело с проверкой архитектуры. Для системы, основанной на компонентах, это означает следующее:

  • непрерывная диагностика интерфейса между компонентами для обеспечения адекватности границ компонентов
  • акцент на тестировании быстродействия, особенно, быстродействия масштабирования для того чтобы обеспечить обработку больших объемов данных
  
  

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

Управление проектами

• Деятельность: Планирование следующей итерации

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

Деятельность на этапе построения

Базовый поток операций для этапа построения применим со следующими исключениями и уточнениями.

Управление проектами

• Деятельность: Планирование следующей итерации

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

Анализ и проектирование

• Деятельность: Уточнение архитектуры и Деятельность: Проектирование компонентов

  Цель построения - анализ оставшихся вариантов использования и идентификации соответствующего кооперирования компонентов, которое реализуют варианты использования. Существующая архитектура расширяется и дополняется и 'внутреннее поведение' компонентов проектируется и реализуется.

• Деятельность: Проектирование базы данных

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

Реализация

• Деятельность: Реализация элементов проектирования

• Данная работа подобна этапу уточнения, но детализация повышается с углублением этапа.

• Деятельность: Объединение каждой подсистемы и Деятельность: Объединение системы

• Система постепенно строится с продвижением этапа.

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

• Деятельность: Определение цели оценки, Проверка метода тестирования, Проверка стабильности компоновки, Тестирование и оценка, Приемлемо выполнимая задача, Улучшение тестовых активов.

Деятельность на этапе внедрения

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