Файл: Унифицированный процесс (Rational Unified Process, rup).docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 05.02.2024
Просмотров: 5
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
RUP
Унифицированный процесс (Rational Unified Process, RUP) [10] был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.
MSF
Microsoft Solutions Framework (MSF) [11] - это гибкая и достаточно легковесная модель, построенная на основе итеративной разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.
технология Xp
Extreme Programming (XP), оно же экстремальное программирование – это методология управления IT-проектами/программными продуктами, разработанная Кентом Бэком и обкатанная им в работе над крупными проектами. В свою основу методология ставит тесное взаимодействие участников, включая заказчиков, непрерывную обратную связь, простоту реализации и храбрость, необходимую для принятия на себя ответственности.
МЕТОД SCRUM
Scrum (/skrʌm/[1]; англ. scrum «схватка») — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем[2].
Scrum может использоваться не только в сфере разработки ПО но и в других производственных отраслях[3].
Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения, как подход к управлению разработкой и сопровождению программ.
Выбор модели процесса
Тяжелые и легкие модели производственного процесса имеют свои достоинства и свои недостатки (Таблица 1).
Таблица 1. Плюсы и минусы тяжелых и легких моделей процессов разработки ПО
| Вес модели | Плюсы | Минусы |
| Тяжелые | Процессы рассчитаны на среднюю квалификацию исполнителей. Большая специализация исполнителей. Ниже требования к стабильности команды. Отсутствуют ограничения по объему и сложности выполняемых проектов. | Требуют существенной управленческой надстройки. Более длительные стадии анализа и проектирования. Более формализованные оммуникации. |
| Легкие | Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями. Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации. | Эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды. Объем и сложность выполняемых проектов ограничены. |
Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа "Карго" - религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения ("муштру") и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи "USA". Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.
Алистер Коуберн, один из авторов "Манифеста гибкой разработки ПО" [14] проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и "гибких" до тяжелых (СММ-5) за последние 20 лет [15, 16]. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что :
-
У каждого проекта должна быть своя модель процесса разработки. -
У каждой модели - свое время.
Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с "Законом 4-х П" (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта "отдохни.ру". И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.
Рисунок 4. "Закон 4-х П". Процесс в проекте должен определяться в зависимости от проекта, продукта и персонала
Команда, которая начинала проект, не остается неизменной, она проходит определенные стадии формирования и, как правило, количественно растет по мере развития проекта. Поэтому процесс должен постоянно адаптироваться к этим изменениям. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую эффективность.
