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.