Arquivo Discussoes de Programacao e Tecnologia 
Olá pessoal.
Fui designado a fazer um sistema de ponto biométrico aqui na empresa onde trabalho. Eu tenho uma semana para análise e 20 dias para desenvolvimento. Bom, tempo eu tenho de sobra hehe, mas nesse tempo de análise, eu queria usar diagramas e fazer uma documentação bem limpa e que seja de fácil entendimento.
Quais são os primeiros passos? O que eu devo fazer em primeiro lugar? E depois como eu devo continuar antes de por a mão nos códigos?
Obrigado.
Pilantra,
Como seu tempo é curto, eu sugiro que faça os diagramas de Casos de Uso, e os de classe.
E outra coisa importante, deixe bem definidos os requisitos e as regras de negócio.
Concordo com o fsquadro, utilizando prototipagem tambem, pelo menos na interface (Se possuir uma interface de software), bem mais procure ler sobre UML, agora o Caso de Uso e Classes é fundamental para um sistema bem modelado.
Abraços
tempo vc tem de sobra???
vc tem certeza do que esta falando?
Olha, não quero te desapontar.
Mas tu não vai aprender isso em um dia para aplicar em uma semana.
Comece por onde o pessoal falou ai, mas tem anos pela frente para você poder dizer que está realmente limpo e organizado.
Principalmente, não desista.
Desculpe,
apesar de não ser o tema… tem relação.
Você já tem definido como será realizado a avaliação biométrica?
Você está com um scanner de digitais por exemplo? você sabe se serão capturadas imagens ou números? você tem idéia de como armazenar esta informação para não vazar posteriormente?
Se for imagem, você sabe como compará-las?
Se você souber e puder, post aqui. Caso contrário… meu amigo você está em uma fria.
fw
Se você não quer que seu sistema atrase, NUNCA pense isso (vide Lei de Parkinson)
Confie em mim: não divida seu projeto em fases.
Que tal você fazer software ao invés de desenhos e textos?
Olá,
Sim, eu já fiz um projeto piloto, a base está praticamente pronta, agora é só fazer o sistema. Praticamente a análise já está feita hehe, eu acho que termino em duas semanas o que eu tenho pra fazer, mas eu fiquei 2 meses no projeto piloto. Mas, eu fiz sem análise nenhuma, fui testando e tentando e por ae vaí. Mas queria fazer diferente dessa vez, acho que com análise qualquer projeto fica mais agradável de trabalhar.
Mas valeu, já conhecia os diagramas, mas queria sabern quais os primeiros passos antes de por os diagramas em prática.
Olá,Sim, eu já fiz um projeto piloto, a base está praticamente pronta, agora é só fazer o sistema. Praticamente a análise já está feita hehe, eu acho que termino em duas semanas o que eu tenho pra fazer, mas eu fiquei 2 meses no projeto piloto. Mas, eu fiz sem análise nenhuma, fui testando e tentando e por ae vaí. Mas queria fazer diferente dessa vez, acho que com análise qualquer projeto fica mais agradável de trabalhar.
Mas valeu, já conhecia os diagramas, mas queria sabern quais os primeiros passos antes de por os diagramas em prática.
O que estava desagradável no projeto piloto? Seja o que for eu te garanto que incluir uma fase de análise não vai te salvar por maus bocados…
Agora não entendi.
Como assim?
Ta dizendo para sair programando sem projetar?
Você sabe o que esta dizendo?
3) Que tal você fazer software ao invés de desenhos e textos?
Essa é uma caracteristica de métodos ageis nao é?
tipo XP, scrum entre outros…
mas diga… nessas metodologias não são desenhado nada?
[]´s
Geraldo
Agora não entendi.Como assim?
Ta dizendo para sair programando sem projetar?
Não, to sugerindo projetar com código! 
Agora não entendi.Como assim?
Dividindo em fases você vai ser tentado a fazer TODA a análise e depois TODA a programação. E quando você estiver na programação e ver que muita coisa da análise previsará ser revista você vai se estressar…
Ta dizendo para sair programando sem projetar?
Não, to sugerindo projetar com código! ;)</blockquote> Esse é o maior erro que se pode cometer. Assim tu estarás projetando com uma mente de programador, e não de alguém que vai utilizar o que você faz. Sem esquecer que tu vai reescrever todo o seu código umas 40 vezes por causa disso;Será que só eu discordo disso?
Pelo amor de deus, pra que existem metodologias de desenvolvimento?
Para que Analistas, Arquitetos, Gerentes de Projeto, DBA’s, se tu vai fazer tudo ao mesmo tempo que desenvolve? :lol:
3) Que tal você fazer software ao invés de desenhos e textos?Essa é uma caracteristica de métodos ageis nao é?
tipo XP, scrum entre outros…mas diga… nessas metodologias não são desenhado nada?
[]´s
Geraldo
Você pode desenhar o que quiser, só que a prioridade é software funcionando, e não sua documentação. Por isso que a especificação em desenvolvimento ágil geralmente é representada por testes automatizados.
Ta dizendo para sair programando sem projetar?
Não, to sugerindo projetar com código! ;)</blockquote> Esse é o maior erro que se pode cometer. Assim tu estarás projetando com uma mente de programador, e não de alguém que vai utilizar o que você faz. Sem esquecer que tu vai reescrever todo o seu código umas 40 vezes por causa disso; </blockquote>Espera aí, qual é exatamente o problema de “projetar com uma mente de programador” ?
A minha definição de programador esta muito além de “macaco evoluído que recebe um diagrama e digita código”
3) Que tal você fazer software ao invés de desenhos e textos?Essa é uma caracteristica de métodos ageis nao é?
tipo XP, scrum entre outros…mas diga… nessas metodologias não são desenhado nada?
[]´s
GeraldoVocê pode desenhar o que quiser, só que a prioridade é software funcionando, e não sua documentação. Por isso que a especificação em desenvolvimento ágil geralmente é representada por testes automatizados.
hum… assisti uma palestra sobre métodos ageis…
Achei bacana, e sem falar que cada vez mais o SCRUM vem sendo recomendado…
valew
[]´s
Geraldo
Espera aí, qual é exatamente o problema de “projetar com uma mente de programador” ?
A minha definição de programador esta muito além de “macaco evoluído que recebe um diagrama e digita código”
Pelo mesmo motivo que hoje existam equipes de testes desacopladas do ambiente de desenvolvimento.
Alguém que projeta fora do desenvolvimento, consegue realmente entender a finalidade do software quando a sua necessidade e principalmente usabilidade do mesmo.
Já se tu larga isso nas mãos de um programador muitas vezes ele vai estar mais preocupado com qual a consulta vai ser rodada para pegar os dados, como ele vai fazer o framework entender o que ele quer ou ainda como manter a performance de tudo isso, e o mais importante que é o cliente fica de lado.
Exatamente por isso que eu falei.
A análise cuida da análise, o desenvolvimento cuida do desenvolvimento.
Não que programadores sejam incapacitados, mas sim é uma questão de visão que cada um deve ter a cada fase.
Nunca ouviram falar em projetar o mundo perfeito?
Não sou eu que estou misturando duas coisas. É você que está tentando separar as duas coisas: análise faz parte do desenvolvimento, e como tal não deveria ser tratada como algo distinto, que deve ser resolvida apenas no início do projeto e apenas pelos analistas
Por isso que eu acredito que desenvolvedor != programador. E também não me iludo que analista = usuário
Será que só eu discordo disso?
Pelo amor de deus, pra que existem metodologias de desenvolvimento?
Para que Analistas, Arquitetos, Gerentes de Projeto, DBA’s, se tu vai fazer tudo ao mesmo tempo que desenvolve? :lol:
bem, eu prefiro uma abordagem Ágil, equipe de testes acopladas com o ambiente de desenvolvimento.
Não gosto de “Análise cuida da análise, desenvolvimento cuida do desenvolvimento”, prefiro “O time decide como vamos fazer x e y”.
Aliás, não gosto de todos estes nomes que usam para rotular programadores/desenvolvedores “Analista”, “Arquiteto”… sem contar as variações “Junior”, “Pleno” e “Senior”. Claro que alguns tem maiores conhecimentos em determinadas áreas, mas não concordo com uma divisão rígida.
Eu nunca ouvi falar em “projetar o mundo perfeito” e uma busca no google não me ajudou.
Não sou eu que estou misturando duas coisas. É você que está tentando separar as duas coisas: análise faz parte do desenvolvimento, e como tal não deveria ser tratada como algo distinto, que deve ser resolvida apenas no início do projeto e apenas pelos analistas
Aqui concordo contigo.
Metodologia não é só desenvolvimento em cascata, sabia? E estes papéis devem existir porque cada um é especialista numa área, e não porque o trabalho de um começa quando termina o de outro…
Eu não compraria isso. :lol:
Sei que não é exatamente isso que querem dizer, mas é isso que esta transparecendo nesta thread.
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.