Forma de projetar...

[Lutzmind]

qual a forma q vocês fazem seus projetos? coloca tudo no papel ou senao coloca a mao na massa de uma vez???

ou senao utiliza alguma tecnica como UML?

e interessantes discutirmos isso

eu geralmente faco um modelo simples no papel e depois faco um prototipo.. depois elabora mais o modelo e faco outro prototipo..

falou

[Apocalypse.RIPnet]

Eu primeiramente começo colocando as idéias no papel.

Despois eu faço a lógica bem limitada, após isso eu à analizo e finalmente faço a lógica "original", mas eu faço o projeto por partes (eu não faço tudo como um conjunto, pode-se dizer q cada função q eu faço tem um papel próprio, uma atenção própria, ai sim depois q cada parte está pronta eu junto elas em um único projeto), depois passo para a linguagem q vou utilizar, após eu corrijo possíveis bugs e quando tudo fica tinindo eu começo aprimorar o meu projeto.

Só!!!!!!

O pessoal do forum, postem ai as suas técnicas!!!!

falou!!

Apocalypse.RIPnet

[tabgal]

Depende muito do programa...

Claro, se for algo simples, só pra testar nem precisa de nada.

Acho que primeiro se deve pensar no que o programa precisa, o que ele faz, pode fazer no futuro ou não faz, e por aí vai.

Depois eu penso nas estruturas de dados do programa. Parece que isso tem me ajudado muito. (Assim, ver o que está em jogo e como as coisas se relacionam).

De preferência quebrar o problema através de várias classes (e marcar bem qual a responsabilidade de cada uma), daí você não vai ter pesadelos

E depois é mão na massa, claro

[peterson.kenji]

eu to refazendo um antigo de tempo de escola, to fazendo por osmose, o que da na kabeça eu coloco, vamos que o sai no final...

mas quando a situação é séria tem que colocar no papel antes de tudo e planejar com cautela senão....

::valeu::

[Clemente Silva]

Eu prefiro trabalhar junto com um analista de sistemas, o qual faz a "pior parte": reuniões e entrevistas com usuários, documentação em geral (diagramas, modelos, etc...) daí depois de tudo pronto é só "pôr a mão na massa". Mas isso só quando o projeto é grande (monstruoso mesmo) e que justifique esse custo à mais.

Mas muitas vezes isso não é possível, princialmente por causa do fator tempo: o cliente quer tudo pronto "pra ontem", tem uns que nem te deixam trabalhar de tanto ficar telefonando pra cobrar resultados.

Então, além da falta de tempo tem também a pressão: aí o jeito é já colocar a mão na massa direto e qualquer caca que sair, tá bom. Depois o cliente burro é que pague pelo retrabalho, remendos, patchs, atualizações, service packs, etc. (como ele quiser chamar).

Tem uns que vem com uma cópia "daquele programinha em DOS que funcionava muito bem mas agora quer que seja feito pra ambiente Windows", aí tem que ao mesmo aprender como funciona aquela porcaria de programa que o cliente trouxe usando a mão esquerda, e codificar o novo programa usando a mão direita.

Tem vários casos, cada um acontece de uma maneira, não tem um padrão.

Mas geralmente, quem leva a pior sou eu.

[Tranzorb]

Saudações pessoal,

Realmente esse é um tópico bastante interessante!

No caso dos projetos menores, sejam de hardware ou software, pulo a parte dos variados diagramas de fluxo (bem, não falo dos diagramas elétricos, fundamentais em 99% das situações).

Certa vez estive elaborando um hardware simples para um sistema de tubulações de gás residencial para uma companhia de gás aqui em São Paulo. Mesmo diante da simplicidade, procurei conhecer ao máximo o sistema completo: com que tipo de circuitos ele iria interagir, condições do ambiente em que ele seria usado (se eventualmente haveria vazamentos de gás), o tamanho do kit, para que não se tornasse um "fardo" a ser carregado pelo operador do equipamento e várias outras questões, técnicas ou nem tanto, mas muito importantes.

Coloco todas essas premissas no papel, as repasso exaustivamente durante a elaboração de tudo, com extrema atenção, e o projeto flui tranqüilamente. Procuro correr na medida do possível porque, infelizmente, o tempo é sempre muito reduzido, como mencionou Clemente Silva. Mas essas medidas, ainda que meio cansativas, poupam bastante tempo, evitando as usuais presepadas que acometem projetistas de pouca experiênica, como eu, ou apressados, também como eu.

Há estudos que indicam uma redução de quase 90% no tempo de desenvolvimento em projetos que fazem uso de recursos como o fluxograma. Após conhecer esses resultados, estive mudando meu conceito sobre esses diagramas, os quais bastante gente experiente não usa. Um fluxograma bem feito permite que a maior parte, ou até a totalidade de bugs no programa sejam corrigidos antes de digitar a primeira linha de código. Vou me esforçar bastante para me familiarizar com esse método :-).

Procuro sempre fazer tudo o mais modular possível. Isso é o domínio da complexidade, essa é a beleza da programação, de organizar e tornar inteligíveis uns verdadeiros monstros.

Há pouco tempo atrás tive uma oportunidade extremamente interessante que escapou por motivos inusitados.

Uma empresa produtora de animações desejava automatizar uma espécie de robô que posiciona uma câmera das mais variadas formas. O robô atualmente utiliza motores DC para cada eixo (9 ao todo), que necessitam ser controlados manual e individualmente através de uma simples chave abre-fecha e um potenciômetro em série. O cara queria controlar todos ao mesmo tempo, via software.

Nós estávamos planejando ligar todos os motores numa rede RS-485 com o microcomputador, numa arquitetura de hardware que permitia até 7 motores adicionais, para futuras expansões, e uma arquitetura de software que disponibilizava funções para que qualquer programa pudesse enviar comandos aos motores. Entre outros detalhes, o projeto apresentava traços de grande modularidade. Estava super-simples de compreendê-lo, e o que nos assustou de início logo tornou-se algo bem familiar (um tipo de rede industrial confinada dentro daquele monstrão). Pena que o projeto não rolou...

OK Pessoal? Lutzmind, grande iniciativa, estamos trocando experiências.

Tranzorb.

[Skred]

ola!

no meu caso e parecido com o de todos.

tento colocar algumas ideias no papel, formular algumas telinhas (esboço)

e depois é mao na massa.

abraço!

[.SubZero.]

Todo mundo diz que o melhor é fazer um esboço no papel pensar na lógica e depois colocar a mão na massa.

Pra falar a verdade eu prefiro ir direto ao assunto, o que ocasiona alguns bugs que consigo corrigir na mesma hora isso porque tudo que crio eu testo pra ver se vai dar mesmo certo, como um dos programas que estou fazendo como fazer o computador falar através do agente do windows, comecei muito devagar depois fui aprimorando e ele virou um tagarela, e também descobri umas funções legais para interagir com o cliente.

[PiruaLLL]

opa, belo topico !!!

como gosto das coisas bem organizadas (estruturardas), faço da seguinte forma, primeiro, vejo o que o o software vai fazer, depois divido em partes, (tem gente que prefere fazer o "grosso" primeiro depois ir incrementando) não sei pensar em um todo, jogo no papel (portugol), depois da primeira parte pronta vou pra segunda, terceira e assim vai, assim fica mais fácil, entre uma parte e outra vão surgindo ideias !