Arquivo Discussoes de Programacao e Tecnologia li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.
alguém quer falar sobre isso?
não da pra ler aqui, mais sei que este eu li hoje cedo.
Cara, pra mim o tdd vem pra complementar UML e vice-versa, se você poder usar os dois é bem melhor. UML dá uma melhor visão de seu sistema, baseando-o em modelos, assim cada participante tem uma visão do sistema de acordo com sua especialização. Trabalhei com TDD e realmente é bem versátil vc desenvolver um sistema já prevendo os bugs. O produto final fica muito mais estável e fica mais dificil de ocorrerem bugs. Mas nada impede de se usar UML. A pessoa que escreveu esse artigo tem uma visão bem limitada, restringindo UML a apenas diagramas de Classe, pois esta vai muito além, sendo uma linguagem unifica que baseia todo seu sistema em Modelos. Em Uml, temos diagramas de classes, caso de uso, configuração, deploy e por ai vai, deixando seu sistema muito bem documentado e de fácil entendimento por todos envolvidos no sistema. Então, dizer que se deve trocar uma pela outra é uma afirmação extremista demais e até imbecil, já que as duas tem propostas diferentes!
Entenda ‘UML’ no caso como sinonimo de pensar em toda estrutura do software, com base em forte documentação em detrimento de um modelo mais empirico.
Claro que todo mundo sabe que UML é somente uma linguagem de modelagem e que não tem nenhuma relação com a forma de desenvolver, mas é comum as empresas usarem os documentos em UML como artefato de entrada e saida para alimentar um processo em cascata, onde as tarefas de levantamento, analise, projeto, codificação e testes podem ser facilmente percebido.
O TDD traz uma visão um pouco diferente, um foco maior nos testes e não no processo.
A diferença é basicamente essa: Um está como sinonimo de foco em processo e o outro está como sinonimo de foco nos resultados (dos testes).
AHh…
outra coisa que esqueci de dizer é que realmente existe uma certa relação entre os dois, pois em uma a documentação está nos testes ( apesar de isso estar mais pra BDD) e no outro a documentação é um artefato próprio (Que raramente alguém se da o trabalho de olhar, pois quando existe ou está desatualizado ou incompleto).
Ainda sim não tem nada haver trocar um pelo outro, sendo que os dois podem coexistir, sem contar que desnvolver software sem um processo bem consolidado é praticamente impossivel, pois gera varias falhas no futuro, tendo todo um retrabalho para corrigir as memas.
li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.alguém quer falar sobre isso?
Eu já fiquei chocado quando você disse que UML é uma metodologia.
li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.alguém quer falar sobre isso?
Meus professores sempre diziam: se for buscar informação, busque de uma fonte confiável.
li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.alguém quer falar sobre isso?
Meus professores sempre diziam: se for buscar informação, busque de uma fonte confiável.
Concordo.
E para ajudar a entender o que é de fato fonte confiavel eu digo o que, pra mim, nao eh: Blog.
Livros sao fontes confiaveis, procure neles o que voce precisa. Blog é otimo pra voce ler uma outra visao, ou nao, de um assunto que voce ja conhece. Como aprendizado eles tem muito pouco a oferecer, normalmente.
Sobre o post, eu entendi a opiniao do autor e concordo em alguns pontos, mas eh bem superficial, o que acaba confundindo mesmo. A comparacao pode parecer estranha a principio, mas acho que a intencao era de mostrar que com TDD vc nao precisa de UML, pelo menos nao da UML documentacao (UML eh bastante eficiente para comunicacao). Na verdade eh uma forma diferente, e um pouco estranha, de fazer a velha comparacao Agil x Cascata.
Fico feliz que quase 4 anos depois esse meu post ainda chama atencao de alguns. Por outro lado, fico surpreso que ainda tem gente ficando chocado com o que esta escrito ali.
Elizeu, voce pode explicar um pouco melhor o que quis dizer com “metodologias com propositos distintos que devem andar lado a lado”?
li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.alguém quer falar sobre isso?
Meus professores sempre diziam: se for buscar informação, busque de uma fonte confiável.
Concordo.
E para ajudar a entender o que é de fato fonte confiavel eu digo o que, pra mim, nao eh: Blog.
Livros sao fontes confiaveis, procure neles o que voce precisa. Blog é otimo pra voce ler uma outra visao, ou nao, de um assunto que voce ja conhece. Como aprendizado eles tem muito pouco a oferecer, normalmente.
Sobre o post, eu entendi a opiniao do autor e concordo em alguns pontos, mas eh bem superficial, o que acaba confundindo mesmo. A comparacao pode parecer estranha a principio, mas acho que a intencao era de mostrar que com TDD vc nao precisa de UML, pelo menos nao da UML documentacao (UML eh bastante eficiente para comunicacao). Na verdade eh uma forma diferente, e um pouco estranha, de fazer a velha comparacao Agil x Cascata.
Estranho não, é muito comum e até é compreensivel.
Como disse antes, é a questão do foco. Quando se da enfase no UML normalmente a empresa está dando enfase no processo e na documentação como suporte a esse processo. ( Isso não é regra, mas é uma generalização ‘aceitavel’)
O TDD inverte as coisas e coloca o foco no resultado(dos testes). A documentação do teu sistema e de tuas regras são os próprios casos de teste ( mais ainda digo que isso está mais pra BDD ).
Raramente uma empresa vai adotar formalmente a UML tendo como foco a comunicação ( apesar da utilização dos artefatos para comunicação ser inerente aos processos ). E indo um pouco além, a UML pode no máximo complementar a comunicação. Ela SOZINHA não é adequada o suficiente nem mesmo para comunicação.
desculpem as falhas nas minhas “metodologias” rsrs.
Fico feliz que quase 4 anos depois esse meu post ainda chama atencao de alguns. Por outro lado, fico surpreso que ainda tem gente ficando chocado com o que esta escrito ali.Elizeu, voce pode explicar um pouco melhor o que quis dizer com “metodologias com propositos distintos que devem andar lado a lado”?
OOP + OOA
UML + TDD
vejo a UML como uma linguagem para documentação, e a TDD como uma tecnologia de testes. não sei se os termos estão corretos, sou iniciante. mais uma sendo documentação e outra de testes deveriam andar juntas e não se substituírem.
pois é. é exatamente minha visão.
Sim, porque UML para comunicacao nao precisa ser formalizada. Quando eu digo muito eficiente para comunicacao, eu digo como auxilio numa explicacao ou numa ideia. Isso nao vai precisar ser arquivado, versionado, etc… Ou viraria documentacao.
Falo de comunicacao como um rascunho no papel, nesse ponto UML é eficiente.
rsrsrs então pera ai.
eu te dou um projeto pra fazer, você simplesmente abre o eclipse, da um “add jars” no junit e começa a programar?
e quando outro programador for fazer manutenção no seu sistema? ah ta, ele vai abrir mil classes uma a uma lendo os “//” e “/** */” e vai entender tudo néh?
sempre que ele tiver duvida de algo ele vai ter que procurar dentro do código. rsrs
isso sim é ser programador!
rsrsrs então pera ai.
eu te dou um projeto pra fazer, você simplesmente abre o eclipse, da um “add jars” no junit e começa a programar?e quando outro programador for fazer manutenção no seu sistema? ah ta, ele vai abrir mil classes uma a uma lendo os “//” e “/** */” e vai entender tudo néh?
sempre que ele tiver duvida de algo ele vai ter que procurar dentro do código. rsrs
isso sim é ser programador!
OK,
então, pra começar, para um programador é melhor que a regra esteja documentada onde?
E onde é mais prático fazer manutenção dessa documentação?
rsrsrs então pera ai.
eu te dou um projeto pra fazer, você simplesmente abre o eclipse, da um “add jars” no junit e começa a programar?e quando outro programador for fazer manutenção no seu sistema? ah ta, ele vai abrir mil classes uma a uma lendo os “//” e “/** */” e vai entender tudo néh?
sempre que ele tiver duvida de algo ele vai ter que procurar dentro do código. rsrs
isso sim é ser programador!
Isso ja aconteceu comigo. Entrei num projeto ja em andamento e nao havia nenhuma documentacao que nao fosse executavel. Por outro lado haviam centenas de testes de aceitacao (FitNesse) e milhares de testes de unidade. Nao tive que ler uma linha sequer de comentarios (o codigo era extremamente limpo), e consegui aprender tudo o que precisava para trabalhar naquele codigo sem maiores problemas. Sempre que tinha uma duvida eu podia recorrer aos testes, e ate mesmo modifica-los para explorar cenarios do tipo “e se?”. Pode ser soh minha preferencia, mas nao troco essa abordagem por nenhum outro tipo de documentacao que eu conheco.
foi mal mano, então tenho de admitir VOCÊ É O CARA!
deve ser engenheiro do Google ou quem sabe da IBM no mínimo. o mais provável é que você~e seja engenheiro da Nasa e que faça metade do serviço sozinho!
classe tal herda de tal… implementa tal… ai você vai nos testes e descobre tudo que a outra tem… ou você vai abrindo todas as classes pra ver… quando você poderia simplesmente olhar em um pedaço de papel ¬¬. e por fim, se desse algo errado, você faria testes para entender melhor como funciona.
veja que você já menosprezou até os comentários de código.
não vou me exaltar ou levar sua opinião em consideração, já entendi seu artigo ¬¬.
Uma boa documentação ajuda e muito não somente no desenvolvimento do sistema/aplicação, mas também na manutenção. 
foi mal mano, então tenho de admitir VOCÊ É O CARA!deve ser engenheiro do Google ou quem sabe da IBM no mínimo. o mais provável é que você~e seja engenheiro da Nasa e que faça metade do serviço sozinho!
classe tal herda de tal… implementa tal… ai você vai nos testes e descobre tudo que a outra tem… ou você vai abrindo todas as classes pra ver… quando você poderia simplesmente olhar em um pedaço de papel ¬¬. e por fim, se desse algo errado, você faria testes para entender melhor como funciona.
veja que você já menosprezou até os comentários de código.
não vou me exaltar ou levar sua opinião em consideração, já entendi seu artigo ¬¬.
É justamente por não ser um “engenheiro da google ou da IBM ou qualquer outro que faça metade do serviço sozinho” é que ele prefere um código bem escrito, limpo e com muitos testes. E quanto mais bem escrito o código estiver, menos comentários vão ser necessários, concorda?
Os testes são ( ou podem ser) uma documentação muito mais eficiente do que um diagrama UML. E o melhor é que ele sempre vai ter que estar atualizado, ao contrário do que sempre acontece na prática com os casos de uso, por exemplo. E além disso os testes são capaz de fazer muito mais, mostrando se alguma intervenção no código afetou alguma funcionalidade.
Sobre a UML, o esforço pra manter os documentos atualizado é bem elevado. A empresa precisa estar bem avançada na implantação de seus processos para que os documentos reflitam de fato a situação do sistema no momento. Por isso existe uma aproximação forte entre a UML e o ‘modelo em cascata’. Na verdade o tal ‘modelo em cascata’ é em espiral. Mas nesse modelo a mudança é desencorajada e evitada. Não que não possa acontecer ( existem processos para gestão da mudança), mas é algo que se tenta minimizar.
Para desenv. software é quase sempre melhor adotar uma abordagem mais flexivel e que aceite melhor a mudança, que não veja a mudança como algo que deva ser evitado. Os testes permitem essa flexibilidade e a manutenção é mais simples.
Uma pena que voce prefere baixar o nivel nessa discussao que poderia ser util para outros. Seja feliz com seus diagramas 
Estou impressionado como mesmo hoje, depois de algum tempo da popularização do agil, TDD, BDD e etc, as idéias de processos rigidos ( foco no processo) no lugar do resultado (Algo que eu mesmo questiono até hoje), ou de um esforço em uma extensa documentação no lugar do esforço na tentativa de criar um código limpo e simplificado ainda seja predominante em um forum como esse.
Acho que alguns professores de faculdade estão precisando voltar pro mercado e deixar de espalhar idéias do século passado.
Estaria errado utilizar UML para representar as classes, interfaces e objetos do sistema em conjunto com testes unitários / integração?
foi mal mano, então tenho de admitir VOCÊ É O CARA!deve ser engenheiro do Google ou quem sabe da IBM no mínimo. o mais provável é que você~e seja engenheiro da Nasa e que faça metade do serviço sozinho!
classe tal herda de tal… implementa tal… ai você vai nos testes e descobre tudo que a outra tem… ou você vai abrindo todas as classes pra ver… quando você poderia simplesmente olhar em um pedaço de papel ¬¬. e por fim, se desse algo errado, você faria testes para entender melhor como funciona.
veja que você já menosprezou até os comentários de código.
não vou me exaltar ou levar sua opinião em consideração, já entendi seu artigo ¬¬.É justamente por não ser um “engenheiro da google ou da IBM ou qualquer outro que faça metade do serviço sozinho” é que ele prefere um código bem escrito, limpo e com muitos testes. E quanto mais bem escrito o código estiver, menos comentários vão ser necessários, concorda?
Os testes são ( ou podem ser) uma documentação muito mais eficiente do que um diagrama UML. E o melhor é que ele sempre vai ter que estar atualizado, ao contrário do que sempre acontece na prática com os casos de uso, por exemplo. E além disso os testes são capaz de fazer muito mais, mostrando se alguma intervenção no código afetou alguma funcionalidade.
Sobre a UML, o esforço pra manter os documentos atualizado é bem elevado. A empresa precisa estar bem avançada na implantação de seus processos para que os documentos reflitam de fato a situação do sistema no momento. Por isso existe uma aproximação forte entre a UML e o ‘modelo em cascata’. Na verdade o tal ‘modelo em cascata’ é em espiral. Mas nesse modelo a mudança é desencorajada e evitada. Não que não possa acontecer ( existem processos para gestão da mudança), mas é algo que se tenta minimizar.
Para desenv. software é quase sempre melhor adotar uma abordagem mais flexivel e que aceite melhor a mudança, que não veja a mudança como algo que deva ser evitado. Os testes permitem essa flexibilidade e a manutenção é mais simples.
Assino embaixo.
x___Daniel_MV________________
escrevi 72 linhas de resposta, porém prefiro RIR e manter longe do tópico meus comentários.
eu crio uma classe main
ai crio uma outra classe
crio mais 3 classes
ai vejo que uma é mais genérica que a outra e se tratam de algo parecido
ai eu misturo e crio uma super-classe
ai eu começo a estender.
ai vejo que preciso de uma outra classe e a crio
ai o ciclo recomeça do segundo pra baixo.
código limpíssimo!
tenho que rir. sem comentários.
a idéia de TDD sem documentação e organização previa de projeto me parece mais XGOHourse.
http://www.gojava.org/node/135
pode ser interessante ler os comentários.
Bom…
testes são uma forma de documentação
se realmente consegue manter um controle sobre os métodos e criar religiosamente os casos
não vejo porque não
até vejo como muito melhor que UML
minha opinião
Não, não é errado. Mas se o código dos testes e da implementação forem bem escritos não é necessário.
Hoje em dia nada mais é necessário.
se existem 5 programadores dentro de uma empresa… vão existir apenas 5 classes. cada um faz uma classe. hoje em dia é assim.
se um projeto é grande e você tem que distribuir o projeto… você não usa UML pra definir as classes que existiram no projeto e assim dividir quem desenvolve quais classes… você faz isso, cada um faz uma classe que realiza um zilhão de tarefas. extend e implements… só com classes do java! ninguém mais estende classe que outro programador desenvolveu. até por que… você não projetou isso! você não sabe o que vai haver dentro da classe que seu amigo de trabalho esta desenvolvendo.
isso me lembra muito do bom e velho estruturado…
Hoje em dia nada mais é necessário.
se existem 5 programadores dentro de uma empresa… vão existir apenas 5 classes. cada um faz uma classe. hoje em dia é assim.
se um projeto é grande e você tem que distribuir o projeto… você não usa UML pra definir as classes que existiram no projeto e assim dividir quem desenvolve quais classes… você faz isso, cada um faz uma classe que realiza um zilhão de tarefas. extend e implements… só com classes do java! ninguém mais estende classe que outro programador desenvolveu. até por que… você não projetou isso! você não sabe o que vai haver dentro da classe que seu amigo de trabalho esta desenvolvendo.isso me lembra muito do bom e velho estruturado…
Nao é por nada não mas mais da metade dos programas em Java não utilizam a OO como deveriam e uma outra boa parte ficariam melhor se fossem feito sem O.O.
UML não é sinonimo de planejamento, organização ou documentação. Na verdade só seria sinonimo se esses conceitos fossem extremamente limitados em nossas cabeças. E se for esse o caso, tanto faz o tipo de estratégia que vai usar pq não vai dar certo mesmo.
Dizer que não vai usar UML para planejar o que vai fazer não que dizer que não vamos planejar nada. Só quer dizer que essa não é a única forma de se organizar, planejar ou documentar… não estamos limitado à UML ( e à forma de gerenciamento que vem agregada à ela). E mais ainda… não estamos limitado a O.O. ou à lingagem java e a forma (pessima na maioria das vezes) que ela propões de programação.
Hoje em dia nada mais é necessário.
se existem 5 programadores dentro de uma empresa… vão existir apenas 5 classes. cada um faz uma classe. hoje em dia é assim.
se um projeto é grande e você tem que distribuir o projeto… você não usa UML pra definir as classes que existiram no projeto e assim dividir quem desenvolve quais classes… você faz isso, cada um faz uma classe que realiza um zilhão de tarefas. extend e implements… só com classes do java! ninguém mais estende classe que outro programador desenvolveu. até por que… você não projetou isso! você não sabe o que vai haver dentro da classe que seu amigo de trabalho esta desenvolvendo.isso me lembra muito do bom e velho estruturado…
Nao é por nada não mas mais da metade dos programas em Java não utilizam a OO como deveriam e uma outra boa parte ficariam melhor se fossem feito sem O.O.
UML não é sinonimo de planejamento, organização ou documentação. Na verdade só seria sinonimo se esses conceitos fossem extremamente limitados em nossas cabeças. E se for esse o caso, tanto faz o tipo de estratégia que vai usar pq não vai dar certo mesmo.
Dizer que não vai usar UML para planejar o que vai fazer não que dizer que não vamos planejar nada. Só quer dizer que essa não é a única forma de se organizar, planejar ou documentar… não estamos limitado à UML ( e à forma de gerenciamento que vem agregada à ela). E mais ainda… não estamos limitado a O.O. ou à lingagem java e a forma (pessima na maioria das vezes) que ela propões de programação.
para você, o que é planejamento?
Organizar um product backlog é um exemplo de planejamento. Uma reunião de meia-hora com rascunhos também, existem 1001 maneiras de se fazer planejamento. Se a equipe entender que UML pode ajudar, ótimo, vá em frente e utilize UML, caso contrário, não há nenhum livro da verdade soberana sobre engenharia de software que o prescreva a utilização de UML.
Como um colega falou há pouco, UML pode ser uma boa ferramenta de comunicação, e se a equipe julgar adequada deve ser usada. O que está sendo questionado é o fato de manter um repositório de documentos UML como artefatos do sistema. É isso que é questionável, pois gera-se um custo adicional de manutenção que agrega pouco. Fatalmente a documentação fica obsoleta. Nesse sentido, testes automatizados e código limpo são muito mais eficientes. Se durante uma implementação o contrato de uma classe ou interface é quebrado, isso é detectado automaticamente na execução dos testes da classe. Se esse comportamento estiver descrito em um diagrama UML por exemplo, não há como confrontar especificação - implementação de maneira automática, somente com inspeção visual, o que é passível de falhas.
O outro ponto é a clareza de código. Não há absolutamente necessidade alguma de UML para escrever código limpo ou para obter clareza. Se uma determinada classe depende de outras 20 para fazer seu trabalho, eu posso concluir tranquilamente que ela não está coesa e está acoplada, e um diagrama UML não resolveria muito a vida de que fosse dar manutenção nesse código. Resumindo: se o código está limpo você não precisa de UML para entendê-lo, e se o código estiver sujo o UML não vai resolver muita coisa.
Hoje em dia nada mais é necessário.
se existem 5 programadores dentro de uma empresa… vão existir apenas 5 classes. cada um faz uma classe. hoje em dia é assim.
se um projeto é grande e você tem que distribuir o projeto… você não usa UML pra definir as classes que existiram no projeto e assim dividir quem desenvolve quais classes… você faz isso, cada um faz uma classe que realiza um zilhão de tarefas. extend e implements… só com classes do java! ninguém mais estende classe que outro programador desenvolveu. até por que… você não projetou isso! você não sabe o que vai haver dentro da classe que seu amigo de trabalho esta desenvolvendo.isso me lembra muito do bom e velho estruturado…
Um dos problemas em ter a documentacao em UML é que é muito dificil de ser mantida atualizada e demanda um esforco quase sobrenatural daqueles que tentam fazer isso, cedo ou tarde a documentacao vai estar desatualizada.
Num cenario hipotetico improvavel em que a documentacao esteja atualizada, ela pode ajudar os coitados (porem jamais esquecidos em qualquer assunto que trate de documentacao) programadores recem chegados ao projeto. Mas mesmo assim ele terá que ir ao codigo, ver como esta lá, entender o que está lá.
Ora, muito melhor se a documentacao estiver la.
O problema é que a grande maioria dos que argumentam a favor da UML desconhece, na prática, qualquer alternativa a ela. E logo tem a ideia de que se nao tem UML é bagunçado, que ser agil é bagunçado, que TDD é bagunça.
Nao é, TDD é uma tecnica muito dificil de ser aplicada, que requer muito planejamento, muito mais do que os diagramas UML e experiencia dos programadores. Por isso é tao dificil de ser compreendida por quem nunca trabalhou com ela na pratica, que é o caso da grande maioria de seus criticos.
A minha pergunta é:
o que eh mais completo e mais facil de entender? Um diagrama de uma classe com um metodo chamado calcularValorTotal() e alguns relacionamentos?
ou:
public void valorTotalDeveSerASomaDoValorDosItensMenosValorDoDesconto(){
Pedido p = new Pedido();
p.adicionarItem(new Item("Tomate", 50.0));
p.adicionarItem(new Item("Feijao", 30.0));
p.aplicarPorcentagemDeDesconto(10);
Assert.assertEquals(72.0, p.calcularValorTotal());
}
Organizar um product backlog é um exemplo de planejamento. Uma reunião de meia-hora com rascunhos também, existem 1001 maneiras de se fazer planejamento. Se a equipe entender que UML pode ajudar, ótimo, vá em frente e utilize UML, caso contrário, não há nenhum livro da verdade soberana sobre engenharia de software que o prescreva a utilização de UML.Como um colega falou há pouco, UML pode ser uma boa ferramenta de comunicação, e se a equipe julgar adequada deve ser usada. O que está sendo questionado é o fato de manter um repositório de documentos UML como artefatos do sistema. É isso que é questionável, pois gera-se um custo adicional de manutenção que agrega pouco. Fatalmente a documentação fica obsoleta. Nesse sentido, testes automatizados e código limpo são muito mais eficientes. Se durante uma implementação o contrato de uma classe ou interface é quebrado, isso é detectado automaticamente na execução dos testes da classe. Se esse comportamento estiver descrito em um diagrama UML por exemplo, não há como confrontar especificação - implementação de maneira automática, somente com inspeção visual, o que é passível de falhas.
O outro ponto é a clareza de código. Não há absolutamente necessidade alguma de UML para escrever código limpo ou para obter clareza. Se uma determinada classe depende de outras 20 para fazer seu trabalho, eu posso concluir tranquilamente que ela não está coesa e está acoplada, e um diagrama UML não resolveria muito a vida de que fosse dar manutenção nesse código. Resumindo: se o código está limpo você não precisa de UML para entendê-lo, e se o código estiver sujo o UML não vai resolver muita coisa.
Fecha a conta e passa a régua.
Outra coisa, o amigo falou ai do tal projeto grande com vários programadores e cada um fazendo a sua maneira.
Ok, mas eu nunca vi uma especificação técnica que não sofreu mudanças no caminho (tirando as pequenas que até um estag modela) , seja por erro, ou seja por mudanças de escopo mesmo, falta de uma visão clara no momento da análise, ou seja, se uma coisa já nasce para ser mudada, me parece que tem alguma coisa errada no processo, me parece um tremendo retrabalho.
E ai o que acontece é o que já citaram, ou vocÊ tem um custo de manutenção de documentação (feito nas coxa, sim pq vc já está com o desenvolvimento em andamento, documentação entregue para o cliente, é atualizar só para falar que atualizou mesmo, mais burocracia) ou a documentação fica obsoleta, ou seja, a partir daquele momento não serve para mais nada, só para confundir nego que vai dar manutenção no futuro.
Já a algum tempo venho tentando convencer o pessoal aqui a adotar agilidade, mas ainda usamos cascatão, minha visão era adotar a agilidade e continuar elaborando algo em UML, mas eu vejo que a UML empurra cada vez mais o processo para o cascata.
Não sei pq abriram este tópico, já que o autor não parece ter dúvidas sobre como é importante UML como documentacao e ainda tira sarro de quem já descobriu na prática outras opcoes. Meu querido, um pouquinho mais de humildade, por favor!
convencer a usar a agilidade…
olha, eu já desisti do tópico. sinceramente, nem vale a pena.
muito legal o teste citado linhas acima… melhor ainda se ele olhasse num pedaço de papel e percebesse que já existe um método que pode ajudar na implementação de algo.
a muito tempo que muitos programadores preferem enfiar a cabeça sem raciocínio do que pensar no que fazer.
em breve vamos discutir “fazer na mão ou usar drag n’ drop” e ai vem as mesmas questões. com um você faz rápido, com outro você sabe exatamente o que tem em cada parte do projeto.
ei, você que nunca olhou um UML, sabe o que tem na classe do seu vizinho? sabe que ele pode ter implementado algo com propósito parecido com o seu e que pode te ajudar?
vou fazer o melhor para o Java, e o melhor para o Java na minha opinião é [TÓPICO RESOLVIDO].
abraço
convencer a usar a agilidade…
olha, eu já desisti do tópico. sinceramente, nem vale a pena.muito legal o teste citado linhas acima… melhor ainda se ele olhasse num pedaço de papel e percebesse que já existe um método que pode ajudar na implementação de algo.
a muito tempo que muitos programadores preferem enfiar a cabeça sem raciocínio do que pensar no que fazer.
em breve vamos discutir “fazer na mão ou usar drag n’ drop” e ai vem as mesmas questões. com um você faz rápido, com outro você sabe exatamente o que tem em cada parte do projeto.
ei, você que nunca olhou um UML, sabe o que tem na classe do seu vizinho? sabe que ele pode ter implementado algo com propósito parecido com o seu e que pode te ajudar?
vou fazer o melhor para o Java, e o melhor para o Java na minha opinião é [TÓPICO RESOLVIDO].
abraço
Melhor pro Java?
Não é por nada não, mas esse topico levantou temas importantes que precisa ser conhecidos e ganhar cada vez mais visibilidade. Empresa, desenvolvedores e clientes ganham com isso.
As faculdades ainda estão completamente desatualizada com relação aos rumos que o mercado está tomando.
O problema aqui não é UML X TDD(ou BDD), mas ‘modelo cascata’ X agilidade.
A verdade é que o ‘modelo em cascata’ a muito tempo deixou de ser em cascata, mas nem por isso ganhou um impulso no sentido de aceitar as mudanças com facilidade.
É isso que o mundo agil traz e é por isso que vem crescendo e mostrando resultado.
UML assume o sinonimo de ‘modelo em cascata’ pois quando pensamos nessa documentação, pensamos em um processo em cascata e em papeis bem definidos. Claro que isso também é uma generalização pois cada empresa tem sua própria cultura.
A UML sozinha não faz nada. Ela é só uma linguagem padrao para documentação e comunicação. Mas é por essa caracteristica que ela se aproxima tanto do ‘modelo em cascata’. Na verdade, em minha opiniao, ela poderia muito bem ser vista como uma solução para os modelo com foco no processo e papeis bem definidos. Isso pq a propria manutenção desses documentos exige que os papeis sejam diferenciados e que o processo seja o foco.
Claro que essa situação é pouco viavel para empresas menores com algumas dezenas de desenvolvedores. Geralmente nessas empresas a pessoa assume vários papeis, sendo analista, programador, testador e etc. Quando sobra tempo pra documentar e para manter essa documentação enquanto as empresas estão constantemente mudando suas regras ou sendo forçada a mudar por imposição do mercado ou da legislação? Essa é a realidade da maioria dos desenvolvedores.
Em empresas maiores ( com foco no processo) as pessoas acabam assumindo menos papeis existe todo um fluxo de informação que precisa ser comunicada e documentada. É aqui que entra a UML. A UML é uma ferramenta incrivel para essas grandes empresas com foco no processo. O problema é que mesmo essas grandes empresas já estão percebendo que esse foco no processo não funciona muito para o desenvolvimento de software. Estao percebendo que desenvolver software não é como desenvolver carro e que o próprio termo ‘fabrica de software’ é contraditorio se for analisado um pouco mais a fundo. Uma fabrica serve para fazer vários produtos iguais em sequencia, diminuindo o custo de produção. Em um software se repetimos uma classe ou um bloco de código que seja, tem algo errado que pode ser melhorado.
Então surge uma nova aboradagem que é o agil. Aqui temos o foco no resultado e o processo serve somente como suporte. Os papeis não são tao importante e o processo menos ainda. A UML não tem mais o processo nem os papeis pra suportar a quantidade de esforço necessário para manter toda documentação atualizada. Os testes estão de acordo com o que prega o agil pois tem foco no resultado e não no processo.
A questão não é saber Java, saber UML ou Padrões de Projeto. A questão é como levar uma solução para o cliente de forma rapida, util e com qualidade… é sempre pensar no retorno que o cliente vai ter com aquilo que foi investido.
Um profissional de TI não tem que fazer o que é melhor pro Java, mas o que é melhor para o cliente.
sim, muito importantes e eu concordo! este foi meu intuito ao criar o tópico. porém as pessoas em geral não se abrem a opinião, seguem e dizem ser correto apenas o mais pratico.
antes de encerrar minha postagem eu gostaria de dizer que PARA MIM TDD e UML são muito importantes. eu procuro conciliar os 2 e obter o melhor para mim.
claro, não vamos falar de ferramentas case… quando vou fazer um projeto em casa eu não desenho diagramas, eu escrevo o que eu vejo que o cliente precisa e as classes que eu provavelmente vou ter em um pedaço de papel higiênico e começo a escrever código. afinal, estou sozinho no projeto, ninguém vai precisar ter referencia sobre o que eu estou fazendo. mais quando vou fazer algo em equipe (igual ao TCC de um amigo ano passado que eu fiz em C++) preciso (EU) criar diagramas para dividir as tarefas . testes por conta de cada programador. quem cria uma classe tem que testa-la.
é assim que eu penso.
se a UML vai ser alterada ou não isso é outra historia. mais o pontapé inicial…
“Claro que essa situação é pouco viavel para empresas menores com algumas dezenas de desenvolvedores. Geralmente nessas empresas a pessoa assume vários papeis, sendo analista, programador, testador e etc.”
concordo plenamente, este eu acredito ser o maior problema. x-desenvolvedores que fazem papel até de faxineira.
concordo plenamente, este eu acredito ser o maior problema. x-desenvolvedores que fazem papel até de faxineira.
Esse negocio de “uma equipe grande” tambem nao serve muito como parametro.
Se voce tem mais de 5 desenvolvedores trabalhando em um mesmo modulo, algo esta errado. Projetos grandes sao modularizados e a integracao deles é que é dificil de ser feita, mas é a comunicação entre os integrantes dos grupos que vai ser importante, não a UML. UML ajudará, mas nao adianta nada um livro de 400 paginas de como deve ser o sistema.
Foco no processo, foco no resultado, que são características que você considera importante para escolher entre a estratégia waterfall x agile, não depende do tamanho da empresa, e sim do seu modelo de negócio.
No geral, concordo quando você diz cada situação deve ser analisada, e deve-se usar a melhor ferramenta para cada situação. Não existe melhor processo.
De fato a estratégia adotada pela empresa define se seu foco será ( de forma simplificada ) ( melhoria de )processo, cliente ou (criação de novos) produto.
Uma empresa pode ter sua estratégia voltada para aperfeiçoar constantemente seus processos mesmo que ainda seja uma pequena empresa. Essa pode ser sua estratégia e o mercado em que atua pdoe exigir isso. Mas se pensarmos exclusivamente em desenvolvimento de software uma pequena empresa jamais poderia adotar um ‘processo de desenvolvimento’ como é adotado nas grandes empresas, onde a UML passa a ser ‘necessária’.
Se uma empresa com foco na melhoria do seus processos deve generalizar essa ideia para todos os setores da empresa, isso seria ruim para a area de desenvolvimento ( se a empresa for pequena). Isso por causa da quantidade de esforço que seria gasto na tentativa de documentação e manutenção desta documentação.
Sendo realista, grande parte das empresas pequenas não tem condição de manter uma área de TI com muitos desenvolvedores… Como podem manter uma área de TI focada no processo sem pessoas suficiente para isso? A solução seria terceirizar sempre?
Eu acho que não…
Dado que:
Diante dos fatos, de onde você tirou a idéia de que UML e waterfall teriam algo em comum?
UML assume o sinonimo de ‘modelo em cascata’ pois quando pensamos nessa documentação, pensamos em um processo em cascata e em papeis bem definidos. Claro que isso também é uma generalização pois cada empresa tem sua própria cultura.
Dado que:
- UML foi criada por 3 das maiores sumidades em OO, os mesmos que fundaram a Rational e por acaso difundiram o ciclo de vida iterativo-incremental como uma alternativa ao modelo waterfall,
- Martin Fowler já escreveu sobre UML
- Scott Ambler já escreveu sobre UML
- Uncle Bob já escreveu sobre UML
- Praticamente toda representação visual de sistemas no mundo inteiro é feita em UML
Diante dos fatos, de onde você tirou a idéia de que UML e waterfall teriam algo em comum?
De onde eu tirei a ideia de que eles teriam algo em comum eu já expliquei exaustivamente neste tópico.
Disse também que o que estamos chamando de “waterfall” é na verdade o modelo “interativo-incremental” (o mesmo que voce citou) ja que na pratica nenhuma empresa moderna aplica esse que era conhecido como modelo “waterfall”. E mesmo nesse modelo a mudança não é tão bem aceita quanto deveria, e que além disso é necessário muito esforço para manter a documentação atualizada.
Considerando que a maioria das empresas nao tem recurso ilimitado ou grande o suficiente para um investimento pesado em TI, teremos um serio problema para manter a documentaçao atualizada.
O problema é a UML foi criada para uma realidade diferente das empresas onde a maioria dos desenvolvedores no Brasil trabalham e quem pensou na UML nao conhecia essa realidade.
então, por favor, sem falácias
" Argumentum ad Verecundiam (Apelo à autoridade) ou Magister Dixit (Meu mestre disse):
Argumentação baseada no apelo a alguma autoridade reconhecida para comprovar a premissa." http://pt.wikipedia.org/wiki/Falácia
tópico esta ficando quente e muito interessante. estou começando a absorver novas idéias.
falta o vinny aqui com agente… alguém linka ai pra ele.
UML assume o sinonimo de ‘modelo em cascata’ pois quando pensamos nessa documentação, pensamos em um processo em cascata e em papeis bem definidos. Claro que isso também é uma generalização pois cada empresa tem sua própria cultura.
Dado que:
- UML foi criada por 3 das maiores sumidades em OO, os mesmos que fundaram a Rational e por acaso difundiram o ciclo de vida iterativo-incremental como uma alternativa ao modelo waterfall,
- Martin Fowler já escreveu sobre UML
- Scott Ambler já escreveu sobre UML
- Uncle Bob já escreveu sobre UML
- Praticamente toda representação visual de sistemas no mundo inteiro é feita em UML
Diante dos fatos, de onde você tirou a idéia de que UML e waterfall teriam algo em comum?
De onde eu tirei a ideia de que eles teriam algo em comum eu já expliquei exaustivamente neste tópico.
Disse também que o que estamos chamando de “waterfall” é na verdade o modelo “interativo-incremental” (o mesmo que voce citou) ja que na pratica nenhuma empresa moderna aplica esse que era conhecido como modelo “waterfall”. E mesmo nesse modelo a mudança não é tão bem aceita quanto deveria, e que além disso é necessário muito esforço para manter a documentação atualizada.
Considerando que a maioria das empresas nao tem recurso ilimitado ou grande o suficiente para um investimento pesado em TI, teremos um serio problema para manter a documentaçao atualizada.O problema é a UML foi criada para uma realidade diferente das empresas onde a maioria dos desenvolvedores no Brasil trabalham e quem pensou na UML nao conhecia essa realidade.
então, por favor, sem falácias
" Argumentum ad Verecundiam (Apelo à autoridade) ou Magister Dixit (Meu mestre disse):
Argumentação baseada no apelo a alguma autoridade reconhecida para comprovar a premissa." http://pt.wikipedia.org/wiki/Falácia
O modelo não é interativo, é iterativo, baseado em iterações e chamar isso de waterfall é errado.
Sua afirmação de que waterfall não é usado por empresas modernas também é completamente equivocada. A realidade do mercado é que as empresas tentam usar waterfall sempre que possível. Ciclos iterativos são raridade. O que normalmente acontece é que o waterfall “dá errado”, ou seja, há necessidade de retrabalho e o processo não acomoda esse tipo de mudança.
Ciclo de vida iterativo-incremental e UML nada tem a ver com manter documentação atualizada. Você está misturando as bolas.
Seu argumento de que UML não foi pensada para a realidade brasileira, também se aplica a métodos ágeis. Ninguém consultou empresas ou programadores brasileiros para criar Scrum ou XP.
Seu argumento é Ad Confundus Cu com Bundis. UML é uma linguagem visual para modelagem de sistemas. Você pode usar UML de milhoes de maneiras diferentes, algumas certas e outras erradas. E não tem PN a ver com o ciclo de vida do seu projeto. Se você quiser especificar exaustivamente um sistema antes de começar a desenvolver, pode faze-lo em UML, português, aramaico ao contrário, não importa. O erro está no ciclo de vida e não no formato da documentação.
O modelo não é interativo, é iterativo, baseado em iterações e chamar isso de waterfall é errado.
Sua afirmação de que waterfall não é usado por empresas modernas também é completamente equivocada. A realidade do mercado é que as empresas tentam usar waterfall sempre que possível. Ciclos iterativos são raridade. O que normalmente acontece é que o waterfall “dá errado”, ou seja, há necessidade de retrabalho e o processo não acomoda esse tipo de mudança.
Ciclo de vida iterativo-incremental e UML nada tem a ver com manter documentação atualizada. Você está misturando as bolas.Seu argumento de que UML não foi pensada para a realidade brasileira, também se aplica a métodos ágeis. Ninguém consultou empresas ou programadores brasileiros para criar Scrum ou XP.
Seu argumento é Ad Confundus Cu com Bundis. UML é uma linguagem visual para modelagem de sistemas. Você pode usar UML de milhoes de maneiras diferentes, algumas certas e outras erradas. E não tem PN a ver com o ciclo de vida do seu projeto. Se você quiser especificar exaustivamente um sistema antes de começar a desenvolver, pode faze-lo em UML, português, aramaico ao contrário, não importa. O erro está no ciclo de vida e não no formato da documentação.
Desculpe o erro de portugues. De fato é iterativo ( de iteração)
E novamente digo que fui muito claro ao explicar pq chamei isso de ‘waterfall’. Não percebeu que durante todo o topico eu utilizei ele entre aspas?
Agora que estou equivocado ao dizer que as empresas não trabalham com iterativo eu discordo completamente. Primeiro pq não existe nada na literatura que dê apoio ao waterfall puro e até mesmo o PMBok tem seus processos para a gestão de mudanças ( para os mais detalhistas, suas ‘recomendações’). Entenderia se falasse que as empresas normalmente não adotam processo algum e é tudo meio caotico, mas dizer que pelo menos uma adota o modelo waterfall puro é meio fantasioso.
Se minha experiencia serve de algo, eu posso dizer que trabalho em uma grande empresa onde o foco é o processo e as etapas do desenvolvimento estão bem definidas e os papeis relativamente separados. Mesmo aqui não existe isso que chamam de waterfall de fato. Aqui existe todo um processo para gestão de mudanças. É claro que a mudança nao é tao bem aceita pq aumenta os custos ( o processo volta ao inicio, tem que atualizar documentação, realizar novas validações e etc).
e novamente já falei também exaustivamente do pq o autor da postagem no blog usou UML como sinonimo em ‘modelo cascata’ e não que seja isso de fato isso. Se fizer uma analise focandoos pontos citados, como dificuldade de manutenção da documentação relacionada com o auxilio que a própria UML traz ao modeo ‘waterfall’ e comparar com o outro lado, do foco nos resultados, do TDD (ou BDD) e do modelo agil. Da pra acompanhar perfeitamente o raciocinio do autor da postagem e entender que a comparação faz sentido
se os métodos ágeis foram pensados para a realidade brasileira, isso eu não sei. Mas que se aplica perfeitamente, se aplica.
A realidade do mercado é que as empresas tentam usar waterfall sempre que possível. Ciclos iterativos são raridade. O que normalmente acontece é que o waterfall “dá errado”, ou seja, há necessidade de retrabalho e o processo não acomoda esse tipo de mudança.
Processos voltados para execução são otimizados para repetição e não para acomodar mudanças. Talvez você queira dizer que quem adota waterfall geralmente o faz sem levar em conta isso, mas acho que é diferente de dizer que waterfall é um processo ruim porque deu errado para algo que não foi pensado originalmente.
A realidade do mercado é que as empresas tentam usar waterfall sempre que possível. Ciclos iterativos são raridade. O que normalmente acontece é que o waterfall “dá errado”, ou seja, há necessidade de retrabalho e o processo não acomoda esse tipo de mudança.Processos voltados para execução são otimizados para repetição e não para acomodar mudanças. Talvez você queira dizer que quem adota waterfall geralmente o faz sem levar em conta isso, mas acho que é diferente de dizer que waterfall é um processo ruim porque deu errado para algo que não foi pensado originalmente.
O que eu quis dizer é que a grande maioria dos projetos de desenvolvimento customizado para grandes empresas são contratados como uma única iteração de tantos meses quantos forem necessários para entregar tudo que o cliente imagina querer, dividida nas fases “req-design-dev-testes” e com modelo de preço fechado. Isso é planejar um waterfall.
Não importa o motivo. Chamar ciclo iterativo-incremental de ‘waterfall’,“waterfall”,‘cascata’,“cascata”, está errado. Seja mais claro e use um nome que você criou, mas não se aproprie de um nome existente para dar a ele o significado que você quer.
Engraçado. Então as dezenas de projetos reais que conheci onde havia um cronograma sequencial de mais de 18 meses dividido em requisitos-análise-construção-testes eram fantasias da minha mente? Todos os processos de desenvolvimento de empresas que tive a oportunidade de ler e que não mencionavam iterações também eram meros construtos de minha psique doentia?
Mas o modelo waterfall é exatamente isso: fases bem definidas onde há ênfase em uma única disciplina e o início da próxima fase se dá após o fechamento e aceitação da fase anterior O que você considera waterfall, é uma versão extremamente limitada dele, que eu chamaria de “waterfall-débil-mental”(entre aspas): eu tenho um projeto de 4 anos e 20 milhoes de dolares, identifico um novo requisito no meio da construção e digo pro cliente que agora só daqui a 4 anos. Isso não existe mesmo. Se existiu, a empresa que usou já faliu há muito tempo.
A analogia me parece forçada e para mim não faz sentido. Culpar a UML pela produção de documentação sem valor é como culpar o Eclipse por um bug no seu código.
Bom…
Troll detectado.
Nesses casos é melhor não alimentar e passar longe.
calma galera, sem nervosismo.
Ok,
vou explicar até onde eu sei.
Pelo que entendo o que ocorreu foi o seguinte… O próprio RUP, que hoje também é sinonimo de cascata, tinha um objetivo completamente diferente.
Quando o RUP foi criado não pensaram em algo tão engessado. Muitos dos que chegaram a trabalhar com o RUP logo no inicio falam isso.
É verdade que muitos projetos definem logo no inicio o produto final. Tentam especificar tudo logo de inicio.
Claro que sempre ocorrem mudanças, então o processo de qualquer empresa que tenha pessoas com um minimo de noção irá definir processos para fazer o gerenciamento de qualquer mudança eventual que ocorra durante o projeto.
Só pela existencia dessa possibilidade, já não posso dizer que meu modelo é realmente cascata. Em um modelo cascata a mudança não vai ocorrer.
No modelo iterativo existem pontos de valçidações onde o processo pode continuar ou voltar para fase inicial ou anterior. Essa é a realidade da maioria das empresas que trabalham com o que chamam de ‘modelo cascata’
Voltando ao RUP, hoje ele é sinonimo de cascata para qualquer agilista, mas nem por isso é cascata de fato e muito menos “waterfall-débil-mental” como voce gosta de chamar
Ok,
vou explicar até onde eu sei.Pelo que entendo o que ocorreu foi o seguinte… O próprio RUP, que hoje também é sinonimo de cascata, tinha um objetivo completamente diferente.
Quando o RUP foi criado não pensaram em algo tão engessado. Muitos dos que chegaram a trabalhar com o RUP logo no inicio falam isso.É verdade que muitos projetos definem logo no inicio o produto final. Tentam especificar tudo logo de inicio.
Claro que sempre ocorrem mudanças, então o processo de qualquer empresa que tenha pessoas com um minimo de noção irá definir processos para fazer o gerenciamento de qualquer mudança eventual que ocorra durante o projeto.
Só pela existencia dessa possibilidade, já não posso dizer que meu modelo é realmente cascata. Em um modelo cascata a mudança não vai ocorrer.No modelo iterativo existem pontos de valçidações onde o processo pode continuar ou voltar para fase inicial ou anterior. Essa é a realidade da maioria das empresas que trabalham com o que chamam de ‘modelo cascata’
Voltando ao RUP, hoje ele é sinonimo de cascata para qualquer agilista, mas nem por isso é cascata de fato e muito menos “waterfall-débil-mental” como voce gosta de chamar
Eu concordo que com o esmirralha quando ele diz que as empresas, na maioria, nao usam o modelo incremental, usam sim waterfall. E o fato de waterfall nao estar em livro algum nao faz a menor diferenca pra eles porque eles nao consultam livro algum. A grande, mas grande mesmo, maioria de quem trabalha com desenvolvimento de softwares - seja desenvolvedor, gerente, diretor, empresario, - se pegou em algum livro de software na vida o fez pra conseguir tirar 7 em alguma prova na faculdade e nunca mais.
O fato é que waterfall é intuitivo e causa sensação em todo mundo de que a coisa foi bem planejada, nós sabemos é que foi bem especulada, os que nao lêem e nao se dao ao trabalhar de observar pra aprender pela experiencia não sabem.
Sobre RUP eu conheço pouco, mas pelo pouco que conheço posso dizer que nao é waterfall. O problema é que a coisa vira moda e se pratica waterfall dizendo que é RUP. Eu ja vi projetos completamente em cascata sendo chamado de Scrum.
Pelo que entendo o que ocorreu foi o seguinte… O próprio RUP, que hoje também é sinonimo de cascata, tinha um objetivo completamente diferente.
Quando o RUP foi criado não pensaram em algo tão engessado. Muitos dos que chegaram a trabalhar com o RUP logo no inicio falam isso.
…
Voltando ao RUP, hoje ele é sinonimo de cascata para qualquer agilista, mas nem por isso é cascata de fato e muito menos “waterfall-débil-mental” como voce gosta de chamar
Seu argumento é Ad Confundus Cu com Bundis. UML é uma linguagem visual para modelagem de sistemas. Você pode usar UML de milhoes de maneiras diferentes, algumas certas e outras erradas. E não tem PN a ver com o ciclo de vida do seu projeto. Se você quiser especificar exaustivamente um sistema antes de começar a desenvolver, pode faze-lo em UML, português, aramaico ao contrário, não importa. O erro está no ciclo de vida e não no formato da documentação.
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk!!!
Em quase 8 anos de guj, nunca ri tanto!!! 
foi mal mano, então tenho de admitir VOCÊ É O CARA!deve ser engenheiro do Google ou quem sabe da IBM no mínimo. o mais provável é que você~e seja engenheiro da Nasa e que faça metade do serviço sozinho!
classe tal herda de tal… implementa tal… ai você vai nos testes e descobre tudo que a outra tem… ou você vai abrindo todas as classes pra ver… quando você poderia simplesmente olhar em um pedaço de papel ¬¬. e por fim, se desse algo errado, você faria testes para entender melhor como funciona.
veja que você já menosprezou até os comentários de código.
não vou me exaltar ou levar sua opinião em consideração, já entendi seu artigo ¬¬.
tópico esta ficando quente e muito interessante. estou começando a absorver novas idéias.falta o vinny aqui com agente… alguém linka ai pra ele.
Se o “vinny” que você citou é o mesmo que eu conheço (o Godoy) ele muito provavelmente concordaria com o s4nchez, do qual você se achou detentor de técnicas melhores.
Ok,
talvez eu tenha misturado muita coisa e muitos conceitos mesmo. Sempre que falo do assunto acabo misturando pq uma coisa leva a outra.
pensando de forma rasteira e ignorando qualquer contexto, temos:
Observando isoladamente cada coisa, concordo com tudo isso. ( e em nenhum momento disse o contrário, levando em consideraçao o contexto)
Mas ainda discordo de quem diz que as empresas adotam o modelo cascata de verdade.
Mesmo que os custos costumem ser estimados no inicio do projeto, que o prazo também seja. Existe “sempre” um processo responsável pela gestão da mudança, que pode impactar nos prazos ou no orçamento.
Se realmente existe empresas que empurram o software, e se ainda existem clientes que aceitam contratos dessse tipo, eu não consigo acreditar.
Posso acreditar sim que existam empresas com processos extremamente deficientes, que nao façam uma boa gestao( ou que nem fazem gestao alguma), que nao sao capaz de manter o controle sobre o projeto, que nao cumprem os prazos e etc. Ou empresas que colocam uma enorme dificuldade para realizar qualquer alteraçao no escopo inicial.
Mas esse escopo nunca é completamente engessado.
Sempre existe uma fase de teste onde o cliente diz se aquilo que está sendo entregue é o que ele precisa. No modelo cascata isso não pode ocorrer. Ele não permite mudança do escopo.
É verdade que existe a fase de teste no modelo em cascata, mas nesse modelo o teste é somente para arrumar problemas relacionados à solução. O cliente vai ter que aceitar aquilo sem chance de fazer qualquer alteração o escopo do projeto.
resumindo o que quero dizer é:
1- UML precisa de processos e papeis bem definidos para dar algum resultado util.
2- Mesmo o modelo incremental adotada em boa parte das empresas hoje em dia não aceitam tão bem a mudança. Qualquer forma de desenvolvimento que utilize a UML para documentar os software e dar andamento ao processo vai naturalmente ter um custo de mudança mais elevado do que a proposta de desenvolvimento agil.
3- A proposta do desenvolvimento agil é o foco no resultado e não no processo. Isso não quer dizer que foco no processo é ruim para qualquer empresa de desenvolvimento, mas quando a empresa trabalha tendo o processo como prioridade ela também terá um custo de mudança necessariamente maior do que a abordagem ágil com foco no resultado.
se for tomar cada coisa isolada, temos a situação que coloquei no post anterior, mas se for colocar dentro do contexto é evidente que a UML não é somente uma linguagem ( como disseram), mas também uma solução para um modelo de desenvolvimento.
Lendo o paper original que descreve o modelo waterfall, você vai perceber que nunca foi proposto um modelo onde não existisse gerenciamento de mudança.
Um trecho:
“Figure 3 portrays the iterative relationship between successive development phases for this scheme.
The ordering of steps is based on the following concept: that as each step progresses and the design is further
detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in
the sequence. The virtue of all of this is that as the design proceeds the change process is scoped down to
manageable limits.”
Ou seja, o modelo waterfall já previa a possibilidade de retorno a fases anteriores caso fosse necessário realizar uma mudança. E isso é corroborado pelos meus 13 anos de experiência, pois nunca participei de um projeto onde não houvesse um processo para gerenciar mudança (por mais engessado que ele fosse).
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Lendo o paper original que descreve o modelo waterfall, você vai perceber que nunca foi proposto um modelo onde não existisse gerenciamento de mudança.Um trecho:
“Figure 3 portrays the iterative relationship between successive development phases for this scheme.
The ordering of steps is based on the following concept: that as each step progresses and the design is further
detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in
the sequence. The virtue of all of this is that as the design proceeds the change process is scoped down to
manageable limits.”Ou seja, o modelo waterfall já previa a possibilidade de retorno a fases anteriores caso fosse necessário realizar uma mudança. E isso é corroborado pelos meus 13 anos de experiência, pois nunca participei de um projeto onde não houvesse um processo para gerenciar mudança (por mais engessado que ele fosse).
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Considerando isso, então RUP é ou não waterfall?
" that as each step progresses and the design is further
detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in
the sequence"
e afinal, waterfall também seria iterativo?
Bom, pelo que entendi de uma rapida olhada no pdf é que existe a possibilidade de retornar a fase anterior, mas nunca de mudança no escopo. Depois da fase de teste posso voltar para codificação, mas não para a fase de analise.
resumindo o que quero dizer é:1- UML precisa de processos e papeis bem definidos para dar algum resultado util.
2- Mesmo o modelo incremental adotada em boa parte das empresas hoje em dia não aceitam tão bem a mudança. Qualquer forma de desenvolvimento que utilize a UML para documentar os software e dar andamento ao processo vai naturalmente ter um custo de mudança mais elevado do que a proposta de desenvolvimento agil.
3- A proposta do desenvolvimento agil é o foco no resultado e não no processo. Isso não quer dizer que foco no processo é ruim para qualquer empresa de desenvolvimento, mas quando a empresa trabalha tendo o processo como prioridade ela também terá um custo de mudança necessariamente maior do que a abordagem ágil com foco no resultado.se for tomar cada coisa isolada, temos a situação que coloquei no post anterior, mas se for colocar dentro do contexto é evidente que a UML não é somente uma linguagem ( como disseram), mas também uma solução para um modelo de desenvolvimento.
1 - Essa afirmação é baseada em algum fato ou é só suposição? UML é uma linguagem de modelagem. Se você não sabe usar, não invente outra definição.
2 - Corrigindo, qualquer processo que se proponha a gerar documentação extensa em QUALQUER FORMATO, vai aumentar o custo de mudança.
Bom, pelo que entendi de uma rapida olhada no pdf é que existe a possibilidade de retornar a fase anterior, mas nunca de mudança no escopo. Depois da fase de teste posso voltar para codificação, mas não para a fase de analise.
Você acha justo eu perder meu tempo explicando, se você não quer perder o seu lendo o artigo?
resumindo o que quero dizer é:1- UML precisa de processos e papeis bem definidos para dar algum resultado util.
2- Mesmo o modelo incremental adotada em boa parte das empresas hoje em dia não aceitam tão bem a mudança. Qualquer forma de desenvolvimento que utilize a UML para documentar os software e dar andamento ao processo vai naturalmente ter um custo de mudança mais elevado do que a proposta de desenvolvimento agil.
3- A proposta do desenvolvimento agil é o foco no resultado e não no processo. Isso não quer dizer que foco no processo é ruim para qualquer empresa de desenvolvimento, mas quando a empresa trabalha tendo o processo como prioridade ela também terá um custo de mudança necessariamente maior do que a abordagem ágil com foco no resultado.se for tomar cada coisa isolada, temos a situação que coloquei no post anterior, mas se for colocar dentro do contexto é evidente que a UML não é somente uma linguagem ( como disseram), mas também uma solução para um modelo de desenvolvimento.
1 - Essa afirmação é baseada em algum fato ou é só suposição? UML é uma linguagem de modelagem. Se você não sabe usar, não invente outra definição.
2 - Corrigindo, qualquer processo que se proponha a gerar documentação extensa em QUALQUER FORMATO, vai aumentar o custo de mudança.
Não defini coisa alguma nessa mensagem. A definição da UML pura e simples, fora de qualquer contexto, eu disse que concordo contigo, como ja disse antes.
Disse que ela precisa de processos bem definidos para dar algum resultado útil. Tente adotar a UML se preocupado principalmente com o resultado para ver o que acontece. Vai ficar com uma documentação bem desatualizada.
Não entendi que diferença faz ser em qualquer formato. De qualquer forma, o BDD por exemplo é uma boa forma de conseguir uma boa documentação sem aumentar tanto o custo de mudança.
resumindo o que quero dizer é:1- UML precisa de processos e papeis bem definidos para dar algum resultado util.
2- Mesmo o modelo incremental adotada em boa parte das empresas hoje em dia não aceitam tão bem a mudança. Qualquer forma de desenvolvimento que utilize a UML para documentar os software e dar andamento ao processo vai naturalmente ter um custo de mudança mais elevado do que a proposta de desenvolvimento agil.
3- A proposta do desenvolvimento agil é o foco no resultado e não no processo. Isso não quer dizer que foco no processo é ruim para qualquer empresa de desenvolvimento, mas quando a empresa trabalha tendo o processo como prioridade ela também terá um custo de mudança necessariamente maior do que a abordagem ágil com foco no resultado.se for tomar cada coisa isolada, temos a situação que coloquei no post anterior, mas se for colocar dentro do contexto é evidente que a UML não é somente uma linguagem ( como disseram), mas também uma solução para um modelo de desenvolvimento.
1 - Essa afirmação é baseada em algum fato ou é só suposição? UML é uma linguagem de modelagem. Se você não sabe usar, não invente outra definição.
2 - Corrigindo, qualquer processo que se proponha a gerar documentação extensa em QUALQUER FORMATO, vai aumentar o custo de mudança.
Não defini coisa alguma nessa mensagem. A definição da UML pura e simples, fora de qualquer contexto, eu disse que concordo contigo, como ja disse antes.
Disse que ela precisa de processos bem definidos para dar algum resultado útil. Tente adotar a UML se preocupado principalmente com o resultado para ver o que acontece. Vai ficar com uma documentação bem desatualizada.Não entendi que diferença faz ser em qualquer formato. De qualquer forma, o BDD por exemplo é uma boa forma de conseguir uma boa documentação sem aumentar tanto o custo de mudança.
1 - Se você quer entender o uso de UML em um contexto ágil, leia (e não dê uma rápida olhada): Modelagem Ágil, de Scott Ambler.
2 - BDD não é documentação de sistema, é uma ferramenta para discussão de cenários de requisitos entre desenvolvedores e clientes. BDD olha o sistema de fora, ou seja, do ponto de vista do usuário. Infelizmente e obviamente esse não é o único ponto de vista de um sistema. Como se descreve o funcionamento interno? E a plataforma operacional onde ele vai rodar?
Não disse que UML não poderia ou nao deveria ser usada no contexto agil, só disse que ela é muito mais útil e natural quando o foco é o processo. De qualquer forma, ainda não conheço como funciona UML com agil, então foi uma boa dica.
E BDD é documentação de sistema sim, e voce mesmo disse isso. Só não é de todos os aspectos. Aliais, documentar esses outros aspectos pra uma boa parte dos casos é desenecessário mesmo.
Sobre RUP eu conheço pouco, mas pelo pouco que conheço posso dizer que nao é waterfall. O problema é que a coisa vira moda e se pratica waterfall dizendo que é RUP. Eu ja vi projetos completamente em cascata sendo chamado de Scrum.
Agora deixando moda de lado, RUP e Waterfall são extremamente similares, visto que ambos tem o mesmo objetivo (processo) e foco (execução).
Não disse que UML não poderia ou nao deveria ser usada no contexto agil, só disse que ela é muito mais útil e natural quando o foco é o processo. De qualquer forma, ainda não conheço como funciona UML com agil, então foi uma boa dica.E BDD é documentação de sistema sim, e voce mesmo disse isso. Só não é de todos os aspectos. Aliais, documentar esses outros aspectos pra uma boa parte dos casos é desenecessário mesmo.
Documentar pode ser desnecessário, mas comunicar não é. E UML é uma boa ferramenta de comunicação para design.
Sobre RUP eu conheço pouco, mas pelo pouco que conheço posso dizer que nao é waterfall. O problema é que a coisa vira moda e se pratica waterfall dizendo que é RUP. Eu ja vi projetos completamente em cascata sendo chamado de Scrum.Agora deixando moda de lado, RUP e Waterfall são extremamente similares, visto que ambos tem o mesmo objetivo (processo) e foco (execução).
Onde você leu isso? O RUP foca em feedback antecipado dos riscos do projeto. É uma abordagem orientada a riscos ao invés de orientada a valor. mas tanto risco quanto valor tem impacto direto sobre os stakeholders de um projeto. Lembrando que usuário final e stakeholder não são sinônimos… Foco exclusivo no usuário final é uma visão limitada.
Sobre RUP eu conheço pouco, mas pelo pouco que conheço posso dizer que nao é waterfall. O problema é que a coisa vira moda e se pratica waterfall dizendo que é RUP. Eu ja vi projetos completamente em cascata sendo chamado de Scrum.Agora deixando moda de lado, RUP e Waterfall são extremamente similares, visto que ambos tem o mesmo objetivo (processo) e foco (execução).
Onde você leu isso? O RUP foca em feedback antecipado dos riscos do projeto. É uma abordagem orientada a riscos ao invés de orientada a valor. mas tanto risco quanto valor tem impacto direto sobre os stakeholders de um projeto. Lembrando que usuário final e stakeholder não são sinônimos… Foco exclusivo no usuário final é uma visão limitada.
Não é por nada não, mas usuário é sim um stakeholder. Qualquer pessoa que esteja envolvido ou seja afetado de alguma forma pelo projeto é um stakeholder.
e nunca ouvi falar de uma abordagem que tenha foco no usuário final.
Sobre RUP eu conheço pouco, mas pelo pouco que conheço posso dizer que nao é waterfall. O problema é que a coisa vira moda e se pratica waterfall dizendo que é RUP. Eu ja vi projetos completamente em cascata sendo chamado de Scrum.Agora deixando moda de lado, RUP e Waterfall são extremamente similares, visto que ambos tem o mesmo objetivo (processo) e foco (execução).
Onde você leu isso? O RUP foca em feedback antecipado dos riscos do projeto. É uma abordagem orientada a riscos ao invés de orientada a valor. mas tanto risco quanto valor tem impacto direto sobre os stakeholders de um projeto. Lembrando que usuário final e stakeholder não são sinônimos… Foco exclusivo no usuário final é uma visão limitada.
Não é por nada não, mas usuário é sim um stakeholder. Qualquer pessoa que esteja envolvido ou seja afetado de alguma forma pelo projeto é um stakeholder.
e nunca ouvi falar de uma abordagem que tenha foco no usuário final.
Eu quis dizer que stakeholder é um conceito que abrange não apenas usuários do sistema, mas todos os interessados no projeto.
Sobre RUP eu conheço pouco, mas pelo pouco que conheço posso dizer que nao é waterfall. O problema é que a coisa vira moda e se pratica waterfall dizendo que é RUP. Eu ja vi projetos completamente em cascata sendo chamado de Scrum.Agora deixando moda de lado, RUP e Waterfall são extremamente similares, visto que ambos tem o mesmo objetivo (processo) e foco (execução).
Onde você leu isso? O RUP foca em feedback antecipado dos riscos do projeto. É uma abordagem orientada a riscos ao invés de orientada a valor. mas tanto risco quanto valor tem impacto direto sobre os stakeholders de um projeto. Lembrando que usuário final e stakeholder não são sinônimos… Foco exclusivo no usuário final é uma visão limitada.
Não é por nada não, mas usuário é sim um stakeholder. Qualquer pessoa que esteja envolvido ou seja afetado de alguma forma pelo projeto é um stakeholder.
e nunca ouvi falar de uma abordagem que tenha foco no usuário final.
Eu quis dizer que stakeholder é um conceito que abrange não apenas usuários do sistema, mas todos os interessados no projeto.
Stakeholder (em português, parte interessada ou interveniente), é um termo usado em diversas áreas como administração e arquitetura de software referente às partes interessadas que devem estar de acordo com as práticas de governança corporativa executadas pela empresa.
Fonte: Wikipédia
Então… eu entendo que o usuário, é sim, um stakeholder.
Os usuários do sistema são um subconjunto do conjunto que representa os stakeholders do sistema.
Entendeu?
sim, mais então eles fazem ou não parte?
é tanta divisão que as vezes confunde.
.
Sobre RUP eu conheço pouco, mas pelo pouco que conheço posso dizer que nao é waterfall. O problema é que a coisa vira moda e se pratica waterfall dizendo que é RUP. Eu ja vi projetos completamente em cascata sendo chamado de Scrum.Agora deixando moda de lado, RUP e Waterfall são extremamente similares, visto que ambos tem o mesmo objetivo (processo) e foco (execução).
Onde você leu isso? O RUP foca em feedback antecipado dos riscos do projeto. É uma abordagem orientada a riscos ao invés de orientada a valor. mas tanto risco quanto valor tem impacto direto sobre os stakeholders de um projeto. Lembrando que usuário final e stakeholder não são sinônimos… Foco exclusivo no usuário final é uma visão limitada.
E ele faz isso prestando atenção na execução. não sei se entendi o resto do seu comentário, você descreveu algo muito similar a Waterfall. Como dizia, ambos são parecidos no sentido em que as duas abordagens são baseadas em um modelo e estrutura organizacional existente.
.
queimem esse topico pela o bem da humanidade
de que vale a humanidade sem a ciência?