Принципы эффективной разработки
Методология RUP основывается на шести принципах, которые направлены на эффективную разработку ПО. Эти принципы считаются мировыми лучшими практиками в области создания программных систем.
Шесть принципов, лежащих в основе RUP:
1. Адаптация среды разработки. Только сбалансированный процесс обеспечит высокую гибкость разработки, удобство планирования и эффективность проекта в целом.
2. Разумный подход к удовлетворению запросов заинтересованных лиц. Необходимо определить приоритеты требований заказчиков, учитывая возможность использования уже имеющихся наработок и готовых продуктов, накопленного опыта. Результаты: понимание реальных потребностей заказчика, снижение объемов разработки.
3. Эффективность взаимодействия участников проекта. Подготовив среду для взаимодействия, основанную на ответственности, энтузиазме и доверии, продуктивность работы будет на высоте. Взаимодействие коллектива исполнителей проекта и заинтересованных лиц обеспечит тесную связь между потребностями заказчиков и возможностями конечного продукта.
4. Итеративно-инкрементная разработка (Demonstrate Value Iteratively, Iterative and incremental development). Это принцип RUP, направленный на сокращение рисков проекта на его ранних стадиях, повышение уровня доверия со стороны заказчиков и предсказуемости проекта.
Принцип предполагает, что проект разделяется на итерации, результатом каждой из которых является частично завершенный, но готовый к тестированию, программный продукт (например, реализовано несколько функций). Каждая итерация имеет свои цели и задачи, план и длительность. Программное обеспечение, как результат итерации, демонстрируется заказчику, который дает обратную связь (feedback). Обратная связь позволяет постоянно учитывать пожелания заказчика (а они будут меняться), повышать эффективность разработки (управлять методами и подходами к разработке) и корректировать планы.
Одним из наиболее значимых преимуществ итеративно-инкрементной разработки является раннее сокращение рисков. Такая возможность обеспечивается благодаря постоянной оценке рисков проекта и их сокращением на каждой последующей итерации. На рисунке 2 показана диаграмма рисков для итеративно-инкрементной разработки и разработки по модели «водопада».
Рисунок 2 — Диаграмма рисков для итеративно-инкрементной разработки и разработки по модели «водопада»
5. Абстрагирование при проектировании. Рассмотрение конечного продукта с различных уровней абстракции повышает наглядность, снижает сложность и, следовательно, повышает производительность разработки ПО. Применение компонентного подхода позволяет использовать уже имеющиеся наработки (компоненты, результаты работ), что снижает стоимость проекта и ускоряет его завершение.
6. Постоянный контроль качества. Для достижения высокого качества ПО необходимо уделять ему внимание на протяжении всего жизненного цикла.
Жизненный цикл проекта
Жизненный цикл проекта разработки состоит из четырех последовательных фаз — Определения проекта (Inception), Уточнения (Elaboration), Построения (Construction) и Внедрения (Transition). Каждая фаза завершается вехой: оценивается достижение поставленных целей и принимается решение о продолжении проекта.
Длительность и трудоемкость фаз жизненного цикла RUP отличается. Отношение этих характеристик для типичного проекта представлено на рисунке 3.
Рисунок 3 — Распределение трудоемкости и затрат времени в течение жизненного цикла типичного проекта
В соответствии с итеративным подходом, команда проекта выполняет работы по девяти дисциплинам на протяжении всего жизненного цикла, однако по ходу выполнения проекта акцент сменяется от бизнес-моделирования к развертыванию. Результаты работ одной дисциплины являются исходными данными для работ другой и представляют непрерывный циклический процесс разработки:
× Бизнес-моделирование (Business Modeling). Программное обеспечение является отражением потребностей бизнеса. Целью дисциплины является общее для всех заинтересованных лиц понимание бизнеса организации-заказчика, существующих проблем и возможностей их решения при внедрении информационных систем. Также результаты работ дисциплины являются основой для определения требований к ПО и организации процесса развертывания;
× Управление требованиями (Requirements). Дисциплина группирует работы, определяющие возможности и характеристики разрабатываемого ПО, которые согласовываются как внутри команды разработчиков, так и среди всех заинтересованных лиц. Требования также являются важными составляющими при оценке стоимости и длительности проекта и его планировании, а также определяющим фактором при оценке готовности ПО к сдаче в эксплуатацию;
× Анализ и проектирование (Analysis and Design). Дисциплина концентрирует усилия разработчиков на описании архитектуры, подсистем, компонентов и других элементов создаваемого ПО. Разрабатываемый проект обеспечивает последующую реализацию установленных требований и характеристик ПО;
× Реализация (Implementation). Целью реализации является создание и интеграция программного кода, реализующего проект ПО. При этом, спроектированные элементы ПО реализуются в виде программ, библиотек и других исполняемых модулей. Результат выполнения работ дисциплины на каждой итерации — готовая к работе версия ПО;
× Тестирование (Test). Тестирование оценивает качество разработанного ПО в нескольких плоскостях: функциональность, практичность, удобство и простота использования, надежность, производительность, возможность поддержки и другие (аналогично категориям требований к ПО);
× Развертывание (Deployment). Дисциплина обеспечивает доступность разработанного программного обеспечения конечному пользователю. При этом осуществляется сборка внешнего релиза, его доставка, установка и тестирование на территории заказчика, настройка, а также обучение пользователей;
× Управление конфигурациями и изменениями (Configuration and Change Management). Целью дисциплины является контроль и синхронизацию изменений результатов работ на протяжении всего процесса разработки. Управление конфигурациями обеспечивает систематизацию и контроль версий результатов работ и является хранилищем всех версий разрабатываемого ПО. Управление запросами на изменения позволяет отслеживать их статус и поддерживает процесс реализации изменений;
× Управление проектом (Project Management). Дисциплина не заменяет общего подхода к управлению проектами, а концентрируется на вопросах управления, связанных с разработкой ПО — итеративном планировании, управлении рисками, контроле и оценке хода выполнения проекта;
× Управление средой разработки (Environment). Дисциплина фокусируется на подготовке рабочей среды разработки — процессе и средствах разработки. Целью дисциплины является поддержание команды проекта на протяжении всего жизненного цикла.
В целом, жизненный цикл разработки в соответствии с методологией RUP можно представить рисунком 4.
Рисунок 4 — Жизненный цикл проекта разработки
Таким образом, например, на фазе Определение проекта наибольшее внимание уделяется управлению проектом, подготовке среды разработки, бизнес-моделированию и определению требований. На рисунке эта фаза представлена одной итерацией, однако, ее можно разбить и на несколько итераций. Фаза Определение проекта сменяется фазой проекта Уточнение, когда будут достигнуты следующие цели:
× среди заинтересованных лиц проекта достигнуты соглашения об ориентировочных объемах работ, сроках и стоимости работ;
× сформировано и согласовано общее понимание требований к ПО;
× выделены риски проекта и определены приоритеты работ;
× определена стратегия для снижения рисков.
Также будут подготовлены первые версии документов, таких как Видение, Список рисков, План разработки, Описание процесса разработки, Словарь терминов.
На основании полученной информации по окончанию фазы Определение проекта принимается решение, продолжать ли проект, или прекратить его.
Поддержка ГОСТ при использовании RUP
На практике все еще встречаются ситуации, когда заказчик ПО требует выполнения работ в соответствии с ГОСТ 19 или даже ГОСТ 34. Поскольку ГОСТ 34 регламентирует разработку автоматизированных (информационных) систем, вести разработку ПО с ориентацией на этот стандарт некорректно. Область интересов RUP ограничивается только разработкой ПО, поэтому сравнивать ГОСТ 34 и RUP также некорректно.
Что касается ГОСТ 19, разрабатывать ПО в соответствии с этим стандартом неэффективно, но сразу стоит сказать, что требования заказчика вести разработку в соответствии с ГОСТ 19 не является препятствием применению RUP.
ГОСТ серии 19 регламентирует только состав документации, и включают рекомендации по содержанию документов и организации процесса разработки. Договор с заказчиком может определять, ЧТО требуется сделать (какие артефакты произвести при выполнении проекта), но не КАК это требуется сделать. В конечном итоге, заказчик хочет получить не набор бумаг, а качественное ПО, и разработчик вправе самостоятельно определять, как эффективнее получить этот результат.
В таблице 1 проведено условное сравнение жизненных циклов, определяемых методологией RUP и ГОСТ 19.102-77.
Таблица 1 — Сравнение жизненных циклов разработки ПО, определяемых методологией RUP и ГОСТ 19.102-77
| Фаза проекта, определяемая методологией RUP | Стадия проекта, определяемая ГОСТ 19.102-77 |
| Определение (Inception) | 1. Техническое задание |
| Уточнение (Elaboration) | 2. Эскизный проект 3. Технический проект |
| Построение (Construction) | 4. Рабочий проект |
| Внедрение (Transition) | 5. Внедрение |
В отличие от жизненного цикла, определяемого ГОСТ 19, методология RUP предполагает итеративную разработку, разделяя фазы на итерации. Каждая итерация заканчивается выпуском новой версии готового продукта (постепенное наращивание реализованных возможностей). Кроме того, при переходе от одной фазе к последующей не происходит смены вида деятельности, как в жизненном цикле «водопадного» ГОСТ.
Согласно требованиям ГОСТа, техническое задание начинает подготавливаться и завершает подготовку, подписывается на стадии Техническое задание. В RUP же каждый документ, в том числе и техническое задание, начинает подготавливаться в самом начале проекта и подвергается изменениям на протяжении всего жизненного цикла. Это не значит, что заказчик может добавить добрый десяток требований в конце проекта без согласования с исполнителем, однако изменения требований имеют место в любом проекте разработки ПО, и это надо учитывать.
В связи с вышесказанным, применение Методологии возможно и при требовании заказчика «Разрабатывать в соответствии с ГОСТ 19». Стоит правда отметить, что исполнитель, убедивший заказчика вообще не ориентироваться на ГОСТ, значительно повышает эффективность проекта.
Скачать PDF-версию с оригинальным оформлением. © Для использования опубликованных на ресурсе материалов достаточно упоминания имени автора и адреса первоисточника. Дата обновления: 2008-10-21.
Комментариев нет:
Отправить комментарий