pra variar um pouco como sempre, o flame ta liberado quando o Marcião cola hehehehehehehe
Aposto que esta topico vai ser bloqueado.
Antes de continuar: vocês estão falando de analistas de sistemas ou analistas de negócios?
Se for analista de sistemas, o que teoricamente este profissional faz no desenvolvimento de software?
[quote=pcalcado]Antes de continuar: vocês estão falando de analistas de sistemas ou analistas de negócios?
Se for analista de sistemas, o que teoricamente este profissional faz no desenvolvimento de software?[/quote]
Eu penso que eles analisam, teoricamente.
[quote=cmoscoso]
Eu penso que eles analisam, teoricamente.[/quote]
Analisam exatamente o que? Qual eh a entrada e qual a saida?
Eu penso que o papel de analista de sistema é melhor visto na figura do programador que é capaz de desenvolver software que atenda as necessidades.
entao um analista eh um programador?
Exatamente. Um programador analisa uma possivel solucao para problemas relacionados ao software, qnd eles existem.
Pra ficar mais claro, acontece que muitos problemas nao sao relacionados com a construcao do sw em si mas acabam refletindo no desenvolvimento.
Que tipos de problema você está falando? O que constitui essa análise?
Analista de sistemas é o kra que tira os requisitos do sistema e os passa para uma nova versão inteligivel ao programador. Isso inclui, UML no caso da OO.
Só que lendo o post do pcalçado e analisando um pouco mais! Talves o papel e função unica de analista de sistemas tenha se perdida por conta da OO. Passando essa bola para o novo analista de negócios que tem a responsabilidade de retirar os fluxos de negocio da empresa a ser atentida e interfaceando entre a software house e a empresa. (Acho que é isso!)
Acredito que o papel de Analista tenha se fundido ao de programador, ou ao menos se juntado. Analista programador!
[quote=Zakim]
Acredito que o papel de Analista tenha se fundido ao de programador, ou ao menos se juntado. Analista programador! [/quote]
Exatamente. E ha mais de uma década.
Analista de Negócios é algo diferente de Analista de Sistemas e se você precisa de um analista de sistemas isso provavelmente indica problemas com seu processo ou o modo em que você desenvolve software. Ler sobre métodos iterativos, métodos ágeis, domain-driven design, model driven development, testes automatizados e outras coisas não tão modernas pode ajudar a entender que analista de sistemas não faz sentido quando não existe muita transformação entre conceitos de negócios e artefatos de software.
Na ultima empresa no rio que trabalhei, famosa aqui no GUJ, ao tentar adotar as mais modernas praticas o analista de negocio disponivel (SCRUM uma delas, n este caso a figura do product owner) era o tipico analista de sistema da casa. Foi o suficiente pra contaminar o processo, os programadores nao seriam mais responsaveis por levantar requisitos e entao yet-another-waterfall-project se instalou. Neste caso sim penso que foi uma infeliz tentativa de inversao de papeis ja que nao existia espaco mesmo para analistas de sistema.
Analistas de sistemas sao legado das ferramentas 4GL. Concordo que analista de negocio nao é de sistemas e devemos ter sim analistas programadores mas quem nao conhece um projeto cascata contratando hoje?
[quote=cmoscoso]
Analistas de sistemas sao legado das ferramentas 4GL. Concordo que analista de negocio nao é de sistemas e devemos ter sim analistas programadores mas quem nao conhece um projeto cascata contratando hoje?[/quote]
:idea: O Analista de negócio tem que se situar sobre os requisitos de sistema b[/b], quem figura tal possibilidade ao plano de modelo de processo é quem interpreta diretamente os requisitos sistemicos com o stakeholders, é o Analista de requisitos(Use Case), essa herarquia de papéis esta sendo reduzida por motivos de agilizar responsabilidades e não adotar um vasto cenário de funcionalidades que podem ou não se extenderem no projeto, todavia o Analista de Sistema é a visão maiorb[/b] ,à em entender todo esse ciclo de desenvolvimento.
[quote=Marcio Duran] :idea: O Analista de negócio tem que se situar sobre os requisitos de sistema b[/b], quem figura tal possibilidade ao plano de modelo de processo é quem interpreta diretamente os requisitos sistemicos com o stakeholders, é o Analista de requisitos(Use Case), essa herarquia de papéis esta sendo reduzida por motivos de agilizar responsabilidades e não adotar um vasto cenário de funcionalidades que podem ou não se extenderem no projeto, todavia o Analista de Sistema é a visão maiorb[/b] , em entender todo esse ciclo de desenvolvimento.
[/quote]
:shock: Voce acha benefico dividir o projeto em fase de requisitos e outra de implementacao :shock:
:?: Analista de Requisitos non ecziste. Mais alguem sabe o que é isso alem do Marcos?
:arrow: Lamento Marcos por saber que vc se denomina analista de requisitos, mas nao vejo necessidade de intermediarios entre o analista de negocio e os programadores para criacao dos casos de uso. :thumbup:
:idea: Penso sim que algumas vezes a figura de um lider tecnico PODE ser importante. Pra concentrar a comunicacao com o analista de negocio, definir a arquitetura geral, inspecionar codigo e programar claro.
:arrow: Troca o termo fase por ciclo pois estamos falando de projeto , não se [b]entende fase/b sendo igual a responsabilidades e funcionalidades.
[/quote]
Então o Alistair Cockburn enganou a IBM durante anos ???
[quote]
:idea: Penso sim que algumas vezes a figura de um lider tecnico PODE ser importante. Pra concentrar a comunicacao com o analista de negocio, definir a arquitetura geral, inspecionar codigo e programar claro.[/quote]
O Analista de negócio tende a ser um colaborador no projeto, mas não lhe cabe função técnica todavia você deve entender que um colaborador pode até ser stakeholder ligado a comprometimento de entrega aos interesses tanto na pontualidade requisitos desejáveis quanto na pontualidade dos mesmos, para outros stakeholders já ligado com o Product Onwer (sócio da empresa).
Eu diria que vc esta enganado hoje! Casos de uso sao ferramentas para captura de requisitos, bem diferente de ter que ter na equipe uma pessoa apeans pra isso.
Resumindo, nao ha porque existir analista de sistemas, muito menos de requisitos.
[quote=cmoscoso][quote=Marcio Duran] :idea: O Analista de negócio tem que se situar sobre os requisitos de sistema b[/b], quem figura tal possibilidade ao plano de modelo de processo é quem interpreta diretamente os requisitos sistemicos com o stakeholders, é o Analista de requisitos(Use Case), (…)
[/quote]
:shock: Voce acha benefico dividir o projeto em fase de requisitos e outra de implementacao :shock:
:?: Analista de Requisitos non ecziste. Mais alguem sabe o que é isso alem do Marcos?
:arrow: Lamento Marcos por saber que vc se denomina analista de requisitos, mas nao vejo necessidade de intermediarios entre o analista de negocio e os programadores para criacao dos casos de uso. :thumbup:
:idea: Penso sim que algumas vezes a figura de um lider tecnico PODE ser importante. Pra concentrar a comunicacao com o analista de negocio, definir a arquitetura geral, inspecionar codigo e programar claro.
[/quote]
Tá dificil de acertar com o nome do cara … :lol: :lol: :lol: :lol: :lol:
Veja bem, os requisitos são para o software o que as leis da física são para a física e os axiomas para a matemática. São as “verdades absolutas” que o software tem que cumprir. Através dos requisitos vc pode prever o funcionamento do software. (o inverso não é verdade)
Sim, alguns são opcionais e alguns são mais importantes que outros, mas os requisitos - que não são software - são a alma do software quando ele estiver pronto.
Bom, então, o levantamento de requisitos é tão importante quanto o software em si. Um sem o outro não faz sentido. As ferramentas, talentos, condicionamentos, treino, etc… que são necessários para construir software não se assemelham aos de levantamento de requisitos. Tal como os de um matemático não se assemelham ao de um lingüista.
Repare que a competência do programador não é levantar requisitos é implementar um modelo que os cumpre. Um bom programador não necessariamente é um bom “levantador de requisitos” e vice-versa.
É como um cara que é bom de matemática ser bom de linguas. São dois mundos diferentes. Não é impossivel, mas em uma sociedade especializada como a nossa, é muiiito raro.
Sim, pode existir um cara que não sendo especializado em nenhum das duas, entenda as duas e ajude a catalizar o dialogo entre ambos ( quem seria esse ? o coordenador? o lider? o gerente? tanto faz… não ha cursos para : cara-que-sabe-um-pouco-de-tudo-para-entender-todos)
Então existe o cara que é melhor a programar e o cara que é melhor a conversar. Levantar requisitos é isso: conversar. É entender, ouvir, perguntar, esclarecer, é ser os olhos e ouvidos da equipa. Repare que ele não lida com problemas como custo, tempo e esforço. Isso é papel do gerente. O gerente por sua vez não interfere nem com o levantamento de requisitos nem com a programação. Ele só deve estar preocupados que as coisas aconteçam nos prazos e custos certos. Mas todos têm que conversas entre si. Isso é o significado de equipa.
Casos de uso não são ferramentas para capturar requisitos. São ferramentas para explorar os requisitos. Exercitá-los e testá-los de forma abstrata. Deixá-los mais simples para o humano comum entender. São muletas para levantar mais requisitos ou esclarecer outros.
Os casos de uso formam a interação com o sistema, mas nem de perto compõem todos os requisitos. Por exemplo, requisitos não-funcionais não cabem em um caso de uso. Requisitos de tipos de dados, interfaces técnicas de, e com, outros sistemas. Requisitos de conformidade com normas ( ISO por exemplo) ou com documentação de terceiros, etc… Casos de Uso são uma ferramente util, mas limitada, que nunca serão capazes de capturar todos os requisitos.
Os requisitos de um sistema são uma simples lista (aka texto). Toda a UML é utilizada para modelar (Unified Modeling Language). Modelar não é levantar requisitos, é arranjar formas de os cumprir. É o rio entre o levantamento e a programação. Esse trafego entre as margens é feito pelo designer e pelo arquiteto juntos( cada um na sua visão) e em ultima grau pela equipe como um todo.
Construir software é um trabalho de uma equipe multi-disciplinar. Isso significa diferentes pessoas fazendo diferentes coisas. Se o mesmo cara sempre faz a mesma coisa em todos os projetos isso é um outro assunto.
O ponto é que alguém tem que as fazer.
Não sei como chamar ao cara cuja responsabilidade é levantar os requisitos. Analista de sistemas ? com certeza não. Analista de Negócios ? pode ser. Analista de Requisitos ? Ok, porque não ?
O cara que levanta os requisitos quase nunca tem o poder de interferir com eles. Ou seja, ele ,quase nunca, tem o poder de convencer o cliente que o requisito que ele está pedindo não faz sentido para o negocio( aka para o cliente ter lucro). “Poder” significa aqui “não lhe pagam para isso” e/ou “ninguém está interessado nisso”. Ele filtra, mas passivamente.
Quando o cara é contratado para levantar os problemas do negocio e/ou como um software o poderia ajudar, esse cara ,tem o poder de convencer o cliente. Esse é o real Analista de Negócios. Ele é pago, para analisar o negocio.
O papel do analista de negócios pode, muitas vezes, confundir-se com o de analisa de requisitos. Tudo depende de quanto poder o cara tem para alterar e/o sugerir requisitos com base no que ele observa do cliente. É uma questão de nivel e de maturidade da pessoa e não do seu “cargo”. Depende também do contrato, se o cliente quer que se faça esse trabalho extra, ou não. Contudo, para que o levantador de requisitos faça o seu trabalho corretamente ele tem que ter a capacidade de entender o negocio do cliente.
Resumindo, não ha porque criar nomes novos para a mesma coisa. Analista de Negócios serve bem para todas as ocasiões que sejam diferentes de gerencia e sejam diferentes de implementação. Mas tal como falamos de arquiteto, desenvolvedor, programador, etc… tb podemos entender categorias dentro do papel do analista: de requisitos, de negocio , de risco, de mercado, etc… Não significa que são pessoas diferentes, mas são papeis diferentes.
Conversa, os requisitos mudam bastante. Sao apenas uma motivacao para o software naquele instante.
E qual o seu ponto? a proposta é considerar a figura do analista de negocio e programadores; um e um sao dois!
O que seria exatamente utilizar casos de uso para exercitar e testar de forma abstrata?
Casos de uso sao apenas documentos utilizados como input aos programadores para a criacao de especificacoes executaveis de verdade. Equipes ágeis nem sequer usam casos de uso!
[quote=sergiotaborda]
[…]para que o levantador de requisitos faça o seu trabalho corretamente ele tem que ter a capacidade de entender o negocio do cliente.[/quote]
Ate’podem usar mas o mais importante é que um software construído com TDD e técnicas simples como Domain-Driven Design fazem com que a necessidade de mapeamento entre requisito e software seja mínima. Um requisito possui cri’terios de aceite? Então temos testes que especificam e esclarecem estes critérios. Um determinado conceito de negócio está descrito num requisito? Então vai haver um artefato de software (classe ou o que for) representando claramente aquele conceito.
Quando me refiro que os programadores nao seriam mais responsaveis por levantar os requisitos na verdade quero dizer que os programadores seriam desencorajados a criar testes e tocar o projeto de forma agil. Mas isso é um outra historia…