Um View de Engenharia de Requisitos

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

Isso é que dá não ignorar o cara, as vezes rende umas boas risadas ! :lol: :lol:

Nossa,

O que você quer dizer com engenheiro de requisitos se confundi com arquiteto de software? Acredito que são papéis em extremos diferentes e nunca vi alguem fazer essa confusão.

[]s

cmoscoso:

[Marcio Duran]

…coreografia de processos…

Isso é que dá não ignorar o cara, as vezes rende umas boas risadas ! :lol: :lol:

:idea:Orquestração e Coreografia são dois termos comumente utilizados para composição de processos de negócio através de Web Services, sendo muitas vezes usados um no lugar do outro, o que causa problemas.

[size=18]Orquestração[/size]

:arrow: Composição de processos de negócio (através de webservices) onde existe a figura de um processo central (processo mestre) que controla e coordena os demais processos. Neste tipo de composição, cada processo participante não tem conhecimento de que faz parte de uma composição de processos, com exceção do processo mestre.

:idea: Somente o processo mestre detém a inteligência sobre o processo completo, e a execução é então centralizada.

:idea: Devido a essa centralização, orquestrações ocorrem normalmente dentro de uma mesma corporação, uma vez que dentro dessa corporação é simples decidir qual processo será o processo-mestre.

[size=18]Coreografia[/size]

:arrow: Composição de processos de negócio (através de webservices) onde não existe a figura de um processo mestre que controla e coordena os demais processos. Neste tipo de composição, cada processo envolvido tem o conhecimento de que faz parte de uma composição de processos e que precisa interagir com outros processos de maneira ordenada para que a composição resultante tenha sucesso.

:arrow: Cada processo participante sabe exatamente quando atuar, com quais outros processos participantes interagir, quais operações deve executar, quais mensagens deve trocar e o até mesmo o momento adequado de troca de mensagens.

:idea: Devido à esta descentralização, coreografia de processos costuma ser utilizada entre processos ou webservices de corporações distintas.

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. (…)

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.

embora seja dificil aceitar o termo engenheiro ou arquiteto como o nome de um curso ou de uma posição na empesa isso não significa que o trabalho feito por pessoas nesse papel (role) não seja relevante.

Sim, o cliente não sabe o que quer. Ele sabe o que espera do sistema, mas não o como espera isso. Muitas vezes o desenvolvedor tem que fazer escolhas ditadas pela inepcidade do cliente em decidir ou entender os problemas levantados pela sua propria necessidade. Especialmente quando os processos de negocios são divergentes do senso comum, das normas, ou dos padrões de mercado. Ai sim tem que existe alguem com capacidade de dialogo (peoples-person) que entenda o cliente e saiba comunicar com os desenvolvedores. O nome desse papel (role) não é importante, mas é importante que se reconheça a sua necessidade. Normalmente é chamado de analista.

Arquiteto, desenvolvedor, programador, tester , gerente, etc… são papeis (roles) dentro da peça (play) que é a criação de um software. A critica do publico (cliente) à peça (sistema) pode destrui-lo ou energizá-lo. Logo, é necessário que se entenda o publico.
Em teatro e no ciname isso e tarefa do produtor executivo e quiça do director e escritores, mas em software essa tarefa também tem que caber a alguem. Ela é a diferença entre a ruina e o exito.

O erro é achar que Arquiteto é um posto na empresa. Que o cara faz apenas aquilo. Tal como tester ou programador ou desenvolvedor. Esse é o erro. Cada um deve fazer todos os papeis. A questão é que são poucas as pessoas que tem capacidade para todos os papeis. Por isso ocorre a especilização. Algo que é o cerne da cultura mundial atual e contra o que é dificil lutar.

O texto do Fowler que citaste é hipocrita*. Desce o pau no termo “arquitetura” porque ele não o consegue definir. Mesmo quando consegue não aceita a definição, mas ele proprio confessa que o termo pertencia no titulo do seu livro. É o mesmo que dizer “não sei o que “arquitetura” significa mas usei o termo para vender livros”. Esse tipo de discurso é inaceitável como evidência de que a arquitura não é necessária. Se ela não fosse, não precisava estar no titulo …
Confundir “arquiteto” com “guia” é o minimo nunca ter sabido, para começo de conversa, o que é um arquiteto. O que aliás fica patente no texto logo cedo. a pergunta não é “quem precisa de um arquiteto?” (cuja resposta é “todo o mundo”) mas sim “O que é um arquiteto?” ou “O que é arquitetura?”

A falta de estrutura, de visão do todo, num projeto é um erro grave.
Ele tem que ter a visão do todo pois o arquiteto é suposto decidir sobre requisitos não-funcionais ( ao contrario do desenvolvedor ) que afetam o sistema. Protocolos de comunicação, ambiente de rede, inclusão ou exclusão de mecanismos de segurança, performance , escalabilidade, etc… É com certeza um papel que é desempenhado no inicio do projeto e que será muito exporádiamente chamado durante o resto do processo ( se o sistema é standalone torná-lo cliente-servidor é fazer outro sistema). No meio tempo a mesma pessoa pode ser desenvolvedor, programador, tester, gerente, ou seja, pode ter outros papeis na construção do software.
O ponto é que cabe a ele decidir, não apenas saber e entender. Isso todos os intervenientes têm que ser capazes de fazer.

É porque o papel é temporário e porque exige sim uma maior cultura e conhecimento das tecnologias ( do maior numero possivel e relevante delas) que é dificil ter mais do que um arquiteto no projeto. Contudo não é impossivel ter mais do que um.

(*consultem um dicionário antes de de vir defender a honra do cara…)

Marcio, se você nao é capaz de escrever com suas proprias palavras nao deixe de dar credito a quem você copia na cara dura.

Eu ja imaginava que “coreografia de processos” vem da WS-Deathstar… realmente não é nada engraçao, é trágico!

editado: inclui sua citação pra ficar mais evidente o copy-and-paste.

Luca:

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.

Luca… massagista de software é o que mais tem… :lol: :lol: :lol:

E lendo o resto da thread creio que teremos o coreógrafo de processos de desenvolvimento de software. É só o que faltava, um Carlinhos de Jesus na nossa área.

cmoscoso:

Marcio, se você nao é capaz de escrever com suas proprias palavras nao deixe de dar credito a quem você copia na cara dura.

Eu ja imaginava que “coreografia de processos” vem da WS-Deathstar… realmente não é nada engraçao, é trágico!

editado: inclui sua citação pra ficar mais evidente o copy-and-paste.

:idea: Eu escrevi com as minhas palavras, mas como você foi sarcástico e nem mesmo procurou algo para questionar melhor, praveleceu a ignorância pela intolerância da sua conduta sarcástica.

:idea: pro seu nível um copy-and-paste é bem aceito.

:shock: Foi você que me perguntou o que era Modelo de Processo “Synergy”, agora vai ficar desconexo com o que não pode melhor contra-argumentar, e vai vender SCRUM no meio disso tudo.

Agora temos um Scrum Master desconexo !!!

Você ao menos sabe interpretar o que foi escrito :?: , naturalmente você atua em cargo que não é de liderança e isso deve mesmo lhe confundir.

cassio:

public interface Pensamento {
  public boolean fazSentido(); 
}

public class MarcioDuranPensamento implements Pensamento {
  
  private String conteudo;
  
  public MarcioDuranPensamento(String conteudo) {
    this.conteudo = conteudo; 
  }
  
  public boolean fazSentido() { return false; }  
  
}

public class MarcioDuran {
  private List<Pensamento> pensamentos = new ArrayList<Pensamento>();
  
  public MarcioDuran() {    
    for(i = 0; i < 100000; ++i) 
      pensamentos.add(new MarcioDuranPensamento(null));
  }
  
  public void postarNoGuj() {
    Collections.shuffle(pensamentos); 
    Guj.criarNovoPost(this, pensamentos.get(0));  
    pensamentos.remove(0);
  }      
  
}

:idea: Não sabe nem digitar !!! Então ao menos aprende o que é interface

public interface Pensamento {
	public void Ser();
	public void NaoSer();

}
public class Intelecto implements arrogancia {
	public void ser();
	ser=true;
}
public void NaoSer(){
	ser=false;
 }
}
public class hipocresia implements Pensamento{
	public void ser(){
		ser=true;
	}
	public void NaoSer(){
		ser=false;
	}
}

Marcio Duran:

cassio:

public interface Pensamento {
  public boolean fazSentido(); 
}

public class MarcioDuranPensamento implements Pensamento {
  
  private String conteudo;
  
  public MarcioDuranPensamento(String conteudo) {
    this.conteudo = conteudo; 
  }
  
  public boolean fazSentido() { return false; }  
  
}

public class MarcioDuran {
  private List<Pensamento> pensamentos = new ArrayList<Pensamento>();
  
  public MarcioDuran() {    
    for(i = 0; i < 100000; ++i) 
      pensamentos.add(new MarcioDuranPensamento(null));
  }
  
  public void postarNoGuj() {
    Collections.shuffle(pensamentos); 
    Guj.criarNovoPost(this, pensamentos.get(0));  
    pensamentos.remove(0);
  }      
  
}

:idea: Não sabe nem digitar !!! Então ao menos aprende o que é interface

public interface Pensamento {
	public void Ser();
	public void NaoSer();

}
public class Intelecto implements arrogancia {
	public void ser();
	ser=true;
}
public void NaoSer(){
	ser=false;
 }
}
public class hipocresia implements Pensamento{
	public void ser(){
		ser=true;
	}
	public void NaoSer(){
		ser=false;
	}
}

É caro amigo, acho que a situação pro seu problema é suicídio mesmo...
Você com certeza:
1) Não entendeu o que eu quis dizer...
2) Não sabe escrever hipocrisia
3) Não sabe MESMO o que é uma interface
4) Não sabe que se você deixar um método sem implementação em uma classe concreta vai dar pau :-)

Fui brincar mas vi que o problema é mesmo gigante... nem falo mais nada :-)

8. Dona esperteza !!!

:arrow: Você com certeza:

1. Entendeu o que eu quis dizer…
2. Sabe escrever hipocrisia
3. Sabe MESMO o que é uma interface
4. Sabe que se você deixar um método sem implementação em uma classe concreta vai dar pau

:thumbup: Mas vi que o seu problema não é mesmo tão [size=24]GIGANTE[/size] assim !!!

Não perderei mais meu tempo lendo seus posts disconexos

Luca,

Com certeza vc sabe do que está falando, mas ainda estou com a pulga atrás da orelha pelos seguintes motivos:

• 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).

bobmoe:

Luca:

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.

Luca,

Com certeza vc sabe do que está falando, mas ainda estou com a pulga atrás da orelha pelos seguintes motivos:

• 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).

++

:shock: Credo !!!

Luca,

Com certeza vc sabe do que está falando, mas ainda estou com a pulga atrás da orelha pelos seguintes motivos:

• 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).

O lucas é aquele falso profeta !!!

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á

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

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)

Luca:

Olá

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

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)

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

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

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?