[quote=Marcio Duran] :idea: Não é a UML que é Inútil.Mas Inútil é transformar o liguagem de Programação em Idioma de Programação, bem ai sim para que vou querer UML, se já posso conversar com as minhas aplicações por igual.
:arrow: É por isso que quando você embarca em projetos as pessoas não tem um sincronismo melhor no projeto porque cada um entende aplicação ao seu modo, e ai nasce esses loucuras de FrameWorks não-funcionais, descabidos por ai, vendendo a torto e a rodo em uma espécie de vendas a toda proa.
:arrow: E concordo, UML não é documentação mesmo, mas é sim o que se tem de mais precioso no contexto do Projeto. [/quote]
Quando vejo suas mensagens nesse “bom” português, sabe do que tenho medo? Do seus códigos!
Baseado em conhecimentos acadêmicos, e algumas horas em projetos, eu diria que quanto melhor especificado o projeto estiver, melhor.
Melhor para quem vai gerenciar (gerente de projeto poderá recusar uma mudança no escopo evitando apertar o tempo de entrega ou o custo do projeto), melhor para o cliente (que tem especificado tudo aquilo que ele necessita, com a ajuda de bons analistas de negócios e de muita conversa com quem mete a mão na massa, literalmente) e melhor para quem vai desenvolver, pois não terá que refazer, alterar, quebrar a cabeça com algo que não valerá a pena.
Agora, o que usar para melhor especificar, aí vai de casa empresa. A maioria pouco faz…
Ao meu ver, realmente acho que temos que partir para soluções mais ágeis, mesmo porque o tempo é escasso na maioria dos projetos. Porém ainda sou contra eliminar toda a documentação, muitas vezes, em um projeto, e mesmo depois da entrega aparecem discussões sobre as funcionalidades que um produto deveria contemplar ou não… Ou mesmo quando se necessita realizar um retrabalho para correção, ou implementação de novas funcionalidades, ou até mesmo numa migração do sistema para uma outra plataforma. Nessas ocasiões, poder abrir uma documentação clara, organizada e atualizada é o melhor dos mundos.
…
[/quote]
Acho que no caso citado, não existe melhor documentação do que testes. [/quote]
Testes ajudam a testar (passo a redundancia) se as alterações não quebraram o sistema, mas os testes não o ajudam a saber como a aplicação funciona. Para que vc altera a aplicação vc tem que entender como ela funciona. Como ela for organizada, qual é a arquitetura, qual é a filosofia de desenvolvimento, o design ,etc… Sem uma documentação que fala sobre isto, a alteração é muito mais dificil e às vezes impossivel. Acho que era isso que o ftrapnell se referia. Documentação para que terceiros entendam o
sistema. Estes terceiros não são o owner nem os desenvolvedores que trabalharam no projeto.
[quote=xGambit]Baseado em conhecimentos acadêmicos, e algumas horas em projetos, eu diria que quanto melhor especificado o projeto estiver, melhor.
Melhor para quem vai gerenciar (gerente de projeto poderá recusar uma mudança no escopo evitando apertar o tempo de entrega ou o custo do projeto), melhor para o cliente (que tem especificado tudo aquilo que ele necessita, com a ajuda de bons analistas de negócios e de muita conversa com quem mete a mão na massa, literalmente) e melhor para quem vai desenvolver, pois não terá que refazer, alterar, quebrar a cabeça com algo que não valerá a pena.
Agora, o que usar para melhor especificar, aí vai de casa empresa. A maioria pouco faz…
[/quote]
Exatamente, porém é bom adicionar que especificação pode ser feita por testes, e geralmente esta é uma ótima técnica. Testes funcionais verificam se os requisitos são obedecidos, testes de integração veriicam a arquitetura e testes unitários dizem como as classes se comportam.
Yoshi, eu sempre me senti mais à vontade com as Especificações Técnicas, onde as funcionalidades do módulo são descritas passo a passo, com a imagem da modelagem (bem normalizada, é claro), com as ações de cada botão (seus respectivos eventos e fluxos alternativos), etc.
Pode ser muito imbecil de minha parte, mas até hoje não consegui entender os diagramas de sequencia, justamente devido à uma falta de padronização (cada um escreve de uma forma, e ninguém entende nada). Também muito estranhamente, até hoje não conheci alguém que use UML total na prática.
Qual seria a melhor forma de explicitar tecnicamente, para o programador, o que ele exatamente deve desenvolver, quais tabelas deverão ser populadas, como cada componente deverá se comportar, etc ?