Upload
marcos16v
View
57
Download
0
Embed Size (px)
DESCRIPTION
rup
Citation preview
RUP Key Principals: Balance Competing Stakeholder Priorities
Balancear prioridades sempre é uma tarefa difícil já que na visão de cada stakeholder
seus requisitos são sempre mais importantes do que os requisitos dos outros.
Desenvolver um software sem estabelecer nas fases iniciais o que realmente é prioritário
significa apenas que foco desnecessário será dado em algo que não agrega valor ao
negócio e muito menos atende as expectativas dos usuários.
Outro fator importante quanto ao processo de priorização de requisitos é que ele não
deve levar em conta apenas as necessidades de alguns stakeholders. Priorizar os
requisitos significa entender o negócio, as necessidades de cada stakeholder e então
balancear cada uma das necessidades.
Outro fator importante relacionado a este princípio é a redução do desenvolvimento
customizado. Isso significa avaliar os prós e contras do desenvolvimento de um
software/componente customizado e a utilização de um já pronto que atenda
parcialmente os requisitos.
Os benefícios desse princípio são:
- Alinhar negócio e necessidades do usuário;
- Reduzir o desenvolvimento customizado;
- Otimizar o valor do negócio.
Práticas para atingir esses benefícios:
- Definir e priorizar o negócio x necessidades do usuário;
- Priorizar requisitos;
- Entender quais ativos podem ser alavancados;
- Equilibrar a reutilização dos recursos x necessidades do usuário.
Como não atingir esses benefícios:
- Documentar a fundo os requisitos no início do projeto;
- Negociar todas as alterações nos requisitos;
- Congelar os requisitos diretos;
- Priorizar o desenvolvimento customizado;
- Atender principalmente as necessidades dos investidores mais vocais.
Postado por Fernando Dantas Santos Júnior às 17:17 0 comentários
Quinta-feira, 21 de Fevereiro de 2008
Resumo Livro: The Rational Unified Process Made Easy
Um dos livros mais conhecidos de RUP e que sem dúvida é leitura obrigatória para quem
está começando no assunto é o “The Rational Unified Process Made Easy: A Practitioner's
Guide to the RUP” de Per Kroll e Philippe Kruchten. Com uma abordagem muito prática o
livro explica toda a estrutura do RUP 2003 passando por seus princípios, processo
Iterativo, fases e disciplinas, etc. Traz ainda um capítulo interessante onde todo o ciclo de
vida de um pequeno software é explicado através do RUP.
Para quem já leu o livro e gostaria apenas de rever seu conteúdo ou mesmo para quem
quer uma visão geral fiz um pequeno resumo (parte em português e parte em inglês) que
pode ser útil. Vale lembrar que esse livro refere-se ao RUP 2003 e conseqüentemente a
Certificação 639 que é a antecessora da atual 839 sobre RUP 7.
Em breve também publicarei um resumo do recém publicado livro “IBM Rational Unified
Process Reference and Certification Guide: Solution Designer (RUP)” de Ahmad K. Shuja e
Jochen Krebs que me ajudou muito na certificação 839.
Download Resumo - Formato ZIP - 1MB
Download Resumo - Formato PDF - 1.2MB
Qualquer sugestão ou contribuição quanto ao resumo comentem ou me enviem por
email([email protected])
Postado por Fernando Dantas Santos Júnior às 18:53 1 comentários
Quarta-feira, 20 de Fevereiro de 2008
RUP Key Principals: Adapt the Process
Este é um princípio simples e que talvez por isso seja tão subestimado. Vejo muitas
pessoas alegarem que o RUP é “muito pesado” e possui muitos artefatos. É aí que mora o
desconhecimento pois esse princípio diz respeito justamente a adaptar o nível de
cerimônia ao seu contexto. É importante entender que o RUP é como um banquete, ou
seja, você deve escolher o que deseja ao invés de se empanturrar.
É extremamente importante para o sucesso de um projeto que o processo seja adequado
e que o nível de cerimônia seja ajustado, pois documentação em excesso não trará
produtividade e documentação superficial trará problemas de comunicação.
Projetos maiores, com tecnologias complexas e maior número de stakeholder geralmente
precisam seguir padrões mais formais. Porém, para pequenos projetos com equipes locais
e tecnologias conhecidas o processo deve ser mais leve.
Outro erro comum que esse princípio trata é a criação de planos e estimativas estáticas.
Todos sabem que o nível de incerteza no início de um projeto é alto e tentar estabelecer
um plano estático e absoluto na fase de Iniciação nunca funciona pois apenas na fase de
Elaboração é que se pode ter uma visão mais estável dos requisitos e da arquitetura.
Os benefícios desse princípio são:
- Eficiência de ciclo de vida;
- Maior agilidade do projeto;
- Planos e estimativas mais realísticas.
Práticas para atingir esses benefícios:
- Dimensione corretamente o processo para o projeto;
- Adapte a cerimônia de acordo com o ciclo de vida;
- Aprimore o processo continuamente;
- Equilibre planos e estimativas com o nível de incertezas.
Como não atingir esses benefícios:
- Determine estimativas fixas no início do projeto;
- Desenvolva planos estáticos.
Postado por Fernando Dantas Santos Júnior às 18:34 0 comentários
Sábado, 16 de Fevereiro de 2008
RUP Key Principals: Demonstrate Value Iteratively
Nada ilustra melhor os benefícios do processo Iterativo (representados por esse princípio)
do que a charge abaixo.
Percebe-se claramente no exemplo que a pirâmide foi construída através de um processo
cascata(waterfall) e que o gerente egípcio fez um “ótimo” trabalho de acompanhamento.
Mas justiça seja feita, até mesmo o gerente foi um refém do processo cascata.
Demonstrar Valor Iterativamente significa beneficiar-se do processo iterativo que
basicamente visa a execução de vários ciclos onde cada um realiza todo o conjunto de
disciplinas desde o requisito até a implantação. Daí nota-se a grande diferença onde uma
aplicação executável já é colocada em prova em um curto espaço de tempo. Em contra-
partida, no processo cascata, o release de um software executável é a última prioridade
onde geralmente tem-se essa saída quase que no final do projeto onde já não existe mais
tempo para resolver os problemas.
Os benefícios desse princípio são:
- Reduzir os riscos o quanto antes;
- Maior previsibilidade no decorrer do projeto;
- Maior confiança entre os stakeholders;
Práticas para atingir esses benefícios:
- Obter Feedbacks do cliente;
- Abraçar as mudanças de escopo;
- Focar na eliminação dos maiores riscos com antecedência;
- Adaptar os planos de forma constante.
Como não atingir esses benefícios:
- Planejar todo o projeto em detalhes desde o início.
- Confiar em Entregáveis ao invés de Testes ou Demonstrações
Postado por Fernando Dantas Santos Júnior às 18:11 0 comentários
Rational Unified Process - O início
Como toda boa metodologia que se preze o RUP traz um conjunto de 6 princípios chaves
que formam a base de toda sua estrutura. Se bem compreendidos e corretamente
aplicados podem apresentar um ganho significativo de qualidade no ciclo de vida do
software. Para facilitar a vida os 6 princípios começam com as letras ABCDEF. São eles:
- Adapt the Process
- Balance Competing Stakeholder Priorities
- Collaborate Across Teams
- Demonstrate Value Iteratively
- Elevate the Level of Abstraction
- Focus Continuously on Quality
Nos próximos posts explicarei cada um dos 6 princípios.
Postado por Fernando Dantas Santos Júnior às 11:36 0 comentários
Hello World
Seja bem-vindo ao meu Blog. Aproveitando para inaugurar os posts gostaria de
compartilhar a notícia de que na última sexta-feira dia 16/02 realizei a prova de RUP 7
com sucesso obtendo a nota de 84%. Sendo assim, posso me considerar o mais recente
IBM Certified Solution Designer - IBM Rational Unified Process V7.0.
Mas independente da certificação o que realmente vale é o conhecimento adquirido
durante os 5 meses de estudo. Para mim, após todos os livros e artigos lidos, fica a clara
sensação de que o ciclo de vida de um software é comumente sub julgado e que um
processo bem definido é a base para o sucesso.
Em virtude do conhecimento adquirido no processo de certificação e também da
dificuldade de obter informações de boa qualidade resolvi inaurar esse blog para tratar
entre outras coisas de RUP.
Espero nos próximos posts lançar conteúdos sobre o assunto iniciando pelos 6 princípios
chaves do RUP que além de serem foco da prova são muito interessantes se
compreendidos corretamente.
Postado por Fernando Dantas Santos Júnior às 5:12 5 comentários
Roteiro para prova RUP 839: Rational Unified Process v7.0
Atendendo a pedidos resolvi postar um roteiro de estudo para quem deseja fazer a prova
839 do RUP 7. Esse foi mais ou menos o caminho que segui, salvo pelo fato de que havia
iniciado os estudos para a prova antiga (639) de RUP 2003 até que descobri a existência
da nova 839 lançada em Jul/2007.
Antes de começar a estudar é importante entender como funciona a prova. Ela não é
muito diferente de outras certificações podendo ser marcada pelos centros Prometric e
custando U$ 100,00. É composta de 52 questões e pode ser feita em até 75min sendo a
nota mínima para aprovação de 62%, ou seja, erre no máximo 19 questões para ser
aprovado.
Outro ponto importante sobre a prova é entender o foco da mesma. Como pode ser visto
no site oficial da Certificação o foco é distribuído conforme abaixo:
- Iterative Development Principles (16.6%)
- Iterative Development Work Products (16.6%)
- Basic Method Elements and their Relationships (16.6%)
- Basic Process Elements and their Relationships (16.6%)
- Basic Content of Disciplines (33.6%)
Passo 01: O caminho das pedras:
- O Livro IBM Rational Unified Process Reference and Certification Guide: Solution
Designer (RUP) de Ahmad K. Shuja e Jochen Krebs foi o primeiro a ser lançado sobre RUP
7 em Jan/2008. Recomendo fortemente a leitura pois nele ficam claras as diferenças do
RUP 2003 em relação ao 7. A cada capitulo os autores apresentam o conteúdo do RUP
atrelado a um simulado para ajudar a fixar o assunto. No último capitulo também é
apresentado um simulado dentro das condições reais da prova, ou seja, 52 questões
divididas dentro dos focos da prova;
- Durante a leitura do Livro você já deverá ter instalado em sua máquina pelo menos uma
versão Trial do RMC que contém o framework do RUP para leitura. Recomendo que você
leia o livro e constantemente complemente a leitura com o conteúdo relativo dentro do
site do RUP. Isso lhe ajudará a se familiarizar com o site do RUP e também a aprofundar
em alguns temas.
- Depois de finalizada toda a leitura do livro é hora de explorar mais o site do RUP. Alguns
conteúdos sugeridos por Hans Admiraal em "Learning RUP 7.0" são realmente
fundamentais e de leitura obrigatória.
Passo 02: Não entre na sala de exames sem ter “decorado”:
- Os 6 Key Principals do RUP e seus benefícios. Não é necessário decorar os Patterns e
Anti-Patterns mas o benefícios com certeza sim;
- As disciplinas do RUP e os propósitos de cada uma delas;
- O que é UMA e quais são exatamente cada um dos elementos de conteúdo (Roles,
Tasks, Steps, WorkProducts, etc..) e dos elementos de processo (Activities, Iterations,
Phases, Capability Pattern, etc);
- As fases do RUP e os objetivos de cada uma, assim como, os Milestones;
- No site do RUP leia com atenção todo o conteúdo disponível em: Work Products > RUP
Domains > Project Management. Vários WorkProducts de gerenciamento são cobrados,
principalmente o Software Development Plan e seus cinco sub-artefatos devem ser
decorados.
Passo 03: Os simulados:
- A essa altura você já deveria estar aplicando os próprios conceitos do RUP para evitar
que seu projeto de Certificação falhe. Sendo assim podemos dizer que os simulados são a
sua Arquitetura Executável. Infelizmente, como a própria certificação 839 é recente você
não encontrará muitos simulados facilmente;
- Para ter uma idéia real das questões da prova o próprio site oficial do RUP dá cinco
questões de demonstração que vale a leitura;
- Não achei nenhum testking liberado sobre a prova mas no site da própria testking é
possível baixar a versão demo com 21 questões que já foram muito úteis;
- Por último no site de Hans Admiraal é possível fazer um simulado do RUP 2003
gratuitamente e outro de RUP 7, porém pago. Digamos que com um pouco de insistência
técnica você pode conseguí-lo gratuitamente :-).
Para facilitar segue link para Download das principais questões que utilizei para estudo.
Passo 04: O grande dia:
- Se você fez tudo como sugerido somando uma grande vontade de não perder U$ 100,00
você terá grandes chances de atingir os 62% da prova e se tornar um IBM Certified
Solution Designer - IBM Rational Unified Process V7.0.
Bom, espero que as dicas sejam úteis na busca pela certificação e se isso acontecer peço
que me mande um post pois ficarei feliz em saber.
Postado por Fernando Dantas Santos Júnior às 21:31
RUP Key Principals: Elevate Level of Abstraction
É basicamente por causa desse princípio que hoje não programamos mais em Assembly
ou C++, ou seja, quanto mais elevado o nível de abstração mais a complexidade de um
projeto é reduzida. Essa abstração pode se manifestar de várias formas como adoção de
uma linguagem de alto nível como .NET ou JAVA, adoção de um componente de mercado
ou mesmo pelo uso de serviços disponibilizados através de WebServices.
Quando esse conceito não é corretamente observado o projeto é guiado pela
complexidade e baixa produtividade ficando o business em segundo plano. Outra
abordagem para gerenciar a complexidade é focalizar na arquitetura através do
desenvolvimento de uma que seja estável e testada atuando como referência para os
projetos que ainda serão desenvolvidos.
Os benefícios desse princípio são:
- Aumento da produtividade;
- Redução da complexidade.
Práticas para atingir esses benefícios:
- Promover a reutilizar de ativos existentes;
- Utilizar ferramentas e linguagens de alto nível;
- Focalizar na arquitetura;
- Estabelecer controles sobre a qualidade e complexidade.
Como não atingir esses benefícios:
- Evoluir de requisitos direto p/ código customizado não estimula o reuso pois: enibe a
discussão no foco conceitual, requer constante revisão de decisões e limita o foco na
arquitetura resultando em atraso e retrabalho no projeto
RUP Key Principals: Focus Continuously On Quality
Este é o último princípio do RUP e pelos motivos óbvios quase dispensa apresentações se
não fosse pelo fato de ser um dos mais mal aplicados. Foco contínuo na qualidade não
significa apenas atender os requisitos ou ter uma equipe de teste como muitos imaginam.
Um conceito errôneo comum é que a qualidade pertence a um grupo ou é
responsabilidade dele. Esse mito é geralmente perpetuado pela criação de um grupo,
algumas vezes denominado Garantia de Qualidade, outros nomes incluem Teste, Controle
de Qualidade e Engenharia de Qualidade, e atribuindo a eles a missão e a
responsabilidade relacionadas à qualidade.
Segundo o RUP qualidade também inclui identificar as métricas e critérios que
demonstram sua existência, assim como, a implementação de um processo para garantir
que o produto atinja o grau desejado de qualidade de forma que isso possa ser repetido e
gerenciado.
O próprio RUP demonstra em Supporting Materials -> Quality Management que os
problemas de software ficam de 100 a 1.000 vezes mais caros para serem localizados e
reparados após a implementação do software.
Por fim, um dos maiores benefícios do desenvolvimento Iterativo está relacionado à
abordagem de testes que reforça os conceitos de qualidade desde o início sendo uma das
vantagens desse processo em relação ao processo cascata.
Os benefícios desse princípio são:
- Maior qualidade
- Percepção prévia no progresso e na qualidade
Práticas para atingir estes benefícios:
- Assegurar que toda a equipe tenha propriedade sobre qualidade do produto;
- Testar de forma antecipada e contínua demonstrando as funções do sistema;
- Construir incrementalmente a automação do teste.
Como não atingir estes benefícios:
- Revisar artefatos e concluir testes unitários antes do teste de integração;
- Conduzir revisões detalhadas dos artefatos intermediários pois atrasam o teste do
aplicativo e conseqüentemente a identificação de problemas maiores;
- Concluir todos os testes de unidade antes de fazer o teste de integração, novamente
retarda a identificação de problemas maiores.
Postado por Fernando Dantas Santos Júnior às 16:24 0 comentários
Sábado, 19 de Abril de 2008
RUP Key Principals: Elevate Level of Abstraction
É basicamente por causa desse princípio que hoje não programamos mais em Assembly
ou C++, ou seja, quanto mais elevado o nível de abstração mais a complexidade de um
projeto é reduzida. Essa abstração pode se manifestar de várias formas como adoção de
uma linguagem de alto nível como .NET ou JAVA, adoção de um componente de mercado
ou mesmo pelo uso de serviços disponibilizados através de WebServices.
Quando esse conceito não é corretamente observado o projeto é guiado pela
complexidade e baixa produtividade ficando o business em segundo plano. Outra
abordagem para gerenciar a complexidade é focalizar na arquitetura através do
desenvolvimento de uma que seja estável e testada atuando como referência para os
projetos que ainda serão desenvolvidos.
Os benefícios desse princípio são:
- Aumento da produtividade;
- Redução da complexidade.
Práticas para atingir esses benefícios:
- Promover a reutilizar de ativos existentes;
- Utilizar ferramentas e linguagens de alto nível;
- Focalizar na arquitetura;
- Estabelecer controles sobre a qualidade e complexidade.
Como não atingir esses benefícios:
- Evoluir de requisitos direto p/ código customizado não estimula o reuso pois: enibe a
discussão no foco conceitual, requer constante revisão de decisões e limita o foco na
arquitetura resultando em atraso e retrabalho no projeto.
Postado por Fernando Dantas Santos Júnior às 14:01 0 comentários
Sábado, 15 de Março de 2008
Roteiro para prova RUP 839: Rational Unified Process v7.0
Atendendo a pedidos resolvi postar um roteiro de estudo para quem deseja fazer a prova
839 do RUP 7. Esse foi mais ou menos o caminho que segui, salvo pelo fato de que havia
iniciado os estudos para a prova antiga (639) de RUP 2003 até que descobri a existência
da nova 839 lançada em Jul/2007.
Antes de começar a estudar é importante entender como funciona a prova. Ela não é
muito diferente de outras certificações podendo ser marcada pelos centros Prometric e
custando U$ 100,00. É composta de 52 questões e pode ser feita em até 75min sendo a
nota mínima para aprovação de 62%, ou seja, erre no máximo 19 questões para ser
aprovado.
Outro ponto importante sobre a prova é entender o foco da mesma. Como pode ser visto
no site oficial da Certificação o foco é distribuído conforme abaixo:
- Iterative Development Principles (16.6%)
- Iterative Development Work Products (16.6%)
- Basic Method Elements and their Relationships (16.6%)
- Basic Process Elements and their Relationships (16.6%)
- Basic Content of Disciplines (33.6%)
Passo 01: O caminho das pedras:
- O Livro IBM Rational Unified Process Reference and Certification Guide: Solution
Designer (RUP) de Ahmad K. Shuja e Jochen Krebs foi o primeiro a ser lançado sobre RUP
7 em Jan/2008. Recomendo fortemente a leitura pois nele ficam claras as diferenças do
RUP 2003 em relação ao 7. A cada capitulo os autores apresentam o conteúdo do RUP
atrelado a um simulado para ajudar a fixar o assunto. No último capitulo também é
apresentado um simulado dentro das condições reais da prova, ou seja, 52 questões
divididas dentro dos focos da prova;
- Durante a leitura do Livro você já deverá ter instalado em sua máquina pelo menos uma
versão Trial do RMC que contém o framework do RUP para leitura. Recomendo que você
leia o livro e constantemente complemente a leitura com o conteúdo relativo dentro do
site do RUP. Isso lhe ajudará a se familiarizar com o site do RUP e também a aprofundar
em alguns temas.
- Depois de finalizada toda a leitura do livro é hora de explorar mais o site do RUP. Alguns
conteúdos sugeridos por Hans Admiraal em "Learning RUP 7.0" são realmente
fundamentais e de leitura obrigatória.
Passo 02: Não entre na sala de exames sem ter “decorado”:
- Os 6 Key Principals do RUP e seus benefícios. Não é necessário decorar os Patterns e
Anti-Patterns mas o benefícios com certeza sim;
- As disciplinas do RUP e os propósitos de cada uma delas;
- O que é UMA e quais são exatamente cada um dos elementos de conteúdo (Roles,
Tasks, Steps, WorkProducts, etc..) e dos elementos de processo (Activities, Iterations,
Phases, Capability Pattern, etc);
- As fases do RUP e os objetivos de cada uma, assim como, os Milestones;
- No site do RUP leia com atenção todo o conteúdo disponível em: Work Products > RUP
Domains > Project Management. Vários WorkProducts de gerenciamento são cobrados,
principalmente o Software Development Plan e seus cinco sub-artefatos devem ser
decorados.
Passo 03: Os simulados:
- A essa altura você já deveria estar aplicando os próprios conceitos do RUP para evitar
que seu projeto de Certificação falhe. Sendo assim podemos dizer que os simulados são a
sua Arquitetura Executável. Infelizmente, como a própria certificação 839 é recente você
não encontrará muitos simulados facilmente;
- Para ter uma idéia real das questões da prova o próprio site oficial do RUP dá cinco
questões de demonstração que vale a leitura;
- Não achei nenhum testking liberado sobre a prova mas no site da própria testking é
possível baixar a versão demo com 21 questões que já foram muito úteis;
- Por último no site de Hans Admiraal é possível fazer um simulado do RUP 2003
gratuitamente e outro de RUP 7, porém pago. Digamos que com um pouco de insistência
técnica você pode conseguí-lo gratuitamente :-).
Para facilitar segue link para Download das principais questões que utilizei para estudo.
Passo 04: O grande dia:
- Se você fez tudo como sugerido somando uma grande vontade de não perder U$ 100,00
você terá grandes chances de atingir os 62% da prova e se tornar um IBM Certified
Solution Designer - IBM Rational Unified Process V7.0.
Bom, espero que as dicas sejam úteis na busca pela certificação e se isso acontecer peço
que me mande um post pois ficarei feliz em saber.
Postado por Fernando Dantas Santos Júnior às 21:31 1 comentários
Domingo, 2 de Março de 2008
RUP Key Principals: Collaborate Across Teams
Walker Royce já dizia que o desenvolvimento de software é um esporte em equipe e
como tal exige grande colaboração para se produzir um produto final. Dentro do ciclo de
vida de um processo cascata o trabalho em equipe geralmente não é estimulado pois o
que freqüentemente ocorre é que um grande volume de requisitos é “empurrado” para a
equipe de analistas, que por sua vez, “empurra” a análise & desenho para os
desenvolvedores e assim por diante. Esse comportamento faz com que cada um se sinta
menos responsável pelo produto final do que o outro.
Dentro do processo iterativo toda a equipe é envolvida desde o início do projeto o que
estimula a integração e aguça o senso de responsabilidade pelo produto final pois todos
estão empenhados em gerar um produto executável ao fim de pequenas iterações.
Estimular a colaboração funcional é outro fator importante. As barreiras que geralmente
separam cada função não devem existir, ou seja, não deve existir a “equipe” de analistas,
a “equipe” de desenvolvedores, a “equipe” de testers pois isso acaba distorcendo o foco.
O importante é que exista uma única equipe cujo objetivo é entregar um software com
qualidade. Isso significa que basicamente todos são responsáveis por compreender o que
está sendo produzido e que qualidade não é uma função apenas dos Testers.
Outro ponto importante e que estimula a colaboração é a existência de um ambiente
integrado onde ferramentas podem automatizar tarefas, coletar métricas, gerar status
reports, auxiliar na gerencia de configuração e mudanças, etc. Isso libera a equipe para
realizar atividades que realmente são importantes e agregam valor ao ciclo de
desenvolvimento.
Os benefícios desse princípio são:
- Produtividade da equipe;
- Melhor integração entre: necessidades de negócio, desenvolvedores e operação.
Práticas para atingir esses benefícios:
- Motivar pessoas a realizarem seu melhor;
- Criar equipes auto-gerenciadas;
- Encorajar colaboração funcional entre analistas, desenvolvedores, etc;
- Proporcionar ambientes de colaboração efetiva;
- Gerenciar evolução de artefatos em tarefas;
- Integrar equipes de negócios, desenvolvimento e operação.
Como não atingir esses benefícios:
- Criar desenvolvedores heróicos e estimular horas extras;
- Ter pessoas especializadas e equipamentos de ponta sem colaboração entre elas.
Postado por Fernando Dantas Santos Júnior às 13:31 0 comentários
Segunda-feira, 25 de Fevereiro de 2008
RUP Key Principals: Balance Competing Stakeholder Priorities
Balancear prioridades sempre é uma tarefa difícil já que na visão de cada stakeholder
seus requisitos são sempre mais importantes do que os requisitos dos outros.
Desenvolver um software sem estabelecer nas fases iniciais o que realmente é prioritário
significa apenas que foco desnecessário será dado em algo que não agrega valor ao
negócio e muito menos atende as expectativas dos usuários.
Outro fator importante quanto ao processo de priorização de requisitos é que ele não
deve levar em conta apenas as necessidades de alguns stakeholders. Priorizar os
requisitos significa entender o negócio, as necessidades de cada stakeholder e então
balancear cada uma das necessidades.
Outro fator importante relacionado a este princípio é a redução do desenvolvimento
customizado. Isso significa avaliar os prós e contras do desenvolvimento de um
software/componente customizado e a utilização de um já pronto que atenda
parcialmente os requisitos.
Os benefícios desse princípio são:
- Alinhar negócio e necessidades do usuário;
- Reduzir o desenvolvimento customizado;
- Otimizar o valor do negócio.
Práticas para atingir esses benefícios:
- Definir e priorizar o negócio x necessidades do usuário;
- Priorizar requisitos;
- Entender quais ativos podem ser alavancados;
- Equilibrar a reutilização dos recursos x necessidades do usuário.
Como não atingir esses benefícios:
- Documentar a fundo os requisitos no início do projeto;
- Negociar todas as alterações nos requisitos;
- Congelar os requisitos diretos;
- Priorizar o desenvolvimento customizado;
- Atender principalmente as necessidades dos investidores mais vocais.
Postado por Fernando Dantas Santos Júnior às 17:17 0 comentários
Quinta-feira, 21 de Fevereiro de 2008
Resumo Livro: The Rational Unified Process Made Easy
Um dos livros mais conhecidos de RUP e que sem dúvida é leitura obrigatória para quem
está começando no assunto é o “The Rational Unified Process Made Easy: A Practitioner's
Guide to the RUP” de Per Kroll e Philippe Kruchten. Com uma abordagem muito prática o
livro explica toda a estrutura do RUP 2003 passando por seus princípios, processo
Iterativo, fases e disciplinas, etc. Traz ainda um capítulo interessante onde todo o ciclo de
vida de um pequeno software é explicado através do RUP.
Para quem já leu o livro e gostaria apenas de rever seu conteúdo ou mesmo para quem
quer uma visão geral fiz um pequeno resumo (parte em português e parte em inglês) que
pode ser útil. Vale lembrar que esse livro refere-se ao RUP 2003 e conseqüentemente a
Certificação 639 que é a antecessora da atual 839 sobre RUP 7.
Em breve também publicarei um resumo do recém publicado livro “IBM Rational Unified
Process Reference and Certification Guide: Solution Designer (RUP)” de Ahmad K. Shuja e
Jochen Krebs que me ajudou muito na certificação 839.
Download Resumo - Formato ZIP - 1MB
Download Resumo - Formato PDF - 1.2MB
Qualquer sugestão ou contribuição quanto ao resumo comentem ou me enviem por
email([email protected])
Postado por Fernando Dantas Santos Júnior às 18:53 1 comentários
Quarta-feira, 20 de Fevereiro de 2008
RUP Key Principals: Adapt the Process
Este é um princípio simples e que talvez por isso seja tão subestimado. Vejo muitas
pessoas alegarem que o RUP é “muito pesado” e possui muitos artefatos. É aí que mora o
desconhecimento pois esse princípio diz respeito justamente a adaptar o nível de
cerimônia ao seu contexto. É importante entender que o RUP é como um banquete, ou
seja, você deve escolher o que deseja ao invés de se empanturrar.
É extremamente importante para o sucesso de um projeto que o processo seja adequado
e que o nível de cerimônia seja ajustado, pois documentação em excesso não trará
produtividade e documentação superficial trará problemas de comunicação.
Projetos maiores, com tecnologias complexas e maior número de stakeholder geralmente
precisam seguir padrões mais formais. Porém, para pequenos projetos com equipes locais
e tecnologias conhecidas o processo deve ser mais leve.
Outro erro comum que esse princípio trata é a criação de planos e estimativas estáticas.
Todos sabem que o nível de incerteza no início de um projeto é alto e tentar estabelecer
um plano estático e absoluto na fase de Iniciação nunca funciona pois apenas na fase de
Elaboração é que se pode ter uma visão mais estável dos requisitos e da arquitetura.
Os benefícios desse princípio são:
- Eficiência de ciclo de vida;
- Maior agilidade do projeto;
- Planos e estimativas mais realísticas.
Práticas para atingir esses benefícios:
- Dimensione corretamente o processo para o projeto;
- Adapte a cerimônia de acordo com o ciclo de vida;
- Aprimore o processo continuamente;
- Equilibre planos e estimativas com o nível de incertezas.
Como não atingir esses benefícios:
- Determine estimativas fixas no início do projeto;
- Desenvolva planos estáticos.
Postado por Fernando Dantas Santos Júnior às 18:34 0 comentários
Postagens mais antigas