Nós, Desenvolvedores

SEMAT – Repensando a Engenharia de Software

2010-01-06T23:23:00.001-02:00

Recentemente, notáveis do mundo da engenharia de software, liderados por Ivar Jacobson, Bertrand Meyer and Richard Soley, criaram um movimento para rediscutir as bases da engenharia de software.

O “SEMAT (Software Engineering Method and Theory) – Call for Action” sugere que não há organização na engenharia de software, que suas práticas são imaturas e, assim, convoca a comunidade para trabalhar seus fundamentos. O ponto de partida é a definição de uma base mínima conceitual, nomeada pelos idealistas por “Kernel”. A importância deste Kernel está na necessidade de “elencarmos o conjunto de elementos que são essenciais a todos esforços do desenvolvimento de software, um BoK (Body of Knowledge) compartilhado para acadêmicos, pesquisadores e profissionais”.

De fato, um dos pontos elencados pelo grupo como o principal problema da engenharia de software atual é a divergência entre a teoria do mundo acadêmico e a prática nas empresas. Em boa parte, este gap é devido aos apelos de marketing e buzzwords a que nosso “mundo” (de TI) está sujeito e muitas vezes parece até idolatrar (por um tempo).

Além dos já citados Ivar Jacobson, Bertrand Meyer and Richard Soley, outros nomes bem conhecidos que já escreveram vários livros sobre processos, metodologias e melhores práticas na engenharia de software também apoiam a ideia. Para citar alguns: Scott Ambler, Philippe Kruchten, Robert Martin, Alistair Cockburn e Erich Gamma. É relevante notar que alguns destes foram autores de metodologias mais tradicionais e outros de boas práticas ágeis.

O movimento já consta com muitos adeptos mas também já provocou opiniões contrárias, como pode ser acompanhado no post: “Against SEMAT”. O autor é da opinião de que os formalismos comuns das engenharias já consagradas (diferente da jovem engenharia de software, de apenas algumas décadas) não são sempre aplicáveis no desenvolvimento de software.

Não sou adepto às comparações de engenharia de software com engenharia civil. Acho até injusta esta comparação, justamente pela diferença de maturidade entre as duas. Há um artigo interessante que tenta explicar o RUP através de analogia com a produção de um filme: “Introducing the IBM Rational Unified Process essentials by analogy”. Entretanto, dizer que o desenvolvimento de software é uma arte, apesar de poético, é assumir que não há maturidade para entregar software de qualidade e de acordo com as necessidades do cliente. E pior ainda do que assumir isso é não agir.

O movimento SEMAT tenta, de certa forma, colocar ordem no caos. Eliminar o estigma de que software é um produto imprevisível, instável e que bugs são normais.

Como profissional da área, ao ver tantos especialistas se unindo neste movimento, sinto-me na obrigação de participar. Se vc também deseja apoiar, pode se subscrever na página do SEMAT.

Que nós desenvolvedores e a engenharia de software tenhamos prosperidade em 2010!

SOA Manifesto

2009-11-24T00:01:00.001-02:00

Após o mundo de TI passar por algumas rodadas de disseminação do conceito SOA, sem esquecer de alguns tumultos “provocados” pelo post “SOA is Dead; Long Live Services”, alguns bam-bam-bans no tema, motivados por Thomas Erl e incluindo a autora do post citado, compilaram o “SOA Manifesto”. Segue uma tradução livre:

Manifesto SOA

Orientação a serviço é um paradigma que direciona o que você faz.
Arquitetura orientada a serviço é um tipo de arquitetura que resulta da aplicação de orientação a serviço.

Nós aplicamos orientação a serviço para auxiliar organizações a entregar valor de negócio sustentável de forma consistente, com maior agilidade e eficiência de custo, alinhado às necessidades de mudança do negócio.

Através de nosso trabalho nós priorizaremos:
Valor de negócio acima de estratégia técnica
Objetivos estratégicos acima de benefícios específicos de projeto
Interoperabilidade intrínseca acima de integração customizada
Serviços compartilhados acima de implementações de propósito específico
Flexibilidade acima de otimização
Refinamentos evolutivos acima de busca da perfeição desde o início
Ou seja, enquanto nós valorizamos os itens da direita, nós valorizamos ainda mais os itens da esquerda.

Princípios que Guiam o Manifesto SOA

Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis.
O escopo da adoção de SOA pode variar. Manter esforços gerenciáveis e dentro de limites significativos.
Produtos e padrões sozinhos não lhe fornecerão SOA nem aplicarão o paradigma de orientação a serviços para você.
SOA pode ser concretizada através de várias tecnologias e padrões.
Estabelecer um conjunto uniforme de políticas e padrões corporativos baseado em padrões de facto da indústria e da comunidade.
Buscar uniformidade no exterior e permitir diversidade no interior.
Identificar serviços através da colaboração entre interessados de negócio e tecnologia.
Maximizar o uso de serviços considerando o escopo atual e futuro de utilização.
Verificar se os serviços satisfazem os objetivos e requisitos de negócio.
Evoluir os serviços e sua organização em resposta ao seu real uso.
Separar os diferentes aspectos de um sistema que mudam em ritmos diferentes.
Reduzir as dependências implícitas e publicar todas as dependências externas para aumentar a robustez e reduzir o impacto de mudanças.
Em todo nível de abstração, organizar cada serviço em torno de uma unidade de funcionalidade coesa e gerenciável.

E ai, concorda? Então vai lá e “assina embaixo”! :-)

Engenharia de Software – Escopo, Prazo, Custo e Qualidade

2009-11-18T00:15:00.001-02:00

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!

Certificação - Análise e Design

2009-03-15T22:30:00.000-03:00

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:

Test 833 - Object Oriented Analysis and Design - Part 1 (Analysis): trata questões relacionadas ao entendimento do problema;
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!!!

Refatoração em Banco de Dados

2009-02-17T15:50:00.000-03:00

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.

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.

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!

WebServices - Integração X SOA

2008-08-03T18:51:00.002-03:00

(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).

Papéis em SOA - Identificando Serviços

2007-09-30T22:04:00.000-03:00

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

Desenvolvimento de Software e SOA

2007-09-27T22:36:00.000-03:00

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.

Certificação SOA

2007-09-18T16:57:00.000-03:00

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!

WTC 11/9 - IBM Forum Brasil

2007-09-11T22:25:00.002-03:00

Ok. Foi intencional o título. Era pra chamar atenção mesmo! (aprendi isto em outro blog)

Mas tirando a coincidência do local e data, não se trata de choques ou explosões. Pelo menos, não fisicamente.

Estou usando este espaço para passar um pouco da minha visão sobre este evento, o IBM FORUM Brasil. Diga-se de passagem, um GRANDE evento. Considerando que é realizado por uma única empresa, mesmo do porte da IBM, é impressionante a quantidade de pessoas e temas. Nesta primeira edição do Forum no Brasil, a Big Blue, comemorando seus 90 anos no país, juntou seus funcionários, parceiros e clientes num evento cuja palavra de ordem é Inovação.
Aliás, Inovação foi repetida várias vezes e frisada pela jornalista Fabiana Scaranzi, condutora das sessões plenárias.

Bom, vamos aos resumos dos principais assuntos que pude acompanhar. Mas, antes, é importante esclarecer que o intuito aqui é despertar a atenção para assuntos interessantes, inovadores, e não nos produtos da IBM. Mas é inevitável falar deste evento sem citar tais produtos.

GIO (Global Innovation Outlook)
Eu não conhecia esta iniciativa. Trata-se de uma reunião de líderes de opinião, do mundo, que discutem sobre oportunidades emergentes da intersecção da tecnologia, dos negócios e da sociedade.
A última edição, chamada de GIO 2.0, reuniu 248 líderes de opinião de 36 países e regiões que discutiram sobre as três áreas de foco:

Futuro da Empresa: o que muda com a era do conhecimento?
Transporte: a mobilidade será facilitada? e os grandes centros?
Ambiente: quais áreas de sustentabilidade ambiental contêm a maior promessa para a inovação dos setores público e privado?

Cada uma abre espaço para oportunidades de Inovação.

Freaknomics
O co-autor do livro "Freaknomics - o lado oculto e inesperado de tudo que nos afeta", Stephen J. Dubner, jornalista colaborador do The New York Times apresentou, baseado nas histórias do livro, uma visão diferente, inovadora, de enxergar as questões econômicas. A idéia básica passada é que "... a economia é mola propulsora das atitudes e dos relacionamentos humanos.". Tudo depende de um incentivo, e incentivos têm relação direta com a inovação.
Lembrei-me de uma palestra sobre Empreendedorismo em que o palestrante frisou muito a importância da inovação, de enxergar os fatos de forma diferente, de questionar o óbvio, de se sobressair, de evitar a mesmice.
Nota: não li este livro, mas fiquei empolgado para ler!

Após estas introduções de Inovação, fomos às palestras.

Palestras
Dynamic Warehousing
Ou, segundo os jargões: Information on Demand.
O objetivo principal é "integrar" os mundos Transacional e OLAP. Utilizar dados analíticos (modelos preditivos) em sistemas transacionais.
Na visão SOA, pode-se dizer que é um BI orientado a serviço.
Com relação ao BI tradicional, ao trabalhar com a informação, a intenção é mudar o foco do Analista de BI para o Consumidor de Serviços.
Ex.: Supermercado. Diferente de realizar análises para encontrar quais produtos são comumente adquiridos em conjunto pelos clientes (caso clássico das Fraldas e Cervejas), a fim de montar as pratileiras com estes produtos próximos, a idéia é oferecer produtos ao cliente no momento do pagamento, "analisando" em real-time que outros produtos relacionados ele poderia, potencialmente, adquirir.
É uma visão mais dinâmica, em tempo-real. Montar tal solução expondo serviços gera oportunidades mais flexíveis de negócio, além de promover uso mais efetivo da solução de BI da empresa. E, certamente, requer uma solução (soft+hard) voltada especificamente para tratar estas necessidades. (Nem tudo são flores)

DataPower
De forma resumida, e até simplista, DataPower é o nome de uma solução da IBM para resolver, via hardware, problemas de desempenho de software.
Especificamente a solução DataPower SOA Appliance, auxilia em resolver:

Desempenho em transformação de mensagens XML (além de outros formatos)
Processamento de alto volume de mensagens XML
Segurança (triple A, criptografia, segurança contra ataques, etc)

Tudo isto via hardware. Estes hardwares são dividos em três categorias:

Verde: acelerador de XML (transformação, parsing, etc)
Amarelo: segurança
Azul: similar a um ESB, um ESB light

A solução Amarelo inclui as features da Verde, e a Azul inclui as features das outras duas.

Governança SOA
Há muita discussão no evento sobre Governança SOA, ciclo-de-vida de Serviços, etc
É possível perceber que, apesar de haver soluções sofisticadas para tratar destes assuntos, elas, aparentemente, ainda não se conversam totalmente. Isoladamente, já estão bem maduras, mas alguns pontos de intersecção entre estas soluções ainda estão soltos.
Assim, citando algumas das ferramentas:

RAM - Rational Asset Manager: ferramenta que apóia o cliclo de desenvolvimento, promovendo o reuso de ativos digitais; foco no build;
WSRR - WebSphere Service Registry and Repository: ferramenta usada para gerenciar o ciclo-de-vida de um Serviço; foco no runtime;
CCMDB: base de Itens de Configuração; suporte para ITIL;
ITCAM for SOA: ferramenta que monitora os Serviços atualizando suas informações nas bases do WSRR e CCMDB.

É possível pesquisar/incluir Ativos Digitais na base corporativa durante o ciclo de desenvolvimento, promovendo assim o reuso de componentes e Serviços. É possível definir o ciclo-de-vida de Serviços e suas características (WSRR), é possível acompanhar o status destes Serviços em runtime (ITCAM for SOA + WSRR + CCMDB).
Mas, há menos que se empregue algum esforço (customização), parece ainda não ser possível rastrear impactos de outros Ativos (servidores, sistemas, etc) nos Serviços, mantendo todas estas soluções sincronizadas.

Perguntas sem uma resposta concreta:

Quais informações/artefatos que compõem um Serviço são registradas no RAM? E quais são registradas no WSRR? É necessário, realmente, ter estas duas ferramentas separadas?
Uma mudança em um servidor irá afetar a disponibilidade de quais Serviços?
A alteração de informação/status de um Serviço será refletida, automaticamente, no CCMDB?

developerWorks
O portal developerWorks reúne demos, trials, apresentações, etc sobre os produtos da IBM. Mas também contém uma quantidade enorme de artigos técnicos. Muitos destes artigos sequer citam produtos da IBM. São diversos canais como: fóruns, blogs, wikis, Second Life.
Considero de leitura obrigatória pra quem usa/depende de soluções de desenvolvimento da IBM. E mesmo pra quem não usa nada da IBM, há artigos excelentes sobre os mais diversos temas, como J2EE, SOA e Grid Computing.

Por enquanto é isso, mas o evento continua.

3 Leis da Robótica e TI

2007-03-20T09:21:00.000-03:00

SOA é a “palavra” da vez. E assim promete ser por um bom tempo. Então, vamos falar sobre SOA.

A grande promessa de SOA é mudar a relação “Biz X TI” para “Biz com TI”.

Vamos explorar isto de forma, digamos, diferente!

O título deste blog tenta homenagear Isaac Asimov, fazendo uma alusão a uma de suas grandes obras “Eu, Robô”.
Nesta obra, o autor elenca as famosas “3 Leis da Robótica”:

1 - Um Robô não pode fazer mal a um ser humano ou, por inação, permitir que algum mal seja causado a um ser humano;
2 – Um Robô deve obedecer a um ser humano, desde que a primeira lei não seja infringida;
3 – Um Robô deve proteger a sua integridade física, desde que não entre em conflito com as duas leis anteriores.

Vamos fazer um paralelo com TI e criar nossas “3 Leis da BizIT”:

1 – A TI não pode engessar o Negócio ou, por falta de ação, permitir que o negócio seja engessado; (Ou seja, deve ser flexível para atender as mudanças de Negócio e, preferencialmente, de forma pró-ativa.)
2 – A TI deve atender as exigências do Negócio, desde que a primeira lei não seja infringida; (Ou seja, ao atender as exigências do Negócio, a TI não pode comprometer o próprio Negócio mas deve atender de forma adequada.)
3 – A TI deve se manter, desde que não entre em conflito com as duas leis anteriores. (Ou seja, deve se manter atualizada, dentro dos padrões de mercado, tornar-se centro de excelência, desde que não comprometa as exigências do Negócio ou imponha barreiras às suas necessidades de mudança.)

Ou seja: TI alinhada ao Negócio = Biz com TI = Flexibilidade+Agilidade+Timetomarket = Orquestramento de Serviços de Negócio = BPM+SOA

Prazer em conhecê-los

2007-03-15T22:18:00.000-03:00

Olás, caros amigos Desenvolvedores!
Aqui pretendo manter contato com vcs, reportando soluções criativas para os problemas do dia-a-dia em TI.
Gostaria de usar este espaço para trocar idéias, compartilhar dificuldades da "vida em TI" e, claro, falar de "coisas" técnicas, como tecnologias, metodologias, melhores e piores práticas, livros, etc
Deixem seus comentários sempre que quiserem. As críticas servirão para melhorar a qualidade do blog.
É isso, prazer em conhecê-los,
Deley.