Será que sua empresa usa o RUP mesmo?
O RUP é sem dúvida o processo de desenvolvimento mais difundido no Brasil, talvez seja o mais utilizado e provavelmente o mais mal utilizado. As empresas tem a necessidade de dizer que tem um processo bem definido, ou pra tirar uma onda, ou pra ganhar licitações ou pra obter alguma certificação, enfim, os motivos são os mais diversos, eventualmente alguém até usa para obter software de melhor qualidade, mas será que essas empresas usam o RUP corretamente?
Segundo Craig Larman, você não entendeu o que é o Processo Unificado quando:
- Tenta definir a maior parte dos requisitos antes de começar o projeto ou a implementação;
- Tenta definir a maior parte do projeto antes da implementação;
- Se compromete com uma arquitetura antes da programação;
- Você gasta dias ou semanas em modelagem UML, antes de programar;
- Você pensa que as atividades de diagramação e projeto UML são um tempo para definir completa e precisamente projetos e modelos com grande detalhe e vê a programação como tradução simples e mecânica de diagramas para código.
- Você pensa que concepção = requisitos, elaboração = projeto e construção = implementação (Isso é cascata)
Tudo isso que ele cita como incorreto eu já vi em pelo menos um projeto, o pior, tudo isso é bastante comum em projetos que usam o RUP/Processo Unificado. Vou tentar explicar aqui os motivos pelos quais o Processo Unificado pode estar sendo utilizado de forma incorreta.
- Tenta definir a maior parte dos requisitos antes de começar o projeto ou a implementação;
- Tenta definir a maior parte do projeto antes da implementação.
- Você pensa que concepção = requisitos, elaboração = projeto e construção = implementação (Isso é cascata)
O Processo unificado é um processo e iterativo e evolutivo, ou seja ele vai evoluindo e é guiado por iterações, se você pensar como concepção = requisitos, elaboração = projeto … seu projeto é um cascata mesmo, você pode usar todos artefatos do RUP mas seu processo é cascata.
Se você por outro lado tentar para cada caso de uso esgotar a parte de análise, depois esgotar a parte de projeto, implementar todo o caso de uso e finalmente testá-lo você deixou de ter um processo cascata mas agora você tem um cascatinha, se você observar o primeiro contato do cliente com o caso de uso (software) será no dia que ele tiver pronto e aí pode surgir a surpresa de não ser o que ele queria.
- Se compromete com uma arquitetura antes da programação
Isso aqui eu nem deveria comentar, mas é algo tão comum que serei obrigado. Nos últimos anos quantos projetos você viu ser definido que seria EJB+Struts antes de levantar o primeiro caso de uso? É impressionante como tem gente que define a arquitetura antes de saber requisitos não funcionais, casos de uso mais significativos pra arquitetura, etc.
- Você pensa que as atividade de diagramação e projeto UML são um tempo para definir completa e precisamente projetos e modelos com grande detalhe e vê a programação como tradução simples e mecânica de diagramas para código.
Nas palavras de Craig Larman “Analistas experientes conhecem o segredo da modelagem:
A finalidade da modelagem (rascunhos em UML) é principalmente entender e não documentar.
Isto é, o próprio ato de modelar pode e deve fornecer um modo de melhor entender o problema ou o espaço da solução. Desse ponto de vista, a verdadeira finalidade de ‘fazer UML’ (que deveria na realidade significar faz APOO) não é de um projetista criar muitos diagramas UML detalhados que são entregues a um programador (um raciocínio não muito ágil e orientado a cascata), mas em vez disso rapidamente explorar(mas rapidamente do que com código) alternativas e o caminho para um bom projeto OO.”
Se você quer conhecer um pouco mais sobre Processo Unificado e especialmente Análise e Projeto OO não deixe de ler o livro do Craig Larman, Utilizando UML e Padrões – Uma introdução à análise e ao projeto OO e ao desenvolvimento iterativo
Mais importante do que usar RUP, Processo Unificado, XP, Scrum, uma mistura ou nenhum deles é lembrar que seu objetivo final é construir um software que atenda seu cliente com o menor custo no menor prazo.
Excelente artigo, trouxe a essência de um processo iterativo. O maior problema: nenhum gerente não-programador tem a mínima idéia do que isso quer dizer. Eu não trabalhei em um, mas vários projetos que são exatamente assim: casos de uso, documentos de requisitos, diagramas feitos todos de ante-mão, com os usuários assinando um aceite formal, depois uma fase “black-box” de implementação longa. Os usuários só vêem o produto final, na fase de testes integrados, pouquíssimo tempo antes de entrar em produção. Não tem o direito de reclamar porque assinaram um aceite formal antes e agora são obrigados a assinar um aceite formal de entrega do produto mesmo se não gostar. É a realidade de 99 em cada 100 projetos de TI. Garantido.
Excelente artigo para uma reflexão. Já que a grande maioria dos projetos passa pelos mesmos problemas, qual a verdadeira razão disso: as pessoas não se ajustarem a metodologia ou a metodologia não se ajustar às pessoas? O surgimento de novas alternativas de desenvolvimento ágil, como o XP, procuram ser uma solução a este problema, já que enfatizam a necessidade de comunicação constante e uma iteração entre cliente e sistema semanal. Além disso os demais artefatos descritos, na grande maioria das vezes, não se faz necessário serem gerados, e quando são, podem causar um “arrasto” no desenvolvimento, pois necessitam serem atualizados quando há mudanças.