Браунфилд (разработка программного обеспечения)
 | Эта статья нуждается в дополнительных цитатах для проверки . ( май 2018 г. ) |
Разработка новых программных продуктов — это термин, обычно используемый в индустрии информационных технологий для описания проблемных областей, требующих разработки и развертывания новых программных систем при непосредственном наличии существующих (устаревших) программных приложений/систем. Это означает, что любая новая архитектура программного обеспечения должна учитывать и сосуществовать с уже существующим программным обеспечением .
В современном гражданском строительстве заброшенная земля означает собственность, расширение, реконструкция или повторное использование которой может быть осложнено наличием или потенциальным присутствием опасного вещества, загрязняющего вещества или загрязняющего вещества.
Разработка Браунфилда добавляет ряд улучшений к традиционным практикам разработки программного обеспечения . Они традиционно предполагают целевую среду «чистого листа бумаги», tabula rasa или « чистой земли » на всех этапах проектирования и реализации разработки программного обеспечения. Браунфилд расширяет такие традиции, настаивая на том, чтобы контекст (локальный ландшафт) создаваемой системы учитывался при любом развитии. Это требует детального знания систем, сервисов и данных в непосредственной близости от разрабатываемого решения.
Решение проблем окружающей среды
[ редактировать ]Надежная реорганизация существующей бизнес- и ИТ-среды в современную конкурентоспособную интегрированную архитектуру является нетривиальной задачей. Сложность деловой и ИТ-среды накапливалась почти беспрепятственно в течение сорока лет, делая изменения все более дорогостоящими. Это потому, что:
- Сложность окружающей среды часто выражается в устаревшем коде . Нехватка устаревших навыков приводит к увеличению затрат на обслуживание и интеграцию.
- Существующие сложные среды необходимо перепроектировать поэтапно, чтобы они имели операционный смысл для связанных с ними бизнес-функций. На этих этапах часто по умолчанию выполняются массовые и рискованные замены систем, поскольку незнание существующей сложности означает, что потенциальные постепенные изменения слишком сложны для понимания и разработки.
- Методы ускоренной разработки оставили предприятия с современными устаревшими системами. Сложные приложения Java и .NET имеют многие из тех же проблем, что и старые приложения COBOL .
В результате все большая часть усилий по развитию новых бизнес-возможностей тратится на понимание и интеграцию с существующей сложной системой и бизнес-ландшафтом, а не на создание ценности. Было замечено [ кем? ] что до 75% общих усилий по проекту теперь тратится на интеграцию и миграцию программного обеспечения, а не на новые функциональные возможности. [ нужна ссылка ]
ИТ-индустрия в целом не очень успешно обеспечивает столь масштабные изменения для своих клиентов. Исследование CHAOS, проведенное Standish Group, выявило общее улучшение успешности реализации ИТ-проектов за последние двадцать лет, но даже в 2006 году крупные ИТ-проекты по-прежнему чаще терпели неудачу, чем добивались успеха. Инженерные изменения и в таких условиях имеют много параллелей с проблемами строительной отрасли, связанными с реконструкцией промышленных или загрязненных территорий. Они полны опасностей, неожиданных сложностей, а их реконструкция, как правило, рискованна и дорога. Накопившаяся сложность ИТ-среды сделала их «заброшенными» объектами.
Не сложность новой функции или какие-либо новые характеристики системы являются корнем неудач крупных проектов, а наша [ чей? ] понимание и информирование об общих требованиях (как указано в «Мифическом человеко-месяце »). Чтобы добиться успеха, требования должны включать точное и глубокое понимание ограничений существующего бизнеса и ИТ. Современные инструменты и методы « гринфилда » используют ранние, неформальные и зачастую неточные абстракции, которые по существу игнорируют такую сложность. Ранние, плохо информированные абстракции обычно ошибочны и часто обнаруживаются на поздних стадиях разработки, что приводит к задержкам, дорогостоящей доработке и даже неудачным разработкам. Подход, ориентированный на уже существующие проекты, учитывает существующую сложность и используется для надежного ускорения общего процесса разработки решения, включая обеспечение поэтапных, постепенных изменений, где это возможно.
Браунфилд использует стандартный подход OMG , основанный на моделях и шаблонах, и переворачивает его с ног на голову. Вместо того, чтобы использовать традиционный подход, начиная с концептуальной модели и переходя к моделям, специфичным для платформы, и генерации кода, Браунфилд начинает со сбора кода и других существующих артефактов и использует шаблоны для формальной абстракции вверх к уровням архитектуры и бизнеса.
Затем стандартные методы «с нуля» используются в сочетании для определения предпочтительной бизнес-цели. Этот метод «встречи посередине» знаком по другим методам разработки, но широкое использование формальной абстракции и шаблонов как для обнаружения, так и для генерации является новым.
Базовая концептуальная архитектура всех инструментов Brownfield известна как VITA. VITA означает «Виды, инвентарь, трансформация и артефакты». В архитектуре VITA определение проблемы целевого пространства может поддерживаться как отдельные (хотя и связанные) собственные «наборы» знаний, известные как представления. Основное преимущество представления заключается в том, что оно может быть основано практически на любом формальном инструменте. Браунфилд не навязывает какой-то один инструмент или язык в проблемном пространстве — основной принцип заключается в том, что «головы» продолжают сохраняться в своих родных формах и инструментах.
Затем собственные представления объединяются и связываются в единый инвентарь. Затем инвентарь используется с рядом возможностей преобразования для создания артефактов, необходимых для решения.
В настоящее время представления можно импортировать из самых разных источников, включая UML , XML источники , DDL , электронные таблицы и т. д. Инструмент Analysis and Renovation Catalyst от IBM еще больше расширил эту возможность за счет использования формальных грамматик и абстрактных синтаксических деревьев, что позволяет практически любая программа, которая будет проанализирована и токенизирована в представление для включения в инвентарь.
Быстрый циклический характер цикла открытия, реинжиниринга, генерации и тестирования, используемый в этом подходе, означает, что решения могут уточняться итеративно с точки зрения их логических и физических определений по мере того, как становится известно все больше ограничений и уточняется архитектура решения.
Итеративная разработка уже существующих проектов позволяет постепенно совершенствовать логическую и физическую архитектуру, а также проводить поэтапное тестирование всего подхода, что приводит к ускорению разработки, повышению качества решения и более дешевому устранению дефектов. Brownfield также можно использовать для создания документации по решению, гарантируя, что она всегда актуальна и согласована с разных точек зрения.
Инвентаризация, созданная в результате обработки Браунфилдов, может быть очень сложной, поскольку представляет собой взаимосвязанную многомерную семантическую сеть . Уровень знаний в Описи может быть очень детальным, очень подробным и взаимосвязанным. Однако такие вещи трудно понять, и они могут стать барьерами для общения. Brownfield решает эту проблему, абстрагируя концепции с помощью лучших догадок мастера, используя известные шаблоны в своих инвентарях для извлечения и вывода взаимосвязей более высокого уровня.
Формальные абстракции позволяют перевести сложность Инвентаря в более простые, но по сути точные представления для облегчения использования теми, кому необходимо понять проблемное пространство. Эти абстрактные модели инвентаризации можно использовать для автоматического рендеринга представлений многоуровневой архитектуры в таких инструментах, как Second Life .
Такая визуализация позволяет обмениваться сложной информацией и воспринимать ее несколькими людьми со всего мира в режиме реального времени. Это усиливает как понимание, так и ощущение единой команды.
См. также
[ редактировать ]- Схема проектирования Душитель, Адаптер, Мост
- Гибкая разработка программного обеспечения
- DevSecOps
- Рефакторинг
- Белый ящик (программная инженерия)
- Бизнес-логика