Um View de Engenharia de Requisitos

Considerando o inferno que uns amigos meus passam p/ se formarem engenheiros eletricistas, eu diria que a minha engenharia (de software) é piada perto da deles.

Talvez isso seja por que ninguém morre (diretamente) se um software mal-projetado ruir, nem caçam a tua carteira, e nem te prendem por isso.

Olá

[quote=bobmoe]- Programar é projetar: Quando estou programando primeiro penso na melhor estratégia para só então resolver o problema através de um plano de execução (mental é claro).

  • Programar é um processo empírico: Utilizo métodos científicos para resolver problemas práticos.

Ainda não consigo entender porque o desenvolvimento não pode ser considerado uma atividade de engenharia (até entendo que transformar isso em cargo não seja uma boa idéia).[/quote]

  1. Projeto de engenharia é TOTALMENTE diferente de projeto de software. Sob determinados aspectos,projetos de engenharia são mais simples e mais fáceis (para quem sabe) porque são determinísticos enquanto os projetos de software são empíricos

  2. Confundir desenvolvimento de software com engenharia talvez tenha sido um dos grandes erros nas teorias e métodos de desenvolvimento de sistemas. Hoje para mim isto é óbvio mas confesso que já gerenciei projetos usando Project, fazendo cronogramas (que nunca batiam é claro) e tentando entender um projeto de software como se fosse um projeto de engenharia.

Antigamente a nossa profissão tinha um nome próprio: análise de sistemas. Todo mundo entendia que um analista de sistemas era o cara que sabia desenvolver um sistema desde a primeira entrevista com o cliente até os testes finais de aceitação e homologação. Hoje inventaram um monte de outros nomes, desgastaram o termo antigo e virou esta bagunça. Para mim, engenharia de requisitos é um termo sem sentido.

Por mim, até para evitar a famosa e perniciosa confusão de engenharia com desenvolvimento de sistemas, acabava logo com o uso de termos de engenharia como blueprints (outra idiotice como se software fosse feito por plantas de engenharia) e o hábito de chamar de engenheiro alguém que precisa ter outras habilidades que normalmente engenheiro NÃO tem.

[]s
Luca (feliz por saber que ninguém pensa que é profeta)

[quote=Luca]Olá

[quote=bobmoe]- Programar é projetar: Quando estou programando primeiro penso na melhor estratégia para só então resolver o problema através de um plano de execução (mental é claro).

  • Programar é um processo empírico: Utilizo métodos científicos para resolver problemas práticos.

Ainda não consigo entender porque o desenvolvimento não pode ser considerado uma atividade de engenharia (até entendo que transformar isso em cargo não seja uma boa idéia).[/quote]

  1. Projeto de engenharia é TOTALMENTE diferente de projeto de software. Sob determinados aspectos,projetos de engenharia são mais simples e mais fáceis (para quem sabe) porque são determinísticos enquanto os projetos de software são empíricos

  2. Confundir desenvolvimento de software com engenharia talvez tenha sido um dos grandes erros nas teorias e métodos de desenvolvimento de sistemas. Hoje para mim isto é óbvio mas confesso que já gerenciei projetos usando Project, fazendo cronogramas (que nunca batiam é claro) e tentando entender um projeto de software como se fosse um projeto de engenharia.

Antigamente a nossa profissão tinha um nome próprio: análise de sistemas. Todo mundo entendia que um analista de sistemas era o cara que sabia desenvolver um sistema desde a primeira entrevista com o cliente até os testes finais de aceitação e homologação. Hoje inventaram um monte de outros nomes, desgastaram o termo antigo e virou esta bagunça. Para mim, engenharia de requisitos é um termo sem sentido.

Por mim, até para evitar a famosa e perniciosa confusão de engenharia com desenvolvimento de sistemas, acabava logo com o uso de termos de engenharia como blueprints (outra idiotice como se software fosse feito por plantas de engenharia) e o hábito de chamar de engenheiro alguém que precisa ter outras habilidades que normalmente engenheiro NÃO tem.

[]s
Luca (feliz por saber que ninguém pensa que é profeta)[/quote]

Agora estou vendo alguns erros (meus):

Eu estava tentando separar a atividade de engenharia dos processos, ou seja, olhando o desenvolvedor como um engenheiro, pois utiliza a ciência para resolver problemas práticos.
Na verdade a atividade de engenherio não pode ser separada de processos pois o engenheiro só define.
Quanto aos processos os de engenharia são baseados em previsão, pois eles definem, especificam… os blue prints q vc disse.
Nós trabalhamos com feedback então só podemos definir os objetivos e não especifica-los.

isso q pude tirar de conclusão.

Márcio, Luca:

Acho que vale a pena lembrar que o termo “engenharia de software” foi originalmente uma provocação:
"já que fazer software está tão caótico, por que não usar métodos das engenharias para fazer software ?"
era a mensagem em 1968. “Engenharia de software” nasceu como um trocadilho, mais ou menos como
a “coreografia de requisitos” que foi colocada aqui.

Se uma frase pode ajudar a pensar num problema que incomoda, por que não ? Se depois deu certo ou
não, é outra história. Eu gostei da idéia de comparar os requisitos a uma dança: passa a idéia de
comunicação e de interação com o cliente, algo que faz muita falta. É uma metáfora que vale a pena
explorar.

Pelo histórico associado à literatura de “engenharia de software” que veio depois, o termo acaba tendo
uma conotação negativa para mim, e fico com um pé atrás quando alguém usa “engenheiro” no contexto
de informática. Já temos muitos nomes de cargos na área. Numa empresa em que trabalhei, eu definia
meu cargo como “consultor de assuntos aleatórios”, mas não cheguei a imprimir no cartão de visitas …

Jorge Diz
Mestre em Engenharia Elétrica :slight_smile:

[quote=Luca]Olá

Como engenheiro estudei 5 anos para me formar (mais 2 de mestrado) e nunca gostei do termo engenheiro de software dado a um cara que estudava 3 anos com menor carga horária do que 3 anos de engenharia.

Menos ainda gosto do termo engenharia de requisitos. Para mim requisito é o que o cliente quer. Precisa de um engenheiro para convencer o cliente do que ele quer? Ou a função seria reescrever o que o cliente quer?

Antigamente se dizia que o bom analista de sistemas precisava ser um pouco psicólogo para entender o que cliente pedia e o que ele queria dizer. Agora vem alguém e tasca o rótulo de engenheiro como se engenharia fosse um título adequado para os burocratas da informática. Isto está errado porque engenharia é prática.

Quando é que vão concluir de vez que engenharia é uma coisa e informática é outra? Ou será que depois da engenharia de software e do arquiteto de software ( http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf ), vão criar também os termos médico de software, massagista de software e advogado de software? Os termos fazem tanto sentido como engenheiro e arquiteto.

[]s
Luca[/quote]

como você pode esquecer do engenheiro de vendas ?

http://www.administradores.com.br/noticias/engenheiro_de_vendas_tem_papel_fundamental_para_o_sucesso_das_empresas/11903/

Já disse isso algumas vezes e vou dizer novamente: Por que vocês ainda continuam respondendo as mensagens desse camarada?