Целеустремленный процесс разработки программного обеспечения - Goal-Driven Software Development Process

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

Следующие разделы основаны на статье Разработка программного обеспечения, ориентированного на достижение цели [1] где была представлена ​​концепция ВВП.

Обоснование

Первый аргумент в пользу принятия принципов GDP - это аспект требований. При разработке программного обеспечения сильная концентрация на требованиях (например, типичных для модель водопада ) вызывает чрезмерные затраты и снижение качества результата, в основном по следующим причинам:[1]

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

Результатом этих двух эффектов обычно является большое количество запросов на изменение во время и после разработки (что влечет за собой перерасход средств и времени), поэтому участие пользователя считается критическим фактором успеха проекта.[2]

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

Процесс разработки на основе целей позволяет заинтересованным сторонам:[3]

  • Откройте для себя варианты использования, адаптированные к требованиям в соответствии с бизнес-целями
  • Установите мост между целями и ИТ-архитектурой

Ключевые принципы

Целеустремленный процесс разработки программного обеспечения

Совместное определение целей

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

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

Конвергенция сверху вниз и снизу вверх

Для получения дополнительной информации см. Дизайн сверху вниз и снизу вверх.

В то время как ориентация сверху вниз поддерживает горизонтальную организацию команды, подходы снизу вверх пытаются предоставить обобщенные компоненты или услуги, ведущие к большему удовлетворению запросов пользователей.[4] Совместная идентификация целей, вводимая ВВП, позволяет сочетать нисходящие и восходящие аспекты («мышление сверху вниз и действие снизу вверх” [1]) поддерживать артефакты последовательность и позволяющая вертикальная организация команды.

Вертикальная командная организация

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

Роли и люди

Из-за своей вертикальной организации ВВП требует квалифицированных специалистов широкого профиля, способных выполнять многие роли в процессе:

  • Программисты (отвечает за конвергенцию сверху вниз и снизу вверх)
  • Бизнес-аналитики (сотрудничать с программистами во время определения целей и позже во время тестирования)
  • Архитекторы программного обеспечения (следите за всем проектом)
  • Руководитель проекта (распределяет ресурсы, отслеживает время и усилия, создает продуктивную среду)
  • Инженер по требованиям

Минимизация размера проекта

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

Уменьшение размера приводит к повышению ремонтопригодности и изменчивости системы для бизнес-процессов, поскольку они являются наиболее вероятным фактором для изменения в будущем.[5]

Деятельность

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

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

Основные виды деятельности:

  1. Определение и приоритезация целей (небольшие группы не более 5 человек, состоящие из заинтересованных сторон и / или бизнес-аналитиков и программистов)
  2. Вертикальное распределение задач (выбранные цели назначаются группам не более 4 программистов)
  3. Внедрение и тестирование (тесты, ориентированные на реализацию во время реализации, тесты, ориентированные на достижение целей, в конце каждой итерации)

Эти действия также можно разделить на шесть основных шагов:[3]

  1. Группируйте бизнес-требования по целям
  2. Формализовать целенаправленное поведение системы внутри процессов
  3. Мониторинг продвижения в реализации целей (по желанию)
  4. Распределите обязанности между участниками процессов
  5. Подключите поведение к целевой архитектурной основе и играйте
  6. Интегрировать ограничения приложений актеров

Рекомендации

  1. ^ а б c d Schnabel, I .; Пицка, М. «Разработка программного обеспечения, ориентированного на достижение цели». ШИТЬ. 2006. Компьютерное общество IEEE.. Получено 2008-12-30.
  2. ^ Отчет о хаосе. Технический отчет, Standish Group, 1994.
  3. ^ а б Беркем, Бирол (март – апрель 2006 г.). «Как согласовать ИТ с изменениями с помощью UML и в соответствии с BMM». Журнал объектных технологий. 5 (2): 85–102. Дои:10.5381 / jot.2006.5.2.c9. Получено 2008-12-30.
  4. ^ Пизка, М .; Бауэр, А. «Краткая философия эволюции программного обеспечения, идущая сверху вниз и снизу вверх». IPWSE. 2004. Компьютерное общество IEEE.. Получено 2008-12-30.
  5. ^ Панас, Лёве, Асманн. На пути к единой архитектуре восстановления для обратного проектирования. Proc. Междунар. Конф. по программной инженерии и практике SERP’03, том 1, страницы 854–860, Лас-Вегас, Невада, июнь 2003 г. CSREA Press.

внешняя ссылка