Rationalный подход

Rational Unified Process

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

Методология Rational Unified Process. Единый взгляд на разработку ПО

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

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

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

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

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

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

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

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

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

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

Передовой опыт от лидеров разработки ПО

Rational Unified Process позволяет интегрировать функции инструментальных средств Rational Software:

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

Высокая степень интеграции инструментов Rational Software позволяет использовать преимущества визуального моделирования на Unified Modeling Language (UML), вместе с автоматизацией всех основных процессов создания ПО. Rational Unified Process может быть адаптирован как для малых, так и для больших проектов и использоваться при разработке приложений всех типов, включая e-business- и web-приложения, приложения реального времени и встроенное ПО. Rational Unified Process был разработан в полном соответствии со стандартом UML, созданным Rational Software совместно с многочисленными партнерами. RUP предоставляет разработчикам точные инструкции для реализации шести основных принципов, проверенных на практике и позволяющих вести эффективную разработку качественных приложений уровня предприятия:

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

Рис.1. RUP организует выполнение проекта по фазам, каждая из которых состоит из одной или нескольких итераций.

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

Технология e-coach — помощник на каждом рабочем месте

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

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

Рис.2. RUP содержит инструкции, шаблоны и примеры для всех критических задач, возникающих в ходе разработки ПО.

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

Легкость адаптации RUP

Rational Unified Process может быть настроен в соответствии с особенностями и требованиями организации-разработчика. Незначительные изменения могут быть произведены инженерами-технологами организации с помощью входящего в состав RUP инструмента Process Engineering Toolkit.

Адаптация RUP. Rational Process Workbench

Rational Process Workbench (RPW) — инструмент настройки и публикации Web-сайтов на основе RUP, предназначен для тех, кому необходимо внести значительные изменения в RUP.

RPW является первым инструментом визуального моделирования процессов, использующим UML. Визуальное моделирование процессов повышает уровень абстракции, облегчая понимание и изменение процессов. Взаимосвязанность процессов обеспечена метамоделью RUP. Основные задачи генерации Web-сайта модифицированного RUP выполняются автоматически. RPW поддерживает три основе задачи моделирования процессов:

  • определение процесса;
  • описание процесса;
  • представление процесса.

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

Библиотека элементов процесса содержит текстовую информацию о каждом элементе в модели процесса. Библиотека содержит все текстовые страницы RUP, а RPW — необходимые шаблоны для создания новых страниц описания.

На последнем этапе — этапе представления процесса — RPW генерирует описание процессов, включающее текст и графику в виде Web-сайта, соединяя модели процессов и библиотеку описаний в единое целое.

Rationalный подход

рациональный подход — — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN management approach … Справочник технического переводчика

рациональный — ая, ое; лен, льна 1) Основанный на разуме, логике; разумный. Рациональные соображения. Рациональная нравственность не может быть основана на человеческой природе в ее настоящем виде (Мечников). Антонимы: иррациона/льный 2) Организованный наиболее … Популярный словарь русского языка

РАЦИОНАЛЬНЫЙ ВЫБОР — (rational choice) Направление или подход к изучению политики, рассматривающие индивидуальное действующее лицо как основную единицу анализа и моделирующие политику, исходя из предположения, что индивиды ведут себя рационально, или исследующие… … Политология. Словарь.

Рациональный агент — Караваджо, Шулеры, прибл. 1594 год. Рациональный агент (англ. rational agent) это агент, действующий о … Википедия

ПОДХОД, РАЦИОНАЛЬНЫЙ — предпосылка неоклассической экономической теории, суть которой состоит в том, что индивид, делая свой выбор, сопоставит все возможные комбинации благ и отдаст предпочтение большему количеству благ перед меньшим … Большой экономический словарь

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

Затратный подход к оценке стоимости — (cost approach to value) метод оценки стоимости, который обеспечивает оценку рыночной стоимости недвижимости на основе оценки затрат на приобретение свободного участка под застройку и строительство здания и других сооружений, необходимых для того … Словарь терминов по экспертизе и управлению недвижимостью

Векторный подход к психотерапии (vector approach to psychotherapy) — В. п. п. постулирует, что все многообразие терапий по существу распределяется по 6 осн. векторам, или модальностям, указывающим направление роста. Выбирая один из мн. терапевтических методов, осн. на этих векторах, эклектически ориентированный… … Психологическая энциклопедия

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

ПОЛИТИКА — (греч. гос. или обществ. дела, от государство), сфера деятельности, связанная с отношениями между классами, нациями и др. социальными группами, ядром которой является проблема завоевания, удержания и использования гос. власти. Самое… … Философская энциклопедия

Унифицированный процесс Rational (RUP)

Унифицированный процесс Rational — это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation , которую в 2003 году купила IBM .

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

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

К примеру, RUP используется в системе управления онлайн-обучением TAP University . Компания поставила перед собой цель расширить область традиционного офлайн-обучения и улучшить свои сервисы для корпоративных, частных пользователей и студентов.

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

Что такое унифицированный процесс Rational (RUP)?

Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.

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

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

RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.

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

Шесть основополагающих принципов RUP

В основе RUP лежит шесть главных принципов :

  • Итеративная модель разработки – устранение рисков на каждой стадии проекта позволяет лучше понять проблему и вносить необходимые изменения, пока не будет найдено приемлемое решение;
  • Управление требованиями – RUP описывает процесс организации и отслеживания функциональных требований, документации и выбора оптимальных решений ( как в процессе разработки, так и при ведении бизнеса );
  • Компонентная архитектура – архитектура системы разбивается на компоненты, которые можно использовать как в текущем, так и в будущих проектах;
  • Визуальное моделирование ПО – RUP методология разработки показывает , как создать визуальную модель программного обеспечения, чтобы понять структуру и поведение архитектуры и его компонентов;
  • Проверка качества ПО – в процессе разработки программного обеспечения контролируется качество всех действий команды;
  • Контроль внесённых изменений – отслеживание изменений позволяет выстроить непрерывный процесс разработки. Создаётся благоприятная обстановка, в рамках которой команда будет защищена от изменений в рабочем процессе.

Структура RUP

Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:

Работники – «Кто»

Элемент « работник » определяет поведение и ответственность всех членов команды, сконцентрированных на общей цели – создании искусственных объектов ( артефактов ). В RUP работник – это скорее роль, определяющая, как индивидуумы должны выполнять свою работу. Работник не только производит определённые действия, но также владеет набором артефактов.

Действия – «Как»

Действие — это единица работы, которую может выполнить работник. У каждого действия есть чётко обозначенная цель. Каждое действие назначено определённому работнику. Действия могут включать в себя создание или обновление артефактов, таких как модель, класс или план.

Артефакты (искусственные объекты) – «Что»

В методологии RUP объекты или информация, производимая и изменяемая в процессе работы над финальным результатом. Артефакты служат как вводными данными для действий работников, так и результатами этих действий.

Рабочий процесс – «Когда»

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

Жизненный цикл RUP

Жизненный цикл RUP разбит на четыре основных фазы, в каждой из которых ведётся работа над новым поколением продукта: фазу начала проекта, уточнение, построение и внедрение.

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

Цель этой фазы — анализ требований к системе и её архитектуры, разработка плана проекта и устранение элементов наивысшего риска. Это самая важная фаза из всех, поскольку она знаменует переход от низкого уровня риска к высокому. В рамках этой фазы команда решает, переходить ли к фазе построения ( разработке и написанию кода ) или нет.

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

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

В конце каждой фазы существует отметка завершения этапа ( Project Milestone ) — момент, когда ваша команда оценивает, достигнуты ли поставленные цели. При этом команда принимает важные решения, влияющие на ход следующей фазы:

Преимущества RUP

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

Недостатки RUP

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

Хотя RUP методология разработки показывает отличные результаты, особенно в сфере создания ПО, это довольно сложный метод, который трудно внедрить в свой проект, особенно если у вас небольшая команда или компания.

Данная публикация представляет собой перевод статьи « Rational Unified Process (RUP) » , подготовленной дружной командой проекта Интернет-технологии.ру

Введение В Rational Unified Process. Методология И Технология

Автор: Новичков Александр, СМ-Консалт

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

Подход к разработке

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

IBM Rational Unified Process — это итерационный процесс. Создавать современные сложные программные системы последовательно, т. е. сначала определять все проблемы, затем принимать все проектные решения, формировать ПС и, наконец, проверять изделие, невозможно. Такой подход (называемый каскадным подходом или «водопадом») в современной информационной индустрии не оправдывает себя, поскольку его использование часто приводит к непредсказуемому увеличению проектной стоимости и сроков выпуска ПС. Эффективной альтернативой «водопаду» служит итерационный процесс разработки ПС.

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

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

Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой.

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

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

Четко определенный процесс

RUP создавался по методике, используемой при проектировании ПС. В частности, моделирование производилось с помощью Software Process Engineering Metamodel (SPEM) — стандарта моделирования процессов, основанного на Unified Modeling Language (UML). У процесса есть два измерения:
Динамическая структура. Горизонтальное измерение представляет собой динамическую структуру или временное измерение процесса. Оно показывает, как процесс, выраженный в форме циклов, фаз, итераций и вех, развертывается в ходе жизненного цикла проекта.

Статическая структура. Вертикальное измерение представляет собой статическую структуру процесса. Оно описывает, как элементы процесса — задачи, дисциплины, артефакты и роли — логически группируются в дисциплины или рабочие процессы (workflows).

Динамическая структура RUP состоит из четырех фаз: Inception, Elaboration, Construction и Transition. Фазы могут подразделяться на итерации. Переход с фазы на фазу возможен только после выполнения задач фазы и представляет собой контрольную точку (milestone) процесса.

Статическая структура RUP состоит из дисциплин, в которые группируются работы, задачи, артефакты и роли. Для описания осмысленной последовательности выполнения работ и задач используются рабочие процессы. Они описывают кто, что, как и когда выполняет в процессе. В RUP входят 6 основных дисциплин:
— Бизнес-моделирование (Business modeling);
— Управление требованиями (Requirements);
— Анализ и Проектирование (Analysis and Design);
— Реализация (Implementation);
— Тестирование (Test);
— Развертывание (Deployment).
И три вспомогательные:
— Управление проектом (Project management);
— Управление изменениями (Change management);
— Среда (Environment).

В отличие от каскадного подхода ( «водопада»), в RUP все дисциплины выполняются практически во всех фазах жизненного цикла ПС. Однако, в зависимости от фазы, меняются текущие цели проекта и соотношение между объемами работ, соответствующих различным дисциплинам.

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

Фаза Elaboration, посвящена тщательной проработке требований и выбору основных проектных решений. В этой фазе концептуальный прототип превращается в реальную систему, позволяющую протестировать и оценить выбранные архитектурные решения. В результате, к концу фазы команда готова к быстрой и качественной разработке основного объема кода системы. Наличие тщательно проработанной устойчивой архитектуры гарантирует, что в дальнейшем не придется перерабатывать большие фрагменты системы.

В фазе Construction основными задачами становится быстрая и экономичная разработка кода системы. К концу фазы система должна быть готова к передаче заказчику для бета-тестирования и/или приемо-сдаточных испытаний.

Фаза Transition жизненного цикла посвящена подготовке разработанного продукта к передаче его заказчику или к тиражированию и распространению (если это «коробочный» продукт).

Готовый продукт

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

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

Использование инструментальных средств

Для обеспечения инструментальной поддержки всех процессов жизненного цикла разработки и сопровождения ПС RUP рекомендует использование специализированных инструментальных средств IBM Rational:
Управление требованиями – IBM Rational RequisitePro;
Визуальное моделирование и генерация объектного кода – IBM Rational Rose, IBM Rational XDE;
Разработка — IBM Rational RapidDeveloper
Конфигурационное управление – IBM Rational ClearCase;
Управление изменениями – IBM Rational ClearQuest;
Автоматизированное документирование – IBM Rational SoDA;
Автоматизированное тестирование – IBM Rational TeamTest, IBM Rational TestFactory, IBM Rational Robot, IBM Rational PurifyPlus, IBM Rational SiteCheck и IBM Rational SiteLoad.

RUP и другие подходы к разработке ПО

IBM Rational Unified Process позволяет компании-разработчику настраивать весь процесс разработки ПС. В отличие от большинства современных методологий или требований к процессу разработки, ориентированных на строго определенный уровень формализации процесса (как правило, либо очень высокий, либо напротив, очень низкий), RUP позволяет получить именно тот уровень формализации, который необходим в проекте.

При разработке ПС для государственных предприятий и в ряде других ситуаций компании-разработчику приходится выполнять формальные требования отечественных и международных стандартов (ГОСТы серий 19 и 34, ГОСТ ИСО/МЭК 12207 и др.). В этом случае можно настроить RUP на достаточно высокий уровень формализации процесса. Более того, при использовании инструментальных средств IBM Rational несложно разработать шаблоны документов, которые будут создаваться автоматически с помощью IBM Rational SoDA на основе стандартных моделей и артефактов и соответствовать требованиям ГОСТ.

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

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

Внедрение RUP

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

Компания CM-Consult предлагает услуги по адаптации и внедрению RUP в конкретной компании-разработчике. Мы можем подобрать для вас процесс требуемой степени формализации. Разработать шаблоны документов. Обучить ваших сотрудников как особенностям разработки ПС с использованием RUP, так и использованию в этом процессе многочисленных инструментальных средств IBM Rational. Все работы будут производиться с участием сотрудников компании-разработчика, что гарантирует передачу им всех необходимых знаний и навыков.

Компания CM-Consult предлагает осуществить на первом этапе обследование компании-заказчика и определить порядок внедрения RUP и необходимый набор инструментальных средств. Под методическим руководством опытных консультантов из компании CM-Consult специалисты компании-заказчика смогут выполнить оценку текущей организации разработки ПС в своей компании, выявить проблемы и причины их возникновения, а также способы устранения или уменьшения, ранжировать эти проблемы по тяжести последствий и важности разрешения.

На втором этапе предлагается силами сотрудников специализированного подразделения компании-заказчика выполнить один или несколько пилотных проектов под методическим руководством опытных консультантов-наставников.

Целью пилотных проектов является поэтапное обучение сотрудников компании-заказчика основным принципам RUP и методам использования инструментальных средств IBM Rational. В ходе пилотных проектов специалисты заказчика под методическим руководством консультантов из компании CM-Consult будут устанавливать, конфигурировать, испытывать и внедрять необходимые для данной итерации внедрения RUP средства инструментальной поддержки.

В ходе пилотных проектов или после их завершения могут быть выработаны:
— описание порядка разработки и сопровождения ПС;
— шаблоны документов, выпускаемых в процессе разработки;
— указания по разработке артефактов проектов;
— указания по использованию инструментальных средств поддержки.

В результате компания-заказчик получит хорошо документированный процесс, настроенный в точном соответствии с особенностями компании и выполняемыми ею проектами. Сотрудники компании приобретут опыт выполнения проектов в соответствии с RUP и навыки использования инструментальных средств IBM Rational. Это поможет компании преодолеть имеющиеся трудности и устранить проблемы, мешающие быстрому и качественному выполнению проектов.

Читать дальше —>
Еще статьи автора —>

Rational Unified Process

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная и поддерживаемая компанией Rational Software. Это:

— новый подход к разработке ПС, основанный на использовании лучших практических методов, успешно зарекомендовавших себя во многих проектах разработки ПС по всему миру;

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

— готовый продукт, предоставляемый в виде веб-сайта, содержащего все необходимые модели и документы с описанием процесса.

В основе методологии лежат 6 основных принципов:

— Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

— Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).

— Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

— Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

— Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

— Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

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

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

История Rational Unified Process (RUP)

Чтобы просмотреть это видео, включите JavaScript и используйте веб-браузер, который поддерживает видео в формате HTML5

Методологии антикризисного жизненного цикла корпоративных систем

Half Faded Star

Предметом курса являются кризисно устойчивые методологии разработки корпоративных систем, процессно-ориентированные подходы к организации, планированию и управлению их разработкой. Исследуется влияние кризисных явлений на процессы разработки программных систем, определяющие эксплуатационные характеристики и экономические показатели программного продукта. В курсе рассматриваются основы использования методологий для антикризисной разработки корпоративных систем, а также систематизируются практические приемы — «лучшие практики» их применения. Основное внимание при этом уделяется исследованию особенностей коррекции жизненного цикла в кризисных условиях с учетом наиболее распространенных адаптивных методологий. Систематизация методологий проводится также и в аспекте их практической пригодности для антикризисной разработки корпоративных систем, с учетом технологических и антропогенных факторов. Будут рассмотрены следующие основные вопросы: • Как сказываются кризисные явления на методологиях разработки программного обеспечения? • Какие процессы разработки корпоративных приложений затрагивает кризис? • Какие факторы наиболее существенны для антикризисного управления процессами разработки корпоративных систем? • В чем состоят «лучшие практики» управления жизненным циклом в кризис? • Почему важно систематически адаптировать методологии разработки к кризисным явлениям? • Какие методологии разработки программного обеспечения лучше использовать в кризис? • В чем состоят особенности применения каждой из этих методологий?

Half Faded Star

Преподаватели

Зыков Сергей Викторович

Текст видео

Немного истории. Расскажем кратко о том, как развивалась методология Rational Unified Process. Она была создана в 95-м году. Первая версия появилась в 98-м уже оформленная в качестве стандарта. Три автора — это Греди Буч, тот самый человек, который в частности представил картинку управленческой и технологической сложности, включающие корпоративные системы, Айвар Якобсон или Ивар Джекобсон и Рембо. Три человека, которые по сути дела создали эту методологию и поддерживающие ее язык UML — Unified modeling language, язык унифицированного моделирования — который описывает в более формальном виде, в графических диаграммах основные примитивы этой методологии. Это классы, состояния, взаимодействия компонент программных систем и целый ряд других аспектов. Всего насчитывается, наверное, порядка 2 десятков видов таких диаграмм. При этом на сегодня методология полностью перешла под контроль IBM. Греди Буч является ведущим научным сотрудником корпорации IBM. Вначале было даже подразделение Rational внутри корпорации IBM, но сегодня это, наверное, не совсем так. IBM на сегодня представляет и методологию как таковую и средства, программно-инструментальные средства поддержки это методологии. Одно из первых средств называлось Rational Rose — это средство для проектирования систем, т. е. для рисования этих самых UML-диаграмм. Но существует большое количество средств, которые теперь уже переданы IBM. А ряд из них был и разработан IBM — это Rational Robot, это Clear Case и целый ряд других средств, которые существуют для того, чтобы поддерживать весь жизненный цикл и тестирование, и разработки корпоративных систем в том числе. На самом деле эти средства достаточно дорогостоящие, достаточно сложные в освоении. Наверное, имеет смысл тратить ресурсы при производстве больших систем на постижение этих средств, поскольку они приводят к достаточно быстрому увеличению производительности, и позволяют, можно сказать, полуавтоматически следовать тем стандартам разработки, которые в них заложены.

Рациональный подход в ситуациях принятия управленческих решений

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

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

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

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

Приходится констатировать, что на практике большинство решений базируется на модели «ограниченной рациональности «(bounded rationality), впервые предложенной Г. Саймоном (H. Simon). Принимающий решение на основе этой модели значительно упрощает ситуацию, принимая во внимание только небольшое количество факторов, которое он способен охватить. [216] Большинство случаев принятия решений связано с поиском удовлетворительных альтернатив, а с открытием и выбором оптимальных альтернатив связаны только исключительные случаи.

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

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

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

Технология Rational Unified Process (IBM Rational Software)

Одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта — Rational Unified Process (RUP). RUP представляет собой программный продукт, разработанный компанией Rational Software, которая в настоящее время входит в состав IBM.

RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами жизненного цикла программного обеспечения и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Ее основными принципами являются:

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

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

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

Общее представление RUP в двух измерениях представлено в приложении. (Приложение А) Горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как стадии, итерации и контрольные точки. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).

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

  • — начальная стадия (inception) ;
  • — стадия разработки (elaboration) ;
  • — стадия конструирования (construction) ;
  • — стадия ввода в действие (transition).

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.

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

Результатами начальной стадии являются:

  • — общее описание системы: основные требования к проекту, его характеристики и ограничения;
  • — начальная модель вариантов использования (степень готовности — 10-20%) ;
  • — начальный проектный глоссарий (словарь терминов) ;
  • — начальный бизнес-план;
  • — план проекта, отражающий стадии и итерации;
  • — один или несколько прототипов.

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

Результатами стадии разработки являются:

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

Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает:

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

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

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

Стадия разработки занимает около пятой части общей продолжительности проекта. Основными признаками завершения стадии разработки являются два события:

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

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

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

Итерации на стадии конструирования являются одновременно инкрементными и повторяющимися:

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

итерации являются повторяющимися по отношению к разрабатываемому коду.

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

Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Он содержит следующие понятия:

программное обеспечение, интегрированное на требуемых платформах;

описание текущей реализации.

Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователей. Данная стадия включает:

бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;

параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

конвертирование баз данных;

обучение пользователей и специалистов службы сопровождения.

Статический аспект RUP представлен следующими основными элементами:

Понятие «роль» (role) определяет поведение и ответственность личности или группы личностей, составляющих проектную команду. Одна личность может играть в проекте много различных ролей.

Под видом деятельности конкретного исполнителя понимается единица выполняемой им работы. Вид деятельности (activity) соответствует понятию технологической операции. Он имеет четко определенную цель, обычно выражаемую в терминах получения или модификации некоторых рабочих продуктов (artifacts), таких, как модель, элемент модели, документ, исходный код или план. Каждый вид деятельности связан с конкретной ролью. Продолжительность вида деятельности составляет от нескольких часов до нескольких дней, он обычно выполняется одним исполнителем и порождает только один или весьма небольшое количество рабочих продуктов. Любой вид деятельности должен являться элементом процесса планирования. Примерами видов деятельности могут быть планирование итерации, определение вариантов использования и действующих лиц, выполнение теста на производительность. Каждый вид деятельности сопровождается набором руководств (guidelines), представляющих собой методики выполнения технологических операций.

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

В рамках RUP определены следующие основные дисциплины:

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

управление конфигурацией и изменениями;

RUP как продукт входит в состав комплекса Rational Suite, причем каждая из перечисленных выше дисциплин поддерживается определенным инструментальным средством комплекса.

Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью Rational Process Workbench (RPW) — специального набора инструментов и шаблонов для настройки и публикации Web-сайтов на основе RUP. RPW поддерживает три основные функции моделирования технологических процессов:

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

Одно из основных инструментальных средств комплекса Rational Rose [9] представляет собой семейство объектно-ориентированных CASE-средств и предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose реализует процесс объектно-ориентированного анализа и проектирования программного обеспечения, описанный в RUP. В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генераторы кодов для каждого поддерживаемого языка, состав которых меняется от версии к версии.

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

Средства автоматической генерации кода, используя информацию, содержащуюся в диаграммах классов и компонентов, формируют файлы описаний классов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на соответствующем языке (основные языки, поддерживаемые Rational Rose — С++ и Java).

В результате разработки проекта с помощью Rational Rose формируются следующие документы:

диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы;

спецификации классов, объектов, атрибутов и операций;

заготовки текстов программ.

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

Рациональный подход.

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

Необходимость применения этого подхода возникает тогда, когда субъект управления — ЛПР осознает факт возникновения сложной проблемы или потенциальной возможности, заслужилвающей повышенного внимания с различных точек зрения (например, с экономической, политической, экологической, социальной и прочих), и сознательно ставит цель найти наиболее рациональный, а в идеальном случае — оптимальный, вариант ее разрешения. Обычно в таких случаях coздaeтся рабочая группа — команда специалистов,на которых возлагается выполнение работ по обеспечению разработки и подготовки управленческого решения. Важными элементами организации успешной работы команды является разработка концепции процесса подготовки и принятия решения по исследуемой проблеме, определение при необходимости состава соисполнителей по конкретной тематике, планирование очередности и сроков выполнения работ процесса подготовки и принятия управленческого решения, а также организация учета, контроля их вы­полнения, своевременной выработки регулирующих воздействий и их осуществления. Состав и очередность выполнения необходимых работ при подготовке и принятии управленческого решения определяются исходя из условий конкретной проблемной ситуации и специально разработанной методики для этих целей. При разработке методики следует ориентироваться на известные из литературных источников сведения методологического характера по разрешению проблематики подготовки и принятия управленческих решений.

Рассмотрим пример рационального подхода к принятию управленческого решения.

Существуют различные трактовки процесса принятия решений рациональным способом, обусловленные спецификой возникающих проблем. Конкретная проблема для своего разрешения требует вполне определенной совокупности этапов, процедур и последовательности их выполнения. В книге Мес-кон MX., Альберт М., Хедоури Ф. «Основы менеджмента». Пер. с англ. М.: Дело, 1994 нахождение рационального решения проблемы представлено в виде пятиэтапного процесса, включающего следующие этапы: диагностика проблемы; формулировка критериев и ограничений; определение альтернатив; оценка альтернатив; окончательный выбор решения.

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

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

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

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

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

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

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

Методологии Rational Unified Process: сущность и области применения.

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

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

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

1) Определение требований;

2) Анализ требований и проектирование;

3) Выполнение (реализация);

5) Внедрение (развертывание);

В зависимости от распределения интенсивности работ на разных этапах или их наборе процесс разработки в целом также условно делят на фазы:

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

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

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

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

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

Рисунок: Распределение усилий при выполнении проекта:

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

Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников. При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.

3.Гибкие методологии разработки программного обеспечения. Их сущность, примеры и области применения.

Гибкие методологии разработки (англ. Agile software development)

Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки

Agile-методы делают упор на непосредственное общение лицом к лицу. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.

Многие руководители проектов, работающие в традиционных методологиях вроде «водопада», критикуют agile-методы. Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути управление требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.

Наиболее известные методики:

+ Экстрема́льное программи́рование (билет 4)

+ Методология SCRUM (билет 5)

+ Microsoft Solutions Framework (MSF) методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта.

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

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

1. Распределение ответственности при фиксации отчетности

2. Наделяйте членов команды полномочиями

3. Концентрируйтесь на бизнес-приоритетах

4. Единое видение проекта

5. Проявляйте гибкость — будьте готовы к переменам

6. Поощряйте свободное общение

+Канбан — система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».

Разница между Канбан и SCRUM:

· В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)

· В Канбан задачи больше и их меньше

· В Канбан оценки сроков на задачу опциональные или вообще их нет

· В Канбан “скорость работы команды” отсутствует и считается только среднее время на полную реализацию задачи

Например, общеизвестная проблема SCRUM — это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт — 2 недели, то 2 дня из 2 недель — это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса — на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%!

Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды — это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи.

Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы — тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале.

Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера — это создать приоритизированный пул задач, а задача команды — выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера — это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом.

Команда для работы использует Канбан-доску. Например, она может выглядеть так

Столбцы слева направо:

Необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, “Увеличить скорость работы на 20%” или “Добавить поддержку Windows 7?.

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

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

Тут задача висит до тех пор, пока разработка фичи не завершена. После завершения она передвигается в следующий столбец.

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

В этом столбце задача находится, пока она тестируется. Если найдены ошибки — возвращается в Разработку. Если нет — передвигается дальше.

У всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то — просто закомитить код в репозиторий.

Сюда стикер попадает только тогда, когда все работы по задаче закончены полностью.

В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как “Expedite”). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна — она должна быть добавлена в “Очередь задач”.

А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.

Что нового и полезного дает такая доска с лимитами?

Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. — делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце “очередь задач”, а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться.

Во-вторых, сразу видны затыки. Например, если тестеры не справляются с тестированием, то они очень скоро заполнят весь свой столбец и программисты, закончившие новую задачу, уже не смогут переместить ее в столбец тестирования, т.к. он заполнен. Что делать? Тут время вспомнить, что “мы — команда” и решить эту проблему. Например, программисты могут помочь тестерам завершить одну из задач тестирования и только тогда передвинуть новую задачу на освободившееся место. Это позволит выполнить обе задачи быстрее.

В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.

Весь Канбан можно описать всего тремя основными правилами:

1. Визуализируйте производство

— Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.

— Используйте названные столбцы, чтобы показать положение задачи в производстве.

2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства.

3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время.

Всего 3 правила!

Например, в SCRUM — 9 базовых правил. В XP — 13,а в классическом RUP — аж более 120. Почувствуйте разницуJ

Приблизительная сравнительная таблица

Ссылка на основную публикацию