• Comunicados

    • Gabriel Torres

      Seja um moderador do Clube do Hardware!   13-02-2016

      Prezados membros do Clube do Hardware,

      Está aberto o processo de seleção de novos moderadores para diversos setores ou áreas do Clube do Hardware. Os requisitos são:
        Pelo menos 500 posts e um ano de cadastro; Boa frequência de participação; Ser respeitoso, cordial e educado com os demais membros; Ter bom nível de português; Ter razoável conhecimento da área em que pretende atuar; Saber trabalhar em equipe (com os moderadores, coordenadores e administradores).   Os interessados deverão enviar uma mensagem privada para o usuário @Equipe Clube do Hardware com o título "Candidato a moderador". A mensagem deverá conter respostas ao formulário abaixo:    Qual o seu nome completo? Qual sua data de nascimento? Qual sua formação/profissão? Já atuou como moderador em algo outro fórum, se sim, qual? De forma sucinta, explique o porquê de querer ser moderador do fórum e conte-nos um pouco sobre você.   OBS: Não se trata de função remunerada. Todos que fazem parte do staff são voluntários.
    • DiF

      Poste seus códigos corretamente!   21-05-2016

      Prezados membros do Fórum do Clube do Hardware, O Fórum oferece um recurso chamado CODE, onde o ícone no painel do editor é  <>     O uso deste recurso é  imprescindível para uma melhor leitura, manter a organização, diferenciar de texto comum e principalmente evitar que os compiladores e IDEs acusem erro ao colar um código copiado daqui. Portanto convido-lhes para ler as instruções de como usar este recurso CODE neste tópico:  
Entre para seguir isso  
Seguidores 0
Lutzmind

Forma de projetar...

9 posts neste tópico

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

:bandeira:

Compartilhar este post


Link para o post
Compartilhar em outros sites

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ó!!!!!! :D

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

falou!!

Apocalypse.RIPnet B)

Compartilhar este post


Link para o post
Compartilhar em outros sites

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 :blink:

E depois é mão na massa, claro :bandeira::muro::-BEER:cry:

Compartilhar este post


Link para o post
Compartilhar em outros sites

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

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

::valeu:: :joia:

Compartilhar este post


Link para o post
Compartilhar em outros sites

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.

:cry::chicote:

Compartilhar este post


Link para o post
Compartilhar em outros sites

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.

Compartilhar este post


Link para o post
Compartilhar em outros sites

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!

Compartilhar este post


Link para o post
Compartilhar em outros sites

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

Compartilhar este post


Link para o post
Compartilhar em outros sites

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 !

Compartilhar este post


Link para o post
Compartilhar em outros sites

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!


Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.


Entrar agora
Entre para seguir isso  
Seguidores 0