Технология RUP. Соотношение и связь между фазами и процессами..
Методология RUP позволяет объединить проектную команду, предоставляя в ее распоряжение проверенные мировой практикой лучшие подходы к разработке ИС. К ним относятся такие процессы жизненного цикла создания ПО, как управление проектами, бизнес-моделирование, управление требованиями, анализ и проектирование, тестирование и контроль изменений. Внедрение в организации способствует выработке качественных внутрикорпоративных стандартов и повышению общей культуры разработки.
Основа RUP — итеративный процесс разработки. В условиях активно развивающегося мирового бизнеса практически невозможно создавать современные сложные программные системы последовательно, т. е. сначала выявлять все проблемы, затем принимать проектные решения, потом формировать программное обеспечение и, наконец, проверять полученное изделие. Итеративный подход позволяет улучшать понимание проблем на основе последовательных усовершенствований и конкретизировать их в эффективных решениях. Этот подход обеспечивает большую гибкость при изменяющихся требованиях и тактических коррективах в бизнес-целях, что позволяет более эффективно и заблаговременно идентифицировать и снижать проектные риски.
Rational Unified Process — управляемыйпроцесс.Итеративный подход предполагает управление требованиями и изменениями, чтобы между всеми участниками проекта обеспечивать единое понимание ожидаемых функциональных возможностей, требуемый уровень качества, наилучшее управление затратами и графиками выполнения работ.
|
|
|
RationalUnifiedProcess — процесс создания и физического воплощения визуальных моделей. RUP фокусирует внимание не на создании большого количества бумажных документов, а на развитии и применении визуальных моделей — семантически богатых представлений разрабатываемой ИС. RUP сосредотачивает внимание на разработке и дальнейшем развитии надежной и гибкой архитектуры, которая облегчает параллельную разработку, минимизирует необходимость изменений, увеличивает возможность многократного использования и надежность эксплуатации системы. Подобная архитектура применяется для планирования использования программных компонентов и управления их развитием.
RationalUnifiedProcess — процесс управления действиями с помощью прецедентов, определяющих функционал системы. Понятия прецедентов и сценариев работы способствуют эффективному управлению технологическим маршрутом от бизнес-моделирования и требований вплоть до испытаний. Они обеспечивают связанные и доступные для анализа направления разработки и развертывания системы.
RUP. Управление требованиями к ПО и ИС.
|
|
|
Управление требованиями
Требоваия к ПС
Требование – это характеристика или условие, которому должна удовлетворять ПС.
Функциональные требования определяют действия, которые должна выполнять ПС, без учета физических ограничений. Тем самым они определяют поведение системы при вводе и выводе. Процесс выявления функциональных требований весьма сложный и трудоемкий. Это объясняется следующими причинами:
таких требований к системе обычно много,
заказчик не всегда способен четко сформулировать, чего он хочет от системы,
требования в итоговом документе должны быть изложены так, чтобы они одинаково понимались заказчиком и исполнителем и не допускали неоднозначности,
между функциональными требованиями могут быть разные зависимости, усложняющие управление ими в случае необходимости внесения изменений.
Для преодоления этих трудностей применяется моделирование требований. Модель требований позволяет, во-первых, установить иерархию требований, что способствует лучшему пониманию человеком, во-вторых, дает наглядное графическое представление требований и зависимостей между ними, в третьих позволяет связать графическую форму представления с текстовой, обеспечивая человека полной информацией.
|
|
|
Нефункциональные требования не описывают поведение программной системы, но описывают ее атрибуты или атрибуты окружения. Нефункциональные требования не требуется включать в модель требований, но они должны быть точно сформулированы. Обычно нефункциональных требований не бывает много, однако они кардинальным образом влияют на выбор архитектуры системы.
Управление требованиями – это достаточно сложный и растянутый во времени процесс. Он продолжается в течение большей части жизненного цикла, поскольку изменения могут вноситься как во время разработки, так и после сдачи системы на этапе опытной эксплуатации и при сопровождении. Причины этого заключаются в том, что требования:
неочевидны,
исходят из многих источников,
трудно формулируются (язык неоднозначен),
состоят из множества различных деталей,
неравнозначны,
связаны друг с другом,
лежат не только в функциональной области.
могут изменяться в течение разработки и при сопровождении.
Цели анализа и моделирования требований
Целями анализа и моделирования требований являются:
достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;
|
|
|
достижение лучшего понимания разработчиками того, что должна делать система;
ограничение системной функциональности;
создание базиса для планирования разработки проекта;
определение пользовательского интерфейса;
составление спецификации требований.
Роли
Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.
Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований.
Заинтересованные лица – люди, предоставляющие информацию.
Эксперт – представитель заказчика, участвующий в разработке модели требований.
Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.
Артефакты
Для достижения поставленных целей предусматривается создание следующих документов:
Предварительное соглашение – текстовый документ, который описывает, что будет включено в ПС и что решено исключить, то есть, он ограничивает системную функциональность. В нем отражаются пожелания заинтересованных лиц, а также указываются основные нефункциональные требования (например, описывается платформа реализации, точность вычислений, время отклика).
Модель требований служит для достижения соглашения между заказчиком и разработчиками, давая возможность заказчику убедиться в том, что система будет делать то, что они ожидают, а разработчикам создать то, что требуется. Модель требований позволяет, во-первых, установить иерархию требований, что способствует лучшему пониманию человеком, во-вторых, дает наглядное графическое представление требований и зависимостей между ними, в третьих позволяет связать графическую форму представления с текстовой. Модель включает актеров и ВИ, показывает, как система взаимодействует с актерами и что она делает в каждом ВИ.
Спецификация требований (SoftwareRequirementsSpecification) – основной документ, используемый при проектировании и разработке ПС. Она включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному продукту, но не к процессу его разработки и не содержат деталей реализации требований.
Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.
Глоссарий – текстовый документ, содержащий определения основных понятий и терминов, которые должны одинаково пониматься заказчиком и разработчиком. Источниками данных для создания перечисленных артефактов могут, в частности, служить артефакты, созданные при бизнес-анализе (см. статью «RUP. Обследование организации (бизнес-анализ)».
Дата добавления: 2018-02-15; просмотров: 665; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!