Como fazer um projeto bem organizado e limpo?

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.

JavaEvangelist Membro desde: 26/02/2007 09:31:49 Mensagens: 329 Offline

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

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3161 Offline

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

Pilantra wrote:
Bom, tempo eu tenho de sobra (1) hehe, mas nesse tempo de análise (2), eu queria usar diagramas e fazer uma documentação bem limpa (3) e que seja de fácil entendimento.

1) Se você não quer que seu sistema atrase, NUNCA pense isso (vide Lei de Parkinson)

2) Confie em mim: não divida seu projeto em fases.

3) 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.

Pilantra wrote: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.

s4nchez wrote:
2) Confie em mim: não divida seu projeto em fases.

Como assim?

s4nchez wrote:
3) Que tal você fazer software ao invés de desenhos e textos?

Ta dizendo para sair programando sem projetar?

s4nchez wrote:Seja o que for eu te garanto que incluir uma fase de análise não vai te salvar por maus bocados...

Você sabe o que esta dizendo?

JavaTeenager Membro desde: 22/05/2005 15:24:41 Mensagens: 150 Offline

s4nchez wrote:
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

nbluis wrote:Agora não entendi.

s4nchez wrote:
2) Confie em mim: não divida seu projeto em fases.

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...

nbluis wrote:

s4nchez wrote:
3) Que tal você fazer software ao invés de desenhos e textos?

Ta dizendo para sair programando sem projetar?

Não, to sugerindo projetar com código!

s4nchez wrote:

nbluis wrote:Agora não entendi.

s4nchez wrote:
2) Confie em mim: não divida seu projeto em fases.

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...

Tu tem que ter um objetivo para poder ter o que desenvolver.
A análise proporciona isso.
Deixando aspectos mais técnicos e específicos para a fase de implementação.
Acho que vc esta misturando as coisas
A análise cuida da análise, o desenvolvimento cuida do desenvolvimento.

s4nchez wrote:

nbluis wrote:

s4nchez wrote:
3) Que tal você fazer software ao invés de desenhos e textos?

Ta dizendo para sair programando sem projetar?

Não, to sugerindo projetar com código!

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?

geraldobarboza wrote:

s4nchez wrote:
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.

Debugger Membro desde: 23/06/2006 08:53:26 Mensagens: 72 Offline

nbluis wrote:

s4nchez wrote:

nbluis wrote:

s4nchez wrote:
3) Que tal você fazer software ao invés de desenhos e textos?

Ta dizendo para sair programando sem projetar?

Não, to sugerindo projetar com código!

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;

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"

Notícias, artigos e o maior fórum brasileiro sobre Java