RUP как методология

Методология RUP позволяет объединить проектную команду, предоставляя в ее распоряжение проверенные мировой практикой лучшие подходы к разработке ИС. К ним относятся такие процессы жизненного цикла создания ПО, как управление проектами, бизнес-моделирование, управление требованиями, анализ и проектирование, тестирование и контроль изменений. Внедрение в организации способствует выработке качественных внутрикорпоративных стандартов и повышению общей культуры разработки.

Основа RUP — итеративный процесс разработки. В условиях активно развивающегося мирового бизнеса практически невозможно создавать современные сложные программные системы последовательно, т. е. сначала выявлять все проблемы, затем принимать проектные решения, потом формировать программное обеспечение и, наконец, проверять полученное изделие. Итеративный подход позволяет улучшать понимание проблем на основе последовательных усовершенствований и конкретизировать их в эффективных решениях. Этот подход обеспечивает большую гибкость при изменяющихся требованиях и тактических коррективах в бизнес-целях, что позволяет более эффективно и заблаговременно идентифицировать и снижать проектные риски.

Rational Unified Process — управляемый процесс. Итеративный подход предполагает управление требованиями и изменениями, чтобы между всеми участниками проекта обеспечивать единое понимание ожидаемых функциональных возможностей, требуемый уровень качества, наилучшее управление затратами и графиками выполнения работ.

Rational Unified Process — процесс создания и физического воплощения визуальных моделей. RUP фокусирует внимание не на создании большого количества бумажных документов, а на развитии и применении визуальных моделей — семантически богатых представлений разрабатываемой ИС. RUP сосредотачивает внимание на разработке и дальнейшем развитии надежной и гибкой архитектуры, которая облегчает параллельную разработку, минимизирует необходимость изменений, увеличивает возможность многократного использования и надежность эксплуатации системы. Подобная архитектура применяется для планирования использования программных компонентов и управления их развитием.

Rational Unified Process — процесс управления действиями с помощью прецедентов, определяющих функционал системы. Понятия прецедентов и сценариев работы способствуют эффективному управлению технологическим маршрутом от бизнес-моделирования и требований вплоть до испытаний. Они обеспечивают связанные и доступные для анализа направления разработки и развертывания системы.

Rational Unified Process поддерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), в качестве единого стандарта для организации взаимодействия участников проекта используют Unified Modelling Language™ (UML) — универсальный язык моделирования.

Rational Unified Process поддерживает компонентно-ориентированный подход. Компоненты — это нетривиальные модули или подсистемы, которые выполняют конкретную функцию и могут быть использованы многократно. Как правило, компоненты соответствуют одной из промышленных спецификаций, таких как CORBA, COM/DCOM, ActiveX, Enterprise Java Beans и др.

Rational Unified Process — адаптируемый и конфигурируемый процесс. Опыт единичного проекта, даже успешно завершенного, вряд ли подойдет для создания ПО во всех случаях и условиях. Но способность RUP к адаптации подойдет как маленьким группам разработчиков, так и большим организациям. RUP содержит рекомендации по конфигурированию процесса для удовлетворения потребностей практически любых компаний и их подразделений.

Rational Unified Process поддерживает объективно осуществляемое управление качеством. Оценка качества всех работ, выполняемых любыми участниками проекта, использует объективные метрики и критерии. Методология RUP создавалась с прицелом на поддержку управления качеством в рамках требований SEI CMM/CMMI.

16. Понятия «архитектура предприятия» и «архитектура ИТ».

Понятие «архитектура предприятия» впервые появилось в 1987 г. в статье Дж.А. Захмана «Структура архитектуры информационных систем», опубликованной в журнале IBM Systems Journal. В этой статье автор изложил свое видение архитектур предприятий и связанных с ними проблем, которое задало направление развития на последующие 20 лет. В качестве проблемы было обозначено управление сложностью распределенных систем. Захман говорит:

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

Термин «предприятие» большинство специалистов по архитектуре и соответствующие методики описания архитектуры трактуют достаточно гибко. Это может быть организация в целом или одно из ее бизнес-подразделений, или же это может быть некоторая совокупность предприятий или организационных единиц в рамках единой цепочки создания добавочной стоимости. Таким образом, под термином "Предприятие" будем иметь в виду формальное объединение, не обязательно связанное с коммерческой деятельностью. Это может быть и государственная организация, и общественное, в том числе неформальное, объединение участников, связанных общей целью. Согласно более общему определению, Предприятие "... представляет собой комплексную систему культурных, технологических и процессных компонент, организованных для достижения целей организации".

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

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

Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В этом плане она дополняет достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL, COBIT и другие.

Многие организации испытывают постоянные трудности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. Существует как бы "облако неопределенности" между определением организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач.

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

Архитектура информационных технологий и архитектура предприятия в целом как раз и является основным механизмом интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура.

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

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

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

ИТ-архитектура - архитектура системы состоит из нескольких компонент, внешних свойств и интерфейсов, связей и накладываемых ограничений, а также архитектуры этих внутренних компонент.

В самом общем виде, в соответствии с определениями Gartner, архитектура – это:

· общий план или концепция, используемая для создания системы, такой как здание или информационная система, или "абстрактное описание системы, ее структуры, компонентов и их взаимосвязей";

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

Другие определения:

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

· " Корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий" (Giga Group);

Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое "расширенное предприятие") и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения потребностей организации, и способных к взаимодействию и интеграции там, где это необходимо. Чуть позже мы вернемся к определению понятия архитектура предприятия.

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

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

Уровни принятия архитектурных решений

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