quarta-feira, 18 de novembro de 2009

Engenharia de Software – Escopo, Prazo, Custo e Qualidade

Sempre que falamos em desenvolvimento de software surge o triângulo:

Não há mágica a ser feita. Para uma mesma área, aumentar um lado implica em diminuir um outro. Mas isto pressupõe que o escopo é (totalmente) conhecido e, o mais importante, não sofrerá mudanças. Já foi esse tempo, não dá mais pra atender ao cliente com escopo fechado. Já dizia o filósofo Heráclito: “a única constante é a mudança”.

No artigo do Ivar Jacobson “Closing the Gap between Business and IT”, ele cita:

“We need to deliver results often and with high quality, on frequent intervals.  IT will have to accept that the business will change its mind about what it wants. This is a natural part of seeing results more frequently, and the feedback obtained is valuable and important. Frequent demonstrations of progress creates confidence and increases productivity, quality and it gives quick results.”

Em resumo, temos que saber lidar com a mudança e demonstrar resultados rapidamente e com qualidade.

Em outro artigo, da Marília Coelho, “Precisamos ser mais psicólogos que engenheiros para ter sucesso com engenharia de software”, a autora fala das dificuldades no entendimento do problema do cliente e cita uma frase de Einstein:

“Einstein certa vez afirmou que se ele tivesse uma hora para salvar o mundo, gastaria 55 minutos definindo o problema e apenas cinco minutos buscando a solução.”

Isto tem a ver com a “pressa” e com a visão míope do “dá pra fazer”, sem buscar o entendimento sobre a real necessidade do cliente e sem explorar as alternativas mais apropriadas.

Ela também cita alguns dados do Standish Group:

“41% dos projetos falham em adicionar valor ao negócio e sobre o Retorno de Investimento – ROI.

49% dos projetos ultrapassam as estimativas iniciais de custo.

Somente 28% dos projetos acontecem no prazo e no orçamento.”

O escopo fechado traz, no início do projeto, a ilusão da certeza do prazo e do custo. Qualquer mudança posterior é temida! A tal da “change request”!

A autora ainda discorre sobre a necessidade de mudança de cultura na engenharia de software e conclui:

“Para que os três pilares – processo, ferramentas e pessoas – funcionem de forma harmônica na organização, o suporte executivo é fundamental, pois as ansiedades, e a pressão do “fazer para ontem” são forças que devem ser gerenciadas corretamente. Os números mostram que continuar como está não é bom para o negócio e não é bom para TI. Pense em fazer algo para mudar o futuro da engenharia de software, conseqüentemente mudando a percepção de que TI não é um centro de custo, mas sim uma área que agrega valor ao negócio através da inovação tecnológica.”

Pensamentos Finais

Escopo muda, é um fato, e assim deveria ser tratado. Com entregas ágeis, frequentes e com qualidade o prazo (final) deixa de ser um “bicho-papão” e a previsibilidade sobre o custo torna-se maior. Ganhar a confiança do cliente, mantendo-o sempre envolvido, aumenta as chances de sucesso pois, no fim das contas, há um relacionamento humano.

Vida longa e próspera à engenharia de software!

domingo, 15 de março de 2009

Certificação - Análise e Design

Análise e Design são atividades do ciclo-de-desenvolvimento de software que lidam, respectivamente, com o tratamento/entendimento do problema e a "criação" da solução técnica para atender os requisitos de software do projeto.

No contexto do RUP (Rational Unified Process), Análise e Design são apresentadas no formato de uma disciplina. Esta disciplina engloba fluxo de trabalho, atividades, papéis e artefatos que orientam o entendimento do problema e a elaboração da solução técnica do software a ser desenvolvido. É nesta disciplina que um dos assuntos mais relevantes do processo unificado é tratado: Arquitetura de Software.

Este post cita, para os amigos leitores, duas certificações relacionadas a A&D.

A primeira não se trata realmente de uma certificação de A&D, mas de UML. Ou seja, tem o intuito de avaliar o quanto você domina a linguagem visual mais usada para representar os modelos de A&D.

 

Certificação UML - OMG:

Site para certificação UML 2 da OMG:

OMG Certified UML Professional (OCUP)

Há 3 níveis de certificação:

  • Fundamental: conceitos básicos, principais elementos e diagramas;
  • Intermediate: amplia o escopo e exige conhecimentos mais avançados dos elementos da UML;
  • Advanced: amplia ainda mais o escopo chegando a exigir conhecimentos sobre a arquitetura da linguagem, representação de semântica usando UML, relação com MDA, conhecimento da OCL (Object Constraint Language) que é uma linguagem de texto que estende a UML para definições e restrições de modelos e metamodelos que não são simples ou mesmo possíveis de serem feitos por diagramas, etc.

Para nós, reles mortais, não parece valer muito a pena ir além da Intermediate. Talvez a Fundamental já baste.

Apesar de interessante (principalmente para o mercado), a certificação de UML, como já dito acima, é limitada à especificação de UML. No escopo de A&D, UML é uma ferramenta (poderosa) que pode ser usada para representar os modelos, através de seus vários diagramas: caso de uso, classes, sequência, implantação, para citar alguns.

De outra forma, uma certificação que avalie o grau de maturidade de um analista quanto ao emprego da UML como ferramenta, além do conhecimento de padrões de design e boas práticas de A&D (baixo acoplamento, alta coesão, poder de abstração, identificação de interfaces, etc) parece ser mais relevante.

A certificação de A&D da IBM Rational abrange todos estes quesitos. Entretanto, é bom deixar claro que ela é fortemente baseada na disciplina de A&D do RUP. Ou seja, além de avaliar estes quesitos, ela também exige seus conhecimentos específicos na disciplina de A&D do RUP. Não sei se isto pode ser ruim, visto que RUP é um dos processos mais seguidos no mundo. Assim, mesmo que sua empresa não siga o RUP, um profissional com conhecimento profundo sobre esta disciplina só tem a acrescentar. Isto se aplica especialmente para arquitetos de software e designers.

 

Certificação A&D - IBM Rational:

Site para certificação de A&D da Rational:

IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2

Para obter a certificação é necessário passar em 2 testes:

  1. Test 833 - Object Oriented Analysis and Design - Part 1 (Analysis): trata questões relacionadas ao entendimento do problema;
  2. Test 834 - Object Oriented Analysis and Design - Part 2 (Design): exige conhecimentos que afetam a definição da solução técnica para os requisitos de software.

Referências

- Livros sobre o assunto que vale a pena conferir:

- Um colega blogueiro postou algumas dicas sobre A&D, confiram em: Análise e Design: Para que serve e como fazer? [José Papo].

 

Dicas

- Estude bem a disciplina de A&D do RUP

- Leia os livros UML Distilled e Applying UML and Patterns

- Entenda a aplicação de design patterns

- Por último, mas talvez o mais importante: pratique A&D!

Boa Sorte!!!

terça-feira, 17 de fevereiro de 2009

Refatoração em Banco de Dados

Muitos de nós já estamos acostumados com o termo Refactoring, uma boa prática amplamente divulgada por Martin Fowler

Refatoração = remodelar (reprojetar) sem alterar comportamento.

O termo tornou-se comum quando falamos em programação orientada a objetos, mas o conjunto de boas práticas pode ser estendido a outros nichos, como programação em banco de dados.

O livro “Refactoring Databases”, do Scott W. Ambler, trata das técnicas de refactoring empregadas em banco de dados (mais informações ao final).

Selecionei deste livro 2 exemplos de Refatoração em Banco de Dados: “Replace Column” e “Merge Columns” . Segue resumo.

 

1 – Replace Column (página 126)

Motivação: O tipo da coluna deve ser alterado (ex.: numérico para alfanumérico).

Exemplo: Para um dado sistema, a informação que identifica um Usuário deve ser mantida no formato Alfanumérico. Atualmente, esta informação é armazenada no BD no formato Numérico. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (CustomerID);

2) Torna-se a coluna que será substituída (CustomerNumber) deprecated. Ou seja, a coluna é marcada para eliminação. No exemplo, isto é representado através da indicação “{drop date = June 14 2007}”

a. Deprecate é um termo comum em Java utilizado para indicar que um método de uma classe está defasado e, possivelmente, será eliminado desta classe em uma próxima versão.

3) Cria-se uma trigger (SynchronizeCustomerIDNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = June 14 2007}”;

4) Converter os dados da coluna original para a nova coluna (CustomerNumber para CustomerID);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se a coluna anterior (CustomerNumber) e a trigger.

image

Figura 1. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Replace Column”.

 

2 – Merge Columns (página 92)

Motivação: Existência de colunas que guardam a mesma informação (replicação de informação); Informação “quebrada” em várias colunas; Colunas com informações similares que convergiram para uma mesma informação.  

Exemplo: Para um dado sistema, o número de telefone do Usuário deve ser mantido como uma informação única obtida da concatenação de Código de Área e Local. Atualmente, é guardado no BD separando os códigos de País, Área e Local. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (PhoneNumber);

2) Marca-se as colunas anteriores como deprecated. No exemplo, isto é representado através da indicação “{drop date = December 14 2007}”

3) Cria-se uma trigger (SynchronizePhoneNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = December 14 2007}”;

4) Converter os dados das colunas originais para a nova coluna (PhoneNumber = merge column);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se as colunas anteriores (PhoneAreaCode e PhoneLocal) e a trigger.

image

Figura 2. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Merge Columns”.

 

Mais sobre o livro

Antes de apresentar as técnicas de refatoração em si, o livro explica como a idéia surgiu e evoluiu. Também é apresentado um processo que visa orientar na aplicação destas técnicas. A importância sobre Testes em Banco de Dados é ressaltada.

Várias outras técnicas são apresentadas. Elas são subdivididas nas categorias: Estruturais (os 2 exemplos acima estão aqui), Qualidade de Dados, Integridade Referencial, Arquiteturais e Métodos.

Sobre o Autor:

O autor, Scott W. Ambler, é bem conceituado e já escreveu vários livros sobre os assuntos: Orientação a Objetos, Processo Unificado, Métodos Ágeis, EJB, Bancos de Dados, UML, etc

Ele mantém um site sobre suas obras.

URL: http://www.ambysoft.com/scottAmbler.html

Há também o site do livro que apresenta um “Catálogo de Refatorações de Banco de Dados”.

URL: http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Boa leitura!

domingo, 3 de agosto de 2008

WebServices - Integração X SOA

(Depois de um longo tempo sem postar, mas acumulando muita informação, vamos retomar o compartilhamento.)

Uma das primeiras dúvidas que surge quando se inicia o estudo de SOA é se "WebServices e Serviços em SOA" são a mesma coisa. A dúvida é natural, até mesmo por conta do termo "serviço".

Nota: Aliás, o termo "serviço" gera confusões a todo momento, não somente com relação a WebServices, mas porque se trata de um termo com aplicabilidade em vários contextos. E (felizmente ou infelizmente) não costumamos empregar "namespaces" ao estabelecermos diálogos. Assim, enquanto a adoção de SOA se encontra em processo de disseminação na empresa, conversas do tipo "melhorar a eficiência dos serviços da empresa" geram dúvidas sobre se estes "serviços" têm relação com SOA ou não. Pode ser que haja a relação, caso se trate de um processo de negócio automatizado, ou em vias de ser automatizado, que demandará o uso de Tecnologia da Informação para acesso a alguma funcionalidade de negócio, como por exemplo uma "reserva de tickets". Mas, pode ser que os "serviços" a serem melhorados sejam trabalhos operacionais que envolvam, por exemplo, a redistribuição de tarefas entre funcionários. Parece estranho, mas acontece. Vez por outra você estará questionando ou explicando que o "serviço" em questão trata-se ou não de SOA. E não raramente, passará a usar de termos como "Serviços SOA".

Um dos erros mais comuns é achar que o uso de WebService (WS) significa adotar SOA. SOA não se trata de uma tecnologia ou linguagem, mas uma mistura de um estilo arquitetural e método de desenvolvimento refletindo uma estratégia de negócio.

Alguns projetos requerem a integração entre aplicações de diferentes tecnologias. Isto pode ser realizado através de WS. Para projetos suportados por uma estratégia SOA, WS também podem ser utilizados como tecnologia para "concretização" dos serviços.

Segue um quadro comparativo do uso da tecnologia de WebServices nestas abordagens:

 

WS para Integração

WS em SOA

Foco

Técnico

Negócio

Requisitos

Interoperabilidade

Consumo (ou exposição) de funcionalidade de negócio

Desafios

Governança TI, Versionamento

Governança SOA, Versionamento, Granularidade

Benefícios

Flexibilidade para alterações na camada de integração

Interoperabilidade, Agilidade na mudança de processos de negócio

Ferramentas

UUDI, ESB

Registry, ESB, BPMS

WS - Integração X SOA

Algumas diferenças são sutis, como a questão da interoperabildiade. Em um problema de integração a interoperabilidade surge como um requisito, uma condição que deve ser atendida. Apesar de também ser importante em SOA, a interoperabilidade, ao utilizar WS, surge mais como um benefício.

A relação entre estas abordagens permeia entre a estratégia de negócio e o uso de tecnologia. Um problema de integração pode não demandar qualquer estratégia orientada a serviços. Entretanto, uma SOA tratará a integração como um de seus pilares.

 

Pensamentos Finais

Há uma diferença crucial na estratégia de uso da tecnologia WebServices para realização de Serviços em SOA e para Integração: "Meio e Fim". Enquanto que para Integração, WS pode ser a solução (fim). Para SOA, WS é o caminho mais apropriado atualmente (meio).

domingo, 30 de setembro de 2007

Papéis em SOA - Identificando Serviços

No post anterior - "Desenvolvimento de Software e SOA"- , foi abordada a importância da utilização de métodos, como SOMA, na identificação de serviços de negócio.

O objetivo deste post é exercitar os desafios do desenvolvimento de software, em uma SOA, quanto aos aspectos de comunicação, estabelecimento de responsabilidades e inter-relacionamentos entre papéis, com foco em identificação de Serviços de Negócio.

O relacionamento entre os diferentes papéis dentro de SOA é fator fundamental para que Processos e Serviços de Negócio sejam identificados, elaborados e construídos utilizando-se de forma sábia os recursos do projeto. Uma mesma solução pode ser atingida de formas diferentes. Mas se puder ser otimizada, promovendo reuso e definindo corretamente os Serviços de Negócio, o sucesso da solução de um projeto refletirá na empresa dentro de outros projetos.

Para não perder o foco - da identificação de serviços - serão explorados apenas aqueles papéis cujas responsabilidades mais se aproximam das atividades de modelagem de negócio, levantamento de requisitos e definição de serviços.

Definição e Responsabilidades
A tabela abaixo apresenta as definições e responsabilidades dos principais papéis, no que se refere a Identificação de Serviços de Negócio, no contexto de uma SOA.

Papel

Definição

Responsabilidade

Cliente

Interessado maior na solução, dono do processo.

Expor necessidades do negócio, gerenciar o processo de negócio.

Analista de Negócio

Profissional de TI ou de área de Negócio que atua como a “ponte” entre cliente e TI.

Entender as necessidades do negócio, auxiliar na modelagem do negócio (desenho, simulação, otimização).

Analista de Requisitos

Profissional de TI que realiza o levantamento dos requisitos de software.

Entender as necessidades do negócio e como estas se traduzem em requisitos de software (funcionais e não-funcionais), procurando identificar serviços em potencial.

Arquiteto de Solução

Arquiteto com foco em integração de aplicações e identificação de serviços.

Entender as necessidades do negócio quanto a integração de soluções, reutilização de serviços, procurando identificar os serviços candidatos.

Arquiteto de Software

Arquiteto com foco em design de aplicações e de serviços.

Entender os requisitos de software e de integração, procurando elaborar o design de aplicações de forma a viabilizar serviços de aplicação e facilitar a composição de destes em serviços de negócio.


SOA - Papéis x Responsabilidades


Há outros papéis muito importantes dentro da construção de projetos focados em SOA. Alguns papéis como Gerente de Projetos, Desenvolvedor e Testador são cruciais para qualquer projeto de TI. Também poderíamos explorar papéis novos, como um Administrador de Serviços. Contudo, o foco deste post está na identificação das necessidades do negócio do cliente, no levantamento de requisitos e no mapeamento destas necessidades e requisitos em Serviços e Processos de Negócio.

Fluxo de Comunicação
O fluxo de comunicação entre os papéis apresentados anteriormente é mostrado na figura abaixo.
As principais trocas de informação entre estes papéis são representadas pelas setas. Certamente, algumas interações não apresentadas aqui podem ocorrer. Este fluxo procura ressaltar aquelas comunicações mais relevantes na Identificação de Serviços em uma SOA.

Fluxo de comunicação
  • Cliente e Analista de Negócios: O Cliente, normalmente, inicia a conversação com um Analista de Negócios. O Cliente expõe seus problemas e necessidades de negócio. O Analista de Negócios precisa ter habilidades de ouvir, interpretar, questionar, conduzir a conversa, auxiliar o Cliente na elaboração do problema, colocar-se na posição do Cliente e identificar oportunidades de Negócio não vislumbradas pelo Cliente.
  • Analista de Negócios e Analista de Requisitos: Após o entendimento das necessidades de negócio do Cliente, o Analista de Negócios precisa interagir com o Analista de Requisitos. Serão repassados ao Analista de Requisitos as necessidades de negócio, os critérios e limitações de regras de negócio. O Analista de Requisitos, então, inicia seu trabalho de levantamento de requisitos funcionais para atender ao negócio.
  • Analista de Requisitos e Cliente: Após ter um entendimento inicial do problema do Cliente e dos principais requisitos de negócios repassados pelo Analista de Negócio, o Analista de Requisitos inicia sua interação diretamente com o Cliente para coletar informações mais específicas. Os requisitos funcionais são refinados e começa a tomar corpo uma visão de sistema para o projeto.
  • Analista de Negócios e Arquiteto de Solução: O Analisa de Negócio necessita interagir com o Arquiteto de Solução a fim de que oportunidades de reuso de serviços sejam identificadas. Também são importantes as informações de negócio que demandarão trabalhos de integração de sistemas. O Arquiteto de Solução inicia seu trabalho de definição das arquiteturas candidatas.
  • Analista de Requisitos e Arquiteto de Solução: O Analista de Requisitos precisa interagir constantemente com o Arquiteto de Solução, principalmente, no início da definição de escopo e visão do projeto, para a definição dos requisitos não-funcionais do projeto. É muito importante nesta fase que os potenciais reusos de serviços e elaboração de novos serviços sejam identificados.
  • Arquiteto de Solução e Arquiteto de Software: Dentro do projeto, é muito importante que as figuras do Arquiteto de Solução e de Software mantenham uma comunicação estreita. O trabalho do Arquiteto de Software deve permitir que os serviços candidatos identificados pelo Arquiteto de Solução possam ser realizados pelos sistemas das camadas de aplicação e de componentes. O Arquiteto de Software deve ter discernimento para elaborar designs flexíveis para as aplicações e propor soluções adequadas para adaptar as aplicações legadas a fim de que estas possam ter o melhor aproveitamento de sua vida útil dentro da plataforma de integração da empesa.
  • Arquiteto de Software e Analista de Requisitos: Uma vez que o Analista de Requisitos e o Arquiteto de Software são os "mais próximos" da solução de software, estes precisam ter um grau alto de relacionamento. O Arquiteto de Software, assim como o Arquiteto de Solução, participam ativamente da definição de requisitos não-funcionais da solução.

Pensamentos Finais
O fluxo de comunicação apresentado considera que os papéis serão executados por diferentes pessoas dentro do processo. Todavia, é possível que uma mesma pessoa exerça mais de um papel. Isto seria compreensível para os papéis de Analista de Negócios e Analista de Requisitos, ou Arquiteto de Solução e Arquiteto de Software. Por um lado, o acúmulo de papéis pode acrescentar riscos dentro de um projeto e comprometer a qualidade final do trabalho. Por outro lado, a divisão excessiva de papéis entre pessoas diferentes pode apresentar dificuldades de comunicação. Foi ponderando os benefícios e as dificuldades que apresentei tal configuração.

Links de referência:
New Techniques for Requirement Management
Requiremens Process for SOA Projects
An Introduction to SOA Solution Scenarios
Create the Ideal SOA Team
SOA Project Planning Aspects

quinta-feira, 27 de setembro de 2007

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.

terça-feira, 18 de setembro de 2007

Certificação SOA

Segue um material de referência e dicas para estudar para os testes de Certificação SOA da IBM.
São duas certificações:
  • IBM Certified SOA Associate - valida a habilidade do candidato em articular o valor de SOA quanto a aspectos técnicos e de negócio. Para obter esta certificação, deve-se realizar o Test 664. São 54 questões de múltipla escolha a serem realizadas em 90 minutos e o score mínimo de 67%.
  • IBM Certified SOA Solution Designer - validada a habilidade do candidato em traduzir os requisitos do cliente de flexibilidade e agilidade do processo de negócio em uma solução de software com foco em serviço usando princípios de SOA. Para obter esta certificação, deve-se realizar o Test 665. São 59 questões de múltipla escolha a serem realizadas em 90 minutos e o score mínimo de 66%.
Links
Site para Certificações IBM SOA:
http://www-03.ibm.com/certify/certs/soa_index.shtml

IBM's SOA Foundation
: http://www.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/

Artigo com dicas de preparação para a certificação
: http://www.ibm.com/developerworks/webservices/edu/ws-dw-ws-soacert1.html

Dicas
A certificação SOA Associate é mais teórica. Foca em conceitos, boas práticas e padrões. É importante assimilar a visão SOA de alinhar TI ao negócio. Quando SOA se aplica e quando não.

A certificação SOA Solution Designer é mais complexa. Nela são exigidos os conhecimentos explorados na anterior, mas com uma visão de aplicação destes conhecimentos na solução de problemas com foco em SOA. São várias questões com cenários de problema onde SOA pode ou não se aplicar. Além disso, é fundamental o conhecimento da "solução" SOA da IBM. Esta certificação, diferente da anterior, explora o uso das ferramentas da IBM que apóia sua visão de SOA (ver IBM's SOA Foundation e IBM SOA Reference Architecture). Muito importante conhecer bem os padrões de tecnologia relacionadas a SOA: W3C, OASIS, WS*. São exploradas também questões de granularidade de serviços e governança.

Boa Sorte!