Importância do UML

Sim.

Nao

Sim, Algumas fases do UML utilizo, mais não avanço muito a fundo…
algumas tecnicas de JAD também mais bem pouco.

Priuli:

Sim, Algumas fases do UML utilizo, mais não avanço muito a fundo…
algumas tecnicas de JAD também mais bem pouco.

Opa… que diagramas da UML você usa?

No máximo pra comunicar com não-tecnicos, mas estes geralmente tb não sabem UML, então fica uma situação que vc usando um artefato definido pela UML, ou um retângulo improvisado, pra descrever um objeto por exemplo, não faz qq diferença.

Não conheço nada melhor que um diagrama de sequência para esclarecer a colaboração entre objeto num cenário complexo. Não há como visualizar essa dinâmica no código fonte.

Diagramas de classes deixam claro aspectos como herança, cardinalidade e niveis de abstração.

A questão é não perder tempo com ferramentas complexas. Os diagramas são úteis. O problema é que gastasse muito tempo montando-os com ferramentas específicas, quando na maioria dos casos o mais adequando e papel e lápis ou um quadro branco.

Abraços

Aqui, como temos uma fase de levantamento de requisitos completa e projeto quase completa (sendo implementada ainda), usamos Diagramas de Caso de Uso, Atividades, Sequência, Classes, ER, Componentes, etc., além, é claro, de um protótipo navegável.
Usamos ferramentas para desenvolver estes diagramas, pois o projeto deve ser versionado, e pode ser desenvolvido por diversas pessoas ao mesmo tempo…

Mas estes são apenas para documentar a parte técnica, servindo como base para o técnico que assumirá a implementação, e não para comunicar algo ao cliente…

rdgms:

Priuli:

Sim, Algumas fases do UML utilizo, mais não avanço muito a fundo…
algumas tecnicas de JAD também mais bem pouco.

Opa… que diagramas da UML você usa?

diagrama de classes,diagrama de sequência.

eltonads:

Aqui, como temos uma fase de levantamento de requisitos completa e projeto quase completa (sendo implementada ainda), usamos Diagramas de Caso de Uso, Atividades, Sequência, Classes, ER, Componentes, etc., além, é claro, de um protótipo navegável.
Usamos ferramentas para desenvolver estes diagramas, pois o projeto deve ser versionado, e pode ser desenvolvido por diversas pessoas ao mesmo tempo…

Mas estes são apenas para documentar a parte técnica, servindo como base para o técnico que assumirá a implementação, e não para comunicar algo ao cliente…

Bom ai ja não concordo muito… quando você fala desses diagramas você parece estar dividindo Analista de Programador…
eu nunca vi um levantamento de requisitos estar totalmente completo e certo de primeira…
a coisa deve ser feita com iterações… o sistema e a “documentação” deveriam crescer junto ao longo do tempo… mas se você vai desenvolvendo por ciclos qual o sentido da documentação no final?

Sim, mas num processo mais burocrático, estilo cascata, é assim mesmo…
Há muitas coisas que não concordo também… Mas é o processo da empresa e o estilo de trabalho que ela vem usando há anos…
E sim, temos papéis separados para Analista e Implementador… Na verdade, existem diversos papéis; Analista de Requisitos, Analista de Negócio, Arquiteto de Software (que faz o projeto e a base da arquitetura… O cara que pensa no software com uma visão mais técnica. Este é o meu papel atualmente), Implementadores, Designers de interface, etc etc… Com uma equipe tão grande e tão diversa, uma estrutura de comunicação baseada em documentos acaba se fazendo necessária.

Mas concordo com você: nunca vi um levantamento de requisitos estar completamente certo de primeira… Nunca vi, e provavelmente nunca vou ver. Não existe isso.