11 (1158690), страница 2

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

Текст из файла (страница 2)

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

• Реализацию архитектуры (переход от проектной модели к модели реализации, представленной в виде диаграмм компонент и диаграмм пакетов).

• Выработку плана сборки для каждой итерации.

• Распределение компонентов системы по узлам вычислительной среды.

• Реализацию кода классов и подсистем.

• Покомпонентное тестирование.

Реализацию архитектуры осуществляет архитектор. Заключается она в трассировке проектных классов, пакетов и подсистем в компоненты и установлении связей (зависимостей) между компонентами.

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

За реализацию кода отвечает инженер по компонентам.

Покомпонентное тестирование – это раздельное тестирование компонент системы. Осуществляет его инженер по компонентам путем тестирования спецификации («черный ящик») и тестирования структуры («белый ящик»).

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

• Планирование тестов на каждой итерации.

• Составление тестовых вариантов (test-case) и тестовых сценариев (test scripts).

• Тестирование с целью обнаружения дефектов.

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

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

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

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

• инсталляционное (проверка возможности установки системы на вычислительной среде и правильность работы инсталлятора);

• конфигурационное (проверка работы системы в разных конфигурациях);

• отрицательное (проверка устойчивости системы на заведомо неверных данных, при неверных действиях пользователя – «защита от дурака» – при недостаточных ресурсах);

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

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

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

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

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

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

6

Характеристики

Список файлов лекций