1- Desenvolva software iterativamente
2- Gerencia Requisitos
3- Utilize arquiteturas baseadas em componentes
4- Utilize modelagem visual
5- Verifique qualidade continuamente
6- Mantenha alterações sob controle
Se você trabalhasse em uma empresa pequena, com recursos limitados, onde você pudesse escolher apenas um destes itens, qual você escolheria?
Essa pergunta foi feita por meu professor, na aula de Engenharia de Software.
De certo modo, todos os 6 itens estão relacionados e, na teoria, são indispensáveis. Mas e se de fato tivéssemos que escolher um deles para seguir rigorosamente?
De nada adianta o desenvolvimento iterativo sem qualidade. Não estou de forma alguma desmerecendo o RUP e o desenvolvimento iterativo. Muito pelo contrário, cada vez que me aprofundo no estudo de processos de desenvolvimento rápido, mais interessado fico. O que quero dizer é que em nada adianta repetir fases do processo à medida que o desenvolvimento avança, se o processo for uma merda ruim.
De maneira análoga, não resolve muita coisa uma arquitetura baseada em componentes, se os componentes não possuirem qualidade, se foram mal projetados.
Acredito que, como ocorreu na aula, a grande maioria ficaria entre os itens 2 e 4. De fato, um dos problemas que mais afetam uma empresa pequena é a análise incorreta dos requisitos. Após desenvolvido, o software retorna várias vezes porque não estava do modo que o cliente queria. E a culpa é de quem? Do cliente que não disse desde o início o que queria? Ou do analista que não soube abstrair da conversa com o cliente as informações de que precisava? Veja bem, quando estou passando mal e vou ao médico, tenho que dizer todos os sintomas de forma detalhada? “Senhor médico, estou com dor de cabeça. Além disso, estou com a perna direita doendo, tem uma áfita na minha boca (no canto superior esquerdo), minha unha está incravada e estou tendo alucinações. Ah.. e faz 3 dias que não me alimento.”
É claro que não é assim que deve funcionar. “Estou com dor de cabeça” ou “Preciso de um software para X”. E o médico/analista é quem deve realizar as devidas inferências, para identificar as causas do problema, e decidir o melhor modo de resolver o problema.

#1 by leonardo kenji - September 15th, 2008 at 15:41
eu acho que deveriam existir empresas especializadas só em levantar requisitos