Vixe, esse assunto dá briga ein!! Eu particularmente, o quanto menos perder tempo melhor. Mas sempre encontro problemas no futuro que se eu parar pra pensar e tivesse feito análise, eu não teria esse tipo de problema. Coisa de uma semana. Então como esse projeto é muito importante, preciso fazer essa análise pra não ter dor de cabeça no futuro.
Já estou fazendo os UseCase, depois eu vou fazer das classes. Acho que entendi o processo hehe.
Valeu pelas opiniões.
Abraços.
Depende.
Eu concordo em partes.
Se o teu software eh pequeno, simples e não vai te causar dor de cabeça com o cliente futuramente, da pra fazer ele sem a analise. Com certeza vai ter codigo pra ser refeito e rotinas pra serem revisadas, mas o tempo perdido com isso vai ser menor do que o tempo de analise.
Mas se for projeto grande, e o cara sair pensando no software sem uma base e uma documentação feita na analise antes, aí vai ser um problema. Falo isso por que ja participei de um projeto que nem era tão grande, não teve analise e o tempo de entrega era curto. Resultado? Ficou mal feito.
E se o projeto nao tiver documentação(diagramas, requisitos…), e depois que tiver pronto, entra um programador novo pra realizar alterações ou melhorias no software. O cara vai ficar perdido, porque nao conhece regras de negocio, estrutura e etc…
A melhor metodologia acho que eh o desenvolvimento com iterações. Assim voce projeta partes pequenas de cada vez, e consegue captar problemas mais facilmente.
Easy tigers.
O RUP, por exemplo, diz que você tem fases. Tem fase onde você faz mais análise, outra onde você programa mais, outra onde você testa mais. Em todas as fases você analisa, implementa e testa, em todas as fases as iterações produzem código funcionando. Se você não faz isso não faz RUP.
Trabalhar com fases (de análise, de projto, de implementação, de testes) é modelo waterfall.
Metodologias ágeis e técnicas de Model-Driven Development (como Domain-Driven Design e MDA) abrem mão de modelos em coisas como UML porque elas na maioria das vezes não acrescentam qualquer valor ao produto. As ferramentas hoje (Java, por exemplo) possuem nível alto o suficiente para uma modelagem executável, tão sonhada pelos pais da UML e seus antecessores. Recomendo uma leitura sobre Agile Modeling e, se você usa ou gosta de RUP, saiba que o criador desta abordagem foi cotnratado ano passado pela IBM para alterar a cara do RUP, que sempre foi um processo ágil e iterativo mas foi destruído por pessoas que trabalham com waterfall.
Exceto pelo modelo de fábrica (que nunca apresentou em toda a sua história bons resultados, pelo contrário) não há separação entre testadores e desenvolvedores. Os processos geralmente pedem que testadores trabalhem lado a lado com testadores o tempo todo, o trabalho de um complementa o do outro no dia a dia.
MDA/MDD abrir mão de modelos ? Hmmm. Acho que não.
AFAIK, a visão do AMDD é a de se trabalhar com modelos “bons o suficiente” - e nisto estou 100% de acordo, pois colocar cada método e atributo, bem como especificar cada seqüência de chamada é perda de tempo - afinal, se vc. tem 100% da informação do sistema no modelo, o código é redundante, certo ?
Por outro lado, modelos que sejam mais do que uns rabiscos em guardanapos tornam-se indispensáveis se vc. utilizar o MDA para aquilo que foi concebido, ou seja, fazer a geração automatizada de artefatos (código sendo apenas um deles) a partir do modelo.
Para quem ainda não viu isto funcionando na prática, sugiro uma olhada atenta no AndroMDA. Os modelos que servem de entrada NÃO são modelos detalhados - e nem poderiam ser, pois isto eliminaria a principal vantagem desta técnica, que é permitir que os PSMs (Platform-Specific Models) possam ter total liberade para “interpretar” o modelo de acordo no contexto da plataforma final, o que está longe de se ser o caso se sua modelagem for feita usando uma linguagem como Java.
Você confundiu “modelos” com “diagramas”.
Releia meu post:
Ficou meio ambiguo mesmo mas o ponto é que UML!=Modelo.
O grande problema do MDA é que simplesmente UML não foi criada para isso. Dê uma olhada nos materiais de Stephen J. Mellor, grande força por trás da Executable UML e que, como dito em Porto Alegre esse ano, já desistiu.
Fiquei curioso. Pq. vc. acha que eu tenha confundido ?
Ok, admito não gastar muito tempo lendo o que se escreve antes de responder, mas reli o que vc. escreveu e não consegui chegar ao ponto a partir do que estava lá. Se este é o ponto, ok, estou de acordo, até por ser uma tautologia. É como dizer que “Português” != “Dom Casmurro”.
O meu ponto é que MDA/MDD != UML. O fato de o Mellor ter desistido do Executable UML é até uma boa notícia para aqueles que usam (como eu) ou querem usar o MDA, já que ficam livres de dogmas tais como o próprio uso exclusivo de UML para esta prática.
Minha opinião é que, embora o UML.exe seja uma utopia, a pressão constante sobre os times de desenvolvimento para entregarem cada vez mais funcionalidades em prazos cada vez menores não deixa outra escolha do que buscar formas de aumentar a produtividade dos desenvolvedores.
A utilização pragmática de MDA, do qual o AndroMDA é um dos melhores exemplos, é, quando empregada adequadamente, um dos melhores mecanismos disponíveis para melhorar esta produtividade, especialmente quando os modelos são gerados em parceria com o analista de negócios
1)Você deve se organizar e ser bem cuidadoso pois quando alguem te pedir você pode dar na hora para você ter uma imagem de transparência;
2)seja transparente;
3)seja honesto;
4)de ideias interessantes para que as pessoas adquiram o seu trabalho;,
5) seja você mesmo;
6)não seja ignorante;
7)seja divertido ou tenha a aparencia de seu cliente;
8) sempre motre seus projetos nunca esconda-os;
9)de sempre boas ideias;
10) sempre me mande as novidades,kkkk, blz
xau
kkkkkkkkkkkkkkkkk, a aparência pode complicar! hehehehe
no meu ponto de vista você deve conhecê-lo bem antes de estruturá-lo, bem como ele esteja acessível por todos.
isto será importante principalmente no início do projeto, bem como gerente e cliente(dono) estar ciente de como a estória foi combinada. faça eles participarem também para que você tenha feedback.
você pode utilizar uma wiki com um fórum agregado. procure utilizar algumas dicas que o pessoal passou aos poucos, ou então tente encarar o desafio em um projeto piloto.