Blog em marcha lenta (quase parando)

Pessoal, por absoluta falta de tempo não estou atualizando este blog (até quando não sei). Mas sempre escrevo no blog da equipe Rational. 


Espero vocês lá!

SOA - Arquitetura Orientada a Serviços

Me espanto com a complicação que vejo no mercado quando o assunto é SOA. Também me espanta o desinteresse que vejo muitos desenvolvedores tratarem o assunto. Me espanta mais ainda a confusão que essa complicação e desinteresse juntos estão causando.

Costumo dizer que a maior contribuição que SOA trás para TI é a unificação do vocabulário em torno de uma palavra: serviço. Essa palavra permite que todos os interlocutores, desde o usuário, passando pelos analistas, desenvolvedores, gerentes de projeto até a área de operações/produção falem a mesma língua. Ao saber que num determinado servidor roda um serviço crítico para o negócio, a área de operações pode calcular o resultado de uma melhora no desempenho dessa máquina. A área de desenvolvimento pode mapear quais serviços suportam os processos de negócio e focar seus esforços no desenvolvimento dos serviços mais importantes.

Técnicamente, SOA não muda a maneira de desenvolver software. Mas do ponto de vista estratégico, permite que pela primeira vez se use um termo simples e que tem significado para quem depende do software. E isso unifica esforços e garante que todos os membros de toda a cadeia produtiva do software falem a mesma língua. SOA permite preencher o "gap" que existe entre o software (componentes) e o negócio (processos). É isso!

Aqui vocês podem ver uma palestra que ministrei na abertura de um curso de pós graduação em Engenharia de Software com UML.

Sobre modelagem de software utilizando SOA com UML, recomendo um estudo da técnica SOMA, e também do profile para serviços de software, desenvolvidos pela IBM.

Depois para descontrair, recomendo uma visita ao site www.soafacts.com. É hilário.

Grande abraço!

Exorcisando o RUP II - Executáveis e Iterações

As vezes, quando conhecemos algo, esquecemos de repetir as coisas básicas sobre ele porque são óbvias para nós. Mas nessa semana realizei algo que me deixou embasbacado: tem gente que ainda acha que as Iterações à lá RUP não terminam em software funcionando.

Vou ser direto (acho esse o grande defeito do RUP, tem muita coisa lá): segundo o RUP, o objetivo de TODA iteração é obter um release TESTÁVEL do software em desenvolvimento .

Agora vamos aos detalhes:
1. Esse release pode ser interno: a equipe vai realizar testes com ou sem a presença do usuário, ou
2. Externo: o software será efetivamente implantado "em produção" para o usuário começar a usar.
3. Existe uma única exceção para essa regra: as iterações da fase de Concepção podem não resultar em executável testável.

A razão para os itens 1 e 2 é que o RUP é um processo centrado em arquitetura e a arquitetura deve ser VALIDADA o mais cedo possível. Perguntas como: "o software vai suportar as X mil transações por segundo?" ou "nossa idéia vai acomodar a inclusão de novos produtos financeiros ao longo do projeto sem necessidade de 'grandes reformas'?", devem ser respondidas logo no início do projeto (fase de Elaboração). E quando digo que a arquitetura deve ser validada, isso significa software FUNCIONANDO e sendo trucidado por testes de carga e desempenho. Arquitetura não é desenho. Não é modelo. Não é framework. É software! Mas é a parte do software que garante o atendimento dos requisitos não funcionais e portanto não tem valor para o usuário. Por isso não é entregue, mas pode ser mostrado, para que o Stakeholder valide se o tempo de resposta está adequado, por exemplo.

Ao ler o Item 3, os "agileiros" de plantão devem ter pensado "A-ha! Sabia que o RUP não obrigava a produção de um software testável a cada iteração!". Lembrem-se, eu disse (e repito) que a regra é software funcionando ao final de cada Iteração. Porém, o RUP suporta o desenvolvimento do software desde antes da decisão de construi-lo. Imagine uma empresa que está examinando seus processos e decidindo quais devem/podem ser automatizados (por software): neste momento, coisas como ROI (Retorno Sobre Investimento) e Time-to-Market (a janela de tempo até que a primeira versão do software esteja funcionando e comece a dar retorno) devem ser avaliadas para decidir se vale a pena construido. Acontece que a maioria dos projetos começam depois dessa decisão (esse estudo já foi feito) e os requisitos já vão começar a ser definidos. Pois bem, neste caso não tem exceção: a iteração só termina com software funcionando sendo testado ao final de cada iteração.

Muita gente me pergunta: mas e se não terminar assim? A resposta é simples: então a iteração não terminou. "Ah! Mas segundo o cronograma, terminou." Neste caso você só está se enganando, porque a Iteração só termina com software funcionando sendo testado.

E é batendo o resultado dos testes contra os requisitos que o gerente do projeto vai aferir progresso e qualidade. Não olhando a pilha de documentos crescer. Nem olhando a percentagem da tarefa no Gantt Chart. Esse é um bom tópico para outro post.

É isso. Espero que não demore tanto pra falar mais (caso estejam gostando, comentem pois isso é um baita estimulo!)

Forte abraço!

Exorcisando o RUP

Decidi criar uma série de posts para desmistificar o (mal afamado) Rational Unified Process. A motivação nasceu depois de ouvir um monte de bobagens tanto de pessoas que aplicam no dia a dia quanto de pessoas que tem pré conceitos e nunca aplicaram o processo. Entre os preconceituosos encontro pessoas que tem verdadeira ogeriza ao termo RUP.

1o MITO: O RUP é pesado

A expressão nasceu em contrapartida ao termo "lightweight" (leve). Mas o que, afinal, é um processo "pesado"? Refere-se a burocrático? Lento? Incapaz de absorver mudanças? Com foco "nos meios" e não no fim?
Se "pesado" referir-se a um destes adjetivos, afirmo categoricamente: o RUP não é pesado.
A justificativa curta é: o RUP pode ser tão "leve" quanto necessário. No livro "Agile Software Development", Cockburn afirma que projetos grandes devem ser suportados por processos com cerimonial "menos leve" e que o processo sempre deve ser adaptado. O RUP é totalmente adaptável.

2o Mito: O RUP tolhe o desenvolvedor

O RUP define papéis, muitos (mais eu gostaria, é verdade) e um deles é "implementer" ou implementador. Você deve ter pensado: olha aê! Tá me reduzindo a um reles digitador.
Antes de mais nada deixa eu lembrar você de uma coisa: desenvolvedor, no linguajar do mercado, é o cara que põe a mão na massa e cria o software. Isso é um CARGO ou POSIÇÃO, como queira. O "implementer" do RUP é um PAPEL. Ou seja, o Desenvolvedor (cargo) preenche o papel de "implementer". Dentre outros! Isso mesmo, o cargo/posição do desenvolvedor deve ser mapeado para os papéis do RUP. Isto é a tal "adaptação" do processo.
Numa empresa que queira tomar uma abordagem "ágil", por exemplo, o desenvolvedor fará os papéis de: Requeriments Specifier/Reviewer, Software Architect/Reviewer, Designer, Implementer e Tester. Só para citar alguns.
Pô mas isso é muita coisa! Claro que é? Por acaso você trabalha pouco?
Acontece que grandes empresas (principalmente) estão em um processo furioso de terceirização e as "áreas de metodologia" dividem o jogo entre os que especificam (os analistas) e os programadores (os que codificam). O RUP, por ser o processo formal mais adotado hoje em dia, acaba pagando o pato pois o processo desenhado pela a empresa foi "inspirado/baseado" no RUP.

Bom, este é só um começo. Tenho dezenas de outros mitos a detonar. Caso tenha alguma idéia, por favor comente.

Abraço!!!

O que é SOA, afinal?

Frequentemente recebo emails de pessoas com dúvidas sobre SOA (Services Oriented Architecture) e sua aplicação prática. O último foi esse aqui:

"Oi Rodolpho, td bem?

Meu nome é Fulano-de-tal. Li um ebook seu na internet sobre SOA, e tb tenho lido alguns artigos sobre o assunto na internet. Tenho tido uma certa dificuldade pra entender esse conceito na prática. Minha dúvida é: SOA é uma maneira de se implementar os softwares, disponibilizando eles como serviços e garantindo que eles possam se integrar? Ou SOA é uma maneira de se integrar os softwares já existentes? Se vc fosse "oferecer SOA" pra minha empresa por exemplo, vc ofereceria serviços que tem a capacidade de se integrar ou uma solução para integrar o que
eu já possuo em minha impresa? Ou não é nada disso e entendi tudo errado? Agradeceria se vc tivesse dois minutinhos pra tirar essa dúvida minha. Se não tiver eu entendo.

Obrigado, Fulano-de-tal."

Essa foi minha resposta:

"Olá Fulano-de-tal.

É por aí mesmo: SOA é tudo isso ao mesmo tempo :-)

SOA é uma ABORDAGEM. Uma abordagem que afeta todas as esferas do desenvolvimento:

1. A implementação utilizando padrões abertos e interoperáveis (exemplo: WebServices);
2. O design (no sentido de projetar) com partes de fraco acoplamento, estanques e com interfaces bem definidas;
3. O projeto em si (no sentido de esforço de desenvolvimento) deve ser orientado a entregar partes atômicas (se possível orçadas e custeadas independetemente)
4. A organização como um todo: todos (o cliente da área de negócio, o pessoal de desenvolvimento e produção) passam a ter uma única unidade de medida: o serviço.

Do ponto de vista tecnológico/técnico SOA não traz nada de revolucionário ou realmente novo. O todo é que faz a diferença: a soma dessas diferentes visões pode mudar radicalmente a maneira como desenvolvemos software. Pense: o negócio existe "sistema" no ambiente de negocio. E se o negócio mudar, o sistema que suporta a empresa tem de mudar junto. E aí começam os problemas: você já foi conversar com o gerente do seu banco para pedir um impréstimo ou outro assunto qualquer? Reparou em quantas telas diferentes (web, caracter, aplicação local, etc) e quantas vezes ele precisa digitar o seu CPF ou o número de sua conta? Ele (o seu gerente) é o ponto de integração entre os diferentes sistemas.

Para piorar, e se parte do negócio for tercerizada? Como tirar um pedaço do "sistema" e terceriza-lo? Neste ponto o sistema (o software) passa a ser um entrave para que o negócio mude, dependendo de como foi construído. Falamos de sistemas a 40 anos... não faz mais sentido. Hoje os "softwares" que suportam as empresas formam uma imensa teia, um emaranhado de integrações que começam a engessar a capacidade de adaptação das empresas.

É aí que SOA brilha: ao mesmo tempo permite construir novos softwares de cima para baixo, também permite"desconstruir" os softwares existentes de baixo para cima sem destruí-los (mantendo seu funcionamento). É como se pegassemos um monte de fios todos emaranhados e começassemos a desembarassar aos poucos. Progressivamente. Eventualmente podemos ter de jogar fora o último "bolôlô", mas conseguimos aproveitar uma boa parte. Sem ter de refazer. Seja qual for a tecnologia: COBOL, .NET, Java, etc.

Portanto, é isso mesmo, você está no caminho correto: SOA tem significado diferente dependendo da esfera na qual a pessoa se encontrar. Mas pela primeira vez temos um vocabulário comum que faz sentido para todos: serviço de aprovação de crédito. Pode ser solicitado, melhorado, codificado, monitorado, implantado, backupeado, restaurado, acelerado... Desde o cliente até o analista de produção, passando pelo desenvolvedor e gerente de projeto sabem o que é o "serviço de aprovação de crédito". E isso faz sentido para todos.

Abraço,
Rodolpho"

É isso aí pessoal... madem comentários ou dúvidas que a gente conversa!

Certificação UML

Uma das dúvidas mais recorrentes é: "como posso me certificar em UML"?
Reposta: depende :-)

Primeiro você deve analisar para que servirá a certificação:
1. Engrossar o Curriculo;
2. Permitir à empresa atender a requisitos de RFPs;
3. Provar para alguém que você sabe UML;
4. Usar a prova como linha guia e um estímulo para estudar o tema;
5. Impressionar os amigos;
6. Todas as anteriores :-)

Não quero entrar no mérito de ter uma certificação, pois eu mesmo tenho reservas quanto à efetividade deste sêlo como prova de que se sabe algo. Como tudo na vida, existem prós e contras, e a prática de certificar é bastante controversa.

Hoje existem basicamente duas certificações bastante difundidas e reconhecidas no mercado: a da OMG, a entidade mantenedora da UML, e a da IBM Rational. A primeira é uma certificação que prova que você conhece (a fundo) a notação, seus muitos elementos e pormenores. A segunda é uma indicação que você sabe usar a notação num projeto real. Na verdade a certificação da IBM não é em UML mas em OOA&D - Object Oriented Analisys and Design.

Portanto, antes de pensar em como se capacitar precisa decidir o que quer provar (ou indicar que sabe) e para quem. Como sugestão, um raciocínio para ajudar a decidir:
- Se você é um instrutor de alguma tecnologia, técnica ou até mesmo linguagem de programação é uma boa mostrar que tem conhecimento profundo sobre UML. Portanto a certificação OMG é para você.
- Caso seja um membro de uma equipe de desenvolvimento de software ou profissional de desenvolvimento de software pode ser um diferencial mostrar que conhece as ferramentas necessárias durante o dia-a-dia do projeto. Neste caso, UML é mais uma ferramenta (uma ferramenta de pensar :o) e a certificação OOAD indica que você domina o necessário da notação e tem capacidade de por em prática os conhecimentos teóricos.

Costumo dizer que a certificação OMG para um desenvolvedor é mais ou menos como um Diploma de Engenharia Mecânica para um motorista: pode ser extramamente útil se o carro encrencar, mas no dia-a-dia não vai ajudar muito.
Por outro lado, a certificação da IBM é "rasa" em se tratando da notação em si (eu diria que cobre os 20% mais usados), focando no emprego da UML num projeto real de desenvolvimento de software.

Espero ter ajudado você a decidir qual prova de certificação prestar. Agora vou ajuda-lo a se preparar para as provas:

Certificação UML (OMG)
Não tenho esta certificação mas conheço pessoas que prestaram (e passaram) na prova e domino o conteúdo. Eu tenho certeza que seria reprovado algumas vezes porque simplesmente sou preguiçoso demais para decorar coisas (resultado da era Google e milhões de pobres neurônios devidamente afogados em muuuita cerveja). Este é o tom da prova: vai testar se você conhece os "pormenores" da notação e realmente entende a coisa "por dentro". Aqui vale um comentário especial: a UML é uma notação para ser entendida por seres humanos *E* por máquinas. Enquanto os elementos que usamos estão na "superfícies", existe uma amarração interna extremamente forte e organizada com regras formais por detrás de cada simbolo e relacionamento. Imagine o diagrama como sendo um painel com luzes e botões que tem por dentro quilômetros de fios e ligações. A máquina pode entender o modelo aqui entra a grande difereça da UML 2.x: a notação foi inteiramente reconstruída de dentro para fora, enquanto externamente pouco mudou (alguns novos diagramas e elementos), permitindo um grau de automação enorme mirando um mundo MDA - Model Driven Architecture, assunto para outro post.
Fontes de estudo:
1. Livros específicos de preparação (cada dia lançam um diferente, basta googlar o nome da certificação);
2. A especificação da Superestrutura da UML. É um pdf que pode ser baixado no site da OMG e se decidir *decora-lo* passa na prova. Mas atenção são quase 700 páginas de texto, que proporcionam um prazer de leitura parecido com bula de remédios. Quem passou na prova estudou forte por aqui e procurou entender o que se passa na "barriga do monstro";

IBM Rational OOA&D UML 2.0

Essa eu tenho. Como quem sabe sempre diz que é fácil, melhor eu não dizer nada. Para se preparar para esta prova você tem dois caminhos: ou sabe OOAD por ter aprendido na prática ou estuda e faz treinamentos.
Se você tem pelo menos 2 anos de experiência em desenvolvimento e projeto (detesto a palavra modelagem, tópico pra outro post) com UML, sabe o que é o Booch Method, sabe ir de um caso de uso até o diagrama de classes *passando pelo de sequência antes*, sabe o que são abstrações-chave, classes de fronteira, entidade e controle, então pode prestar as duas provas que vai passar tranquilo. Se não sabe, ou acha que a única maneira de chegar no código é extraindo o diagrama de classes diretamente dos requisitos, então recomendo fortemente um treinamento da IBM Rational que mantém turmas de OOAD regulares no calendário de turmas abertas de treinamento (este mesmo treinamento pode ser obtido junto a parceiros IBM certificados Rational). Este treinamento é tiro-e-queda: 4 dias de imersão com 2/3 do tempo em exercícios práticos que partem de um caso de uso, chegando ao final nas classes de implementação. Se você dedicar atenção, fizer com afinco e entender os exercícios, basta estudar com afinco os conceitos contidos no material (que não é pouco) que as chances são grandes de passar na certificação. De quebra, garanto que você vai melhorar seu skill de desenvolvimento de software :-). Bom, caso você assim como eu tenha ogeriza a sala de aula e nao queira fazer o treinamento, pode comprar o livro de OOAD do Booch e estudar por ele. Está TUDO lá. Mas atenção: a sua vida vai se dividir entre antes e depois deste livro. Bem... mas tem um problema: a técnica do Booch precede a UML e o livro ainda usa a notação Booch (uma nuvenzinha simboliza uma classe, que fofo :-)))), portanto, você terá um trabalho de traduzir mentalmente para UML.

É isso aí! Boas provas!

Requerimentos não são Requisitos

Apesar da aparentemente óbvia a diferença entre solicitação de mudança e requisito, vamos definir os dois termos:
Requisito: uma condição que deve ser atendida ou entregue;
Requerimento: uma "requisição" para que algo seja cumprido.

Vejo com frequência o uso de ambos como sinônimos. E podem até ser (acho que o são mesmo), mas neste post chamo de Requerimento o ATO de solicitar algo. Você pode fazer um "requerimento de mudança" no software e/ou projeto e, como resultado, ter um ou mais requisitos alterados e/ou criados. Então temos: Requerimento = Solicitação <> Requisito

A troca de um pelo outro ou a tentativa de resolver o problema de um lado sem cuidar do outro tem causado um bom estrago nas empresas: desde uma burocratização do processo de desenvolvimento até compra desnecessária de ferramentas.

Hoje em dia é bastante difundido que mais da metade dos problemas em projetos de software tem por causa raiz os requisitos (fonte: Chaos Report em http://www.standishgroup.com/) . Seja por falha na definição, no entendimento ou no gerenciamento. Não vou entrar no mérito neste post e acredito até que por essa informação estar bem difundida hoje em dia, é que a reação natural de toda empresa é achar que *todos* (ou quase) os problemas do desenvolvimento de software tem origem nos requisitos.

Ocorre que em qualquer empresa que possua software desenvolvido internamente temos um cenário onde 80%-90% do esforço de desenvolvimento é para manutenção de software e somente 10%-20% são novos desenvolvimentos. Portanto, se temos muito software com requisitos mal definidos ou, o que é bastante comum, nenhum requisito documentado, temos muita modificação no software sem manutenção nos respectivos requisitos (por que ou não existem ou estão desatualizados).

Portanto, quando uma organização decide "entrar de cabeça" no gerenciamento de requisitos, esquece que 80% a 90% do esforço é despendido MODIFICANDO requisitos existentes. Ora, se os requisitos não estão documentados, como proceder então? Estou para ver empresa que tope investir para fazer a engenharia reversa da documentação dos requisitos. Portanto, sobra somente uma alternativa: não modificar o requisito, mas somente a mudança no software.

A resposta certa para este imbróglio é uma abordagem mista: passa-se a documentar os requisitos dos novos desenvolvimentos (ou re-desenvolvimentos de coisas velhas) e catalogar as mudanças em softwares existentes.

Por isto vos digo: você sabe que tem problemas com requisitos, mas vá com calma. Atacar o touro de frente pode não ser a melhor alternativa neste caso: é necessário comer pelas beiradas. Passe a catalogar e controlar mudanças (prática de CM ou Change Management) para todo o backlog de desenvolvimento e documentar requisitos (direito) apenas para os novos desenvolvimentos. Adicionalmente, você pode descobrir que determinados softwares ou cenários recebem mais modificações e pode decidir investir algum tempo para documenta-los e poder avaliar impactos com mais precisão.