Projetar e organizar o trabalho em um sistema Web

Eu faria diferente. Primeiro criaria a camada de acesso aos dados e com isso geraria um componente. Depois disso faria uma outra camada para as regras de negócio e geraria um novo componente também e só depois disso desenvolveria a UI. Mas claro, isso é só opinião, você deve começar por onde se sentir mais seguro. Apenas estou de expondo uma maneira diferente.

Apenas creio que seria interessante você aplicar alguma ferramenta de TDD quando desenvolver as classes de acesso aos dados e negócio.

Primeiramente tem que estar na sua cabeça as entidades e seus relacionamentos, enfim, o negócio em si. Como funciona um Sistema de Contas a Pagar? Faça esta pergunta a você mesmo e saia desenhando e criando as entidades. Com o modelo relacional fechado, você começa a levantar os serviços que você vai ter e depois as telas principais.

Se vai usar Spring MVC, Struts, JSF bla bla bla isso é o de menos, primeiro você tem que fechar o que o sistema fará e como ele fará.

Mendigo_do_Futuro:

Bom dia pessoal

Estou desenvolvendo(para fins de aprendizagem) um sistema web de contas a pagar, porém, estou muito perdido com o que fazer e o que fazer primeiro. Estou usando as seguintes ferramentas:

Banco de dados: MySql
Interface visual: Dreamweaver
IDE: Eclipse
Framework 1: Spring MVC
Framework 2: Hibernate

O banco de dados já está criado e inicialmente minha ideia é desenvolver todas as interfaces com o usuário no Dreamweaver. Após esse ponto pensei em iniciar a codificação das classes que representam as entidades e fazer o mapeamento com o Hibernate e só então começar a organizar o projeto com o spring.

Eu sei que a explicação da ideia está bem genérica, mas alguém poderia me dizer se devo seguir essa linha ou mudar a forma como vou trabalhar? Gostaria de seguir o processo que seguiria em uma empresa, pois como mencionei no começo, estou desenvolvendo esse sistema para fins de aprendizagem.

Obrigado pela atenção, abraços.

O processo usado por empresas (fazer todo o banco, depois fazer toda interface, etc.) não é apropriado nem mesmo para as próprias empresas, imagina quem esta aprendendo.

lkbm:

Mendigo_do_Futuro:

Bom dia pessoal

Estou desenvolvendo(para fins de aprendizagem) um sistema web de contas a pagar, porém, estou muito perdido com o que fazer e o que fazer primeiro. Estou usando as seguintes ferramentas:

Banco de dados: MySql
Interface visual: Dreamweaver
IDE: Eclipse
Framework 1: Spring MVC
Framework 2: Hibernate

O banco de dados já está criado e inicialmente minha ideia é desenvolver todas as interfaces com o usuário no Dreamweaver. Após esse ponto pensei em iniciar a codificação das classes que representam as entidades e fazer o mapeamento com o Hibernate e só então começar a organizar o projeto com o spring.

Eu sei que a explicação da ideia está bem genérica, mas alguém poderia me dizer se devo seguir essa linha ou mudar a forma como vou trabalhar? Gostaria de seguir o processo que seguiria em uma empresa, pois como mencionei no começo, estou desenvolvendo esse sistema para fins de aprendizagem.

Obrigado pela atenção, abraços.

O processo usado por empresas (fazer todo o banco, depois fazer toda interface, etc.) não é apropriado nem mesmo para as próprias empresas, imagina quem esta aprendendo. :P

Já viu a construção de um prédio, casa ou alguma coisa ligada a construção civil ?

Primeiro você precisa planejar, escolher a quantidade de dependências, pavimentos, entre outros fatores. Depois vem terraplenagem e só aí você consegue ter o seu alicerce implantado. Pós último você deixa para fazer o acabamento, perfumaria e detalhes visuais.

Com construção de software não é diferente, primeiro defina sua arquitetura, escolha sua plataforma de desenvolvimento, deixe bem claro os teus requisitos funcionais e não funcionais, especifique os teus requisitos, encare o projeto da forma correta, mesmo sendo apenas para aprendizado.

Depois de ter feito todas as suas definições, comece a construção da sua infraestrutura, pegue os requisitos que possuem impacto arquitetural e tente implementar eles.

A parte de acabamento você vai fazer depois, estilizar, fazer telas, dá cara para seu projeto…

Bom, é isso, claro que foi bem simplório, mas dá para você ter uma ideia.

javaflex:

Pelo menos sem querer ou não ele está simulando uma situação mais possível de acontecer na realidade. Nem sempre “o errado” academicamente é errado para algum cenário real. Mas concordo que ele deveria estar ciente do que seria o “fluxo ideal”.

O cenário que você se refere como real (de uma empresa) e o cenário do autor do tópico (um projeto solo) são duas situações completamente diferentes. Você esta dizendo que ele devia usar o processo usado por empresas mesmo que ele não precise no projeto dele? E por que alguém faria isso?

lanlico:

Com construção de software não é diferente…

Na verdade, desenvolvimento de software é completamente diferente de construção civil.

lkbm:

javaflex:

Pelo menos sem querer ou não ele está simulando uma situação mais possível de acontecer na realidade. Nem sempre “o errado” academicamente é errado para algum cenário real. Mas concordo que ele deveria estar ciente do que seria o “fluxo ideal”.

O cenário que você se refere como real (de uma empresa) e o cenário do autor do tópico (um projeto solo) são duas situações completamente diferentes. Você esta dizendo que ele devia usar o processo usado por empresas mesmo que ele não precise no projeto dele? E por que alguém faria isso?

Na verdade a minha intenção é realmente simular um cenário real, como se fosse dentro de uma empresa. O meu objetivo é chegar o mais próximo possível disso, para que com esse projeto, de alguma forma, eu ganhe conhecimento que possa servir como “experiência de campo” e possa ser usado durante uma entrevista de emprego por exemplo.

lkbm:

javaflex:

Pelo menos sem querer ou não ele está simulando uma situação mais possível de acontecer na realidade. Nem sempre “o errado” academicamente é errado para algum cenário real. Mas concordo que ele deveria estar ciente do que seria o “fluxo ideal”.

O cenário que você se refere como real (de uma empresa) e o cenário do autor do tópico (um projeto solo) são duas situações completamente diferentes. Você esta dizendo que ele devia usar o processo usado por empresas mesmo que ele não precise no projeto dele? E por que alguém faria isso?

Mendigo_do_Futuro:

Na verdade a minha intenção é realmente simular um cenário real, como se fosse dentro de uma empresa. O meu objetivo é chegar o mais próximo possível disso, para que com esse projeto, de alguma forma, eu ganhe conhecimento que possa servir como “experiência de campo” e possa ser usado durante uma entrevista de emprego por exemplo.

Como vai simular uma equipe com analistas e programadores num projeto solo?

javaflex:

O banco de dados dele já está criado, por isso eu toquei nessa questão de sem querer ou não estar diante de uma situação da maioria das empresas. Isso não é errado, ele só está seguindo a modelagem orientado a banco como acontece muito. Importante é ele estar ciente agora que o “fluxo ideal” seria outro, mas não tendo que se sentir errado para refazer um trabalho.

Então o cenário é o mesmo pq o banco ta pronto e nas empresas o banco costuma ficar pronto primeiro?

hm, entendi.

Mas quando critiquei fazer todo o banco primeiro, depois toda a interface, estava me referindo ao “todo”, e não a ordem com que são feitos. Não vejo nada de errado em fazer o banco ou a interface primeiro, e sim que eles devem ser feitos em pequenos passos e de maneira iterativa.

lkbm:

javaflex:

O banco de dados dele já está criado, por isso eu toquei nessa questão de sem querer ou não estar diante de uma situação da maioria das empresas. Isso não é errado, ele só está seguindo a modelagem orientado a banco como acontece muito. Importante é ele estar ciente agora que o “fluxo ideal” seria outro, mas não tendo que se sentir errado para refazer um trabalho.

Então o cenário é o mesmo pq o banco ta pronto e nas empresas o banco costuma ficar pronto primeiro?

hm, entendi.

Mas quando critiquei fazer todo o banco primeiro, depois toda a interface, estava me referindo ao “todo”, e não a ordem com que são feitos. Não vejo nada de errado em fazer o banco ou a interface primeiro, e sim que eles devem ser feitos em pequenos passos e de maneira iterativa.

javaflex:

Sim, fazer de forma iterativa concordo plenamente, mas já é outro assunto, não envolvendo só o banco. “Nas empresas” costuma sim ficar pronto antes, quando se tem uma equipe de ADs que vão liderar a modelagem. Se fizer OO antes e gerar tabelas corre o risco da AD barrar e ter retrabalho ou dificuldade de mapear o que a AD aprovar. Fora isso, existem casos que nem todos os sistemas envolvidos são orientados a objetos.

Desenvolver um sistema solo como se fosse uma empresa (ou seja, usando o mesmo processo) é uma coisa retardada de se fazer. Não conheço ninguém com experiencia que defende fazer isso, quanto mais quem esta aprendendo e não sabe fazer as adaptações necessárias.

lkbm:

javaflex:

Sim, fazer de forma iterativa concordo plenamente, mas já é outro assunto, não envolvendo só o banco. “Nas empresas” costuma sim ficar pronto antes, quando se tem uma equipe de ADs que vão liderar a modelagem. Se fizer OO antes e gerar tabelas corre o risco da AD barrar e ter retrabalho ou dificuldade de mapear o que a AD aprovar. Fora isso, existem casos que nem todos os sistemas envolvidos são orientados a objetos.

Desenvolver um sistema solo como se fosse uma empresa (ou seja, usando o mesmo processo) é uma coisa retardada de se fazer. Não conheço ninguém com experiencia que defende fazer isso, quanto mais quem esta aprendendo e não sabe fazer as adaptações necessárias.

javaflex:

Não me referi a sistema solo essa última resposta.

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.

lkbm:

lanlico:

Com construção de software não é diferente…

Na verdade, desenvolvimento de software é completamente diferente de construção civil.

Claro, mas tem muitas similaridades.
De onde veio os padrões de projeto?

lkbm:

Mendigo_do_Futuro:

Na verdade a minha intenção é realmente simular um cenário real, como se fosse dentro de uma empresa. O meu objetivo é chegar o mais próximo possível disso, para que com esse projeto, de alguma forma, eu ganhe conhecimento que possa servir como “experiência de campo” e possa ser usado durante uma entrevista de emprego por exemplo.

Como vai simular uma equipe com analistas e programadores num projeto solo?

Dividindo o trabalho.
O importante é executar os papéis, não quem faz.

A H Gusukuma:

lkbm:

lanlico:

Com construção de software não é diferente…

Na verdade, desenvolvimento de software é completamente diferente de construção civil.

Claro, mas tem muitas similaridades.
De onde veio os padrões de projeto?

Dica: não veio de engenheiros civis ou arquitetos.

A H Gusukuma:

Como vai simular uma equipe com analistas e programadores num projeto solo?

Dividindo o trabalho.
O importante é executar os papéis, não quem faz.[/quote]

Não existe divisão de trabalho em projetos solo.

lkbm:

A H Gusukuma:

lkbm:

lanlico:

Com construção de software não é diferente…

Na verdade, desenvolvimento de software é completamente diferente de construção civil.

Claro, mas tem muitas similaridades.
De onde veio os padrões de projeto?

Dica: não veio de engenheiros civis ou arquitetos.

Pelo que me consta, Christopher Alexander é um arquiteto.

lkbm:

A H Gusukuma:

lkbm:

Como vai simular uma equipe com analistas e programadores num projeto solo?

Dividindo o trabalho.
O importante é executar os papéis, não quem faz.

Não existe divisão de trabalho em projetos solo.

Depende do que se entende por “divisão de trabalho”.

lkbm:

javaflex:

Não me referi a sistema solo essa última resposta.

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.

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.

A H Gusukuma:

Pelo que me consta, Christopher Alexander é um arquiteto.

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.

javaflex:

Sim, porque na prática na maioria dos casos é “usar Hibernate” mesmo.

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.

lkbm:

A H Gusukuma:

Pelo que me consta, Christopher Alexander é um arquiteto.

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.

A H Gusukuma:

lkbm:

A H Gusukuma:

Pelo que me consta, Christopher Alexander é um arquiteto.

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.

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.

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

YvGa:

A H Gusukuma:

lkbm:

A H Gusukuma:

Pelo que me consta, Christopher Alexander é um arquiteto.

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.

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.

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

A H Gusukuma:

A influência do Christopher Alexander é imensa, em diversas áreas.

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.

lkbm:

A H Gusukuma:

A influência do Christopher Alexander é imensa, em diversas áreas.

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.

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.

YvGa:

A H Gusukuma:

O grande problema do pessoal de TI parece ser de entendimento ou de se expressar. hehehe!

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.

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.

YvGa:

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

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.

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.

A H Gusukuma:

YvGa:

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

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.

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.

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.

rmendes08:

A H Gusukuma:

YvGa:

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

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.

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.

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.

PS: não sei o que faz!

A H Gusukuma:

rmendes08:

A H Gusukuma:

YvGa:

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

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.

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.

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.

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!

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.

rmendes08:

A H Gusukuma:

rmendes08:

A H Gusukuma:

YvGa:

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

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.

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.

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.

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!

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.

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

A H Gusukuma:

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

Veja, a gente entende o que você quer dizer com construção, o que a gente não concorda é com a similaridade entre engenharia e desenvolvimento de software. Ela não existe, são processos completamente distintos, embora haja sim a confusão e ainda há quem tente usar dessa suposta similaridade para desenvolver software.

A questão é que essa confusão sempre foi péssima para nós. E a prova dessa confusão são os termos emprestados deles, como projeto, construção, manutenção.

Nós entendemos o que você quer dizer com construção, o que não entendemos é como o que chamamos de construção na área de software pode ser similar com o que chamamos de construção na área de engenharia.

YvGa:

Veja, a gente entende o que você quer dizer com construção, o que a gente não concorda é com a similaridade entre engenharia e desenvolvimento de software. Ela não existe, são processos completamente distintos, embora haja sim a confusão e ainda há quem tente usar dessa suposta similaridade para desenvolver software.

A questão é que essa confusão sempre foi péssima para nós. E a prova dessa confusão são os termos emprestados deles, como projeto, construção, manutenção.

Nós entendemos o que você quer dizer com construção, o que não entendemos é como o que chamamos de construção na área de software pode ser similar com o que chamamos de construção na área de engenharia.

Se você for ver o termo construir, vai encontrar: dar estrutura a, edificar, fabricar, arquitetar, dispor, organizar; então fica fácil entender o que o termo significa para cada área. Construir uma frase, significa dispor palavras de acordo com as regras gramaticais de determinada linguagem. Ninguém fica discutindo o que tem o Português com construção civil.

Obviamente a frase “a construção de um programa” só tem sentido pra quem entende sobre programas. Quem não entende, não é que ela vai ganhar alguma compreensão sobre o tema depois de ouvir de você que “construção” é aquela “similar” a construção civil. kkkk

Um tanto relativo não acha?

Se você já sabe escrever, fica fácil saber o que é construir textos.

Se você não sabe escrever programas e tem uma vaga idéia de como levantar prédios, ou erguer uma ponte, não é muito fácil entender o que termo construir significa.

A H Gusukuma:

YvGa:

Veja, a gente entende o que você quer dizer com construção, o que a gente não concorda é com a similaridade entre engenharia e desenvolvimento de software. Ela não existe, são processos completamente distintos, embora haja sim a confusão e ainda há quem tente usar dessa suposta similaridade para desenvolver software.

A questão é que essa confusão sempre foi péssima para nós. E a prova dessa confusão são os termos emprestados deles, como projeto, construção, manutenção.

Nós entendemos o que você quer dizer com construção, o que não entendemos é como o que chamamos de construção na área de software pode ser similar com o que chamamos de construção na área de engenharia.

Se você for ver o termo construir, vai encontrar: dar estrutura a, edificar, fabricar, arquitetar, dispor, organizar; então fica fácil entender o que o termo significa para cada área. Construir uma frase, significa dispor palavras de acordo com as regras gramaticais de determinada linguagem. Ninguém fica discutindo o que tem o Português com construção civil.

Justamente, ninguém diz que desenvolver software se parece com escrever um texto só porque em ambos existe algo que pode ser chamado de construção. No entanto você, por causa dessas palavras, disse que desenvolver software é similar a engenharia civil.

Mas tudo bem, a minha intenção não é te por contra a parede é fazer com que os que estão chegando não confundam desenvolvimento de software com engenharia civil. Por isso eu repito, uma área não tem nada de similar a outra.

Note que eu não “disse que desenvolver software é similar a engenharia civil”, disse e repito que tem similaridades.

YvGa:

Mas tudo bem, a minha intenção não é te por contra a parede é fazer com que os que estão chegando não confundam desenvolvimento de software com engenharia civil. Por isso eu repito, uma área não tem nada de similar a outra.

Mas, não adianta eu fazer a comparação entre outras áreas e ver as “similaridades”, e você fazer a mesma comparação e ver as diferenças. Não tem como comparar o que vejo e o que você vê.

A H Gusukuma:

YvGa:

Justamente, ninguém diz que desenvolver software se parece com escrever um texto só porque em ambos existe algo que pode ser chamado de construção. No entanto você, por causa dessas palavras, disse que desenvolver software é similar a engenharia civil.

Note que eu não “disse que desenvolver software é similar a engenharia civil”, disse e repito que tem similaridades.

Se você pegar qualquer assunto aleatório poderá observar diversas maneiras em que ele vai vir a ser similar com outro assunto totalmente não relacionado.

Aonde você espera chegar com isso não sei, mas é possível.

Principalmente porque você não diz quais são as semelhanças, deixa vago.

Você diz, construção, testes, manutenção… Sendo que não há semelhanças em nenhum desses pontos.

YvGa:

A H Gusukuma:

Mas, não adianta eu fazer a comparação entre outras áreas e ver as “similaridades”, e você fazer a mesma comparação e ver as diferenças. Não tem como comparar o que vejo e o que você vê.

Principalmente porque você não diz quais são as semelhanças, deixa vago.

Você diz, construção, testes, manutenção… Sendo que não há semelhanças em nenhum desses pontos.

lkbm:

A H Gusukuma:

YvGa:

Justamente, ninguém diz que desenvolver software se parece com escrever um texto só porque em ambos existe algo que pode ser chamado de construção. No entanto você, por causa dessas palavras, disse que desenvolver software é similar a engenharia civil.

Note que eu não “disse que desenvolver software é similar a engenharia civil”, disse e repito que tem similaridades.

Se você pegar qualquer assunto aleatório poderá observar diversas maneiras em que ele vai vir a ser similar com outro assunto totalmente não relacionado.

Aonde você espera chegar com isso não sei, mas é possível.

Simples: falei uma coisa óbvia, mas as reações foram como se tivesse falando um absurdo.

A H Gusukuma:

YvGa:

A H Gusukuma:

Mas, não adianta eu fazer a comparação entre outras áreas e ver as “similaridades”, e você fazer a mesma comparação e ver as diferenças. Não tem como comparar o que vejo e o que você vê.

Principalmente porque você não diz quais são as semelhanças, deixa vago.

Você diz, construção, testes, manutenção… Sendo que não há semelhanças em nenhum desses pontos.

Vamos começar pelo início: especificação do trabalho, não se fala com o cliente, levanta o que ele quer, verifica se é possível, faz-se protótipos, etc.

No caso, pode-se dizer que existem similaridades entre desenvolver software e odontologia?

YvGa:

A H Gusukuma:

YvGa:

A H Gusukuma:

Mas, não adianta eu fazer a comparação entre outras áreas e ver as “similaridades”, e você fazer a mesma comparação e ver as diferenças. Não tem como comparar o que vejo e o que você vê.

Principalmente porque você não diz quais são as semelhanças, deixa vago.

Você diz, construção, testes, manutenção… Sendo que não há semelhanças em nenhum desses pontos.

Vamos começar pelo início: especificação do trabalho, não se fala com o cliente, levanta o que ele quer, verifica se é possível, faz-se protótipos, etc.

No caso, pode-se dizer que existem similaridades entre desenvolver software e odontologia?

A H Gusukuma:

Nem pensei sobre, mas se tivesse teria algum problema?

Não, fora o fato de que pouco agregaria a discussão e mais serviria para confundir do que esclarecer, não teria problema algum.

A H Gusukuma:

Vamos começar pelo início: especificação do trabalho, não se fala com o cliente, levanta o que ele quer, verifica se é possível, faz-se protótipos, etc.

Pensando assim, construção civil tem similaridades com desenvolvimento de software, odontologia, tatuagens…

lkbm:

A H Gusukuma:

Vamos começar pelo início: especificação do trabalho, não se fala com o cliente, levanta o que ele quer, verifica se é possível, faz-se protótipos, etc.

Pensando assim, construção civil tem similaridades com desenvolvimento de software, odontologia, tatuagens…

A H Gusukuma:

YvGa:

No caso, pode-se dizer que existem similaridades entre desenvolver software e odontologia?

Nem pensei sobre, mas se tivesse teria algum problema?

Acho que temos um troll.

Cara, cada uma das profissões tem sua própria maneira de construir que é diferente de construção civil. Sim, o mesmo termo é usado pela nossa linguagem pra se referir ao conceito (construir), mas o conceito em si varia de cada profissão.

Não considero mais que você esteja falando sério (fazer tatuagem é similar com construção civil?) Só pode ser piada.

Realmente eu fico impressionado com a capacidade de argumentação de alguns, eu falo que existem semelhanças entre algumas atividades, vocês falam que não existe nenhuma. E no fim, trazem uma série de outras profissões (odontologia, tatuadores, etc) e eu é que sou “troll”?
Nunca disse que o produto, ou a forma de produzir, fosse igual, até porque seria insultar a inteligência alheia e eu não tenho esse hábito.
Mas, acho que o nível está indo para uma direção não desejável, melhor ficar por aqui.

A H Gusukuma:

Realmente eu fico impressionado com a capacidade de argumentação de alguns, eu falo que existem semelhanças entre algumas atividades, vocês falam que não existe nenhuma. E no fim, trazem uma série de outras profissões (odontologia, tatuadores, etc) e eu é que sou “troll”?
Nunca disse que o produto, ou a forma de produzir, fosse igual, até porque seria insultar a inteligência alheia e eu não tenho esse hábito.
Mas, acho que o nível está indo para uma direção não desejável, melhor ficar por aqui.

Isso é uma falácia clássica, você fez uma afirmação e nós refutamos dizendo que se é essa a semelhança ela pode ser semelhante a qualquer outra profissão, por isso a sua primeira afirmação não fazia sentido. Aí você tenta inverter como se nós estivéssemos comparando software com odontologia e não você, pelo uso da lógica sobre seus próprios argumentos.

Ok, vejamos como tudo começou. Aqui começa a discussão:

lanlico:

Já viu a construção de um prédio, casa ou alguma coisa ligada a construção civil ?

Primeiro você precisa planejar, escolher a quantidade de dependências, pavimentos, entre outros fatores. Depois vem terraplenagem e só aí você consegue ter o seu alicerce implantado. Pós último você deixa para fazer o acabamento, perfumaria e detalhes visuais.

Com construção de software não é diferente, primeiro defina sua arquitetura, escolha sua plataforma de desenvolvimento, deixe bem claro os teus requisitos funcionais e não funcionais, especifique os teus requisitos, encare o projeto da forma correta, mesmo sendo apenas para aprendizado.

Depois de ter feito todas as suas definições, comece a construção da sua infraestrutura, pegue os requisitos que possuem impacto arquitetural e tente implementar eles.

A parte de acabamento você vai fazer depois, estilizar, fazer telas, dá cara para seu projeto…

Bom, é isso, claro que foi bem simplório, mas dá para você ter uma ideia.

Ao que o ikbm responde:

lkbm:

lanlico:

Com construção de software não é diferente…

Na verdade, desenvolvimento de software é completamente diferente de construção civil.

Ao que você responde:

A H Gusukuma:

lkbm:

lanlico:

Com construção de software não é diferente…

Na verdade, desenvolvimento de software é completamente diferente de construção civil.

Claro, mas tem muitas similaridades.
De onde veio os padrões de projeto?

Como você não explicou nada, passa a clara impressão de que está defendendo o que disse lanlico. Repare no uso da palavra MUITAS antes de similaridades.

Sério que o que você quis dizer aqui foi: “Claro, mas usa alguns termos em comum, como construção, testes, viabilidade.”?

Você insiste em dizer que eles se parecem embora não diga nem como nem onde e eu insisto em dizer que não.

Elas não tem qualquer similaridade, são processos completamente distintos, exceto pelo uso de alguns termos emprestados, e somente os termos, tendo eles significados completamente diferentes entre as áreas.

Eu não tenho a menor pretensão de mudar o que você pensa, eu insisto nas respostas apenas para deixar claro para quem lê ou vai ler daqui a um tempo que existe uma outra forma de se pensar sobre software, que é bem distante da comparada a engenharia civil e que tanto mal já causou, e continua causando na nossa área.

YvGa:

Como você não explicou nada, passa a clara impressão de que está defendendo o que disse lanlico. Repare no uso da palavra MUITAS antes de similaridades.

Sério que o que você quis dizer aqui foi: “Claro, mas usa alguns termos em comum, como construção, testes, viabilidade.”?

Você insiste em dizer que eles se parecem embora não diga nem como nem onde e eu insisto em dizer que não.

Elas não tem qualquer similaridade, são processos completamente distintos, exceto pelo uso de alguns termos emprestados, e somente os termos, tendo eles significados completamente diferentes entre as áreas.

Eu não tenho a menor pretensão de mudar o que você pensa, eu insisto nas respostas apenas para deixar claro para quem lê ou vai ler daqui a um tempo que existe uma outra forma de se pensar sobre software, que é bem distante da comparada a engenharia civil e que tanto mal já causou, e continua causando na nossa área.

Não me constava que no mercado se compara construção civil com desenvolvimento de software no sentido que estão falando. Nunca, em muitos anos de carreira, alguém citou alguma coisa nesse sentido. Nem usuário nem pessoal de TI.

Veja o caso de usabilidade, em software temos que ver fatores como, facilidade de uso, de aprendizado, de obter resultados, de navegação, simplicidade, etc. Em arquitetura, circulação, iluminação, ventilação, conforto, etc.
Não tem nada a ver?
É muito tosco ficar na comparação dos produtos finais, ou não.

A H Gusukuma:

Não me constava que no mercado se compara construção civil com desenvolvimento de software no sentido que estão falando.
Nunca, em muitos anos de carreira, alguém citou alguma coisa nesse sentido. Nem usuário nem pessoal de TI.

Mas já deve ter ouvido falar de projetos que degeneraram em caos e produto final que foi recusado pelo cliente porque era difícil de usar ou simplesmente não atendia as reais necessidades do cliente?

lkbm:

A H Gusukuma:

Não me constava que no mercado se compara construção civil com desenvolvimento de software no sentido que estão falando.
Nunca, em muitos anos de carreira, alguém citou alguma coisa nesse sentido. Nem usuário nem pessoal de TI.

Mas já deve ter ouvido falar de projetos que degeneraram em caos e produto final que foi recusado pelo cliente porque era difícil de usar ou simplesmente não atendia as reais necessidades do cliente?

O lance de nunca ter ouvido citar comparação nesse sentido com construção civil em TI pode ser porque é um assunto inconveniente para quem toma as decisões na empresa, logo aqueles que são pagos por eles (usuários e pessoal de TI) não tem mesmo incentivo pra falar no assunto. Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.

Agora eu não concordo em querer mudar como as empresas pensam. Quanto mais elas comprarem sua idéia que TI é similar com construção civil e fracassarem, mais fácil pra mim, e outros programadores que realmente entendem de software, se destacarem no mercado.

lkbm:

O lance de nunca ter ouvido citar comparação nesse sentido com construção civil em TI pode ser porque é um assunto inconveniente para quem toma as decisões na empresa, logo aqueles que são pagos por eles (usuários e pessoal de TI) não tem mesmo incentivo pra falar no assunto. Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.

Sinceramente, quando projetos fracassam ou sejam sucessos, eu costumo procurar os reais motivos para o ocorrido. Colocar a culpa das incompetências ou competências dessa maneira simplista é o caminho para o auto-engano.

lkbm:

Agora eu não concordo em querer mudar como as empresas pensam. Quanto mais elas comprarem sua idéia que TI é similar com construção civil e fracassarem, mais fácil pra mim, e outros programadores que realmente entendem de software, se destacarem no mercado. ;)

Desculpa, mas não vejo como dizer que existem vários incentivos e conflitos de interesse envolvidos seja mais simplista pra você do que achar que existe um, e apenas um, motivo para projetos falharem.

Minha desconfiança se confirma, o problema é de entendimento!

Deixa eu explicar:
“Sinceramente, quando projetos fracassam ou sejam sucessos, eu costumo procurar os reais motivos para o ocorrido.”. Ponto. “Colocar a culpa das incompetências ou competências dessa maneira simplista” (como você colocou em: “Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.”) " é o caminho para o auto-engano."
Deu para entender?

Minha desconfiança se confirma, o problema é de entendimento!

Deixa eu explicar:
“Sinceramente, quando projetos fracassam ou sejam sucessos, eu costumo procurar os reais motivos para o ocorrido.”. Ponto. “Colocar a culpa das incompetências ou competências dessa maneira simplista” (como você colocou em: “Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.”) " é o caminho para o auto-engano."
Deu para entender?

Bom, você não disse porque esses motivos que citei não podem ter sido os reais causadores de fracasso nos projetos que participei, nem quais “reais” motivos você encontrou nos projetos que participou. Isso é uma anti-resposta, no sentido que fornece a ilusão de uma resposta quando na verdade ela não existe.

Se considerar que estou pelo menos apontando um motivo, enquanto você diz que o motivo é “mal-encaminhamento”, não acho que estou sendo tão simplista quanto você até agora.

,

lkbm:

Bom, você não disse porque esses motivos que citei não podem ter sido os reais causadores de fracasso nos projetos que participei, nem quais “reais” motivos você encontrou nos projetos que participou. Isso é uma anti-resposta, no sentido que fornece a ilusão de uma resposta quando na verdade ela não existe.

Se considerar que estou pelo menos apontando um motivo, enquanto você diz que o motivo é “mal-encaminhamento”, não acho que estou sendo tão simplista quanto você até agora.

Dessa vez fui eu que não entendi direito. Não estava considerando que na sua resposta eram projetos que você participou, não me pareceu ser essa situação. Quando disse “na quantidade [de] projetos…”, deu-me a impressão de que estava falando “muitos”, daí pensei que estava falando de forma mais genérica, desculpe-me a falha.

No meu caso, de todos os projetos que participei, apenas um projeto não foi ok. Mas, eu me incluo como um dos responsáveis pelo insucesso. Avaliamos mal o escopo e os recursos, mas abortamos logo após o início.

Se detectou o problema no início e abortou o projeto, não é um exemplo de projeto mal encaminhado na minha compreensão.

Mas já deve ter ouvido falar de projetos que degeneraram em caos e produto final que foi recusado pelo cliente porque era difícil de usar ou simplesmente não atendia as reais necessidades do cliente?

Até onde sei, não é possível detectar problemas de usabilidade do software, ou software que não faz o que o cliente pediu, na fase inicial do projeto. Logo, podemos deduzir pela sua resposta que nunca ouviu falar de projetos assim?

lkbm:

A H Gusukuma:

No meu caso, de todos os projetos que participei, apenas um projeto não foi ok. Mas, eu me incluo como um dos responsáveis pelo insucesso. Avaliamos mal o escopo e os recursos, mas abortamos logo após o início.

Se detectou o problema no início e abortou o projeto, não é um exemplo de projeto mal encaminhado na minha compreensão.

Até onde sei, não é possível detectar problemas de usabilidade do software, ou software que não faz o que o cliente pediu, na fase inicial do projeto.
Concordo, é claro.

Logo, podemos deduzir pela sua resposta que nunca ouviu falar de projetos assim?

Se foram apenas problemas que puderam ser detectados no início, da entender que nunca teve projetos com problema de usabilidade ou de produto não atender as expectativas do cliente, já que essas situações não podem ser detectadas no início, mas não fica claro, não da pra deduzir. Por isso minha pergunta. rs

Em outras palavras, se tivesse antecipado o problema. Acho que estou começando a entender porque acha desenvolvimento de software similar a engenharia.

Mas e quanto a problemas de usabilidade, de não fazer o que se pede, e tantos outros problemas que podem surgir durante a implementação de um software, e que não podem ser detectados e corrigidos no início como seria por um engenheiro numa obra?

lkbm:

A H Gusukuma:

O erro foi ter deixado iniciar, poderia ter optado por não iniciar se tivesse feito uma análise mais cuidadosa da situação.

Em outras palavras, se tivesse antecipado o problema. Acho que estou começando a entender porque acha desenvolvimento de software similar a engenharia.

Mas e quanto a problemas de usabilidade, de não fazer o que se pede, e tantos outros problemas que podem surgir durante a implementação de um software, e que não podem ser detectados e corrigidos no início como seria por um engenheiro numa obra?

Creio que continua sem entender, eu vou repetir: eu não disse que desenvolvimento de software é similar a engenharia.

O grande diferencial de desenvolvimento de software é o fato de que ele deve ser flexível, engessar o projeto pela inflexibilidade é um dos fatores que mais inviabilizam o desenvolvimento de bons produtos.

A H Gusukuma:

Creio que continua sem entender, eu vou repetir: eu não disse que desenvolvimento de software é similar a engenharia.

Mas as pessoas que tomam as decisões nas empresas dizem: e o motivo que elas dizem isso é porque querem acreditar que fazendo uma análise mais cuidadosa da situação antes, eles podem evitar os problemas surgirem durante a implementação no futuro.

O problema com isso é que o conhecimento sobre o software muda enquanto esta sendo implementado, diferente da engenharia, onde o conhecimento da ponte não muda enquanto os pedreiros estão construindo.

Ser flexível ou ser bom, são coisas tão subjetivas que vou considerar essa como mais uma das suas anti-respostas que não dizem nada.

lkbm:

A H Gusukuma:

Creio que continua sem entender, eu vou repetir: eu não disse que desenvolvimento de software é similar a engenharia.

Mas as pessoas que tomam as decisões nas empresas dizem: e o motivo que elas dizem isso é porque querem acreditar que fazendo uma análise mais cuidadosa da situação antes, eles podem evitar os problemas surgirem durante a implementação no futuro.

O problema com isso é que o conhecimento sobre o software muda enquanto esta sendo implementado, diferente da engenharia, onde o conhecimento da ponte não muda enquanto os pedreiros estão construindo.

Ser flexível ou ser bom, são coisas tão subjetivas que vou considerar essa como mais uma das suas anti-respostas que não dizem nada.

A idéia que o conhecimento sobre o software é único deve explicar porque alguém considera similar a engenharia. Afinal, como uma ponte seria erguida ou produto fabricado numa linha de montagem, se o conhecimento sobre o que deve ser construído mudasse a cada etapa do processo? Não seria possível, de maneira eficiente, gerenciar uma equipe de operários e obreiros assim.

Mas isso não quer dizer que software é similar a engenharia, apenas que alguém decidiu usar engenharia e técnicas de gestão tradicional (mão de obra), pra desenvolver software.

Por outro lado, a idéia que o conhecimento sobre o software não é estático, mas dinâmico, e esta em constante mudança, me parece mais correta. Inclusive é uma das premissas básicas das metodologias consideradas “ágeis”.

lkbm:

A idéia que o conhecimento sobre o software é único deve explicar porque alguém considera similar a engenharia. Afinal, como uma ponte seria erguida ou produto fabricado numa linha de montagem, se o conhecimento sobre o que deve ser construído mudasse a cada etapa do processo? Não seria possível, de maneira eficiente, gerenciar uma equipe de operários e obreiros assim.

Mas isso não quer dizer que software é similar a engenharia, apenas que alguém decidiu usar engenharia e técnicas de gestão tradicional (mão de obra), pra desenvolver software.

Por outro lado, a idéia que o conhecimento sobre o software não é estático, mas dinâmico, e esta em constante mudança, me parece mais correta. Inclusive é uma das premissas básicas das metodologias consideradas “ágeis”.

De fato, a princípio ficou um pouco estranho porque se alguma coisa é única, não pode ser flexível, já que o que é único não muda, ou seja, é estatico.

Mas ficou mais claro do que o primeiro post que não estava acompanhado do que quer dizer por flexível.