RUP 7.0 com o Projeto Eclipse

Esse artigo analisa de maneira breve o lançamento da versão 7 do RUP e a sua ligação com o projeto Eclipse.

RUP 7
A Rational/IBM lançou em 2007 a versão 7 do RUP, que agora está na versão 7.1.
A versão 7 do RUP traz algumas mudanças conceituais que a primeira vista são complicadas de se entender, principalmente porque não há grandes alterações no conteúdo do RUP, mas sim na forma como esse conteúdo foi reorganizado.
A evolução do RUP 7 se baseia na evolução da Linguagem para Modelagem de Processos de Software (SPEM 2.0), gerada pelo OMG (Object Management Group). Essas alterações geram uma abstração maior no RUP posicionando-o mais como arquitetura de métodos do que arquitetura de software. O que faz sentido pois o RUP é um software que suporta uma metodologia para desenvolvimento de software.
O Rational Method Composer é a ferramenta que implementa, ou que é capaz de manipular os metamodelos nos quais o RUP se baseia. É essa ferramenta que possibilita a customização dos conceitos que compõe o Method Content; tasks, roles, work products, e guidance. Os Method Content são organizados pelos processos em atividades, que compõe o ciclo de vida que expressa o trabalho a ser desenvolvido.


A representação bi-dimensional da separação entre
Method Content e Processos do Rational Unified Process
fonte: http://www.ibm.com/developerworks/rational/library/dec05/haumer/

Existe um vasto material sobre RUP 7 na Internet e na sua maioria de autoria da própria Rational/IBM. Os pontos abordados acima são apenas uma pequena descrição das alterações conceituais que ocorreram na versão 7 do RUP.
Para os usuários que estão habituados com o RUP 2003 ou RUP 6, pode parecer que não houve grandes mudanças, pois a Rational manteve ao máximo a compatibilidade entre os elementos principais da metodologia como as disciplinas, fases, iterações, etc, ao mesmo passo que tornou o produto mais modular devido a nova especificação do Software Process Engineering Metamodel (SPEM 2.0).
SPEM é uma Linguagem para Modelagem de Processos de Software e foi incorporado como um profile UML pela UML 2.0. Profile UML pode ajustar a linguagem UML para propósitos específicos, não limitado-a em engenharia de software, mas também cobrindo design e modelagem de outras disciplinas como engenharia mecânica, transformação de negócios, ciclo de vendas, etc.

O que se observa de fato é que a UML ou a OMG (Object Management Group) procura expandir os seus domínios ao adotar o UML Profile.
Se encontra em andamento a discussão da AP233 - STEP's System Engineering Project (Standard for the exchange of product model data - Application Protocol 233) .
Esse projeto é uma colaboração entre a OMG e a INCOSE (International Council on Systems Engineering) que está desenvolvendo extensões de processos de engenharia para a UML. Mas aí tem o dedo de gente muito maior como PDES Inc (a STEP industry consortium) , NIST (National Institute for Standards) , NASA STEP. E o fato é que a IBM com o RUP 7 está seguindo os padrões que são determinados com muito critério pelos grandes players desse conluio entre o mercado e as entidades reguladoras norte americanas.
Vou procurar, quando possível, escrever um artigo sobre padronização e regulamentação nos EUA, mas por hora seguem algums links para quem se interessar, e mais abaixo vamos analisar a estratégia adotada pela IBM para o desenvolvimento do RUP 7.

OpenUP/BasicUP
Em outubro de 2005, a Eclipse Foundation anuncia a criação do projeto Eclipse Project Framework (EPF), um framework open source para manipular um software/website da metodologia UP. A metodologia Basic Unified Process foi fornecido pela IBM e rebatizada de Open Unified Process (OpenUP) em março de 2006.
Em setembro de 2006, é lançado o Eclipse Project Framework (EPF) e a versão 0.9 do OpenUP.
O Eclipse Project Framework (EPF) é compatível com o RUP 7. Na verdade, o Rational Method Content é "Powered by Eclipse Technology".
A IBM forneceu um processo, o Basic Unified Process e o projeto Eclipse se encarregou de desenvolver o framework que foi empacotado em EPF e RMC.

Caso o usuário queira utilizar o OpenUP, ferramenta e processo, o mesmo está disponível gratuitamente e é uma ótima solução para empresas que queiram experimentar o Processo Unificado.
O Eclipse Project Framework não é compatível com as outras ferramentas de produtividade da Rational, mas a empresa que não quer utilizar o RUP agora, provavelmente não possui as outras ferramentas mesmo.
Para se customizar o processo de acordo com as necessidades do projeto, o OpenUP deve ser instalado juntamente com o Eclipse Project Framework. Caso alguém queira navegar por uma versão padrão disponibilizada na Internet, pode seguir o link abaixo:
http://www.epfwiki.net/wikis/openup/index.htm

O Basic Unified Process é uma versão mais leve do RUP, e que gera um processo ágil para equipes pequenas mas, aplicando os princípios e práticas do RUP, e podendo ser configurado rapidamente por profissionais que disponham de conhecimentos para estabelecer os processos adequados.

Method Composer versus Eclipse Process Framework overview. A fonte em preto nas duas colunas indica funcionalidades presente em releases passados. A fonte azul indica funcionalidades adicionadas na versão 7
Fonte: http://www.ibm.com/developerworks/rational/library/dec05/haumer/

Web 2.0 - Criando novas fronteiras para a Colaboração e a Inteligência Corporativa

Outro dia estive no IBM Fórum - 2007. Ele aconteceu nos dias 11, 12 e 13 de setembro com palestras incríveis sobre colaboração, web 2.0, SOA, BPM, Mobilidade Corporativa, entre outros. Mas a palestra que, para mim, foi mais interessante foi a de Mario Costa. Incrível pelo conteúdo e pela forma como foi ministrada. O cara é fera! E deu um show no que diz respeito à Web 2.0.

Para quem não conhece, o Web 2.0 é um conceito. Uma nova forma de usar a internet para tirar benefícios para o negócio. SOA e Web 2.0 estão bem relacionados porém um está mais para infra-estrutura e o segundo para usuários, mas os 02 caminham juntos. Mas tudo isto não é novo não e eu estava vendo, o Web 1.0 até há tão pouco tempo, eram os computadores conectados, hoje, com o Web 2.0 as pessoas estão conectadas...!

É mesmo incrível imaginar que há pouco tempo atrás, mal tínhamos como falar com alguém que estava do outro lado do mundo. O importante nisto tudo é aproveitar o conhecimento de quem você NÃO conhece, incrível! E por este motivo também estou por aqui, compartilhando conhecimentos e buscando outros, novos...aproveitando toda a tecnologia e esta nova era.

O vídeo abaixo mostra bem esta realidade:

Balanced Scorecard, Dashboards e por aí vai...

Andei pesquisando, até porque utilizo no meu dia a dia e é uma das coisas mais citadas no MBA de Gestão Empresarial , sobre as demandas por Balanced Scorecards, Dashboards e Cockpits. As definições abaixo ajudam muito a diferenciar e direcionar sobre os conceitos de cada um destes assuntos.

É impressionante a confusão que nós, praticantes de tecnologia, conseguimos fazer com esse tema na cabeça dos nossos clientes… A todo momento vejo as pessoas chamando um punhado de gráficos de scorecard, ou um conjunto de 800 indicadores de cockpit executivo. Aqui vão algumas considerações a respeito:

Balanced Scorecard não é uma ferramenta, é uma metodologia de gerenciamento estratégico. A criação de um scorecard é naturalmente um processo top-down, que parte da missão e estratégia da empresa para criar os objetivos estratégicos. Estes objetivos são desdobrados para os níveis inferiores, até chegar aos objetivos individuais. Este processo garante o alinhamento dos objetivos individuais e da execução com a estratégia da empresa. E o scorecard é balanceado pois é incentivado que os indicadores reflitam diferentes perspectivas (indicadores de clientes, processos, recursos humanos e financeiros, por exemplo), e não apenas a visão financeira.

Dashboards são composições gráficas de vários indicadores relacionados, como em um painel de instrumentos de um carro. Os dashboards são úteis para analisar o motivo de um comportamento abaixo do esperado de um indicador específico, principalmente quando existem recursos de aprofundamento (drill-down) e diferentes visualizações.
Soluções baseadas em OLAP fornecem uma análise multidimensional, realizando cálculos complexos, análise de tendências e modelagem de dados. Os resultados de consultas OLAP normalmente são visualizados em matrizes (ou cubos) que podem ser manipulados e cruzados.

Existe alguma sobreposição entre estas abordagens, e quando adotamos uma das abordagens temos a tentação da “síndrome do martelo” (quem tem um martelo acha que tudo é prego). Ou seja, como os conceitos são tão parecidos, é comum encontrarmos uma boa solução de Business Intelligence sendo usada também para gerar um scorecard deficiente.

Outra coisa é a suposição de que temos que automatizar todos os processos, ou primeiro implementar um datawarehouse, antes de se criar um scorecard. Processos deste tipo, bottom-up, geram scorecards descolados da real estratégia da empresa. Nada impede que você comece a montar um scorecard a partir de dados que não estão em nenhum sistema, mas que são intimamente relacionados com a estratégia da empresa.

Uma boa prática seria ter os objetivos estratégicos de alto-nível refletidos em um scorecard, e desdobrados para os objetivos das áreas, até o nível tático e operacional. Os indicadores podem ser relacionados a dashboards, ou a cubos OLAP, que podem ser acionados quando alguém desejar analisar o motivo da baixa performance. Resumindo, um scorecard fornece uma visão estratégica, multifacetada, de médio e longo prazo, enquanto dashboards e cubos fornecem uma visão analítica, de um ponto de vista de um indicador.