GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

diferença entre projetista e arquiteto


#1

Alguem poderia me explicar a diferença entre projetista e arquiteto ?? Eu entendo que o arquiteto é quem faz o projeto do software, não ??


#2

Ate onde eu sei arquiteto eh quem define frameworks, estrutura, divisao de componentes do sistema, essas coisas mais alto nivel.

Projetista pega um caso de uso, le e escreve um projeto (diagrama UML por exemplo) explicando como deve ser codificado.

Algo assim.


#3

Nao é por ae não... Arquiteto não é só isso não, é MUITO mais alem... Definir frameworks é só detalhe. Bom arquiteto se preocupa sim dim divisão de componentes, suas interfaces, etc... o que vale dizer é que arquiteto se preocupa principalmente com coisas importantes no sistema... Enfim... há muito que o arquiteto deve fazer, existem muitos artigos da IBM, etc que explica isso de forma mais correta (to com preguiça de ser mais detalhista), enfim...

Mas NUNCA confunda desenvolvedor senior com arquiteto.... existem muitos desenvolvedores seniors aqui que se considera arquiteto, principalmente no que se trata de tecnologia... Tem uma cambada de baba ovo de Spring aqui que mostra como qualquer idiota pode pegar um cracha e escrever arquiteto nele... Arquitetura é principalmente tomada de decisão, e não 'Eu sei Spring, babo ovo de Spring, e qualquer idiota que nao gosta é imbecil que nao sabe o que é AOP, IoC, etc bem feito e bla bla' ... Some desse tipo de arquiteto, ele nao é arquiteto, é um idota como varios em nossa profissao que nem sabe o que faz... Desenvolvedores não adoram falar mal de gerente de projeto que nao sabe o que é projeto de tecnologia? Entao esse gerentes sao idiotas e todo muito sabe... Da mesma forma existem arquitetos que nem sabe o que é ser um arquiteto, o problema é que ainda ninguem falou isso pra ele.


#4

bom, tá aqui um doa artigos que estou falando:

http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/apr01/CommonMisconceptionsaboutSoftwareArchitectureApr01.pdf


#5

O que seriam essas "coisas importantes do sistema"?


Quanta mágoa no coração!

Agora sério, se arquitetura é tomada de decisão, acredito que isto pode ser feito até pelo programador júnior, se ele tiver embasamento o bastante para isso e o resto da equipe for inteligente o bastante para dar ouvidos a ele neste caso. Então, qual a necessidade de se diferenciar tanto desenvolvedor de arquiteto afinal?


#6

Resumindo:


#7

Em um ambiente onde as coisas são "jogadas por cima do muro" (coisa execrada em RUP, XP, Scrum e qualquer outra emtodologia séria) geralmente se chama de arquiteto o cara que toma macro-decisões sobre o projeto e de projetista o sujeito que tenta programar em UML.

Programadro é oc ara que pega toda a fanstasia e tenta criar a única coisa que importa: software.

'Projetista' é um papel que os gurus da ciência da computação já aboliram há décadas mas algumas empresas insistem em tentar mantêr. Fazia sentido quando você tinha uma śerie de transformações entre o modelo lógico e o físico mas hoje com um mapeamento quase 1-para-1 não faz qualquer sentido.


#8

hummm, não.... Arquiteto ajuda a encontrar risco de projeto, procura principalmente necessidades não funcionais, promove conhecimento aos desenvolvedores, verifica se o plano de arquitetura/metricas/praticas esta sendo seguido pelos desenvolvedores, ajuda na formação da equipe (verificando qualificacao necessaria), ajudar a avaliar o planejamento do projeto (dando informações tecnicas ao gerente de projeto), enfim...

bom, mais 2 artigos que ajudam entender o que ´arquitetura:

http://www-128.ibm.com/developerworks/rational/library/feb06/eeles/

http://www-128.ibm.com/developerworks/rational/library/mar06/eeles/index.html

Ps: Ignorem o que o s4nchez disse sobre que qualquer um é capaz de tomar decisão


#9

Seria mais fácil você responder meus questionamentos, não?

Apropósito, você citou tarefas que podem muito bem ser executadas por qualquer desenvolvedor (ajudar na formação da equipe, encontrar risco de projeto, dar feedback técnico aos gerentes). Se a empresa precisa de uma pessoa específica para este fim e dá o nome de arquiteto tudo bem, mas ainda não entendi qual a necessidade de se diferenciar tanto este papel do resto da equipe (e por isso respondi em primeiro lugar)


#10

Gente, vamos conversar sem brigas, OK? Não há necessidade nenhuma de bate-boca.

Eu concordo com a descrição que o Jordan deu sobre o "cargo" de Arquiteto. Mas também concordo com o Sanchez que não há nada que um Arquiteto faça que um Desenvolvedor experiente não possa fazer. Essa pode não ser a definição correta de Arquiteto, mas é o que eu vejo e vi nas empresas que passei.

A impressão que eu tenho é que o Arquiteto é o degrau acima do Desenvolvedor Sênior, e com a diferença de que o Arquiteto está muito mais focado na infraestrutura do sistema do que com a lógica de negócios que aquele sistema implementa.

Existe uma definição de Arquiteto?


#11

Existe uma grande diferença entre papel e cargo... Vc pode possuir um cargo de desenvolvedor e executar o papel, as tarefas, ou como vc quiser chamar, de um arquiteto e de um desenvolvedor... e contrario tb...

E em relação de seus 'questionamentos', se isso pode-se chamar de questionamento, eu postei 3 links e se pesquisar possuem vários na internet...

Bom, coisas importantes no sistema que o PAPEL de arquiteto deve verificar é POR EXEMPLO, é a interação entre alguns componentes. O componente de venda precisa do componente de clientes e do componente de produtos.... Pronto.


#12

Perfeito... E que eu me lembre nunca disse que eram a mesma coisa. Minha dúvida é só no que se refere a necessidade deste rótulo de "Arquiteto", uma vez que até onde eu vi ele não faz nada além do que os desenvolvedores mais experientes já fazem.

Se não quer responder basta ignorar. É mais fácil e fica menos feio do que desmerecer a pergunta.

Mais uma vez, isso é coisa que o PAPEL de desenvolvedor já inclui :wink:


#13

Questionamento geralmente ocorre quando vc 'vai contra' contra um ideia... Aquilo foi uma simples pergunta

Hummm, não... uma das coisas que discutimos na pos de arquitetura é exatamente isso. Maioria NÃO consegue entender e NUNCA vai entender... Bom, go learn : http://www.sei.cmu.edu/architecture/arch_duties.html

PS: essa sua ultima frase foi um questionamento


#14

Qual o curso de pós que você faz? Gostaria de ler a ementa do curso para entender do que se trata. No link que você me mandou há uma discussão sobre os deveres do Chief Software Architect, o que me parece ir mais além ainda do que o papel do Arquiteto, não?

Pra mim o difícil de entender não é o que é o Arquiteto, e sim o que justifica ter este papel destacado dentro da equipe, inclusive separando uma pessoa exclusiva para esta função.


#15

Por isso que eu disse que ser arquiteto é muito alem de escolher frameworks e é muito alem de ser desenvolvedor senior...

Bom, eu faço na puc, nao to achando a ementa do curso pq acho q eles tiraram da internet... bom, te falo q é muito bom, te dá um otima visão sobre arquitetura, algo que nunca tinha imaginado...


#16

Ei, calma rapazes.

Para inicio de conversa, não existe definição oficial do que é arqutietura porque não existe orgão oficial. Honestamente: a bibliografia do SEI sobre arquitetura é horrivel. CBAN, por exemplo, é algo que merece ser catalogado de anti-pattern.


#17

Seria esse o seu curso -> http://www.pucminas.br/cursos/dados_cursos.php?tipo=2&pai=52&pagina=5&ordem=alfa&curso=1196&PHPSESSID=502c16abb86b681901a52f31521d489e


#18

Ia comentar isso agora shoes... rs


#19

Cara, na minha opinião, essas nomenclaturas são podres demais.

Uma leitura legal é a seguinte:
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf


#20

Code Complete:

Na fase de arquitetura definem-se:

Componentes arquiteturais típicos, organização do programa, as classes principais, design dos dados, regras de negócio, design de interface com o usuário, gerenciamento de recursos, segurança, performance, escalabilidade, interoperabilidade, internacionalização/localização, I/O, processamento de erros, tolerância à falhas, viabilidade do projeto, robustez, decisões "comprar pronto" vs. "desenvolver do zero", decisões de reúso, estratégia de mudanças e qualidade geral.

E uma lista de tópicos que o arquiteto tem que pensar (em inglês, preguiça de traduzir):

Arquiteto é o cara responsável por pensar e responder, por si e pela equipe, sobre tudo isso.