Um View de Engenharia de Requisitos

Um dos poucos assuntos, que vejo aqui no GUJ sobre esse tema (Engenharia de Requisitos), no entanto gostaria de explora-lo mais.

:arrow: Em muitas consultorias ou mesmo em reuniões o Engenheiro de Requisitos se confundi, com o que seria um Arquiteto de Software.

:arrow: A Capturar requisitos e entrevistas, penso eu que requer um nível cultural diversificado e bem descolado desse profissional que deva entender os requisitos sistemicos e de interesses dos chamados stakeholders . Porém a separação de responsabilidades é sempre algo que tende ser conflitante pois a gerencia se coloca como o cliente e nisso, se trava todo um divisão de papeis.

:stuck_out_tongue: Sabemos que a coreografia de processos não é igual a um projeto e outro, então ai vem a situação como se colocar perante um assunto de alta relevância.

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

[quote=cmoscoso]
[Marcio Duran]

coreografia de processos

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

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

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);
  }      
  
}

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

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.
[/quote]

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.

[quote=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.[/quote]

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.

[quote=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.[/quote]

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

:stuck_out_tongue: Agora temos um Scrum Master desconexo !!!

:wink: 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.

[quote=cassio][code]
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);
}

}
[/code][/quote]

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

[code]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;
}
}[/code]

[quote=Marcio Duran][quote=cassio][code]
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);
}

}
[/code][/quote]

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

[code]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;
}
}[/code][/quote]

É 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 :slight_smile:

Fui brincar mas vi que o problema é mesmo gigante… nem falo mais nada :slight_smile:

  1. 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 :stuck_out_tongue:

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

[quote=bobmoe][quote=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.
[/quote]

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).[/quote]

++

:shock: Credo !!!

[quote]
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).[/quote]

:stuck_out_tongue: O lucas é aquele falso profeta !!!