Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea:
Olá,
Nossa equipe utiliza pelo menos diagrama de caso de uso, classe e estado para alguns fluxos complexos. Em alguns cenários o de sequencia.
Lembrando que utilizamos para comunicação entre a equipe.
Quanto a perder tempo, não vejo dessa forma. Talvez para um projeto pessoal seja uma “perda de tempo”, agora em um ambiente corporativo, se ganha, pois nessa fase se elimina alguns problemas que se pode ter pela frente.
Eu acredito que UML vale a pena sim, ajuda a ter uma visão melhor dos processos e a identificar problemas antes que eles apareçam de surpresa, assim é possível encontrar outra forma para resolver, ao invés de uma gambiarra.
Não digo usar todos os diagramas, apenas os mais importantes ou aqueles que te ajudem a entender o processo.
Toda vez que eu comecei, fazendo pelo menos com o diagrama de Use Case e o de classes ganhei muito tempo no desenvolvimento!
Documentar Casos de Uso é imprescindível. Diagramas de Caso de Uso são úteis em raríssimos casos. Modelos de Classes pode ser gerado automaticamente de seu código, voce nao precisa ficar preenchendo os quadradinhos e ligando com setinhas. Diagramas de Sequência são ótimos para estabelecer padrões de desenvolvimento no projeto e para documentar de maneira física a implementação de Casos de Usos complexos. E por fim, Modelagem dos Processos de Negocio esse sim qualquer projeto coorporativo de porte razoável deve possuir. Sinceramente, um sistema sem um modulo de workflow na camada de negócio não pode ser chamada de sistema coorporativo, é amadorismo puro.
Código bom é aquele em que o programador sabe qual problema resolver antes de escrever qualquer linha de código. Código ruim é aquele baseado em templates mentais, baseados em decorebas, que são marretados até chegar a algo que funcione para os problemas mais imediatos.
Usar UML é um meio de compreender aquilo que deverá ser feito. Porém, existem muitas equipes que desvirtuam o UML, e que realmente atrasam o desenvolvimento. Os problemas comuns são:
:arrow: a UML é usada como se fosse um fluxograma ou um DFD glorificado;
:arrow: a UML é vista como mais importante que o código, havendo pessoas que praticamente chegam a “codificar visualmente”;
:arrow: a UML é usada como um meio de comunicação entre um lider técnico e seus subordinados, criando burocracia e substituindo conversas reais.
Com pessoas usando UML exclusivamente para resolver problemas de design, ela se torna uma vantagem.
[quote=Leonardo3001]Código bom é aquele em que o programador sabe qual problema resolver antes de escrever qualquer linha de código. Código ruim é aquele baseado em templates mentais, baseados em decorebas, que são marretados até chegar a algo que funcione para os problemas mais imediatos.
[/quote]
Concordo com tudo o que voce disse sobre UML, só não entendi o que você quis dizer nesse primeiro comentário.
[quote=sulito]Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea: [/quote]
Isso prova que você trabalhou apenas em projetos pequenos.
Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.
Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.
Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.
A UML é utilizada para modelar e surgiu com o advento do reaquecimento da OO. E é como todas as outras coisas; quando bem utilizada se obtem beneficios, quando não perde-se tempo ou pode causar confusão.
Uma das técnicas para não se perder tempo com ela é: não modelar o que já é óbvio para equipe inteira.
Utilize a UML para ajudar a esclarecer pontos obscuros e criar soluções para questões mais complexas ou de difícil dominio.
flws
Bem-vindo ao mundo do CMMi…
Eu discordo totalmente do seu post. Ter um arquiteto da torre de marfim pra escrever UML e 10 code monkeys para cegamente implentar os diagramas UML nao é algo produtivo… ja trabalhei bastante nesse esquema e a produtividade é muito baixa. E geralmente a qualidade tambem nao é das melhores, por que o diagrama nao consegue representar tudo o que o programador precisa pra codificar, algumas decisoes o programador tem que tomar. Se o programador é um code monkey, ele vai tomar decisoes ruins. Se ele nao é um code monkey, ele nao precisa de um diagrama mostrando o que ele tem que codificar passo-a-passo.
E se voce quiser fazer um diagrama que mostra todos os detalhes pra um programador codificar, o diagrama vai ficar tao complexo e tao demorado pra fazer que voce vai precisar de 10 arquitetos da torre de marfim.
E o problema mais grave é que em 99% dos casos esses diagramas acabam ficando desatualizados. Com o passar do tempo, mudanças vao sendo feitas no codigo refletindo uma mudança nos requisitos que nao é refletida nos diagramas UML. O que acaba confundindo que vai dar manutencao no sistema. E se for necessario adicionar funcionalidade nova, o diagrama desatualizado confunde o arquiteto da torre de marfim… No fim acabam fazendo UML só para seguir o processo, mas ignoram na hora de codificar.
Enfim, eu nao acho uma boa idea fazer o sistema usando a metodologia “Arquiteto da torre de marfim que manja de UML + 10 code monkeys”. É melhor e mais produtivo ter 2 desenvolvedores com boas noçoes de design, orientacao a objetos e TDD.
Voce pode usar UML, mas acho que projetar num nivel mais alto. Ou entao pra projetar algo, mas nao pensando que aquilo vai ser o passo-a-passo de um outro desenvolvedor.
[quote=deniswsrosa]Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.
Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.[/quote]
Como tudo nesta área, depende.
Essa “ótima análise de requisitos” pode virar um BDUF, e tem projetos que precisam estar prontos no dia X senão eles falham completamente. Imagine um site de Copa do Mundo ficando pronto depois da final.
BTW, independente da análise, programa feito por code monkeys vira macacada. 
Eu diria: Vira gilete na mão de macaco!
flws
[quote=Rubem Azenha][quote=deniswsrosa]
Isso prova que você trabalhou apenas em projetos pequenos.
Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.
Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.
Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.
[/quote]
Bem-vindo ao mundo do CMMi…
Eu discordo totalmente do seu post. Ter um arquiteto da torre de marfim pra escrever UML e 10 code monkeys para cegamente implentar os diagramas UML nao é algo produtivo… ja trabalhei bastante nesse esquema e a produtividade é muito baixa. E geralmente a qualidade tambem nao é das melhores, por que o diagrama nao consegue representar tudo o que o programador precisa pra codificar, algumas decisoes o programador tem que tomar. Se o programador é um code monkey, ele vai tomar decisoes ruins. Se ele nao é um code monkey, ele nao precisa de um diagrama mostrando o que ele tem que codificar passo-a-passo.
E se voce quiser fazer um diagrama que mostra todos os detalhes pra um programador codificar, o diagrama vai ficar tao complexo e tao demorado pra fazer que voce vai precisar de 10 arquitetos da torre de marfim.
E o problema mais grave é que em 99% dos casos esses diagramas acabam ficando desatualizados. Com o passar do tempo, mudanças vao sendo feitas no codigo refletindo uma mudança nos requisitos que nao é refletida nos diagramas UML. O que acaba confundindo que vai dar manutencao no sistema. E se for necessario adicionar funcionalidade nova, o diagrama desatualizado confunde o arquiteto da torre de marfim… No fim acabam fazendo UML só para seguir o processo, mas ignoram na hora de codificar.
Enfim, eu nao acho uma boa idea fazer o sistema usando a metodologia “Arquiteto da torre de marfim que manja de UML + 10 code monkeys”. É melhor e mais produtivo ter 2 desenvolvedores com boas noçoes de design, orientacao a objetos e TDD.
Voce pode usar UML, mas acho que projetar num nivel mais alto. Ou entao pra projetar algo, mas nao pensando que aquilo vai ser o passo-a-passo de um outro desenvolvedor.[/quote]
Calma!
Primeiro, que quando me refiro a code monkeys, não imaginem um indiano numa baia apertada todo suado traduzindo linguagem estruturada para Java. Mas sim programadores que não devem tomar decisões críticas, eu tb jah trabalhei com o método de “N desenvolvedores com boas noções de design”, e particularmente acho muito produtivo também, masss… para projetos pequenos, vc já tentou fazer isso num projeto com mais de 50 pessoas pra ver o resultado??? Nesses casos são poucas as pessoas capazes de realmente tomar uma decisão tendo consciencia do impacto disso no todo. Sem contar que nesses casos, o conhecimento não flui tão bem assim como quando temos 5 … 10 pessoas.
A UML não se limita a “Diagrama de Clases”, existem diagramas muito úteis como o de sequencia por exemplo, e todos eles ajudam a tornar menos provavel que acontecam “mal entendidos” do que foi especificado do que foi desenvolvido, limitando a decisão dos programadores a coisas comuns do dia a dia e não.
Agora, que a maioria dos projetos não são bem analisados, que muitos fazem mal uso do UML, isto é um fato que todos nós sabemos na pele. Mas é questão de Mal uso para a sua necessidade.
Desculpe, mas esse papo de “projeto grande” é coisa de CMMista. Se um projeto tem 50 desenvolvedores, não existe milagre que faça a comunicação fluir bem. Nessa caso o ideal seria quebrar em algumas equipes menores. Enfim, quem tem ja alguns anos de projetos nas costas ja viu essa papo de 1 arquiteto fazendo UML e 10 programadores traduzindo UML em codigo nao funciona. Simples assim. Nao funciona. Pelos motivos que eu disse no post anterior.
Se voce acha que um programador deve apenas traduzir UML para codigo, eu acho que voce esta tao errado que eu nem sei como comecar a me explicar…
Se voce ler sobre metologias ageis, existe muita discussao sobre o que fazer em projetos grandas. Eu acredito que a maioria dos especialistas de verdade vao falar que nao tem como fazer um desenvolvimento de qualidade com 50 desenvolvedores na equipe e que o correto seria quebrar em equipes menores.
Eu sei muito bem que existe outros diagramas… tenho pesadelos da epoca em que eu tinha que ler diagramas de sequencia. Perdia mais tempo lendo e discutindo coisas que nao iam dar certo/poderiam ser melhores se eu implementasse da maneira como havia sido escrito do que efetivamente codificando. Era comum do “projetista” ficar horas com o “programador” para explicar o que ele havia feito no diagrama.
Cara, até concordo com você, mas para um programador implementar um funcionalidade dessa forma ele teria que ser “o cara do caso de uso”, ou seja, ele tem que entender muito bem aqueles requisitos e tem que saber exatamente tudo que deve ser feito, o problema é que na maioria dos casos não é assim que funciona, simplesmente você é contratado no meio do projeto. Sem contar que os projetos são vendidos como “pacotes fechados”, ou seja, tudo o que deve ser feito é definido antes. Se você pensar em situações que você cumpre demanda interna, ok, sua afirmação é valida, agora num contexto de fábrica de software é mais dificil usar essa metodologia.
Voltando ao UML, provavelmente fizeram um grande mau uso dela neste projeto que vc citou, pois tentam “mastigar demais” um diagrama, e acabam complicando mais, diagrama de sequencia mesmo, é otimo pra saber o fluxo das informacoes, não pra ficar rabiscando chamada de métodos.
Eu dúvido que vocês não tenham pelo menos um rascunho de um diagrama de estados no seu projeto.
Enfim… acho que a minha visão de “code monkeys” é um pouco mais abrangente que a de vocês.
[quote=deniswsrosa][quote=sulito]Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea: [/quote]
Isso prova que você trabalhou apenas em projetos pequenos.
Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.
Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.
Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.
[/quote]
Ei calma ai, existi projectos grandes com programadores experientes que fica mais facil dividir as tarefas e começar a programar, para cumprir prazo, do que ficar metade do tempo dado para o projecto discutindo UML.
E analisando bem ter 1 desenhador de UML e uns 10 code monkes nao funciona em projectos grandes, porque normalmente nos UML se mete as interfaces ( como as classes devem estar e como devem se comportar) e não se mete codigo nos UML, e com code monkeys ai fica dificil o software ter um bom desempenho e performance, porque eles podem implementar o código da pior forma possivel e respeitar a interface( requisitos) UML.
Normalmente eu estou abituado a programar sozinho , não importando o tamanho do projecto, e quero mudar este quadro por isso abri este topico para saber se os UML são vantajosos ou se fazem o pessoal perder tempo.
Mas notei que mesmo com os UML os code monkeys podem cometer erros graves na implementação programando da pior forma possivel e respeitando os requisitos UML.
e Alem do mais na hora de codificar pode se notar que a outra forma melhor de implementar o projecto para ganhar performance ou desempenho, e ai tem que se alterar novamente os UML.
Mas resumindo segundo as coisas que os outros gujeiros disseram , eu achei que a melhor forma é dividir a equipe em equipes pequenas e dividir as tarefas de uma forma que na hora da implementação cada equipe de 2 a 4 pessoas podera ter a extrema liberdade de implementar o codigo e a logica da forma que melhor achar. mas quando estiverem no fim começar a fazer os UML para ficar a documentação para os outros membros dos outros grupos poderem entender mais facilmente o que foi feito e como foi feito.
:idea: :idea: :idea: :idea: :idea: :idea: :idea: :idea:
[quote=sulito][quote=deniswsrosa][quote=sulito]Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea: [/quote]
Isso prova que você trabalhou apenas em projetos pequenos.
Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.
Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.
Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.
[/quote]
Ei calma ai, existi projectos grandes com programadores experientes que fica mais facil dividir as tarefas e começar a programar, para cumprir prazo, do que ficar metade do tempo dado para o projecto discutindo UML.
E analisando bem ter 1 desenhador de UML e uns 10 code monkes nao funciona em projectos grandes, porque normalmente nos UML se mete as interfaces ( como as classes devem estar e como devem se comportar) e não se mete codigo nos UML, e com code monkeys ai fica dificil o software ter um bom desempenho e performance, porque eles podem implementar o código da pior forma possivel e respeitar a interface( requisitos) UML.
Normalmente eu estou abituado a programar sozinho , não importando o tamanho do projecto, e quero mudar este quadro por isso abri este topico para saber se os UML são vantajosos ou se fazem o pessoal perder tempo.
Mas notei que mesmo com os UML os code monkeys podem cometer erros graves na implementação programando da pior forma possivel e respeitando os requisitos UML.
e Alem do mais na hora de codificar pode se notar que a outra forma melhor de implementar o projecto para ganhar performance ou desempenho, e ai tem que se alterar novamente os UML.
Mas resumindo segundo as coisas que os outros gujeiros disseram , eu achei que a melhor forma é dividir a equipe em equipes pequenas e dividir as tarefas de uma forma que na hora da implementação cada equipe de 2 a 4 pessoas podera ter a extrema liberdade de implementar o codigo e a logica da forma que melhor achar. mas quando estiverem no fim começar a fazer os UML para ficar a documentação para os outros membros dos outros grupos poderem entender mais facilmente o que foi feito e como foi feito.
:idea: :idea: :idea: :idea: :idea: :idea: :idea: :idea: [/quote]
Novamente, nem se quer citei diagrama de classes, e claro, o desenvolvimento não tem que ( e nao pode) ser waterfall, só digo que todo mundo usa UML no seu dia a dia, seja pra passar conhecimento pro colega, seja pra tirar uma dúvida ou etc, todos os bons programadores que conheco no mínimo rabiscam alguma coisa antes de sair programando, e isso é na verdade um diagrama UML qualquer que simplesmente não segue os padrões de formatação. E quando você não guarda esse seu rabisco em algum lugar, vc mesmo pode esquecer a forma que implementou, ou uma pessoa pode ter um outro entendimento de como a coisa realmente funciona quando o conhecimento é passado de boca em boca.
A UML ajuda na visão do que está sendo feito além de ser de grande ajuda na Gestão do conhecimento.
UML é muito importante tanto para equipes pequenas ou grandes para melhorar a comunicação, até mesmo para quem programa sozinho como eu. Eu costumo utilizar os diagramas de componentes, sequência e o de modelagem de processo de negócio, que é exelente para demostrar o processo de uma determinado requisito ou processo do sistema, dando um visão mais abrangente. Esses digramas que citei na minha opnião são essencias para qualquer projeto seja individual ou em equipe.
[quote=deniswsrosa]Cara, até concordo com você, mas para um programador implementar um funcionalidade dessa forma ele teria que ser “o cara do caso de uso”, ou seja, ele tem que entender muito bem aqueles requisitos e tem que saber exatamente tudo que deve ser feito, o problema é que na maioria dos casos não é assim que funciona, simplesmente você é contratado no meio do projeto. Sem contar que os projetos são vendidos como “pacotes fechados”, ou seja, tudo o que deve ser feito é definido antes. Se você pensar em situações que você cumpre demanda interna, ok, sua afirmação é valida, agora num contexto de fábrica de software é mais dificil usar essa metodologia.
Voltando ao UML, provavelmente fizeram um grande mau uso dela neste projeto que vc citou, pois tentam “mastigar demais” um diagrama, e acabam complicando mais, diagrama de sequencia mesmo, é otimo pra saber o fluxo das informacoes, não pra ficar rabiscando chamada de métodos.
Eu dúvido que vocês não tenham pelo menos um rascunho de um diagrama de estados no seu projeto.
Enfim… acho que a minha visão de “code monkeys” é um pouco mais abrangente que a de vocês.[/quote]
Cara… deu pra ver que voce comprou a ideia do CMMi, PMBok, Cascata, etc… Voce falou algumas palavrinhas magicas, como fabrica de software e gestao de conhecimento, tudo tem que ser definido antes. Sinto muito, mas voce esta indo na contra-mao do resto da industria. Quase todo mundo esta indo na direcao completamente oposta ao mindset que voce esta seguindo. Se voce nao acreditar em mim, e nao acreditar em todo o material que vem sendo publicado sobre desenvolvimento agil nos ultimos, sei la, 5 anos, só o tempo mostrara pra voce como essa abordagem é falha.
Nao tem jeito, o desenvolvedor tem que aprender do negocio, a equipe de negocios tem que interagir com a equipe de desenvolvimento, as equipes grandes tem quer quebradas em times menores e os desenvolvedores tem que ter boas nocoes de design, orientacao a objetos e TDD. Sem isso, voce pode fazer a documentacao que voce quiser, usar o diagrama que voce quiser, o trabalho nao sera eficiente.
[quote=sulito]Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea: [/quote]
uml é só uma ferramenta pra analisar a situação e não é porque parou um pouco para se esclarecer antes de codificar que é waterfall.
apesar de várias ocasiões conseguirmos fazer a modelagem da situação mentalmente, as vezes é mais difícil fazer isso, principalmente em grupo quando todos devem entender o problema.