Programação (I) - Planejamento e Otimização

Este é o primeiro de uma série de artigos sobre programação. Não se trata de um manual e nem de conhecimento sobre uma linguagem específica. São tópicos que podem contribuir para uma melhor qualidade dos programas, de uma forma geral. Espero que a série venha a ajudar de alguma forma, em especial aos novatos na área.

[ Hits: 26.184 ]

Por: Edvaldo Silva de Almeida Júnior em 11/04/2008 | Blog: http://emeraldframework.net


Faça uma especificação do seu programa



Faça uma especificação completa e detalhada do seu programa antes de começar a codificar. Isso pode parecer tedioso quando comparado à emoção de ficar horas na frente do computador digitando como um lunático, mas vai ajudar em vários aspectos.

Antigamente tínhamos as especificações funcionais escritas, ou seja, um grosso calhamaço de papel que resultava das entrevistas de análise e que ninguém lia mesmo e ia fazendo as coisas como dava na telha.

Tínhamos também os algoritmos, que ainda são bastante úteis para especificar pequenos trechos de código.

Mas se você quer realmente fazer uma especificação boa e prática para seus programas, sugiro que estude UML. Com UML você pode criar uma especificação totalmente visual para o seu programa, que será muito mais fácil de consultar do que as antigas especificações escritas. Afinal, uma imagem vale por mil palavras, como já foi dito.

Há várias razões para especificar um sistema detalhadamente:

a) Com uma boa especificação você não fica perdido, não fica em dúvida e nem tem de consultar o cliente repetidas vezes durante o processo de desenvolvimentos e teste;

b) Com uma boa especificação você sempre sabe onde chegar e como chegar lá;

c) Com uma boa especificação você tem um mecanismo para avaliar prazos e custos. Algumas métricas como a dos Pontos de Função baseiam-se na especificação do sistema;

d) Com uma boa especificação você terá uma excelente ferramenta para a manutenção futura, como veremos adiante;

e) Com uma boa especificação você tem um mecanismo para se proteger daquele cliente que, depois de combinar com você o preço do programa e o prazo de entrega, fica pedindo para acrescentar uma coisinha aqui e outra ali no sistema. Esse tipo de cliente quer sempre mais, mas quando você fala em extensão do prazo ou em aumento dos custos ele reclama, dizendo que só pediu umas besteirinhas... Prepare a especificação e mostre ao cliente, fazendo com que ele concorde em ater-se a ela e deixando claro que o software será entregue daquele jeito e que se alguma necessidade nova surgir será implementada na versão seguinte. Sugiro que bote isso no papel, mediante um contrato formal. Os clientes sempre dão um jeito de bagunçar tudo, se deixarmos.

Na fase inicial da análise, aquela de conversar com os interessados no programa para saber o que eles desejam, dê especial atenção aos DIAGRAMAS DE CASOS DE USO. São uns diagramas UML bonitinhos, com uma porção de bonequinhos para lá e para cá, representando as formas de interação dos usuários com o seu programa. Podem parecer meio infantis no princípio, mas serão um grande apoio durante o processo de desenvolvimento.

Mais adiante, concentre-se no DIAGRAMA DE CLASSES se estiver pensando em Programação Orientada a Objetos (POO) ou no DIAGRAMA DE FLUXO DE DADOS e DIAGRAMA DE ENTIDADES/RELACIONAMENTOS se estiver usando Programação Estruturada.

Página anterior     Próxima página

Páginas do artigo
   1. O porquê desta série de artigos
   2. A importância do planejamento
   3. Saiba onde quer chegar
   4. Faça uma especificação do seu programa
   5. Planeje seu programa pensando em várias coisas
   6. Pesquise sempre a melhor forma de fazer
Outros artigos deste autor

Afinal, qual a melhor distribuição?

Livre não precisa ser gratuito

Programação (II) - Modularização

KDE em um PC "primitivo"

Programação (III) - Programação Orientada a Objetos (POO)

Leitura recomendada

Mini-howto de configuração e utilização do aptitude no Debian

Baixando as fotos da sua câmera digital

Cube 2 - Sauerbraten: Jogo de tiro em primeira pessoa

Sorteio de Livros - Resultado da Quinta Semana

Analogia: X-Window como um sistema operacional

  
Comentários
[1] Comentário enviado por eversonamancio em 11/04/2008 - 10:36h

Edvaldo,

Seu artigo está ótimo.

Pretendo ingressar nessa área, e essas informações me foram preciosas.

[2] Comentário enviado por kabalido em 11/04/2008 - 11:20h

Muito bom cara. Parabéns;

[3] Comentário enviado por foguinho.peruca em 11/04/2008 - 14:24h

Olá!

Mto bom artigo. aborda aspectos importantissimos na área de engª de sw...

[4] Comentário enviado por ssdeassis em 11/04/2008 - 17:05h

muito bom artigo, vou ler todos os outros da continuação

[5] Comentário enviado por elionw3 em 11/04/2008 - 17:58h

Otimo, em 15 minutos de leitura conseguiste resumir o q os professores tentam nos ensinar por 5 anos na facul, heehauhuh

principalmente em "Engenharia de Software", o problema é q pelo fato de ser uma materia muito teorica o pessoal não da credito, e depois acaba "se quebrando" pra consertar os furos, q poderiam ser evitados no Planejamento :)

Cumprimentos,
e...
quando sai "Programacao (II)" ?

[]'s

[6] Comentário enviado por raci0nal em 14/04/2008 - 00:28h

Muito bom o artigo e aliás muito bem estruturado.
Só queria deixar registrado, que por causa de vários problemas citados no artigo é que surgiram outras metodologias de desenvolvimento, como XP e SCRUM por exemplo, conhecidas como metodologias ágeis.
Um contato direto com o cliente, mostrando os resultados gradativos, torna a resolução de problemas muito mais rápida e menos "dolorosa".
Como no primeiro caso que você citou, onde após 2 meses apresentaram o projeto e estava tudo errado, se na primeira semana fosse apresentado algum material para o cliente, este poderia detectar diferenças de pensamento no ato, poupando muito tempo (e tempo = dinheiro).
O modelo abordado no artigo, que é conhecido como waterfall (em cascata) tem suas vantagens, mas fazer todo o planejamento antes de iniciar com a mão na massa também acarreta vários problemas, afinal quase todos (para não dizer todos) os projetos estão sujeitos a mudança de escopo no decorrer da implementação ou em um tempo muito curto após ela.

Bom, finalizando gostaria de salientar que não é uma crítica, apenas queria mostrar que existem outras possibilidades nas metodologias de desenvolvimento.

Abraços,

Marcos Antonio Campos Jordão''

[7] Comentário enviado por agk em 14/04/2008 - 16:41h

Muito bom, gostei das explicações, parabéns pelo artigo.

Meu byte de contribuição: no teu shell script pode utilizar o time, fica mais fácil para saber os tempos de execução de cada script.

man time

[ ]'s.

[8] Comentário enviado por EdDeAlmeida em 15/04/2008 - 14:33h

Obrigado pelos comentários! Programação II sai em breve, estou dando meus últimos retoques. Valeu pela dica, agk. Eu já usei o time, mas não sei porque resolvi usar esse método do script. Com certeza o time é mais eficiente.

[9] Comentário enviado por marcio_paim em 14/02/2012 - 20:49h

Muito bom! Acho que a maioria do pessoal que está começando não nota a importância das dicas por que ainda não se deparou com o desenvolvimento de um software cujo tamanho mostre que elas são realmente úteis.

[10] Comentário enviado por MrCrawl3r em 02/05/2016 - 20:26h

Excelente!

Parabéns pelo artigo que já tem um bom tempo e mesmo assim continua ajudando iniciantes como eu rs.

--------------------------------------------------
Att,
Mr Crawler.

O mundo depende dos computadores. Tenha total domínio sobre os computadores e domine o mundo!


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts