Целенаправленный процесс разработки программного обеспечения
Целенаправленный процесс разработки программного обеспечения (GDP) — это итеративный и поэтапный метод разработки программного обеспечения . Несмотря на то, что ВВП похож на другие современные модели процессов , он в первую очередь фокусируется на определении целей, прежде чем устанавливать требования, и явно использует восходящий подход к проектированию.
Следующие разделы основаны на статье « Разработка программного обеспечения, ориентированная на цели» . [1] где была введена концепция ВВП.
Обоснование
[ редактировать ]Первым аргументом в пользу принятия принципов ВВП является аспект требований. При разработке программного обеспечения сильная концентрация на требованиях (например, типичная для каскадной модели ) приводит к чрезмерным затратам и снижению качества результата, в основном по следующим причинам: [1]
- Требования обычно не совпадают с бизнес-целями из-за ограниченных знаний автора о технических возможностях и их стоимости – такие требования, как правило, включают ненужные дорогостоящие пожелания, исключая при этом технически простые функции, которые могли бы обеспечить существенную выгоду.
- Формализация поддерживаемого бизнес-процесса в ходе разработки обычно выявляет несоответствия и пробелы внутри этого процесса, которые необходимо компенсировать изменением самого процесса или роли программной системы.
Результатом этих двух эффектов обычно является большое количество запросов на изменения во время и после разработки (что влечет за собой перерасход времени и средств), поэтому участие пользователей считается критическим фактором успеха проекта. [2]
Во-вторых, в то время как установленные процессы разработки программного обеспечения уточняют требования вплоть до реализации, процесс разработки, ориентированный на достижение целей, рекомендует попытаться найти оптимальное соответствие между бизнес-целями и возможностямитехническую платформу в итеративном процессе, одинаково учитывающем и корректирующем бизнес-цели и технические аспекты, чтобы прийти к оптимальному, конвергентному решению.
Целенаправленный процесс разработки позволяет заинтересованным сторонам: [3]
- Откройте для себя варианты использования, адаптированные к требованиям в соответствии с бизнес-целями
- Установите мост между целями и ИТ-архитектурой
Ключевые принципы
[ редактировать ]
Совместное определение целей
[ редактировать ], тесно связанная с парадигмой «Цель-Вопрос-Метрика» , Цель верхнего уровня определяется как неформальное описание того, что заинтересованная сторона хочет изменить или улучшить в своей бизнес-среде, разбиваясь на более конкретные подцели . Более того, с каждой целью связан набор вопросов, который характеризует способ тестирования программного обеспечения на соответствие определенным целям после каждой итерации .
Поскольку это ключевой принцип ВВП, совместное определение целей объединяет знания пользователей и разработчиков программного обеспечения. В то время как определение цели осуществляется сверху вниз, решение о том, достижима ли цель, ориентировано снизу вверх.
Конвергенция сверху вниз и снизу вверх
[ редактировать ]- Дополнительную информацию см. в разделе Проектирование сверху вниз и снизу вверх .
В то время как ориентация сверху вниз поддерживает горизонтальную организацию команды, подходы снизу вверх пытаются предоставить обобщенные компоненты или услуги, что приводит к большей удовлетворенности пользователей. [4] Совместное определение целей, введенное ВВП, позволяет сочетать аспекты «сверху вниз» и «снизу вверх» (« мышление сверху вниз и действие снизу вверх »). [1] ) для поддержки согласованности артефактов и обеспечения вертикальной организации команды.
Вертикальная организация команды
[ редактировать ]В отличие от горизонтально организованных проектных групп, где программисты реализуют решение, заданное командой моделирования, вертикальная организация, подразумеваемая ВВП, требует опытных и квалифицированных специалистов широкого профиля. Как утверждает IBM Rational Unified Process , отдельные разработчики могут и должны брать на себя несколько ролей в проекте, чтобы избежать ненужных коммуникационных издержек и конфликтов.
Роли и люди
[ редактировать ]Из-за своей вертикальной организации ВВП требует квалифицированных специалистов широкого профиля, способных выполнять многие роли в этом процессе:
- Программисты (отвечают за конвергенцию сверху вниз и снизу вверх)
- Бизнес-аналитики (сотрудничают с программистами во время определения цели и в дальнейшем во время тестирования)
- Архитекторы программного обеспечения (следят за всем проектом)
- Менеджер проекта (распределяет ресурсы, следит за временем и усилиями, создает продуктивную среду)
- Инженер по требованиям
Минимизация размера проекта
[ редактировать ]Согласно ВВП, еще одним ключом к успеху в крупных проектах является минимизация размера проекта во всех аспектах, т.е. ограничение количества целей и программных артефактов, таких как документы, спецификации требований, модели и т. д., а также ограничение количества участников проекта, чтобы избежать взаимного ожидания и размера кода.
Минимизация размера приводит к повышению ремонтопригодности и возможности изменения системы под бизнес-процессы, поскольку они являются наиболее вероятным фактором изменения в будущем. [5]
Деятельность
[ редактировать ]Каждая итерация начинается с определения бизнес-целей и их приоритетов и заканчивается запуском рабочей версии программной системы, соответствующей выбранным целям.
Хотя поэтапная разработка системы программного обеспечения также выполняется в других процессах разработки программного обеспечения , объем итерации GDP расширяется и включает обсуждение бизнес-целей после каждой итерации, поскольку считается, что сами бизнес-цели созревают при наличии пригодной для использования реализации. [1]
Основными видами деятельности являются:
- Определение и приоритезация целей (небольшие группы максимум из 5 человек, состоящие из заинтересованных сторон и/или бизнес-аналитиков и программистов)
- Вертикальное распределение задач (выбранные цели распределяются по группам максимум из 4 программистов)
- Внедрение и тестирование (тесты, ориентированные на реализацию во время реализации, тесты, ориентированные на цели, в конце каждой итерации)
Эту деятельность также можно разделить на шесть основных этапов: [3]
- Группировать бизнес-требования по целям
- Формализуйте целенаправленное поведение системы внутри процессов.
- Отслеживать прогресс в реализации целей (по желанию)
- Распределите обязанности между участниками процессов
- Подключите поведение к целенаправленной архитектурной основе и играйте.
- Интегрируйте ограничения приложений актеров
Ссылки
[ редактировать ]- ^ Jump up to: а б с д Шнабель, И.; Пицка, М (2006). «Целевая разработка программного обеспечения» . 2006 г. 30-й ежегодный семинар IEEE/NASA по разработке программного обеспечения . ШИТЬ. 2006. Компьютерное общество IEEE. стр. 59–65. дои : 10.1109/SEW.2006.21 . ISBN 0-7695-2624-1 . S2CID 2964715 . Проверено 30 декабря 2008 г.
- ^ Отчет о хаосе. Технический отчет, Standish Group , 1994 г.
- ^ Jump up to: а б Беркем, Бирол (март – апрель 2006 г.). «Как привести ИТ в соответствие с Изменениями с помощью UML и по BMM» . Журнал объектных технологий . 5 (2): 85–102. дои : 10.5381/jot.2006.5.2.c9 . Проверено 30 декабря 2008 г.
- ^ Пицка, М.; Бауэр, А. «Краткая нисходящая и восходящая философия эволюции программного обеспечения» . ИПВСЕ. 2004. Компьютерное общество IEEE . Проверено 30 декабря 2008 г.
- ^ Панас, Лёве, Асманн. На пути к единой архитектуре восстановления для реверс-инжиниринга. Учеб. стажера. Конф. по разработке и практике программного обеспечения SERP'03, том 1, страницы 854–860, Лас-Вегас, Невада, июнь 2003 г. CSREA Press.
