O Rational Unified Process é um processo de engenharia de software criado pela Rational que posteriormente foi adquirida pela IBM. O processo utiliza muito a UML bem como uma abordagem para projetos orientados a Objetos.

Muitos autores e profissionais da aérea questionam o uso de UML em projetos. Particularmente eu acredito que a UML traz muito valor para um projeto OO, porém devemos discernir quais diagramas são válidos para a realização da Análise de Requisitos, Design e Arquitetura. O próprio Scott Ambler questiona muito o uso “inicial” de ferramentas para a diagramação. A abordagem recomendada por ele é que após um determinado momento do projeto, quando o Domínio já está mais maduro, que seria interessante diagramar em uma ferramenta.

Bom, voltando ao RUP, vou explicar um pouco mais o processo. Talvez depois dessa explicação muitos mitos que você ouviu ou ainda ouve possam ser explicados. Caso a sessão abaixo não acabe com suas “Dúvidas, Angustias, Agonias e Tristezas” não se preocupe, no final vou fazer um resumo em grandes tópicos desmistificando diversas “Besteiras” que eu e com certeza você já deve ter ouvindo sobre o processo.

Princípios do Processo

O RUP se norteia em princípios largamente utilizados no desenvolvimento de software desde o seu surgimento até os dias presentes. O processo, ao contrário que muitos pensam, não prega que devemos fazer tudo exatamente como está no papel, ele prega que devemos seguir as boas práticas de desenvolvimento de software e ele se propõe a ser um guia que ajuda na construção de software de qualidade.

Os princípios que descreverei a seguir são utilizados há mais de uma década pela Rational com sucesso. O Processo prega que o desenvolvimento deve estar cada vez mais próximo na área de negócios, isso é o ideal que muitas vezes não é feito. Quantos de nós não cansamos de ver projetos sendo Sepultados e falhando porque não atenderam as necessidades do negócio? A idéia do processo é fazer com que de fato essas necessidades sejam atendidas.

1º Adaptar o processo: Bom, eu gosto muito de falar que esse é o primeiro principio chave do RUP, porque as pessoas acham que devem utilizar todos os Roles e Artefatos que existem no RUP. Isso só prova a ignorância e desconhecimento do processo.

O Objetivo desse princípio é dimensionar correntemente o processo para o projeto e a empresa em questão. A instrução é que devemos adaptar o grau de cerimônia e controle que o processo prove bem como o tamanho da equipe e quantidade de roles. Todos esses fatores só podem ser realizados projeto a projeto.

Estimativas iniciais: O Processo é claro quando diz que é um Anti-Pattern desenvolver estimativas antecipadas e fixas e bem como planos precisos e gerência através de ajustes nesse plano estático.

Dependendo do projeto e das características do mesmo, o uso maior de cerimônia e controle. Isso pode ser uma realidade em projetos com muitos investidores e quando existem questões de Compliance como SOX. Isso não é muito comum no Brasil (SOX), mas na Europa e Ásia é uma realidade constante, apesar de ser algo relativamente recente.

2º Equilibrar prioridades dos investidores: Esse princípio prega que devemos equilibrar as necessidades dos investidores do projeto como o desenvolvimento de customizações VS e a reutilização de recursos. A idéia do RUP é de otimizar ao máximo o valor do negócio.

O principio é guarda-chuva para a boa prática de priorização de Requisitos e até mesmo priorização de projetos. Novamente o processo é claro quando diz que é um Anti-Pattern documentar os requisitos minuciosamente no início do projeto e negar a mudança de requisitos.

De forma enfática, o RUP prega que, para podemos atender e priorizar as necessidades dos investidores de forma correta, precisamos gerenciar os requisitos efetivamente. Para que isso aconteça de forma efetiva é necessário que o cliente esteja envolvido no projeto para garantir que as necessidades do mesmo sejam compreendidas.

Reutilização: A Reutilização de recursos como sistemas legados, componentes, serviços pode reduzir os custos de um projeto em até 80%. Portanto a reutilização é necessária para que podemos equilibrar os custos. Nesse ponto o processo se encaixa perfeitamente com a Filosofia SOA. E notem que o RUP surgiu muito antes de SOA.

3º Trabalho em Equipe: Esse principio descreve como é possível desenvolver efetivamente o trabalho e colaboração através de equipes. O princípio diz que é importantíssimo desenvolver uma comunicação ampla no projeto através de ambientes de Colaboração. Vejam que muitos desses conceitos que o RUP traz são pregados por métodos ágeis. Mas o RUP veio muito antes do movimento ágil, então como isso é possível? Será que o movimento ágil se inspirou em conceitos que já existiam no RUP? Isso pode ser muito doloroso para alguns, mas a resposta é SIM!

Esse princípio prega que deve haver uma comunicação efetiva entre analistas, desenvolvedores e outros participantes do projeto, além de motivar pessoas e integração com áreas operacionais do negócio.

Novamente existe clareza na definição do processo quando se diz que é um Anti-Pattern ter desenvolvedores heróicos que trabalham horas a fio, incluindo finais de semana.

Outra questão clara e condenada pelo processo é o fato de ter desenvolvedores altamente qualificados com ferramentas e não existir colaboração e comunicação.

4º Demonstrar Valor iterativamente: O desenvolvimento iterativo Incremental que gera o famoso “Incremento de Software” é a maneira mais eficiente na maioria dos casos para se desenvolver software. Independente do processo e metodologia utilizado, usar o modelo de cliclo de vida de projeto “Iterativo incremental” é um fator chave para o sucesso.

Dentre os benefícios dessa abordagem, temos o Feedback que é importantíssimo e com ele podemos fazer correções de rumo no projeto a tempo.

Isso não é do RUP, mas eu acho fantástica a frase “Abrace as pessoas, Gerencie a mudança“. Devemos gerenciar a mudança e não simplesmente aceitá-la sem maiores entendimento e priorização. Pois se não podemos vivenciar o fenômeno de “Creep Requirements“.

No que diz respeito ao RUP, ele fala que devemos gerenciar as alterações e ele vem em uma abordagem Orientada a Riscos. Significando que devemos atacar inicialmente os maiores riscos do projeto.

Novamente o processo é claro quando diz que é um Anti-Pattern planejar detalhadamente todo o ciclo de vida do projeto. Percebam que o RUP não é contra estimativas, pelo contrario, é a favor, porém existe um momento mais apropriado para estimar, e esse momento não é no inicio do projeto. Nesse ponto que entram questões como o Cone de incertezas e modelos de contratos os quais irem falar mais em futuros posts. 🙂

Sobre as iterações: A idéia é que a cada iteração realizamos tarefas relacionadas a requisitos, design, arquitetura, implementação, gestão e testes. Essas atividades são repetidas durante várias iterações. Dependendo do tamanho do projeto, a diferença é que a cada iteração essas atividades estarão atuando sobre um conjunto de requisitos diferentes.

5º Elevar o nível de Abstração: Esse conceito não é brinquedo, quando digo isso estou querendo dizer que isso não é uma tarefa simples de ser efetuada. A idéia é que elevando o nível de abstração podemos diminuir a complexidade.

Essa questão está totalmente ligada à quantidade de documentação do processo. Podemos conseguir isso através de reutilização, ferramentas e de modelos arquiteturais. Mas quando eu falo arquiteturais não estou dizendo que a arquitetura deve resolver todos os problemas, mas ela deve resolver os maiores problemas. O princípio reduz a complexidade conforme já relatei antes, mas também é uma fonte poderosa de aumento de produtividade.

O RUP informa que é um Anti-Pattern você desenvolver requisitos vagos de alto nível. É outro Anti-Pattern revisar exaustivamente requisitos capturados ‘Verbalmente’. O RUP coloca como outro Anti-Pattern o fato de colocar a solução de todos os problemas na arquitetura.

Nota: Já participei de projetos em que a arquitetura resolvia tudo à base de frameworks construídos in-house. Não tenho nada contra a construção de frameworks in-house quando os mesmos têm um propósito específico e bem definido. O problema é quando os frameworks e as soluções arquiteturais tentam abraçar o mundo e resolver todos os problemas e deixam os desenvolvedores mais amarrados do que beneficiados.

Na questão da representação das abstrações, a UML é muito útil pois com ela podemos expressar bem esses modelos.

6º Foco Contínuo na Qualidade: Qualidade é algo com que sempre devemos estar comprometidos. Esse princípio do processo enfatiza que podemos atingir a qualidade através de testes contínuos. E até mesmo automação de testes, sendo que em alguns casos é relevante desenvolver uma solução arquitetural para automatização de testes.

Para que o princípio seja atendido, devemos identificar medidas e critérios. Isso não se trata de apenas “Atender os Requisitos”. A qualidade não deve residir apenas na equipe de testes, ou em profissionais de Q.A. Mas em todos os membros da equipe como analistas, desenvolvedores e gerentes.

Por fim, o processo identifica como um Anti-Pattern o ato de fazer com que os testes aconteçam somente em uma fase e conduzir testes detalhados em todos os artefatos.

Além desses princípios chave do processo, o RUP é centrado na Arquitetura e em casos de Uso. Casos de uso não significa que têm que ser visuais conforme o diagrama de casos de uso da UML, mas eles podem ser textuais.

O processo é iterativo Incremental, sendo que ele possui marcos. Esses marcos nos ajudam a nos situarmos no projeto e ver se o projeto tem condições de continuar em termos de riscos e se estamos no rumo correto.

A figura acima mostra as fases do processo (Inception, Elaboration, Construction e Transiction), para detalhar as fases e o propósito de caso preciso de outro post. 🙂 Na seqüência (em outro post) estarei detalhando essas fases.

Mas o propósito da figura, que também é conhecida como gráfico de baleias, é mostrar as disciplinas do projeto como (construção, requisitos, configuração, etc..) através das iterações e com os marcos de fases. O gráfico de baleias mostra a intensidade das disciplinas através das iterações e fases. Pelo amor de Deus não confunda isso com Cascata!

Realizando a Adaptação

Também conhecido como tailoring. Essa palavra é temida por muitas pessoas, mas não podemos condenar nossos irmãos mais ignorantes e desprovidos de informações. Baseados nesses conceitos chaves do RUP que apresentei acima, podemos realizar o tailoring do processo de acordo com as necessidades do mesmo.

O RUP define uma série de elementos essenciais que você deve considerar seriamente ao realizar o tailoring do processo. São os elementos:

1. Visão do projeto: Devemos desenvolver uma visão do projeto para deixar registrados os interesses do projeto bem como os seus objetivos e requisitos que devem ser atendidos. Esse recurso nos possibilita alinhamento com os stakeholders do projeto e membros da equipe técnica.

2. Plano de Gerência: Devemos desenvolver um plano de desenvolvimento e gerência do projeto. No plano do projeto iremos expor o planejamento do projeto de forma aberta demonstrando os recursos necessários como orçamento, escopo e pessoas.

3. Mitigar Riscos: Esse é outro ponto essencial em um tailoring do RUP. Sempre devemos levantar os maiores riscos para o projeto e planejar formar de ação contra esses riscos. Devemos criar uma Lista de Riscos e através dela dirigir ações e decisões do projeto.

4. Casos de Negócio: São as informações necessárias do negócio que nos dizem se vale a pena ou não investir no projeto. Seu propósito é para viabilizar o plano econômico do projeto bem como questões relativas a ROI. Através dele são criados argumentos convincentes em termos de Custo vs. Benefícios que dão base à criação do projeto.

5. Projete uma Arquitetura: Com o aumento da complexidade em termos de desenvolvimento de sistemas, uma arquitetura se faz necessária sendo uma estrutura base que trata e interfaceia os principais problemas da aplicação.

6. Uso de Protótipo: Utilizar protótipos para refinar e entender os requisitos e necessidades do usuário. Esse uso está relacionado à idéia de desenvolvimento iterativo e incremental e com testes.

7. Avaliação de Resultados: É importante a comunicação aberta e freqüente provida através de Feedback. Freqüentemente devemos medir os resultados do produto de software e com isso realizar as correções de rumo necessárias para atender as necessidades do cliente bem como a acomodação de mudanças. Sendo que a avaliação da iteração é um elemento chave no desenvolvimento iterativo e incremental.

8. Controle as mudanças: Controlar mudanças não significa “barrar” mudanças. Mudanças sempre irão ocorrer, isso é fato, mas o que devemos fazer é passar essas mudanças por um mecanismo de controle de mudanças gerências por um processo consistente. Uma das vantagens do controle de mudanças é o fato de possibilitar a análise de impacto, que é uma poderosa ferramenta que pode nos “dizer” o quanto será custoso implementar essa mudança.

Nota: Você pode realizar mudanças com ou sem análise de impacto. A questão é que com análise de impacto você sabe onde está pisando. Sem a análise de impacto você pode tomar um susto no momento de codificar a mudança!

9. Suporte ao Usuário: Aqui o RUP se preocupa com questões de “Usabilidade”. E como são importantes essas questões. Dependendo do produto de software, é necessário ter até um guia ou documentação procedente de como se deve utilizar o produto. Essa necessidade irá variar de acordo com o projeto.

10. Adotar um processo: É fundamental escolher um processo que se adapte ao projeto e a organização em questão. Aqui o RUP se referencia ao seu primeiro conceito chave: Adaptar o processo. As questões de adaptação de projetos o RUP tratam em sua disciplina de ambiente.

Verdades e Mitos

Como mencionado antes, espero que após você ter lido o que eu escrevi, diversas “Bobagens” tenham saído de sua cabeça. Mas se isso não aconteceu, agora vou ser mais direto. Então vamos a algumas verdades.

Verdades

• O RUP é um processo de desenvolvimento de software com um grau de cerimônia maior.
• É pago, logo o acesso as informações é dificultado
• Com certeza é o processo mais utilizado hoje em dia, porém foi e é utilizado de forma errada.
• Consultorias do processo são caríssimas.

Mitos

O RUP é Cascata: Eu já cansei de ouvir isso. Muitas pessoas pensam que o RUP é cascata. Se você leu o que eu escrevi acima vai ver que eu disse “Iterativo Incremental”. O RUP não é Cascata!

O RUP é pesado: Essa é outra besteira, o que é pesado é a burrice das pessoas. O que pesa é o tailoring do RUP que você faz ou, muitas vezes, o tailoring que você não faz. Existem cenários em que o RUP vai ser realmente muito cerimonioso e formal, porém isso depende da situação. E o fato de algo ser formal não significa que é ruim, depende muito da situação. O RUP não é pesado!

O RUP prega BIG Especs. Up to Front: De forma alguma! Muitos utilizadores do processo acabam cometendo esse erro. Mas se você leu o que eu escrevi acima não vai mais acreditar nisso. Infelizmente esse erro é muito comum dentro os utilizados da metodologia, muitas vezes por desconhecimento. O RUP não prega BIG Especs. Up to Front.

Casos de uso Textuais são ruins: Olha, pessoal, a forma mais amorosa que eu tenho para responder isso é bom… não vou nem falar. O RUP é baseado em casos de uso, além do mais casos de uso são eficientes para especificarmos. Casos de uso não são ruins.

Com o RUP podemos ter pessoas ‘mais fracas’: Pro diabo! Eu já cansei de ouvir isso também. E o pior de utilizadores da metodologia. O RUP não especifica isso em lugar algum na especificação do processo. Com pessoas ‘fracas’ ou ‘incompetentes’, o resultado será ruim. Não existe processo ou metodologia no mundo que consiga obter sucesso com pessoas ‘fracas’. O RUP não encoraja esse tipo de loucura.

Infelizmente as empresas ainda usam o modelo em cascata, e em muitas vezes tentam transvestir esse modelo em cascata com uma roupinha do RUP. Ao meu ver o processo é bom e pode ser utilizado em diversos cenários.

E quanto às metodologias Ágeis?: Acredito que uma coisa não elimina a outra. É extremamente valioso nós unificarmos valores ágeis com processos de software que o RUP prove. Acredito que sempre devemos estar buscando o equilíbrio projeto a projeto: de disciplina a cerimônia vs. agilidade.

O RUP é um processo muito bom que pode ser utilizado em diversos cenários. O que devemos fazer é adaptar o processo de forma correta sempre pensando nos 6 conceitos chave do processo que descrevi nesse post.

Abraços e até a próxima.