RUP: Verdades e Mitos
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, porem 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 posam ser explicados. Caso a sessão a baixo 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 des do 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 a 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 nos não cansamos de ver projetos sendo Sepultados e falhando por que 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 essa é o primeiro principio chave do RUP, por que 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 principio é dimensionar correntemente o processo para o projeto e a empresa que 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 gerencia 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 principio prega que devemos equilibrar a necessidades dos investidores do projeto como o desenvolvimento de customizações VS 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 inicio 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 serão compreendidas.
Reutilização: A Reutilização de recursos como sistemas legados, componentes, serviços pode reduzir os cursos 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. Atrávez 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 principio 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 fim 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" é maneira mais eficiente na maioria dos casos para se desenvolver software. Independente do processo e metodologia utilizado utilizar o modelo de cliclo de vida de projeto "Iterativo incremental" é um fator chave para o sucesso.
Dentro 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, Gerência a mudança" devemos gerenciar a mudança e não simplesmente aceita-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 Orienta 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, porem 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 ligado a 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 principio 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 a base de frameworks construídos in-house. Não tenho nada contra a construção de frameworks in-house quando os mesmos tem um propósito especifico e bem definido. O problema é quando os frameworks e as soluções arquiteturais tentam abraçar o mundo e resolver todos os problema 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 Continuo na Qualidade: Qualidade é algo sempre devemos estar comprometidos. Esse principio 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 principio 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 o 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 tem 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 a cima mostra a fases do processo(Inception, Elaboration, Construction e Transiction), para detalhar as fases e o propósito de caso uma preciso de outro post. :) Na seqüencia( em outro post) estarei detalhando essas fases.
Mas o propósito da figura, que também é conhecida como gráfico de baleais é 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. Baseado nesses conceitos chaves do RUP que apresentei a cima podemos realizar o tailoring do processo de acordo com as necessidades do mesmo.
O RUP define uma serie 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 valhe 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éz dele são criados argumentos convincentes em termos de custo Vs Beneficios que sudtificam a 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 Prototipo: Utilizar protótipos para refinar e entender os requisitos e necessidades do usuário. Esse uso está relacionado a idéia de desenvolvimento iterativo e incremental e com testes.
7. Avaliação de Resultados: É importante a comunicação aberta e frqü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 siginifica "barrar" mudanças. Mundanças sempre iram 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 vantágens do controle de mudanças é o fato de possibilitar a análise de impacto, que é uma poderosa ferramenta que podemos nos "dizer" o quanto será custozo implementar essa mudança.
Nota: Você pode realizar mudanças com ou sem análise de impacto a questão é 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 preucupa 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 utilziar 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 trata em sua disciplina de ambiente.
Verdades e Mitos
Como mencionado antes, espero que após você ter lido que eu escrevi antes diversas "Bobagens" tenham saido de sua cabeça. Mas se isso não aconteceu agora vou ser mais direto. Então vamos a algumas verdades.
Verdades
O RUP é Cascata: Eu já cancei de ouvir isso. Muitas pessoas pensam que o RUP é cascata. Se você leu o que eu escrevi a cima vai ver que eu disse "Iterativo Incremental". O RUP não é Cascata!
O RUP é pesado: Essa é outra besteira o que é pessado é a burrice das pessoas. O que pesa é o tailoring do RUP que você faz ou em muitas vezes o tailoring que você não faz. Existem cenários em que o RUP vai ser realmente muito cerimoniozo e formal porem 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 é pessado!
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 a cima 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 ruim: Casos de uso são ruim, olha pessoal a forma mais amoroza que eu tenho para responder isso é bom... não vou nem falar. Não sei da onde essa asneira vou cagada. O RUP é baseado em casos de uso, alem 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á cancei de ouvir isso também. E o pior de utilizadores da metodologia. O RUP não especifica isso em lugar algum na espesificação do processo. Com pessoas 'fracas' ou 'incopetentes' 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 ter pode ser utilizado em diversos cenários.
E quanto as metodologias Ágeis ?: Acredito que uma coisa não elimina a outra. É extremanete valioso nos unificarmos valores ágeis com processo de software que o RUP prove. Acredito que sempre devemos estar buscando o equilibrio projeto a projeto de disciplina e cerimocia Vs agilidade.
O RUP é um processo muito bom que pode ser utilizado em diversos cenário. O que devemos fazer é adaptar o processo de forma correta sempre pensando nos 6 conceitos chave do processo que descri ness post.
Abraços e até a próxima.
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, porem 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 posam ser explicados. Caso a sessão a baixo 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 des do 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 a 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 nos não cansamos de ver projetos sendo Sepultados e falhando por que 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 essa é o primeiro principio chave do RUP, por que 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 principio é dimensionar correntemente o processo para o projeto e a empresa que 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 gerencia 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 principio prega que devemos equilibrar a necessidades dos investidores do projeto como o desenvolvimento de customizações VS 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 inicio 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 serão compreendidas.
Reutilização: A Reutilização de recursos como sistemas legados, componentes, serviços pode reduzir os cursos 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. Atrávez 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 principio 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 fim 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" é maneira mais eficiente na maioria dos casos para se desenvolver software. Independente do processo e metodologia utilizado utilizar o modelo de cliclo de vida de projeto "Iterativo incremental" é um fator chave para o sucesso.
Dentro 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, Gerência a mudança" devemos gerenciar a mudança e não simplesmente aceita-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 Orienta 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, porem 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 ligado a 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 principio 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 a base de frameworks construídos in-house. Não tenho nada contra a construção de frameworks in-house quando os mesmos tem um propósito especifico e bem definido. O problema é quando os frameworks e as soluções arquiteturais tentam abraçar o mundo e resolver todos os problema 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 Continuo na Qualidade: Qualidade é algo sempre devemos estar comprometidos. Esse principio 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 principio 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 o 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 tem 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 a cima mostra a fases do processo(Inception, Elaboration, Construction e Transiction), para detalhar as fases e o propósito de caso uma preciso de outro post. :) Na seqüencia( em outro post) estarei detalhando essas fases.
Mas o propósito da figura, que também é conhecida como gráfico de baleais é 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. Baseado nesses conceitos chaves do RUP que apresentei a cima podemos realizar o tailoring do processo de acordo com as necessidades do mesmo.
O RUP define uma serie 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 valhe 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éz dele são criados argumentos convincentes em termos de custo Vs Beneficios que sudtificam a 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 Prototipo: Utilizar protótipos para refinar e entender os requisitos e necessidades do usuário. Esse uso está relacionado a idéia de desenvolvimento iterativo e incremental e com testes.
7. Avaliação de Resultados: É importante a comunicação aberta e frqü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 siginifica "barrar" mudanças. Mundanças sempre iram 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 vantágens do controle de mudanças é o fato de possibilitar a análise de impacto, que é uma poderosa ferramenta que podemos nos "dizer" o quanto será custozo implementar essa mudança.
Nota: Você pode realizar mudanças com ou sem análise de impacto a questão é 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 preucupa 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 utilziar 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 trata em sua disciplina de ambiente.
Verdades e Mitos
Como mencionado antes, espero que após você ter lido que eu escrevi antes diversas "Bobagens" tenham saido 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 é dificiltado
- Com certeza é o processo mais utilizado hojé em dia porem foi e é utilizado de forma errada.
- Consultorias do processo são carissimas.
O RUP é Cascata: Eu já cancei de ouvir isso. Muitas pessoas pensam que o RUP é cascata. Se você leu o que eu escrevi a cima vai ver que eu disse "Iterativo Incremental". O RUP não é Cascata!
O RUP é pesado: Essa é outra besteira o que é pessado é a burrice das pessoas. O que pesa é o tailoring do RUP que você faz ou em muitas vezes o tailoring que você não faz. Existem cenários em que o RUP vai ser realmente muito cerimoniozo e formal porem 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 é pessado!
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 a cima 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 ruim: Casos de uso são ruim, olha pessoal a forma mais amoroza que eu tenho para responder isso é bom... não vou nem falar. Não sei da onde essa asneira vou cagada. O RUP é baseado em casos de uso, alem 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á cancei de ouvir isso também. E o pior de utilizadores da metodologia. O RUP não especifica isso em lugar algum na espesificação do processo. Com pessoas 'fracas' ou 'incopetentes' 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 ter pode ser utilizado em diversos cenários.
E quanto as metodologias Ágeis ?: Acredito que uma coisa não elimina a outra. É extremanete valioso nos unificarmos valores ágeis com processo de software que o RUP prove. Acredito que sempre devemos estar buscando o equilibrio projeto a projeto de disciplina e cerimocia Vs agilidade.
O RUP é um processo muito bom que pode ser utilizado em diversos cenário. O que devemos fazer é adaptar o processo de forma correta sempre pensando nos 6 conceitos chave do processo que descri ness post.
Abraços e até a próxima.
