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

0 0

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

Muito bom cara. Parabéns;

0 0

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

0 0

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

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

0 0

[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

0 0

[6] Comentário enviado por removido 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''

0 0

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

0 0

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

0 0

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

0 0

[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!

0 0