Гибкий унифицированный процесс
Эта статья нуждается в дополнительных цитатах для проверки . ( август 2009 г. ) |
Agile унифицированный процесс ( AUP ) — это упрощенная версия рационального унифицированного процесса (RUP), разработанного Скоттом Эмблером . [1] В нем описан простой и понятный подход к разработке программного обеспечения для бизнес-приложений с использованием гибких методов и концепций, сохраняющий при этом верность RUP. AUP применяет гибкие методы, включая разработку через тестирование (TDD), гибкое моделирование (AM), гибкое управление изменениями и рефакторинг базы данных для повышения производительности.
В 2011 году на долю AUP приходилось один процент всех используемых гибких методологий. [2] В 2012 году AUP был заменен дисциплинированной гибкой поставкой (DAD). С тех пор работа над развитием AUP была прекращена.
Дисциплина
[ редактировать ]В отличие от РУП, в АУП всего семь дисциплин. [ нужна ссылка ] :
- Модель . Понять бизнес организации, проблемную область, которую решает проект, и определить жизнеспособное решение для решения проблемной области.
- Выполнение . Преобразуйте модель(и) в исполняемый код и выполните базовый уровень тестирования, в частности модульное тестирование .
- Тест . Проведите объективную оценку для обеспечения качества. Это включает в себя поиск дефектов, проверку того, что система работает так, как задумано, и проверку соответствия требованиям.
- Развертывание . Запланируйте поставку системы и выполните план, чтобы сделать систему доступной для конечных пользователей.
- Управление конфигурацией . Управляйте доступом к артефактам проекта. Это включает не только отслеживание версий артефактов с течением времени, но также контроль и управление их изменениями.
- Управление проектом . Руководит деятельностью, которая происходит в рамках проекта. Это включает в себя управление рисками, управление людьми (назначение задач, отслеживание прогресса и т. д.), а также координацию с людьми и системами, не входящими в проект, чтобы быть уверенным, что он будет выполнен вовремя и в рамках бюджета.
- Среда . Поддерживайте остальную часть усилий, гарантируя, что надлежащий процесс, руководства (стандарты и рекомендации) и инструменты (аппаратное обеспечение, программное обеспечение и т. д.) будут доступны команде по мере необходимости.
Философия
[ редактировать ]Agile UP основан на следующих философиях: [3]
- Ваши сотрудники знают, что делают . Люди не будут читать подробную документацию по процессам, но время от времени им потребуется руководство и/или обучение высокого уровня. Продукт AUP предоставляет ссылки на многие детали, если они вам интересны, но не навязывает их вам.
- Простота . Все описано кратко, на нескольких страницах, а не на тысячах.
- Ловкость . Agile UP соответствует ценностям и принципам гибкой разработки программного обеспечения и Agile Alliance .
- Сосредоточьтесь на деятельности с высокой ценностью . Основное внимание уделяется действиям, которые действительно имеют значение, а не всем возможным вещам, которые могут случиться с вами в проекте.
- Независимость от инструмента . С Agile UP вы можете использовать любой набор инструментов, какой захотите. Рекомендуется использовать инструменты, которые лучше всего подходят для работы, и зачастую это простые инструменты.
- Вы захотите адаптировать AUP под свои нужды .
Релизы
[ редактировать ]Гибкий унифицированный процесс различает два типа итераций. Итерация выпуска разработки приводит к развертыванию в области обеспечения качества и/или демонстрационной области. Итерация производственного выпуска приводит к развертыванию в производственной зоне. Это значительное усовершенствование рационального единого процесса .
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Уотерс, Джон К. (28 февраля 2008 г.). «Роль Agile в играх и бизнес-программном обеспечении» . Регистр . Проверено 3 августа 2009 г.
- ^ «Результаты исследования состояния гибкой разработки, 2011 г. Версия первая» . Архивировано из оригинала 17 июля 2015 г. Проверено 26 июня 2014 г.
- ^ Эмблер, Скотт. «Унифицированный гибкий процесс (AUP)» . Амбисофт . Архивировано из оригинала 8 августа 2019 года . Проверено 21 декабря 2015 г.