Brownfield (desenvolvimento de software) - Brownfield (software development)
Desenvolvimento brownfield é um termo comumente usado na indústria de tecnologia da informação para descrever espaços de problemas que precisam do desenvolvimento e implantação de novos sistemas de software na presença imediata de aplicativos / sistemas de software existentes (legados). Isso implica que qualquer nova arquitetura de software deve levar em consideração e coexistir com o software ativo já in situ . Na engenharia civil contemporânea , terreno brownfield significa lugares onde novos edifícios podem precisar ser projetados e erguidos considerando as outras estruturas e serviços já existentes.
O desenvolvimento brownfield adiciona uma série de melhorias às práticas convencionais de engenharia de software . Estes tradicionalmente pressupõem um ambiente de destino de "folha de papel em branco" ou " terreno novo " ao longo das fases de design e implementação do desenvolvimento de software. Brownfield estende essas tradições ao insistir que o contexto (paisagem local) do sistema que está sendo criado seja considerado em qualquer exercício de desenvolvimento. Isso requer um conhecimento detalhado dos sistemas, serviços e dados nas imediações da solução em construção.
Lidando com a complexidade ambiental
A reengenharia confiável dos ambientes de negócios e TI existentes em arquiteturas modernas e integradas competitivas não é trivial. A complexidade dos ambientes de negócios e de TI vem se acumulando quase sem controle há quarenta anos, tornando as mudanças cada vez mais caras. Isto é porque:
- A complexidade ambiental é freqüentemente expressa em código legado . A escassez de habilidades legadas está aumentando os custos de manutenção e integração.
- Os ambientes complexos existentes devem ser reprojetados em fases que façam sentido operacional para a função de negócios associada. Essas fases costumam ser substituições de sistemas por atacado e arriscadas, pois a ignorância da complexidade existente significa que as mudanças incrementais em potencial são muito difíceis de entender e projetar.
- Os métodos de desenvolvimento acelerado deixaram as empresas com sistemas legados modernos. Os aplicativos Java e .NET complexos têm muitos dos mesmos problemas dos aplicativos COBOL mais antigos .
Como resultado, uma proporção cada vez maior do esforço de desenvolver novos recursos de negócios é gasta na compreensão e integração com o sistema complexo existente e no cenário de negócios, em vez de entregar valor. Foi observado que até 75% do esforço geral do projeto agora é gasto na integração e migração de software, em vez de em novas funcionalidades.
O setor de TI como um todo tem uma baixa taxa de sucesso na entrega de mudanças em grande escala para seus clientes. A pesquisa CHAOS do Standish Group acompanhou uma melhoria geral no sucesso da entrega de projetos de TI nos últimos vinte anos, mas mesmo em 2006 grandes projetos de TI ainda falhavam com mais frequência do que bem-sucedidos. As mudanças de engenharia e em tais ambientes têm muitos paralelos com as preocupações da indústria da construção em reconstruir locais industriais ou contaminados. Eles estão cheios de perigos, complexidades inesperadas e tendem a ser arriscados e caros para reconstruir. A complexidade acumulada dos ambientes de TI os tornou sites “brownfield”.
Não é a complexidade da nova função ou quaisquer novas características do sistema que são a raiz de grandes falhas de projeto - é a nossa compreensão e comunicação do requisito geral (conforme identificado no The Mythical Man Month ). Para ter sucesso, os requisitos precisam incluir uma compreensão precisa e completa das restrições dos negócios e TI existentes. As ferramentas e métodos “ greenfield ” atuais usam abstrações iniciais, informais e muitas vezes imprecisas que essencialmente ignoram essa complexidade. Abstrações precoces e mal informadas geralmente estão erradas e muitas vezes são detectadas tarde na construção, resultando em atrasos, retrabalho caro e até mesmo em desenvolvimentos malsucedidos. Uma abordagem orientada para o Brownfield abrange a complexidade existente e é usada para acelerar de forma confiável o processo geral de engenharia da solução, incluindo a ativação de mudanças graduais e incrementais sempre que possível.
Brownfield pega o modelo padrão OMG / abordagem orientada a padrões e vira de cabeça para baixo. Em vez de adotar a abordagem convencional de começar com um Modelo Conceitual e descer para Modelos Específicos de Plataforma e geração de código, o Brownfield começa colhendo código e outros artefatos existentes e usa padrões para abstrair formalmente para cima em direção à camada de Arquitetura e Negócios.
As técnicas padrão do Greenfield são então usadas em combinação para definir o alvo de negócios preferido. Essa técnica de “encontro no meio” é conhecida de outros métodos de desenvolvimento, mas o uso extensivo de abstração formal e o uso de padrões para descoberta e geração são novos.
A arquitetura conceitual subjacente de todas as ferramentas Brownfield é conhecida como VITA. VITA significa Visualizações, Inventário, Transformação e Artefatos. Em uma arquitetura VITA, a definição do problema do espaço de destino pode ser mantida como "cabeças cheias" nativas separadas (embora relacionadas) de conhecimento conhecidas como vistas. A principal vantagem de uma Visualização é que ela pode ser baseada em praticamente qualquer ferramenta formal. Brownfield não impõe uma única ferramenta ou linguagem em um espaço de problema - um princípio básico é que as cabeças cheias continuem a ser mantidas em suas formas e ferramentas nativas.
As visualizações nativas são então reunidas e vinculadas em um único inventário. O Inventário é então usado com uma série de recursos de Transformação para produzir os Artefatos de que a solução precisa.
As visualizações podem atualmente ser importadas de uma ampla variedade de fontes, incluindo UML , fontes XML , DDL , planilhas , etc. A ferramenta Analysis and Renovation Catalyst da IBM levou esse recurso ainda mais longe por meio do uso de gramáticas formais e árvores de sintaxe abstrata para permitir quase qualquer programa a ser analisado e tokenizado em uma Visualização para inclusão no Inventário.
A natureza cíclica rápida do ciclo de descoberta, reengenharia, geração e teste usado nesta abordagem significa que as soluções podem ser refinadas iterativamente em termos de suas definições lógicas e físicas à medida que mais restrições se tornam conhecidas e a arquitetura da solução é refinada.
O desenvolvimento brownfield iterativo pode permitir o refinamento gradual das arquiteturas lógicas e físicas e testes incrementais para toda a abordagem, resultando em aceleração de desenvolvimento, melhoria na qualidade da solução e remoção de defeitos mais barata. Brownfield também pode ser usado para gerar a documentação da solução, garantindo que ela esteja sempre atualizada e consistente em diferentes pontos de vista.
O Inventário que é gerado através do processamento Brownfield pode ser altamente complexo, sendo uma rede semântica multidimensional interconectada . O nível de conhecimento no inventário pode ser muito refinado, altamente detalhado e inter-relacionado. No entanto, essas coisas são difíceis de entender e podem criar barreiras à comunicação. Brownfield resolve esse problema abstraindo conceitos por meio da melhor suposição de um artesão, usando padrões conhecidos em seus inventários para extrair e inferir relacionamentos de nível superior.
Abstrações formais permitem que a complexidade do Inventário seja traduzida em representações mais simples, mas inerentemente precisas, para facilitar o consumo por aqueles que precisam entender o espaço do problema. Esses modelos de inventário abstraídos podem ser usados para renderizar automaticamente representações de arquitetura em várias camadas em ferramentas como o Second Life.
Essas visualizações permitem que informações complexas sejam compartilhadas e experimentadas por vários indivíduos de todo o mundo em tempo real. Isso aumenta a compreensão e o senso de equipe única.