Atualmente existe no mercado uma demanda cada vez maior de softwares de qualidade e com prazos cada vez menores para o seu desenvolvimento.
As metodologias(que eu conheço!!!) descrevem de forma quase utópica os processos para desenvolvimento de software, pois na prática é tudo muito diferente (eu acho). :roll:
Será que essas metodologias funcionam ou funcionarão algum dia?
Alguém já teve alguma experiência bem sucedida a esse respeito? Se sim, qual delas foi utilizada?
Até hoje tsutsumi a unica metodologia que trabalhei e posso dizer que conheço é o RUP (Rational Unified Process), com o processo de desenvolvimento orientado a objetos no desenvolvimento de uma aplicação de médio porte em Java, que foi o sistema que fiz.
Pois segue um modelo não em cascata, e sim uma pratica na qual você irá desenvolver o sistema é varias em basicamente 4 etapas: concepção, elaboração, construção e testes.
Sendo que em cada fase você irá executar um pouco de cada outra fase. Bom acho que você deve saber disso.
Claro que ele não é 100% aplicável, mas reduz bastante o risco de inuscesso do seu sistema.
Nesta pagina
Tem um resumo muito legal, que sempre é bom ler para relembrar, e o tradicional gráfico das baleias
Acho que o que atrapalha mais na aplicação das metodologias, são as constantes mudanças que ocorrem, inevitavelmente, durante o desenvolvimento de um projeto, que faz com que haja várias alterações nas especificações do software(nem sempre documentadas 8O ),que podem causar problemas futuros,como o da manutenção.
Falou tudo, isso ocorre mesmo, vc já tem algo definido, mas chega em um determinado ponto do sistema que começa a ter falhas e vc é obrigado a reavaliar se a metodologia aplicada é correta.
Poutz, isso é F#$%
vc já tá com o levantamento de requistos, todo levantado, documentação, diagramas e tal
Chega seu usuário, Muda isso aqui pra mim!
Isso literalmente atrapalha muito, mais ainda em relação a prazo inicialmente proposto
por isso q surgiu a XP (eXtreme Programming)
p/ diminuir todos esses problemas…
A verdade é que o relacionamento Usuário-Desenvolvedor é sempre uma questão a parte quando se trata de desenvolvimento de softwares, principalmente quando são usuários leigos no assunto.Por isso as metodologias sugerem que os usuários tenham um analista que domine o assunto pra defender seus interesses e informá-lo do custo de cada mudança solicitada,evitando assim, uma maior insatisfação por parte do usuário :briga:
Nossa como se fala na metodologia XP :haha: :!:
Ela é sugerida para equipes com número reduzido de desenvolvedores e para softwares de pequeno a médio porte. Vale lembrar que a equipe deve ser bastante experiente e integrada,pois a comunicação é tudo na metodologia XP. Mas nem todos os projetos se adequam à ela,por isso a discussão sobre outras metodologias e a melhor forma de utilizá-las para evitar desgastes no processo de desenvolvimento de software
[quote=“rbarioni”]por isso q surgiu a XP (eXtreme Programming)
p/ diminuir todos esses problemas…[/quote]
Xp é nada mais nada menos que dar nome a bagunça! :lol:
Porém funciona muito bem em projetos pequenos que necessitam ter “releases” rápidos. E com constrante mudança do sistema. O maior problema é quando o sistema começa a ficar grande. Pois o mesmo não foi projetado com visão de crescimento, o que torna as futuras alterações extremamente difíceis. É como se começasse a construir uma casinha de 3 quartos e ela ir crecendo até o dono descidir que não é mais casinha que ele quer mas sim um prédio de 10 andares. Você literalmente tem que “demolir” o código e começar do zero.
Quando vc utiliza a metodologia UP ou RUP (a diferenca da UP p/ RUP é basicamente a utilização das ferramentas da Rational para otimizar as etapas) tem que tomar muito cuidado na parte de análise, que na minha visão é a mais importante. Pois na análise que será definido as funcionalidades do sistema, e a análise não deve ser feita correndo em poucas etapas, ela tem que amadurecer aos poucos até que vc tenha informação suficiente para montar a proposta.
Com a proposta pronta, documentada e aceita por ambas as partes (cliente e desenvolvedor) qualquer nova funcionalidade deverá ser tratada a parte como um novo projeto. A única alteração que deverá ser feita no sistema após começar o projeto são correções de bugs e nada mais.