RUP - Environment discipline
Analisarei aqui a responsabilidade sobre a configuração dos processos do RUP de uma maneira alternativa ao proposto pela metodologia.
Hora utilizarei UP e hora utilizarei RUP pois um é derivado do outro. Utilizarei RUP quado estiver falando especificamente do produto/processo da Rational.
UP/RUP
O Processo Unificado é uma metodologia para desenvolvimento de softwares, bem aceita por um segmento dos profissionais do mercado e criticada por outros.
O UP prega que o processo seja adaptável, que haja um balanceamento nas prioridades dos interessados, que o grau de colaboração entre as equipes seja elevado e que haja agregação continuada de valor entre outros princípios chaves.
Ao meu ver, a complexidade na adoção do RUP está na configuração do ambiente que disponibiliza a metodologia, para que as equipes possam utilizá-la corretamente. O RUP exige um grau elevado de customização para que ele vista bem no projeto que irá usá-lo, e não fique "folgado" ou "apertado" demais.
Eu participei da implantação de uma metodologia baseada no Processo Unificado, e acredito que integrando-a com outras metodologias como a metodologia de gerenciamento de projetos fornecida pelo PMI (Project Managemente Institute) e com a implementação de um escritório de projetos (PMO), os resultados obtidos valem a pena.
O RUP são duas coisas; metodologia e produto da Rational.
O UP também possui um produto para suportá-lo, o Eclipse Project Framework. Eu escrevi um artigo nesse blog que aborda esse produto. Quem se interessar pode acessá-lo em:
http://robsonkoji.blogspot.com/2007/08/rational-unified-process-rup-verso-7.html
RUP - Metodologia
A metodologia RUP em sí não é complexa. Como pode se esperar pelo nome, se trata de um processo unificado racional, processo unificado lógico. Basicamente ela é suportada por dois vetores, um dinâmico e um estático.
O vetor estático (eixo y), chamado de Method Content, descreve como o software é desenvolvido. Esse vetor lista as 9 disciplinas do RUP, que por sua vez possuem "roles" que executam "tasks" que recebem ou geram "workproducts". O eixo y abrange todo o modo como as coisas são desenvolvidas.
O eixo x por sua vez, captura tudo isso e distribui no tempo através de fases, iterações, atividades e sub-atividades, controladas por milestones gerando processos.
A área gerada pela intersecção dos pontos dos eixos x e y representa a quantidade de esforço (y) dispendido ao longo do tempo (x), gerando essas formas coloridas que ilustram bem o ciclo de vida de um projeto.
Listando as características do RUP, veremos que se trata de uma metodologia extensa não pela sua complexidade, mas pela quantidade de informações manipuladas.
Ela documenta mais de 30 funções, mais de 50 artefatos, mais de 60 atividades e mais de 70 conceitos distribuidos entre as 9 disciplinas, ao longo de 4 fases e n iterações.
O RUP organiza uma vasta quantidade de informações em poucas categorias distintas, o que faz com que seja uma metodologia simples de se entender.
A complexidade do RUP está na quantidade de informações que precisam ser manipuladas e no tempo de resposta de processamento das mesmas.
RUP - Produto
A tecnologia utilizada no RUP é muito simples, o que é um ponto forte. A ferramenta RUP é um website que disponibiliza a metodologia com os seus templates de documentos, descrição das funções, artefatos e atividades, assim como todas as etapas do projeto.
A vantagem do produto da Rational, é que o mesmo se integra aos outros produtos da Rational (ClearCase, ClearQuest, etc).
Customização do RUP
O RUP define que a disciplina de Environment é a responsável por prover o ambiente da metodologia, configurando templates, guidelines, mentoring e escolhendo as ferramentas de suporte (ferramenta CASE, automação de controle de qualidade, etc).
Quem trabalha ou já trabalhou em grandes projetos, sabe que a complexidade do ambiente, da infra-estrutura utilizada para o desenvolvimento de sistemas, vai muito além da utilização de ferramentas de suporte. Existem atividades como pesquisa, configuração e manutenção de servidores de aplicação, servidores de banco de dados, requisitos de infra-estrutura, redes, segurança, sistemas operacionais, etc.
Seguindo as disciplinas do RUP e dependendo das características do projeto, como tamanho, complexidade tecnológica, características da equipe, é apropriado que a disciplina de Environment seja responsável por essas atividades.
Portanto a disciplina de Environment se vê em duas frentes distintas e não complementares, configuração do processo para o ambiente de desenvolvimento e suporte do ambiente técnico. Note que não estamos falando do ambiente corporativo da empresa, como servidor de e-mail, servidor de arquivos, etc, e sim das ferramentas/software/sistemas utilizados no projeto.
Uma vez que o RUP continua o seu processo evolutivo na corporação independente de um projeto específico, deve-se retirar da equipe do projeto a responsabilidade pelo "projeto" de configuração do RUP. A coleta de lessons learned e a consequente melhoria continuada, deve ser analisada e gerida pelo Escritório de Projetos (PMO) e não por uma disciplina do projeto corrente. As diciplinas de Business Modeling, Requirements, Analysis & Design, Implementation, Test e Deployment convivem iterativamente em um fluxo continuo de troca de informações. Nenhuma delas possui autoridade sobre as demais, diferentemente da disciplina ou do departamento responsável pela configuração do processo, que deve ser considerado estratégicamente no nível da empresa e não no nível do projeto.
Conclusão
A qualidade que se observa no bom funcionamento de determinados requisitos solicitados pelo cliente, são resultados do ciclo de vida de um projeto, que por sua vez são consequência da correta utilização dos processos propostos, ou da efetividade dos processos propostos.
A boa utilização da metodologia é do domínio do projeto, porém o ciclo de vida dessa metodologia deve ser tratado de maneira independente. Os pontos de interseção entre eles são a customização da metodologia para o projeto, a avaliação de resultados para se verificar a sua efetividade e a coleta de lições aprendidas para propiciar a sua evolução.
RevisõesEscrito em 23/08/2007 01:00 em aprox. 2:45 hr
Esse artigo se originou da divisão do artigo: http://robsonkoji.blogspot.com/2007/08/rational-unified-process-rup-verso-7.htmlRev. 1.1.a - 10/09/2007 01:50 em aprox. 0:40 hr
Hora utilizarei UP e hora utilizarei RUP pois um é derivado do outro. Utilizarei RUP quado estiver falando especificamente do produto/processo da Rational.
UP/RUP
O Processo Unificado é uma metodologia para desenvolvimento de softwares, bem aceita por um segmento dos profissionais do mercado e criticada por outros.
O UP prega que o processo seja adaptável, que haja um balanceamento nas prioridades dos interessados, que o grau de colaboração entre as equipes seja elevado e que haja agregação continuada de valor entre outros princípios chaves.
Ao meu ver, a complexidade na adoção do RUP está na configuração do ambiente que disponibiliza a metodologia, para que as equipes possam utilizá-la corretamente. O RUP exige um grau elevado de customização para que ele vista bem no projeto que irá usá-lo, e não fique "folgado" ou "apertado" demais.
Eu participei da implantação de uma metodologia baseada no Processo Unificado, e acredito que integrando-a com outras metodologias como a metodologia de gerenciamento de projetos fornecida pelo PMI (Project Managemente Institute) e com a implementação de um escritório de projetos (PMO), os resultados obtidos valem a pena.
O RUP são duas coisas; metodologia e produto da Rational.
O UP também possui um produto para suportá-lo, o Eclipse Project Framework. Eu escrevi um artigo nesse blog que aborda esse produto. Quem se interessar pode acessá-lo em:
http://robsonkoji.blogspot.com/2007/08/rational-unified-process-rup-verso-7.html
RUP - Metodologia
A metodologia RUP em sí não é complexa. Como pode se esperar pelo nome, se trata de um processo unificado racional, processo unificado lógico. Basicamente ela é suportada por dois vetores, um dinâmico e um estático.
O vetor estático (eixo y), chamado de Method Content, descreve como o software é desenvolvido. Esse vetor lista as 9 disciplinas do RUP, que por sua vez possuem "roles" que executam "tasks" que recebem ou geram "workproducts". O eixo y abrange todo o modo como as coisas são desenvolvidas.
O eixo x por sua vez, captura tudo isso e distribui no tempo através de fases, iterações, atividades e sub-atividades, controladas por milestones gerando processos.
A área gerada pela intersecção dos pontos dos eixos x e y representa a quantidade de esforço (y) dispendido ao longo do tempo (x), gerando essas formas coloridas que ilustram bem o ciclo de vida de um projeto.
Listando as características do RUP, veremos que se trata de uma metodologia extensa não pela sua complexidade, mas pela quantidade de informações manipuladas.
Ela documenta mais de 30 funções, mais de 50 artefatos, mais de 60 atividades e mais de 70 conceitos distribuidos entre as 9 disciplinas, ao longo de 4 fases e n iterações.
O RUP organiza uma vasta quantidade de informações em poucas categorias distintas, o que faz com que seja uma metodologia simples de se entender.
A complexidade do RUP está na quantidade de informações que precisam ser manipuladas e no tempo de resposta de processamento das mesmas.
RUP - Produto
A tecnologia utilizada no RUP é muito simples, o que é um ponto forte. A ferramenta RUP é um website que disponibiliza a metodologia com os seus templates de documentos, descrição das funções, artefatos e atividades, assim como todas as etapas do projeto.
A vantagem do produto da Rational, é que o mesmo se integra aos outros produtos da Rational (ClearCase, ClearQuest, etc).
Customização do RUP
O RUP define que a disciplina de Environment é a responsável por prover o ambiente da metodologia, configurando templates, guidelines, mentoring e escolhendo as ferramentas de suporte (ferramenta CASE, automação de controle de qualidade, etc).
Quem trabalha ou já trabalhou em grandes projetos, sabe que a complexidade do ambiente, da infra-estrutura utilizada para o desenvolvimento de sistemas, vai muito além da utilização de ferramentas de suporte. Existem atividades como pesquisa, configuração e manutenção de servidores de aplicação, servidores de banco de dados, requisitos de infra-estrutura, redes, segurança, sistemas operacionais, etc.
Seguindo as disciplinas do RUP e dependendo das características do projeto, como tamanho, complexidade tecnológica, características da equipe, é apropriado que a disciplina de Environment seja responsável por essas atividades.
Portanto a disciplina de Environment se vê em duas frentes distintas e não complementares, configuração do processo para o ambiente de desenvolvimento e suporte do ambiente técnico. Note que não estamos falando do ambiente corporativo da empresa, como servidor de e-mail, servidor de arquivos, etc, e sim das ferramentas/software/sistemas utilizados no projeto.
Uma vez que o RUP continua o seu processo evolutivo na corporação independente de um projeto específico, deve-se retirar da equipe do projeto a responsabilidade pelo "projeto" de configuração do RUP. A coleta de lessons learned e a consequente melhoria continuada, deve ser analisada e gerida pelo Escritório de Projetos (PMO) e não por uma disciplina do projeto corrente. As diciplinas de Business Modeling, Requirements, Analysis & Design, Implementation, Test e Deployment convivem iterativamente em um fluxo continuo de troca de informações. Nenhuma delas possui autoridade sobre as demais, diferentemente da disciplina ou do departamento responsável pela configuração do processo, que deve ser considerado estratégicamente no nível da empresa e não no nível do projeto.
Conclusão
A qualidade que se observa no bom funcionamento de determinados requisitos solicitados pelo cliente, são resultados do ciclo de vida de um projeto, que por sua vez são consequência da correta utilização dos processos propostos, ou da efetividade dos processos propostos.
A boa utilização da metodologia é do domínio do projeto, porém o ciclo de vida dessa metodologia deve ser tratado de maneira independente. Os pontos de interseção entre eles são a customização da metodologia para o projeto, a avaliação de resultados para se verificar a sua efetividade e a coleta de lições aprendidas para propiciar a sua evolução.
RevisõesEscrito em 23/08/2007 01:00 em aprox. 2:45 hr
Esse artigo se originou da divisão do artigo: http://robsonkoji.blogspot.com/2007/08/rational-unified-process-rup-verso-7.htmlRev. 1.1.a - 10/09/2007 01:50 em aprox. 0:40 hr
