Conceito:
|
White Papers: |
O RUP (Rational Unified Process) é uma estrutura de processo que o Rational Software aperfeiçoa com o passar dos anos e tem sido amplamente utilizado para todos os tipos de projetos de software, do pequeno ao grande. Recentemente um número crescente de processos "dinâmicos", como XP (eXtreme Programming), SCRUM, FDD (Feature-Driven Development) e a Metodologia Crystal Clear têm obtido reconhecimento como métodos eficazes para a criação de sistemas menores. (Consulte www.agilealliance.org para obter informações adicionais sobre a Agile Alliance.)
As seguintes seções têm por objetivo auxiliar essas equipes de projeto, avaliando algumas das práticas "dinâmicas" localizadas em um desses métodos para verificar como elas são abordadas por um processo de desenvolvimento de software mais completo, definido pelo RUP.
A comunidade dinâmica sintetizou um número de "boas práticas" que são especialmente aplicáveis às equipes de projeto pequenos no mesmo local. Embora o RUP seja destinado às equipes de projeto de qualquer tamanho, ele pode ser aplicado com êxito aos projetos pequenos. Em geral, o RUP e os processos da comunidade Agile têm uma visualização semelhante às boas práticas principais requeridas para desenvolver software de qualidade, por exemplo, aplicando o desenvolvimento iterativo e enfatizando os usuários finais.
As seguintes seções explicam como aplicar algumas das "boas práticas",
identificadas na comunidade Agile para projetos com base em RUP que gostariam de se beneficiar
de algumas dessas práticas. Nesse caso, o foco estará especificamente nas práticas apresentadas pela metodologia eXtreme Programming (XP).
(Para obter informações adicionais sobre o XP, consulte o Web site: http://www.extremeprogramming.org.)
O XP inclui quatro "atividades" básicas (codificação, teste, monitoramento e design), que na verdade, estão mais intrinsecamente relacionadas às disciplinas RUP. Essas atividades de XP são executadas usando um conjunto de práticas que requerem a execução de atividades adicionais, que estão mapeadas em outras disciplinas do RUP. As práticas do XP, de acordo com Extreme Programming Explained, são:
As atividades realizadas como resultado da prática de "jogo de planejamento", por exemplo, mapearão principalmente para a disciplina de gerenciamento de projeto do RUP. No entanto, alguns tópicos do RUP, como modelagem de negócios e implantação do software liberado, estão fora do escopo de XP. A obtenção de requisitos está ainda mais fora do escopo de XP, já que é o cliente quem define e fornece os requisitos. Além disso, devido aos projetos de desenvolvimento mais simples com os quais lida, a XP pode tratar de forma mais superficial as questões que o RUP aborda em detalhes na disciplina de Gerenciamento de Configuração e Mudança e na disciplina de Ambiente.
Nas disciplinas em que o XP e o RUP se sobrepõem, as seguintes práticas descritas no XP podem ser e, em alguns casos já são, empregadas no RUP:
A idéia de que um bom processo deve ser imposto no nível "micro" não costuma ser bem recebida e pode não ser adequada a algumas culturas empresariais. Por isso, qualquer imposição rígida não é defendida pelo RUP. Entretanto, em algumas circunstâncias, o trabalho em pares, e algumas das outras práticas de equipe defendidas pela XP, é obviamente vantajoso, como cada membro de equipe pode ajudar o outro; por exemplo:
As práticas do RUP, a seguir, não são compatíveis com sistemas grandes (nem a XP afirma que o são). Por isso, seu uso estaria sujeito a esta condição no RUP.
Finalmente, uma prática de XP que aparentemente possa ser utilizada no RUP-Design Simples-precisa
de alguma elaboração e cuidado quando aplicada geralmente.
Há um problema aqui, semelhante ao problema das otimizações locais, que é lidar com o que o RUP chama de requisitos "não-funcionais". Esses requisitos também agregam valor de negócio para o cliente, mas são mais difíceis de expressar como histórias. Algumas das restrições (assim denominadas pela XP) se enquadram nessa categoria. O RUP também não defende que se faça design a mais do que seja necessário em qualquer tipo de modo especulativo, mas defende o design com um modelo arquitetural mental - modelo este que é uma das chaves para se encontrar os requisitos não-funcionais.
Assim, o RUP concorda com a XP que o "design simples" deve incluir a execução de todos os testes, mas com a condição de que ele inclua testes que demonstrem que o software atenderá aos requisitos não-funcionais. Mais uma vez, essa só é uma questão válida à medida que o tamanho do sistema e a complexidade aumentem ou quando a arquitetura é inédita ou os requisitos não-funcionais são dispendiosos. Por exemplo, a necessidade de dados desordenados (para operar em um ambiente distribuído de forma heterogênea) parece tornar o código excessivamente complexo, mas ele ainda será necessário durante todo o programa.
Quando adaptamos o RUP para um projeto pequeno e reduzimos os requisitos do artefato de acordo, como isso se comparar ao equivalente de artefatos em um projeto XP? Verificando o exemplo de caso de desenvolvimento para projetos pequenos no RUP, observamos que uma configuração RUP de amostra
foi configurada para produzir menos artefatos (conforme mostrado na Tabela 1).
Artefatos de XP
|
Artefatos RUP
(do ![]() |
---|---|
Histórias Documentação adicional a partir de conversações |
Visão Glossário Modelo de Casos de Uso |
Restrições | Especificações Suplementares |
Testes de aceitação e testes de unidade Dados de teste e resultados de teste |
|
Software (código) | Modelo de Implementação |
Releases | ![]() ![]() |
Metáfora | Documento de Arquitetura de Software |
Design (CRC, esboço UML) Tarefas técnicas e outras tarefas Documentos de design produzidos no final Documentação de suporte |
Modelo de Design |
Padrões de codificação | ![]() |
Espaço de Trabalho
Estrutura de teste e ferramentas |
![]() ![]() |
Plano de liberação Plano de iteração Estimativas de história e de tarefa |
Plano de Desenvolvimento de Software
Plano de Iteração |
Orçamento e plano geral | Caso de Negócios Lista de Riscos |
Relatórios em andamento Registros de tempo para o funcionamento da tarefa Dados de métricas (incluindo recursos, escopo, qualidade, tempo) Rastreamento de resultados Relatórios e notas sobre reuniões |
Avaliação de Status Avaliação de Iteração Registro de Revisão |
Defeitos (e dados associados) | Controle de Mudanças |
Ferramentas para gerenciamento de código | Repositório de Projeto ![]() |
Pico (solução) |
Protótipos |
A própria XP (suas recomendações e diretrizes) | |
[Não incluído no XP] |
Tabela 1: mapeamento XP-a-RUP dos artefatos para um projeto pequeno
Embora a granularidade dos artefatos varie nos dois lados, em geral os artefatos no RUP para projetos pequenos (do tipo com o qual a XP lidaria tranqüilamente) são mapeados sem problemas para os de um projeto de XP.
Observe que o Exemplo de Caso de Desenvolvimento
para Projetos Pequenos também inclui alguns artefatos que não são cobertos pela
XP, mas são necessários em muitos projetos. Incluem Modelo de
Dados e artefatos relacionados à implementação, como
Material de
Suporte ao Usuário Final.
O RUP define uma atividade como o trabalho realizado por uma função, utilizando e transformando artefatos de entrada ou produzindo artefatos de saída novos e alterados. O RUP continua enumerando essas atividades e as categoriza de acordo com as disciplinas do RUP. Essas disciplinas incluem: modelagem de negócios, requisitos, análise e design, implementação e gerenciamento de projeto (entre outras).
As atividades estão relacionadas ao tempo por meio dos artefatos que produzem e consomem: uma atividade pode logicamente ser iniciada quando suas entradas estiverem disponíveis (e em um estado de maturação apropriado). Isso significa que os pares de atividades produtor-cliente podem se sobrepor no tempo, se o estado do artefato permitir. Eles não precisam obedecer a uma seqüência rígida. As atividades se destinam a fornecer diretrizes claras sobre como um artefato deve ser produzido ou alterado e podem ser usadas para ajudar o gerente de projeto no planejamento.
Combinadas por meio do RUP, já que são descritas em termos de ciclo de vida, artefatos e atividades são "boas práticas": princípios de engenharia de software que comporvadamente produzem softwares de qualidade criados para orçamento de programação previsíveis. Através de suas atividades (e artefatos associados), o RUP suporta e realiza essas melhores práticas. Elas são temas executados através do RUP. Observe que a XP utiliza a noção de "práticas" também, mas, como veremos, não corresponde exatamente ao conceito de boas práticas do RUP.
A XP apresenta uma visão de desenvolvimento de software que é atraentemente simples, composta por quatro atividades básicas (codificação, teste, monitoramento e design) que devem ser ativadas e estruturadas de acordo com algumas práticas de suporte (conforme abordado no capítulo 9 do livro Extreme Programming Explained). Na verdade, como observado anteriormente, as atividades de XP estão mais relacionadas em escopo às disciplinas do RUP do que às atividades do RUP. Muito do que acontece em um projeto de XP (além de suas quatro atividades básicas) é resultado da elaboração e da aplicação de suas práticas.
Portanto, há equivalência entre as atividades de XP e RUP, mas as "atividades" de XP não estão formalmente identificadas ou descritas como tal. Por exemplo, verificando o Capítulo 4, "Histórias de Usuários", no Extreme Programming Installed, você encontrará o título, "Definir requisitos com histórias, escritas em cartões" e em todo o capítulo há uma mistura da descrição do processo e da orientação sobre o que são histórias de usuários e como (e por quem) elas devem ser produzidas. E continua assim; nas várias seções dos manuais de XP (com títulos que são uma mistura de ênfase em artefato e ênfase em atividade), os "itens produzidos" e os "itens feitos" são descritos em graus variáveis de prescrição e de detalhes.
O grau de prescrição aparentemente alto do RUP é resultado da abrangência e maior formalidade no tratamento de atividades e de suas entradas e saídas. Não falta prescrição à XP, porém, na sua tentativa de permanecer leve, a formalidade e os detalhes são simplesmente omitidos. A falta de especificidade não é vantagem nem desvantagem, mas a falta de informações detalhadas no XP não deve ser confundida com simplicidade. A falta de detalhes pode ser ótima para desenvolvedores mais experientes, mas, em muitos casos, a fartura de detalhes é uma grande ajuda para membros da equipe que sejam novos ou que ainda estejam tentando acompanhar o ritmo da abordagem da equipe quanto a desenvolvimento de software.
Com Atividades, assim como com Artefatos, é importante manter o foco no que estamos tentando alcançar.
Executar uma atividade às cegas nunca é uma boa prática.
As atividades e as diretrizes associadas estão à disposição para quando você precisar delas para atingir seus objetivos, mas não devem ser usadas como desculpa para não ter de descobrir qual é o seu objetivo.
Esse pensamento é bem articulado
em XP e acreditamos que deva ser aplicado a todos os usuários de RUP.
No RUP, dizem que as atividades devem ser executadas por funções (ou, mais precisamente, por indivíduos ou grupos exercendo funções). As funções também têm responsabilidade por artefatos específicos; a função responsável normalmente criará o artefato e garantirá que as mudanças feitas por outras funções (se permitidas) não danifiquem o artefato. Um indivíduo ou um grupo de pessoas pode assumir apenas de um a vários papéis. Uma função não tem que ser mapeada para uma única posição ou "slot" em uma organização.
O Extreme Programming Explained identifica sete funções aplicáveis ao Programador XP, Cliente, Testador, Rastreador, Técnico, Consultor e Diretor e descreve suas responsabilidades e as competências requeridas das pessoas que as executarão. As referências são feitas a essas funções em alguns dos outros manuais de XP também. A diferença no número de papéis no XP e no RUP é fácil de explicar.
Quando as funções RUP são mapeadas para um projeto pequeno, o número de funções parecidas com XP
as quais elas correspondem é reduzido consideravelmente em que o número de posições ou títulos de tarefas
é 5. A Tabela 3 (retirada do RUP) mostra este mapeamento com a Função XP correspondente.
Função XP | Exemplo de Membro da Equipe de Projeto Pequeno do RUP | Função RUP |
---|---|---|
Técnico Consultor Diretor |
Sally Slalom, Gerente Sênior | Coordenador de Projeto![]() Revisor Técnico Gerenciador de Configuração Gerenciador de Controle de Mudanças |
Cliente | Investidor (conforme documentado naVisão) |
Revisor de
Gerenciamento Revisor Técnico (requisitos) |
Cliente
Diretor Rastreador |
Tom Telemark, Engenheiro de Software Sênior | Analista de Sistemas Especificador de Requisitos Designer da Interface com o Usuário Arquiteto de Software Revisor Técnico Gerenciador de Teste ![]() e, em menor proporção, os papéis de desenvolvimento. |
Programador Testador |
Susan Snow, Engenheira de Software Henry Halfpipe, Engenheiro de Software Júnior |
Designer Implementador Revisor Técnico Integrador ![]() ![]() ![]() |
Rastreador | Patrick Powder, Assistente Administrativo | Responsável por manter o site do projeto na Web, auxiliar a pessoa que exerce o papel de Gerente do Projeto no planejamento/programação de atividades e ajudar a pessoa que exerce o papel de Gerente de Controle de Mudança a controlar mudanças nos artefatos. Também pode auxiliar outras funções conforme necessário. |
Tabela 3: Mapeando funções XP para funções RUP em um projeto pequeno
O RUP é um framework de processo a partir do qual determinados processos podem ser configurados e, em seguida, instanciados. O RUP deve ser configurado, esta é uma etapa obrigatória, definida no próprio RUP. Especificamente falando, devemos comparar uma versão adaptada do RUP com XP, ou seja, com o RUP adaptado às características do projeto que a XP explicitamente estabelece (e as que podem ser inferidas). Um processo de RUP adaptado dessa forma poderia acomodar muitas das práticas de XP (como programação em pares, refatoração e teste anterior ao design), mas ainda não seria idêntico à XP, por causa da ênfase do RUP em arquitetura, abstração (em modelagem) e risco e de sua estrutura diferente no tempo (fases e iterações).
A XP é dirigida intencionalmente para a implementação de um processo leve para projetos pequenos. Ao fazer isso, ela também inclui descrições (pelo menos nos livros) que não são totalmente elaboradas. Em uma implementação de XP, sempre haverá itens que precisam ser descobertos, inventados ou definidos rapidamente. O RUP acomodará projetos que estejam adequados ou além do escopo da XP em escala e tipo. Como mostra este roteiro, na verdade, o RUP é perfeitamente compatível com a maioria das práticas descritas na literatura sobre XP.
Lembre-se de que a essência da XP é o foco na organização, nas pessoas e na cultura. Isso é importante em todos os projetos e, certamente, é aplicável aos projetos que usam o RUP. O uso conjunto dessas práticas seria muito vantajoso para projetos pequenos.
Rational Unified Process
|