[quote=lkbm][quote=A H Gusukuma][quote=lkbm][quote=lanlico]
Com construção de software não é diferente…[/quote]
Na verdade, desenvolvimento de software é completamente diferente de construção civil.[/quote]
Claro, mas tem muitas similaridades.
De onde veio os padrões de projeto?
[/quote]
Dica: não veio de engenheiros civis ou arquitetos.[/quote]
Pelo que me consta, Christopher Alexander é um arquiteto.
[quote=lkbm][quote=A H Gusukuma][quote=lkbm]
Como vai simular uma equipe com analistas e programadores num projeto solo?[/quote]
Dividindo o trabalho.
O importante é executar os papéis, não quem faz.[/quote]
Não existe divisão de trabalho em projetos solo.[/quote]
Depende do que se entende por “divisão de trabalho”.
[quote=lkbm][quote=javaflex]
Não me referi a sistema solo essa última resposta.[/quote]
98% dos programadores não são treinados em OO e acham que fazer OO é usar hibernarte, se não pode usar hibernaste então não deve ser OO.
Mas achei que estavamos falando de processos usados em empresas e não de OO e hibernaste.[/quote]
Sim, porque na prática na maioria dos casos é “usar Hibernate” mesmo.
Certo, se você entende que a definição de divisão de trabalho muda com a situação deve concordar que a idéia de fazer adaptações genéricas como “usar processo de empresa no meu projeto solo” não vai ser muito útil.
[quote=A H Gusukuma]
Pelo que me consta, Christopher Alexander é um arquiteto.[/quote]
Não, o livro de padrões de projeto de software não “veio” do trabalho desse cara, e sim de anos de experiência dos autores desenvolvendo sistemas.
A influência do Christopher Alexandre foi a idéia de fazer um livro estruturado em forma de catálogo. Isso não quer dizer que o processo de construir pontes ou casas tem alguma relação com desenvolvimento de software. Não confunda alhos com bugalhos.
[quote=javaflex]
Sim, porque na prática na maioria dos casos é “usar Hibernate” mesmo.[/quote]
Você precisa de um modelo de dados antes de fazer qualquer sistema OO. Com hibernate não é diferente.
Ferramentas como hibernate apenas pegam o modelo de dados que você usou para criar o modelo OO e transforma para um sistema relacional.
[quote=lkbm][quote=A H Gusukuma]
Pelo que me consta, Christopher Alexander é um arquiteto.[/quote]
Não, o livro de padrões de projeto de software não “veio” do trabalho desse cara, e sim de anos de experiência dos autores desenvolvendo sistemas.
A influência do Christopher Alexandre foi a idéia de fazer um livro estruturado em forma de catálogo. Isso não quer dizer que o processo de construir pontes ou casas tem alguma relação com desenvolvimento de software. Não confunda alhos com bugalhos.[/quote]
Padrões de projeto de software (GoF) reúne conhecimento de anos de desenvolvimento de software da comunidade, não apenas dos autores do livro.
A influência do Christopher Alexander é imensa, em diversas áreas.
Agora, quanto a confundir alhos com bugalhos, é uma forçação de barra da sua parte, em nenhum post coloquei que é a mesma coisa. O máximo que disse, foi “similaridade”, mas não vou discutir nesse nível. Se conhece um pouco de cada área vai identificar o que tentei dizer.
[quote=A H Gusukuma][quote=lkbm][quote=A H Gusukuma]
Pelo que me consta, Christopher Alexander é um arquiteto.[/quote]
Não, o livro de padrões de projeto de software não “veio” do trabalho desse cara, e sim de anos de experiência dos autores desenvolvendo sistemas.
A influência do Christopher Alexandre foi a idéia de fazer um livro estruturado em forma de catálogo. Isso não quer dizer que o processo de construir pontes ou casas tem alguma relação com desenvolvimento de software. Não confunda alhos com bugalhos.[/quote]
Padrões de projeto de software (GoF) reúne conhecimento de anos de desenvolvimento de software da comunidade, não apenas dos autores do livro.
A influência do Christopher Alexander é imensa, em diversas áreas.
Agora, quanto a confundir alhos com bugalhos, é uma forçação de barra da sua parte, em nenhum post coloquei que é a mesma coisa. O máximo que disse, foi “similaridade”, mas não vou discutir nesse nível. Se conhece um pouco de cada área vai identificar o que tentei dizer. [/quote]
Não existe nenhuma similaridade entre desenvolver software e engenharia civil e o não aceitar isso tem gerado um enorme desperdício de dinheiro com desenvolvimento de sistemas e é um dos principais fatores responsáveis pela má fama que programadores (TI em geral) tem entre os “leigos”.
[quote=YvGa][quote=A H Gusukuma][quote=lkbm][quote=A H Gusukuma]
Pelo que me consta, Christopher Alexander é um arquiteto.[/quote]
Não, o livro de padrões de projeto de software não “veio” do trabalho desse cara, e sim de anos de experiência dos autores desenvolvendo sistemas.
A influência do Christopher Alexandre foi a idéia de fazer um livro estruturado em forma de catálogo. Isso não quer dizer que o processo de construir pontes ou casas tem alguma relação com desenvolvimento de software. Não confunda alhos com bugalhos.[/quote]
Padrões de projeto de software (GoF) reúne conhecimento de anos de desenvolvimento de software da comunidade, não apenas dos autores do livro.
A influência do Christopher Alexander é imensa, em diversas áreas.
Agora, quanto a confundir alhos com bugalhos, é uma forçação de barra da sua parte, em nenhum post coloquei que é a mesma coisa. O máximo que disse, foi “similaridade”, mas não vou discutir nesse nível. Se conhece um pouco de cada área vai identificar o que tentei dizer. [/quote]
Não existe nenhuma similaridade entre desenvolver software e engenharia civil e o não aceitar isso tem gerado um enorme desperdício de dinheiro com desenvolvimento de sistemas e é um dos principais fatores responsáveis pela má fama que programadores (TI em geral) tem entre os “leigos”.[/quote]
Não pode ser o contrário?
Desenvolver software tem sim similaridade com outras áreas do conhecimento humano. É claro que cada área tem suas particularidades, mas tem muitas similaridades, sim. Agora, a má fama, não vem disso não. Pode ser da ignorância em relação à profissão ou das experiências negativas. Culpa dos dois lados, e, também do fato de que é uma atividade nova.
[quote=A H Gusukuma]
A influência do Christopher Alexander é imensa, em diversas áreas.[/quote]
Não no sentido de usar técnicas de arquitetura e construção civil nas diversas áreas.
Mas entendo que existe essa impressão quando se lê apenas a biografia do autor.
[quote=lkbm][quote=A H Gusukuma]
A influência do Christopher Alexander é imensa, em diversas áreas.[/quote]
Não no sentido de usar técnicas de arquitetura e construção civil nas diversas áreas.
Mas entendo que existe essa impressão quando se lê apenas a biografia do autor.[/quote]
Não entendo a insistência em colocar a discussão nesse nível, ninguém está falando em usar técnicas de construção civil no desenvolvimento de software.
O grande problema do pessoal de TI parece ser de entendimento ou de se expressar. hehehe!
Na verdade o lanlico estava falando isso de usar técnicas de construção civil no desenvolvimento de software. Minha resposta foi pra ele. Entendeu?
De fato, talvez o problema esteja no entendimento do pessoal de TI, no caso eu. Mas você disse, com essas palavras, que desenvolvimento de software tem muitas similaridades com engenharia civil. Para esclarecer o meu fraco entendimento, gostaria que você dissesse quais são elas.
Desculpe insistir nesse ponto, mas é que eu acho que essa confusão entre as duas áreas é muito maléfica para o desenvolvimento e tem atrapalhado bastante em ambientes com esse tipo de pensamento. Por isso, acho que não se deve, em hipótese alguma, deixar essa ponta em aberto numa discussão com iniciantes participando do tópico, ou mesmo para quem passar por aqui algum dia e ler as opiniões.
Se existem similaridades, e eu não vejo quais, exceto aquelas que são comuns a qualquer atividade profissional, como coordenação, organização, administração, elas devem ser explicitadas.
[quote=YvGa][quote=A H Gusukuma]
O grande problema do pessoal de TI parece ser de entendimento ou de se expressar. hehehe!
[/quote]
De fato, talvez o problema esteja no entendimento do pessoal de TI, no caso eu. Mas você disse, com essas palavras, que desenvolvimento de software tem muitas similaridades com engenharia civil. Para esclarecer o meu fraco entendimento, gostaria que você dissesse quais são elas.
Desculpe insistir nesse ponto, mas é que eu acho que essa confusão entre as duas áreas é muito maléfica para o desenvolvimento e tem atrapalhado bastante em ambientes com esse tipo de pensamento. Por isso, acho que não se deve, em hipótese alguma, deixar essa ponta em aberto numa discussão com iniciantes participando do tópico, ou mesmo para quem passar por aqui algum dia e ler as opiniões.
Se existem similaridades, e eu não vejo quais, exceto aquelas que são comuns a qualquer atividade profissional, como coordenação, organização, administração, elas devem ser explicitadas.
[/quote]
Vou colocar uma lista de termos, verifica se (com termos específicos de área) não encontramos em diversas [areas (não apenas em eng civil).
1 Viabilidade
2 Requisitos
3 Especificação
4 Arquitetura
5 Documentação
6 Testes
7 Construção
8 Retrabalho
9 Manutenção
10 Ampliação
Outros: padrões, riscos, segurança, expansibilidade, previsão, custos, prazos, etc e etc.
PS: antes que alguém comente, não estou simplificando ou diminuindo a importância de cada área, muito menos da minha área (TI)!
Repare que na primeira vez você falou similaridades com engenharia civil e essas palavras aí são conceitos vagos. Podem existir nas duas áreas, como em muitas outras, mas cada palavra dessas tem abordagens completamente diferentes entre uma área e outra. Além de que muitos desses termos são emprestados da área de engenharia e responsáveis por aumentar a confusão. Documentação, por exemplo, na engenharia, trata-se de projeto, em software anda em conjunto com a construção. Testes em engenharia estão na fase de projetos, em desenvolvimento estão na construção e no caso dos funcionais, depois de pronto, algo impossível na engenharia civil.
Você está usando conceitos vagos e só está aumentando a confusão de quem está começando agora a desenvolver sistemas.
[quote=YvGa][quote=A H Gusukuma]
Vou colocar uma lista de termos, verifica se (com termos específicos de área) não encontramos em diversas [areas (não apenas em eng civil).
1 Viabilidade
2 Requisitos
3 Especificação
4 Arquitetura
5 Documentação
6 Testes
7 Construção
8 Retrabalho
9 Manutenção
10 Ampliação
Outros: padrões, riscos, segurança, expansibilidade, previsão, custos, prazos, etc e etc.
PS: antes que alguém comente, não estou simplificando ou diminuindo a importância de cada área, muito menos da minha área (TI)!
[/quote]
Repare que na primeira vez você falou similaridades com engenharia civil e essas palavras aí são conceitos vagos. Podem existir nas duas áreas, como em muitas outras, mas cada palavra dessas tem abordagens completamente diferentes entre uma área e outra. Além de que muitos desses termos são emprestados da área de engenharia e responsáveis por aumentar a confusão. Documentação, por exemplo, na engenharia, trata-se de projeto, em software anda em conjunto com a construção. Testes em engenharia estão na fase de projetos, em desenvolvimento estão na construção e no caso dos funcionais, depois de pronto, algo impossível na engenharia civil.
Você está usando conceitos vagos e só está aumentando a confusão de quem está começando agora a desenvolver sistemas.[/quote]
Sinto muito se os termos sejam vagos, ou tenham significados diferentes em cada área. Mas, não deveria ter muitas dúvidas para quem é da área.
Não creio que para alguém de TI, por exemplo, que o termo “construção” cause alguma dúvida do que seja.
[quote=A H Gusukuma][quote=YvGa][quote=A H Gusukuma]
Vou colocar uma lista de termos, verifica se (com termos específicos de área) não encontramos em diversas [areas (não apenas em eng civil).
1 Viabilidade
2 Requisitos
3 Especificação
4 Arquitetura
5 Documentação
6 Testes
7 Construção
8 Retrabalho
9 Manutenção
10 Ampliação
Outros: padrões, riscos, segurança, expansibilidade, previsão, custos, prazos, etc e etc.
PS: antes que alguém comente, não estou simplificando ou diminuindo a importância de cada área, muito menos da minha área (TI)!
[/quote]
Repare que na primeira vez você falou similaridades com engenharia civil e essas palavras aí são conceitos vagos. Podem existir nas duas áreas, como em muitas outras, mas cada palavra dessas tem abordagens completamente diferentes entre uma área e outra. Além de que muitos desses termos são emprestados da área de engenharia e responsáveis por aumentar a confusão. Documentação, por exemplo, na engenharia, trata-se de projeto, em software anda em conjunto com a construção. Testes em engenharia estão na fase de projetos, em desenvolvimento estão na construção e no caso dos funcionais, depois de pronto, algo impossível na engenharia civil.
Você está usando conceitos vagos e só está aumentando a confusão de quem está começando agora a desenvolver sistemas.[/quote]
Sinto muito se os termos sejam vagos, ou tenham significados diferentes em cada área. Mas, não deveria ter muitas dúvidas para quem é da área.
Não creio que para alguém de TI, por exemplo, que o termo “construção” cause alguma dúvida do que seja.[/quote]
Pode começar explicar então, pois eu não acho lugar para o termo construção para o que eu faço no dia a dia.
[quote=rmendes08][quote=A H Gusukuma][quote=YvGa][quote=A H Gusukuma]
Vou colocar uma lista de termos, verifica se (com termos específicos de área) não encontramos em diversas [areas (não apenas em eng civil).
1 Viabilidade
2 Requisitos
3 Especificação
4 Arquitetura
5 Documentação
6 Testes
7 Construção
8 Retrabalho
9 Manutenção
10 Ampliação
Outros: padrões, riscos, segurança, expansibilidade, previsão, custos, prazos, etc e etc.
PS: antes que alguém comente, não estou simplificando ou diminuindo a importância de cada área, muito menos da minha área (TI)!
[/quote]
Repare que na primeira vez você falou similaridades com engenharia civil e essas palavras aí são conceitos vagos. Podem existir nas duas áreas, como em muitas outras, mas cada palavra dessas tem abordagens completamente diferentes entre uma área e outra. Além de que muitos desses termos são emprestados da área de engenharia e responsáveis por aumentar a confusão. Documentação, por exemplo, na engenharia, trata-se de projeto, em software anda em conjunto com a construção. Testes em engenharia estão na fase de projetos, em desenvolvimento estão na construção e no caso dos funcionais, depois de pronto, algo impossível na engenharia civil.
Você está usando conceitos vagos e só está aumentando a confusão de quem está começando agora a desenvolver sistemas.[/quote]
Sinto muito se os termos sejam vagos, ou tenham significados diferentes em cada área. Mas, não deveria ter muitas dúvidas para quem é da área.
Não creio que para alguém de TI, por exemplo, que o termo “construção” cause alguma dúvida do que seja.[/quote]
Pode começar explicar então, pois eu não acho lugar para o termo construção para o que eu faço no dia a dia. [/quote]
Estou começando a entender porquê tem tantos problemas no desenvolvimento de software, o pessoal não tem muita flexibilidade com a linguagem.
PS: não sei o que faz!
[quote=A H Gusukuma][quote=rmendes08][quote=A H Gusukuma][quote=YvGa][quote=A H Gusukuma]
Vou colocar uma lista de termos, verifica se (com termos específicos de área) não encontramos em diversas [areas (não apenas em eng civil).
1 Viabilidade
2 Requisitos
3 Especificação
4 Arquitetura
5 Documentação
6 Testes
7 Construção
8 Retrabalho
9 Manutenção
10 Ampliação
Outros: padrões, riscos, segurança, expansibilidade, previsão, custos, prazos, etc e etc.
PS: antes que alguém comente, não estou simplificando ou diminuindo a importância de cada área, muito menos da minha área (TI)!
[/quote]
Repare que na primeira vez você falou similaridades com engenharia civil e essas palavras aí são conceitos vagos. Podem existir nas duas áreas, como em muitas outras, mas cada palavra dessas tem abordagens completamente diferentes entre uma área e outra. Além de que muitos desses termos são emprestados da área de engenharia e responsáveis por aumentar a confusão. Documentação, por exemplo, na engenharia, trata-se de projeto, em software anda em conjunto com a construção. Testes em engenharia estão na fase de projetos, em desenvolvimento estão na construção e no caso dos funcionais, depois de pronto, algo impossível na engenharia civil.
Você está usando conceitos vagos e só está aumentando a confusão de quem está começando agora a desenvolver sistemas.[/quote]
Sinto muito se os termos sejam vagos, ou tenham significados diferentes em cada área. Mas, não deveria ter muitas dúvidas para quem é da área.
Não creio que para alguém de TI, por exemplo, que o termo “construção” cause alguma dúvida do que seja.[/quote]
Pode começar explicar então, pois eu não acho lugar para o termo construção para o que eu faço no dia a dia. [/quote]
Estou começando a entender porquê tem tantos problemas no desenvolvimento de software, o pessoal não tem muita flexibilidade com a linguagem.
PS: não sei o que faz!
[/quote]
Desenvolvo software, como a maioria deve fazer no fórum, suponho eu.
Mas sendo mais explícito, particularmente eu não encontro lugar para a palavra “construção” em desenvolvimento de software. Pelo menos não da maneira como ela é utilizada em engenharia civil.
[quote=rmendes08][quote=A H Gusukuma][quote=rmendes08][quote=A H Gusukuma][quote=YvGa][quote=A H Gusukuma]
Vou colocar uma lista de termos, verifica se (com termos específicos de área) não encontramos em diversas [areas (não apenas em eng civil).
1 Viabilidade
2 Requisitos
3 Especificação
4 Arquitetura
5 Documentação
6 Testes
7 Construção
8 Retrabalho
9 Manutenção
10 Ampliação
Outros: padrões, riscos, segurança, expansibilidade, previsão, custos, prazos, etc e etc.
PS: antes que alguém comente, não estou simplificando ou diminuindo a importância de cada área, muito menos da minha área (TI)!
[/quote]
Repare que na primeira vez você falou similaridades com engenharia civil e essas palavras aí são conceitos vagos. Podem existir nas duas áreas, como em muitas outras, mas cada palavra dessas tem abordagens completamente diferentes entre uma área e outra. Além de que muitos desses termos são emprestados da área de engenharia e responsáveis por aumentar a confusão. Documentação, por exemplo, na engenharia, trata-se de projeto, em software anda em conjunto com a construção. Testes em engenharia estão na fase de projetos, em desenvolvimento estão na construção e no caso dos funcionais, depois de pronto, algo impossível na engenharia civil.
Você está usando conceitos vagos e só está aumentando a confusão de quem está começando agora a desenvolver sistemas.[/quote]
Sinto muito se os termos sejam vagos, ou tenham significados diferentes em cada área. Mas, não deveria ter muitas dúvidas para quem é da área.
Não creio que para alguém de TI, por exemplo, que o termo “construção” cause alguma dúvida do que seja.[/quote]
Pode começar explicar então, pois eu não acho lugar para o termo construção para o que eu faço no dia a dia. [/quote]
Estou começando a entender porquê tem tantos problemas no desenvolvimento de software, o pessoal não tem muita flexibilidade com a linguagem.
PS: não sei o que faz!
[/quote]
Desenvolvo software, como a maioria deve fazer no fórum, suponho eu.
Mas sendo mais explícito, particularmente eu não encontro lugar para a palavra “construção” em desenvolvimento de software. Pelo menos não da maneira como ela é utilizada em engenharia civil.[/quote]
É claro que sei (imagino) o que faz, foi uma provocação!
Veja que coloquei “… (com termos específicos de área)…”, os termos não são os mesmos, cada área (pode) ter/usar um mais condizente com o que faz. Não creio que a frase “a construção de um programa” seja estranha ou incompreensível.