Desenvolvimento de Software e SOA

O desenvolvimento de software é um trabalho complexo. Esta complexidade é evidenciada nas dificuldades enfrentadas pelos projetos de software. Para contornar estas dificuldades, as pesquisas em engenharia de software geraram, ao longo dos anos, várias técnicas e metodologias de desenvolvimento visando tornar este trabalho mais simples. Evoluções partiram da programação estruturada, passando pela programação orientada a objetos, dirigida a componentes e, enfim, orientada a serviços. Estas evoluções tiveram, em comum, o objetivo de simplificar, reutilizar e utilizar-se de abstrações para tornar a unidade fundamental do software mais próxima da linguagem natural.

Níveis de Abstração
Segundo Grady Booch, os fundamentos de engenharia como abstrações e separação de interesses são sempre válidos. E há oportunidades reais para elevar o nível de abstração novamente. SOA introduz dois níveis de abstração: Serviços de Negócio e Processos de Negócio Corporativos. Serviços de Negócio Corporativos representam as capacidades de TI que estão alinhadas com as funções de negócio da empresa. Processos de Negócio definem o funcionamento geral do negócio da empresa, normalmente realizando orquestramento de Serviços de Negócio.

De acordo com o Gartner, SOA deslocará o foco do desenvolvimento das funções de software para funções de negócio, transformando software instalado de um inibidor a facilitador de mudanças rápidas no negócio. SOA tornar-se-á o framework dominante para criar e entregar software, movendo o valor do software empacotado para serviços de subscrição, e de suites monolíticas para aplicações compostas. A forma de pensar (abstrair) o software é novamente mudada.

Levantamento de Requisitos
Dentre as dificuldades do desenvolvimento de software, o levantamento de requisitos é freqüentemente apontado como um dos “vilões” responsáveis pelas falhas nos projetos de TI. São freqüentes os projetos que estouram o budget e/ou o prazo devido a requisitos incorretos, não levantados ou que sofreram mudanças. Segundo o Chaos Report, os três principais fatores que contribuem para dificuldades em projeto de software representam mais de 36% do total e estão relacionados à engenharia de requisitos. A tabela abaixo apresenta o resultado do Chaos Report para os fatores de dificuldades em projetos de TI.

Fatores de Dificuldade em Projetos de TI. [Fonte: Chaos Report]

Apesar da "defasagem" deste relatório (data de 1994), o que se percebe é que as dificuldades relacionadas a entender a diferença entre o que o usuário quer e o que ele precisa ainda existem. Por outro lado, muitos esforços foram e continuam sendo empregados para melhorar esta questão. O avanço da Engenharia de Requisitos, aumento de maturidade no uso de processos incrementais e uma maior "aceitação" quanto à natureza mutante dos requisitos têm contribuído.

Com a disseminação de SOA, o foco em desenvolvimento de serviços que apóiem o negócio faz ressaltar a importância do levantamento de requisitos. O uso de novas tecnologias e metodologias por si só não eliminarão os problemas. Faz-se necessário rever alguns artefatos, redefinir papéis e a interação entre eles, assim como definir ou redefinir processos.

SOMA
Recentemente, algumas metodologias têm ganhado espaço e amadurecido. É o caso da SOMA (Service-Oriented Modeling and Architecture) que aborda técnicas para identificar, especificar e realizar Serviços.

Método SOMA

Identificação
Consiste da combinação de técnicas top-down, bottom-up e middle-out, para elencar Serviços Candidatos.

• Na visão top-down, realiza-se a decomposição de domínio de negócio em suas áreas funcionais, processos, subprocessos e casos-de-uso de negócio. Estes casos-de-uso de negócio são fortes candidatos a Serviços de Negócio.
• Na visão bottom-up, os sistemas existentes são analisados e selecionados como candidatos viáveis a prover soluções de baixo custo para implementação das funcionalidades de Serviço que suportam os Processos de Negócio.
• Na visão middle-out, adota-se uma estratégia de identificar os Serviços candidatos que atendem a objetivos de negócio, associando-se métricas e KPIs aos Serviços. O principal objetivo desta visão é garantir o alinhamento com o negócio.
  

Especificação
Nesta fase ocorre a classificação dos Serviços, definindo características de hierarquia e composição. Avalia-se a interdependência entre serviços, mantendo a preocupação com sua granularidade. Especifica-se os detalhes dos componentes que implementam os Serviços.

Realização
Neste ponto decide-se sobre que sistema irá prover Serviços especificados, e que novos Serviços serão construídos. Também são exploradas as decisões quanto a segurança, gerenciamento e monitoração de Serviços.

(Um exemplo prático de aplicação do método SOMA pode ser visto no post de outro colega blogueiro.)

Pensamentos Finais
A realização de promessas por reuso, agilidade e time-to-market atualmente são esperadas pela SOA. Realizar estes benefícios, porém, irá requerer maior investimento em software, infra-estrutrua, habilidades (skills) e mudança de processos.