UML e desenvolvimento

Kaizenman, essa é a melhor prática que existe.
Varias empresas acabam por passar as definições de seus projetos a seu programadores na base do papel A4 ou de outras maneiras. Mas o que realmente acontece é que os programadores acabam se confundindo por não entenderem realmente onde o analista quer chegar, ou ate entende mas as vezes como não há um bom entendimento do que é preciso ser feito, o projeto acaba tomando um outro rumo!

É aquela velha historinha…O cliente pede um carro, o gerente imagina um avião, o analista ver uma biscicleta e o programador desenvolve uma roda. :?

Por isso a prática melhor é o uso da UML.
Assim todos procuram ver uma única coisa entende?
( Ou em alguns casos evita a enrrolação de certos companheiros programadores! :lol: )

(Isso evita um pouco também o uso de POG(Programação Orientada a Gambiarra));
Se existe desvantagens eu desconheço.Mas o que posso realmente te passar é que as vantagens são bem maiores que as desvantagens!

Acredito que a representação UML é de fundamental importancia, mas antes de implementar creio que deve-se ter a lista de requisitos bem explicada e entendida pelo programador.

Acredito que O UML não é suficiente para o desenvolvimento. Então essa seria a desvantagem.

"

Concordo, so a UML não ajuda, tem que estar bem explicado as regras do negócio e a metodologia a ser usada na aplicação… Como programador, vejo que isso dificulta certos projetos, na hora de serem realizados…

kaizenman:

Olá pessoal. Seguinte, em algumas empresas, o UML é amplamente utilizado. Às vezes, o programador recebe o UML já pronto,
completo, e só deve preencher a implementação, devendo seguir À RISCA o UML. Essa é uma prática boa? Ou tem várias desvantagens?

A melhor abordagem, na minha opinião, é deixar o programador em contato com o cliente direto, sem aquele hierarquia engraçada e gigante de Engenheiro de Requisitos, Engenheiro de Software (que, na verdade, é um modelador que sabe usar UML, um pouco de OO e não sabe (ou tem medo de) escrever código) e por aí vai.

Editado: o resultado dessa hierarquia é aquela figurinha que todos conhecem. O cliente pede uma balança e passa por tanta gente aquela modelagem e aquelas regras de negócio que ela sofre tantas modificações que o programador, que é o coitado e o culpado da história, só fez o que foi pedido - enquanto que se ele tivesse conversado com o cliente, ele entenderia BEM melhor.

Editado2: http://blog.fragmental.com.br/2008/07/25/uh-eme-ele/

É só minha opinião né

O problema é que a UML é apenas (não que ela não seja importante e não tenha valores) uma ferramenta de apoio e algumas pessoas utilizam ela como ferramenta principal achando que ela vai resolver o projeto; simples assim. Ao utilizar orientação a objetos a abstração aumentou muito; fazendo com que a complexidade do entendimento, elaboração, comunicação se elevasse bastante também e foi aí que surgiu a idéia da UML para nos ajudar.
Quando vc utiliza a UML para expor alguma idéia perceba que os dialogos ficam mais objetivos e enriquecidos; verifica-se muito mais coisas do se vc não estivesse visualizando graficamente o problema em questão.

Quando um problema estiver confuso, causando muitas divergencias com dificuldade de chegar em uma idéia interessante; utiilze a uml e vc vai ver o resultado, faça este teste. Aqui no guj existem alguns casos assim, a pessoa expôs o problema e logo depois colocou o diagrama; vc vai perceber que a thread ficou mais curta e a DISCUSSÂO (essa é a idéia) mais produtiva.

Ela é só mais uma bala (não é de prata não) no arsenal do desenvolvedor.

flws

"

Eu adoro UML, sempre que possível eu uso, é ótimo pra tu ter algumas informações representadas, de modo que com um simples olhar tu já consegue saber praticamente tudo sobre o sistema. Desde visão abstrata das coisas até detalhes técnicos que auxiliam no desenvolvimento.

Agora, obrigar a ter UML em todos os processos, pra mim não é muito legal. É bom usar em situações específicas, senão acaba só atrasando o desenvolvimento IMHO.

pô galera valeu aí pelas respostas… deu uma clareada melhor

Lendo este tópico sinto que eu vivo em outro planeta. Ha uns 5 anos nao sei mais o que eh UML e tenho que confessar que nao sinto falta nenhuma!

Realmente…

Algumas empresas os desenvolvedores são “Digitadores de Luxo”.

igor_jua:

Mas o que realmente acontece é que os programadores acabam se confundindo por não entenderem realmente onde o analista quer chegar, ou ate entende mas as vezes como não há um bom entendimento do que é preciso ser feito, o projeto acaba tomando um outro rumo!

Mito -> o que realmente acontece é que os programadores acabam se confundindo…

Verdade -> o que realmente acontece é que o analista não sabe usar/escrever UML, quanto mais entender sobre a tecnologia que resolve um problema de negócio. É muito bonito software rodando no papel. Vai chegar o dia em que haverá um compilador para .docs. Enquanto isso as crianças precisam de leite e a área continua infestada com profissionais que só sabem fazer bonequinhos e bolinhazinhas.

Solucao: manda o analista embora, contrata um programador capaz de conversar com o cliente e escrever especificacoes executaveis. O resultado eh um produto melhor, entregue mais cedo, gastando menos e (adivinha?) sem precisar de UML.

acho que isso depende de projeto a projeto, muitas vezes o cliente quer entender sobre o projeto, bem como acompanhar por especificações e/ou código-fontes, configurações e documentação, e isto varia de projeto a projeto.

mas, por exemplo, mesmo uma equipe que adota algumas práticas do scrum, onde um time com 10 pessoas ou pouco mais, mesmo que não seja equipe multidisciplinar, é necessário centralizar esta conversa com cliente entre 1 ou mais membros.

quanto ao analista sair ou ter que programar concordo, mas contato direto com cliente e ficar como regra não usar UML varia. eu por exemplo utilizo bastante um diagrama de classes básico sobre um conjunto de novas features ou mudanças destas dentro de um backlog, e o resultado é a não perca de tempo com interpretações falsas para requisitos descritos pelo cara que contactou o cliente e compilou tudo, e sem contar que ajuda na comunicação!

É o que sempre digo:

Existem 2 grupos, os que querem o software e os que desenvolvem o software; o restante existe para atrapalhar o bom entendimento entre estas 2 partes.

flws

Mas o cliente consegue ver até em que passo está o desenvolvimento só de olhar pro quadro onde estão as estórias. Além disso, se for ele mesmo que escrever essas estórias, não vai ter problema em saber o que já foi feito e que falta fazer.

É verdade. Mas a razão disso é porque são 10 pessoas! Pega um cliente tímido e joga 10 pessoas em cima dele! Ele vai ficar aterrorizado (isso é exagero hehe). As vezes, umas 4, 5 já dão conta do trabalho e tem um contato melhor com o cliente.

Eu to com você nessa. As vezes usar UML pra comunicação é interessante, mas IMHO é muito mais interessante fazer uns rabiscos em vez de uns quadrados ligados nos outros.

Abraço.

"

Entre um monte de diagramas UML e uma historia bem escrita em portugues (ou outro idioma) que sera interpretado, por exemplo, pelo Cucumber/RSpec e pode disparar testes de aceitação - inclusive selenium - eu fico com o segundo.

Eu posso usar UML se eu quero modelar as minhas classes e processos de uma forma melhor e isso não ter nada haver com clientes - e posso escolher não usar. Agora existe um componente onde eu TENHO que usar devido as circunstâncias (o cliente quer ver, quer acompanhar, quer dar pitaco, quer exigir herança multipla em C++ no lugar de um deamon escrito em Perl). Acho que nessas situações as metodologias Ageis trouxeram novos desafios.

Acho que a critica maior ao UML é na verdade uma critica à muleta de querer “controlar” processos complexos com metodos exatos, em detrimentos à metodos empiricos. Acho, IMHO, que a UML fala um pouco sobre a sensação de segurança de um cliente ou gerente sobre um processo complicado e com “tudo para dar errado”. Acho que não é a Big Picture pois deixamos de lado outras coisas nessa simplificação (como MDA) mas vai por ai.

"

Mas o cliente consegue ver até em que passo está o desenvolvimento só de olhar pro quadro onde estão as estórias. Além disso, se for ele mesmo que escrever essas estórias, não vai ter problema em saber o que já foi feito e que falta fazer.
ok, neste ponto de vista ele também consegue, ainda mais se ele participar das histórias.

no exemplo que citei, pensei em cliente também, como um conjunto de pessoas com responsabilidades e outros aspectos diferentes, dentro de um contexto, onde você debate sobre um determinado tema, então sempre após uma reunião, é interessante colocar em uma wiki, por exemplo uma abordagem daquilo que foi apresentado, e as vezes alguma representação ajuda bastante.

se bem que, isto varia porque, algumas pessoas tem mais facilidade para decorar fatos, outras imagens e/ou relacionamento e fluxos de processo.

defendo esta forma, por achar estórias(user stories) um pouco selvagem(se alguém duvidar de mim, me explique que eu preciso entender melhor as limitações de user stories, estou curiosíssimo, mas sem tempo ? quais referências ?), mas ao mesmo tempo bastante objetivo, dependendo do caso.

Eu to com você nessa. As vezes usar UML pra comunicação é interessante, mas IMHO é muito mais interessante fazer uns rabiscos em vez de uns quadrados ligados nos outros.
é verdade. por isto mencionei não seguir regra, pois você sente necessidade, se bem que a necessidade, pode vir do vício que o cara tem de explicar as coisas, e nestas horas as críticas e feedback ajudam.

hj mesmo eu fiz uns rabiscos em papel e digitalizei em scanner, posteriormente coloquei em fórum, uma sugestão para adoção de mudança de política do uso de branchs. poderia ter utilizado o visio, ou outra ferramenta que possibilite criar, mesmo assim fiz meio que artisticamente, mas que vem dando certo.

kaizenman:

Olá pessoal. Seguinte, em algumas empresas, o UML é amplamente utilizado. Às vezes, o programador recebe o UML já pronto,
completo, e só deve preencher a implementação, devendo seguir À RISCA o UML. Essa é uma prática boa? Ou tem várias desvantagens?

Acho que é boa sim. Pois provavelmente quem fez foi o arquiteto (teoricamente o cara deve manjar* bem).

*Na minha opinião um arquiteto deve ser bom em Java(OOP, EJB, e etc) e na “regra de negócio”. O que adianta uma certificação de arquiteto se ele não vai ter a visão da regra de negócio de que “Pessoa” pode ser “Jurídica” e “Física”. Na prática, vejo coisas totalmente esdrúluxas em termo de arquitetura, pois o cara sabe bem Java, mas não conhece “regra de negócio”.

kaizenman:

Olá pessoal. Seguinte, em algumas empresas, o UML é amplamente utilizado. Às vezes, o programador recebe o UML já pronto,
completo, e só deve preencher a implementação, devendo seguir À RISCA o UML. Essa é uma prática boa? Ou tem várias desvantagens?

Esse modelo é ineficiente. Mas vantagem ou desvantagens depende de cada caso, por exemplo se nao souber fazer melhor qual outro jeito senao desenvolver software como ha 20 anos?

Particularmente, quando uso, uso UML pra comunicacao informal entre os papeis de perfil tecnico, nunca entre os usuarios. Uma equipe que usa UML pra especificar requisitos tem muito que melhorar no seu processo.

Felipe Kan:

kaizenman:

Olá pessoal. Seguinte, em algumas empresas, o UML é amplamente utilizado. Às vezes, o programador recebe o UML já pronto,
completo, e só deve preencher a implementação, devendo seguir À RISCA o UML. Essa é uma prática boa? Ou tem várias desvantagens?

Acho que é boa sim. Pois provavelmente quem fez foi o arquiteto (teoricamente o cara deve manjar* bem).

*Na minha opinião um arquiteto deve ser bom em Java(OOP, EJB, e etc) e na “regra de negócio”. O que adianta uma certificação de arquiteto se ele não vai ter a visão da regra de negócio de que “Pessoa” pode ser “Jurídica” e “Física”. Na prática, vejo coisas totalmente esdrúluxas em termo de arquitetura, pois o cara sabe bem Java, mas não conhece “regra de negócio”.

Nada é mais esdruxulo pra mim do que arquitetos que nao produzem sistemas, apenas documentacao.

É porque esses arquitetos devem ter medo de código :p. Os programadores tem mais cojones do que esses “arquitetos”.

Uma das melhores ferramentas que eu conheço (e que muita gente usa) é o Fitnesse. Dá pra fazer umas coisas bem legais, como um wiki com os testes de aceitação. Aliás, esqueci de falar, mas uma suíte de testes bem feito já pode ser o suficiente como documento de requisitos.

Pra mim, sistema sem UML é o site do seu Nenê, dono da mercearia do bairro.

Como organizar uma equipe em um grande sistema sem o diagrama de classe? Eu não vejo muitos horizontes… Quem quiser me ensinar como, eu estou aberto a aprender mais. Tudo o que sei é que eu nada sei…

Olá,
Trabalho com recrutamento e seleção e estou precisando de profissionais com a certificação UML. Interessados, encaminhar currículo com urgência para: [email removido]
Att,
Fernanda