Engenheiros ainda usam diagramas de casos de uso e diagramas de classe?

cmoscoso wrote:Projetos sérios também falham, não é brincadeira!

Sem dúvida, e o Longhorn que o diga.

Mas o que eu quis dizer é que existem situações em que justifica ter uma equipe tão grande. Diferentemente do que faz muita softwarehouse por aí, que quer impressionar o cliente, e contrata vários programadores de baixo conhecimento técnico só para cobrar caríssimo, sem que isso seja sequer justificável.

Ah sim, e elas ainda usam a documentação como uma forma de dizer que tem "padrões de qualidade". Como se papel garantisse algum tipo de qualidade.

(Aliás, o oposto também vale. Tem muita gente usando a desculpa de que é ágil para fazer bagunça e justificar a ausência de processo, o que também não é correto).

ViniGodoy wrote:

cmoscoso wrote:Projetos sérios também falham, não é brincadeira!

Sem dúvida, e o Longhorn que o diga.

Mas o que eu quis dizer é que existem situações em que justifica ter uma equipe tão grande. Diferentemente do que faz muita softwarehouse por aí, que quer impressionar o cliente, e contrata vários programadores de baixo conhecimento técnico só para cobrar caríssimo, sem que isso seja sequer justificável.

Ah sim, e elas ainda usam a documentação como uma forma de dizer que tem "padrões de qualidade". Como se papel garantisse algum tipo de qualidade.

(Aliás, o oposto também vale. Tem muita gente usando a desculpa de que é ágil para fazer bagunça e justificar a ausência de processo, o que também não é correto).

Gostei disso, exatamente o que vejo por aí.

++

This message was edited 2 times. Last update was at 12/05/2008 17:22:02

ViniGodoy wrote:
Mas setor aqui do lado tem mais de 30 pessoas que fazem software de centrais telefônicas, aqui na Siemens. Além deles tem o pessoal do firmware, mas como estamos falando de processos de software, não entremos nesse quesito.

Acho muito difícil imaginar um processo menos burocrático, já que a equipe é grande, os requisitos vem da Alemanha e muitas vezes a visão do cliente se baseia em pesquisas estatísticas sobre o mercado consumidor. Além disso, há custos envolvendo também hardware e um erro de dimensionamento do software da central pode se tornar muito caro.

Independente do cliente na alemenha alguem será eleito pra fazer a parte cliente on-site, e nao vale dizer que ta faltando pessoal!

Desculpe mas não vejo isso como falha da metodologia ja que ela esta preocupada em entregar software funcional. Isso nao exclui a necessidade de competencia para gerir sua cadeia de processos. Por exemplo, não acho que o tamanho do projeto deva se dar em funcao do numero de pessoas disponiveis e sim em funcao do que é possível ser gerenciado levando em conta as possibilidades. Grandes projetos precisam ser divididos para serem conquistados. Não com o objetivo primario de eliminar burocracia mas de permitir algo passível de ser gerenciado.

ViniGodoy wrote:
A correção do software no cliente, uma vez que é produzido e distribuída em escala, num equipamento que muitas vezes não aceita updates automáticos, também não é simples como no caso de software de prateleira. Só para se ter uma idéia, existe um outro departamento inteiro só focado em testes e rigorosas especificações de qualidade.

No caso dos processos ágeis usamos um pressuposto, que é válido para a absurda maioria dos sofwares, que é o de que modificar programas é relativamente fácil e barato. O que não é válido para o pessoal aqui do lado, mas é bastante válido em meu setor.

Se é uma caracteristica do seu negócio nao vejo porque nao pode ser suportado pelo processo ágil mas se também vocês adotam outra metodologia que lhe servem e permite desenvolver o software de qualidade que precisam ótimo, seria um bom estudo de caso!

O fato de haverem X mil programadores num projeto não traz necessidade de diagramas de classe, interação e etc como especificação formal ou mesmo documentação (apesar de haverem -poucos- casos onde isso seria útil). Como o Moscoso falou um projeto desse tem que ser dividido em projetos menores ara se tornar gerenciável.

Assim como ninuém nunca precisa nsultar um diagrama de classes do Hibernate para ver como ele funciona (para coisas simples uma página de wiki te basta, para coisas complexas a documentação é textual e baseada em exemplos) não é preciso mantêr diagramas em UML.

alexsander.santana wrote:Em projetos grandes utilizar automatização para geração de código através de MDA, traz muita agilidade ao processo.

Isso foi o que lhe contaram ou você já teve essa experiência?

This message was edited 1 time. Last update was at 12/05/2008 23:47:11

cmoscoso wrote:Independente do cliente na alemanha alguem será eleito pra fazer a parte cliente on-site, e nao vale dizer que ta faltando pessoal!

Seria realmente ótimo se existisse essa figura. Teriam que distribuir uma pessoa para cada um dos 7 sites de desenvolvimento no mundo, que deveriam estar totalmente integradas com o projeto centralizado. Mas com um pouco de esforço acho que poderia ser feito.

cmoscoso wrote:Desculpe mas não vejo isso como falha da metodologia ja que ela esta preocupada em entregar software funcional.

Não entendi no contexto, isso o que?

cmoscoso wrote:Isso nao exclui a necessidade de competencia para gerir sua cadeia de processos. Por exemplo, não acho que o tamanho do projeto deva se dar em funcao do numero de pessoas disponiveis e sim em funcao do que é possível ser gerenciado levando em conta as possibilidades. Grandes projetos precisam ser divididos para serem conquistados. Não com o objetivo primario de eliminar burocracia mas de permitir algo passível de ser gerenciado.

Bom, acho que isso é meio óbvio, não? Dividir para conquistar é um lema de todos os processos sérios, desde os mais burocráticos até os mais simples. O número de pessoas pode não ser o único fator para definir se um projeto é grande ou complexo, mas certamente é um dos fatores.

cmoscoso wrote:Se é uma caracteristica do seu negócio nao vejo porque nao pode ser suportado pelo processo ágil mas se também vocês adotam outra metodologia que lhe servem e permite desenvolver o software de qualidade que precisam ótimo, seria um bom estudo de caso!

Ainda não vejo como aplicar métodos ágeis quando o custo de modificar fica exponencialmente mais alto a medida que o produto final aproxima-se do cliente. Embora essa já tenha deixado de ser a realidade da maior parte dos softwares, esse certamente não é o nosso caso, por todos os motivos já citados. Já citando o próprio Kent Beck, no seu livro Extreme Programming Explained:
"It is the technical premise of XP. If the cost of change rose slowly over time, you would act completely differently from how you do under the assumption that costs rise exponentially."

O mesmo foi repetido pelo Craig Larmann numa palestra que ele deu na Nokia Siemens, falando de Agile no geral.

Torno a repetir: Eu não sou contra processos ágeis. E aliás, não só sou completamente a favor como também me empenhei para que ele fosse implantado onde trabalho. Também creio que haja muito mais potencial para ele dentro das empresas, especialmente as grandes. Reconheço que ele é adequado para a absurda maioria dos softwares atuais, especialmente aqueles desenvolvidos no comércio (grandes ou não). No nosso caso, acho que muitos setores ainda poderiam se beneficiar de um método ágil. Mas não creio que ele seja a solução para todos os problemas de TI.

Vini, eu entedi seu arument e concordo, só que para mim a quantidade de softwares que cai nessa exceção é bem menor e não inclui seus exemplos. Sobre Sisemas Operacionais, a Microsoft é um dos grandes nomes por trá de agile nos últimos anos e apesar de eu não conhecer a fundo o processo de desenvolvimento do kernel do Linux eu nunca coheci um projto livre de sucesso que fosse waterfall ou mesmo BDUF. Já trabalhei com telefonia o suficiente para saber que o problema é cultural, não tecnológico (convencer engenheiros a não fazer um mega-projeto numa ferramenta CAD, ops, CASE é algo complicado) e sobre jogos , apesar de não ter experiência,eu tenho um exemplo bem interessante:

http://www.se-radio.net/podcast/2008-04/episode-92-introduction-game-development

É engraçado como o processo de desenvolvimento é descrito, extremamente iterativo e incremental, e como o entrevistado fala que processos burocráticos servem apenas para sotware comercial em grandes empresas.

alexsander.santana wrote:A discussão parece bem interessante e gostaria de comentar.
Em projetos grandes utilizar automatização para geração de código através de MDA, traz muita agilidade ao processo.
Como fazer isso sem utilizar diagramas UML??

Acho que o ponto aqui é ailidade como o que foi definido pleo manifesto ágil, não sobre velocidade. Ainda assim, alternativas de Model Driven Design não dependem de uma linguagem especifica, Microsoft DSL Tools, Metacase, Jetbrains MPS e outros métodos são alternativas. Segundo alguns defensores de MDA nem mesmo este padrão depende de UML -o que eu não concordo.

This message was edited 1 time. Last update was at 14/05/2008 07:41:39

pcalcado wrote:Vini, eu entedi seu arument e concordo, só que para mim a quantidade de softwares que cai nessa exceção é bem menor e não inclui seus exemplos. Sobre Sisemas Operacionais, a Microsoft é um dos grandes nomes por trá de agile nos últimos anos e apesar de eu não conhecer a fundo o processo de desenvolvimento do kernel do Linux eu nunca coheci um projto livre de sucesso que fosse waterfall ou mesmo BDUF. Já trabalhei com telefonia o suficiente para saber que o problema é cultural, não tecnológico (convencer engenheiros a não fazer um mega-projeto numa ferramenta CAD, ops, CASE é algo complicado) e sobre jogos , apesar de não ter experiência,eu tenho um exemplo bem interessante:

O processo de desenvolvimento do kernel do Linux não é nada muito complexo.

Existe um grupo de responsáveis por cada parte (os maintainers) e os desenvolvedores mandam patches, normalmente para uma lista de discussão. As pessoas comentam, mandam sugestões/correções e quem dá a palavra final é o responsável, que no final do processo adiciona o patch ao kernel.

Esse artigo mostra com detalhes como funciona o processo.

Virtual Machine Man Membro desde: 10/07/2006 10:37:23 Mensagens: 929 Offline

dividir o projto em menores para não precisar utilizar tais documentações e uma boa...
mas e em casos onde o projeto e muito integrado como fica?

O maior problema é o custo do software que vai embarcado para o cliente, ou que acompanha o hardware (e não necessariamente é embarcado, mas gravado em memória flash ou outro dispositivo que ficará isolado de uma rede e, portanto, não sujeito a updates automáticos).

Esse software sim, é caríssimo de se modificar. Mas também concordo (e por isso venho tentando convencer o pessoal de adotar mais técnicas ágeis por aqui), que boa parte do processo poderia ser, no mínimo, mais ágil. E que nem todas as etapas do processo precisam necessariamente ser burocráticas.

Os processos ágeis, na minha opinião, foram os primeiros a encarar software realmente como ele é: software. E não a utilizar uma abordagem inspirada na engenharia civil.

Quanto aos exemplos, eu só estava citando casos de software de grande porte, em que se justificava ter vários programadores. Não falava exatamente do fato disso ser aplicável a processos ágeis ou não.

Quanto aos jogos: Eu acho o desenvolvimento de jogos ainda é burocrático demais hoje. Tenho defendido um processo mais interativo e práticas ágeis no desenvolvimento há muito tempo. Mas por lá, também existe uma séria dificuldade cultural. Me deixou feliz saber que a Hoplon, desenvolvedora do Taikodom inspirou-se muito em processos ágeis para melhorar o seu ciclo produtivo. Ainda no GamaSutra surgem artigos de grandes figuras no mundo dos games defendendo um processo muito próximo do RUP. Claro, já existem movimentos no sentido contrário, o que creio que será realmente a tendência futura.

ViniGodoy wrote:

cmoscoso wrote:Desculpe mas não vejo isso como falha da metodologia ja que ela esta preocupada em entregar software funcional.

Não entendi no contexto, isso o que?

Suportar essa caracteristica de nao poder atualizar o sw, concordo que é uma situção diferente do "normal" mas processos podem ser estendidos para atender suas necessidades, dizer que agile nao funciona aqui é desconsiderar varios outros principios que ainda seriam util para o desenvolvimento como todo.

ViniGodoy wrote:
Ainda não vejo como aplicar métodos ágeis quando o custo de modificar fica exponencialmente mais alto a medida que o produto final aproxima-se do cliente. Embora essa já tenha deixado de ser a realidade da maior parte dos softwares, esse certamente não é o nosso caso, por todos os motivos já citados. Já citando o próprio Kent Beck, no seu livro Extreme Programming Explained:
"It is the technical premise of XP. If the cost of change rose slowly over time, you would act completely differently from how you do under the assumption that costs rise exponentially."

O mesmo foi repetido pelo Craig Larmann numa palestra que ele deu na Nokia Siemens, falando de Agile no geral.

Torno a repetir: Eu não sou contra processos ágeis. E aliás, não só sou completamente a favor como também me empenhei para que ele fosse implantado onde trabalho. Também creio que haja muito mais potencial para ele dentro das empresas, especialmente as grandes. Reconheço que ele é adequado para a absurda maioria dos softwares atuais, especialmente aqueles desenvolvidos no comércio (grandes ou não). No nosso caso, acho que muitos setores ainda poderiam se beneficiar de um método ágil. Mas não creio que ele seja a solução para todos os problemas de TI.

Nao é facil introduzir Agile numa organizacao justamente pelo fato de nao haver one-size-fits-all e como disse o Phillip agile nao é velocidade. Se algumas coisas precisam ser de um jeito sera que essa coisa inviabiliza estar sob a influencia do paradigma agil?

Se essa coisa é não poder atualizar o software no cliente eu diria que ainda vale muito a pena agora se estamos falando em equipes de 30 programadores aí nao há como suportar devido ao overhead de comunicacao.

pcalcado wrote:
Acho que o ponto aqui é ailidade como o que foi definido pleo manifesto ágil, não sobre velocidade. Ainda assim, alternativas de Model Driven Design não dependem de uma linguagem especifica, Microsoft DSL Tools, Metacase, Jetbrains MPS e outros métodos são alternativas. Segundo alguns defensores de MDA nem mesmo este padrão depende de UML -o que eu não concordo.

E sendo UML uma GPL é necessário alterar o código gerado para implementar o que nao foi capturado na linguagem de modelagem. Como isso é suportado pelo MDA sem inviabilizar o processo? Esse é o problema que LOP pretende resolver?

Taz wrote:

rodrigoy wrote:

Sem exageros. Um caso de uso é uma história. Caso de uso é um conceito, assim, não considero o termo caso de uso nem o diagrama e nem a narrativa.

Bastante política sua visão sobre Casos de Usos, mas para mim: casos de usos != estórias. Caso de Uso é o que UML define como Caso de Uso, com toda sobrecarga de seus templates e com toda sua buracracia. Casos de Usos possuem homenzinhos, bolinhazinhas, setinhas, fluxo principal, fluxos alternativos, etc, etc.

Mantenho a posição. Casos de Usos (de acordo com a definição da UML) geram muita confusão e desperdício de recursos em projetos. Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML. Por exemplo: ora um Diagrama de Estados aqui, ora um Diagrama de Atividades ali, de acordo com o requisito sendo definido.

Quando você fala "Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML."... eu concordo com isso.
Não gosto muito de fazer casos de uso porque tenho a mania de colocar muitos casos de uso no sistema. Não sei se é um problema de iniciante, mas tenho que corrigir isso urgentemente.

Não sou engenheiro (ainda), mas eu usaria casos de uso quando o funcionamento da empresa estivesse complicado de entender. Seria correto fazer isso?

ViniGodoy wrote: Ah sim, e elas ainda usam a documentação como uma forma de dizer que tem "padrões de qualidade". Como se papel garantisse algum tipo de qualidade.

Concordo em grau, número e gênero. É similiar ao diploma: alguns não tem e dão um cacet* em quem tem.

pcalcado wrote: Assim como ninuém nunca precisa nsultar um diagrama de classes do Hibernate para ver como ele funciona (para coisas simples uma página de wiki te basta, para coisas complexas a documentação é textual e baseada em exemplos) não é preciso mantêr diagramas em UML.

Mesmo quando a UML deixa as coisas mais claras entre os desenvolvedores?

Estou gostando da discussão... aprendo bastante com grandes nomes aqui do Forum.
Abraço.

This message was edited 1 time. Last update was at 13/05/2008 15:47:50

dedejava wrote:

Não sou engenheiro (ainda), mas eu usaria casos de uso quando o funcionamento da empresa estivesse complicado de entender. Seria correto fazer isso?

Depende. O que é "complicado"?

O último projeto que participei com Casos de Usos era para refazer o sistema das lojas de uma Telco. Isso é complicado? Depois que uma 3 letrinhas foi expulsa do projeto, o pessoal ficou 2 meses tentando "fechar" os 54 Casos de Usos (idéia maldita de outro fornecedor de 3 letrinhas) com os usuários e tivemos 1 semana para fazer o protótipo com o agravante os Casos de Usos estavam muito mal escritos e só criavam "bate-cabeça". Isso é complicado!!!

A saída foi criar um mapa de navegação (Diagrama de Estados) do projeto para que a equipe pudesse captar a essência do projeto e detectar pontos de sobreposição e oportunidades de reuso.

Ahhh, e CASOS DE USOS SÃO BEM DIFERENTES DE ESTÓRIAS.