· Непрерывная проверка качества программы. Доказано, что, чем раньше обнаруживается проблема, тем дешевле ее устранить. Более того, опыт свидетельствует, что устранение проблем, обнаруженных уже после развертывания программы, всегда обходится в несколько раз дороже. Непрерывная проверка означает проверку на ранних этапах, которая может быть гораздо более рентабельной. Такая проверка также дает более объективную информацию об истинном состоянии проекта.
· Контролирование изменений в ПО. В наше время в разработку больших программных проектов обычно вовлекается много групп, расположенных в различных местах и включающих большое количество разработчиков. Вероятность конфликта изменений, ведущего к неразберихе, очень высока. Таким образом, существует серьезная необходимость контролировать изменения в ПО, чтобы обеспечить эффективное продвижение проекта.
Процесс RUP имеет два основных измерения. В одном из них действия по разработке группируются логически в соответствии с дисциплинами, которые отвечают за их выполнение. В процессе RUP определено шесть основных дисциплин.
· Деловое моделирование. Как ясно из названия, цель этой дисциплины состоит в разработке модели деловых операций. Это необходимо для лучшего понимания их логики, чтобы приложение могло более эффективно реализовать ее. Деловое моделирование наиболее полезно в ситуациях, когда система должна управлять большим объемом информации и сама, в свою очередь, использоваться относительно большой группой людей. Обычно в рамках делового моделирования строятся деловая модель прецедентов и деловая модель объектов.
· Требования. Дисциплина требований необходима для ясного понимания требований к системе. Это нужно для достижения согласия с заказчиками и выработки указаний для разработчиков. В рамках дисциплины требований строится модель прецедентов. Также может быть построен прототип пользовательского интерфейса.
· Анализ и проектирование. В рамках этой дисциплины требования, определенные в дисциплине требований, анализируются и преобразуются в проект системы. Разрабатывается архитектура, которая должна направлять действия разработчиков на последующих стадиях. Здесь строятся модели анализа и проектирования.
· Реализация. В рамках этой дисциплины проект системы преобразуется в конкретный код реализации. Разрабатывается стратегия разбиения системы на уровни и подсистемы. В результате должна получиться совокупность реализованных и проверенных компонентов, из которых состоит продукт.
· Тестирование. Как ясно из названия, эта дисциплина связана с проверкой всех аспектов системы. В частности, проверяется, выполнены ли все требования, работают ли компоненты вместе, как ожидается, и выявляются все дефекты, оставшиеся в продукте. Основным результатом этой дисциплины являются испытательная модель и набор дефектов, выявленных в результате тестирования.
· Развертывание. В рамках этой дисциплины продукт становится доступен конечным пользователям. Кроме того, сюда включаются такие операции, как формирование дистрибутива, инсталляция, обучение пользователей и распространение продукта.
Существуют также три вспомогательные дисциплины: конфигурирование и управление изменениями, руководство проектом и окружение.
В другом измерении RUP вырабатывается структура для итераций программного проекта. В RUP итерации группируются в четыре стадии. Каждая стадия заканчивается контрольной точкой, в которой должно быть принято какое-либо решение на уровне управления.
Как показано на рис. 5.3, каждая стадия (и каждая итерация в пределах стадии) обычно имеет дело с несколькими дисциплинами. В зависимости от итерации какая-то определенная дисциплина может играть на стадии первостепенную роль, а остальные дисциплины — вспомогательную. Например, ранние итерации, скорее всего, будут посвящены в основном выработке требований, а на поздних итерациях решающее значение будет иметь дисциплина тестирования, а дисциплина требований — гораздо меньшее.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.