Analise + programacao

28 respostas
S

Boa noite pessoal,

eu sei que há alguns topicos abordando o assunto Analise x programacao, porém eu queria saber a opinião de quem tá trabalhando com isso no seu dia a dia.

Faço o curso de Ciência da Computação.

Não gosto dessa parte de analise de requisitos, uml, rup…
No entanto, gosto muito de programar.

O que eu queria saber é:

Vocês que estão trabalhando na área como programadores, vocês consideram bastante importante aprender bem sobre essa área de análise?
Como isso funciona no dia a dia de vocês?

Eu acho muito chato ficar desenhado quadradinhos la da uml, fzendo aquelas regras de negocio e tauz.
Bem, há a chance deu não gostar por não ter visto isso de uma maneira tão legal na faculdade, mas mesmo assim ainda tenho maior enfase na parte de desenvolvimento.

Bem, eh isso

abrassss

28 Respostas

ViniGodoy

Trabalhei apenas uma vez numa empresa em que os analistas eram separados dos programadores. Era um fiasco.

Sorte que os processos ágeis estão acabando com essa divisão. Amém.

S

Processos ágeis…

Acho que vi algo do tipo na caelum qdo eu tava fzendo curso la, nao sei se eh isso de scrum e tauz.

Mas o que vc ker dizer quando diz que essa divisao esta acabando? Quem esta fazendo o trabalho de quem (analistas vs programadores).

E outra, se essa divisao esta acabando, digamos, vale a pena (falando em mercado) eu continuar meu esforco no aprendizado java?

ah, mesmo assim eu vo continuar pq eu gosto hehe

abrasss

georgesq

no mínimo é esperado do desenvolvedor saber ler diagramas UML, pois mesmo tendo algumas empresas trabalhando com metodologia ágil, existem outras tantas com UP e vc receberá artefatos que deverá entender e implementar.

[s]

ViniGodoy

É uma tendência que o desenvolvedor faça um pouco de tudo. Claro que na equipe vai ter gente com um ou outro perfil mais forte, mas como as iterações são pequenas e os requisitos nessas iterações são bem controlados, não é necessário uma montanha de papel e documentos para especifica-los.

S

O que eu ando vejo na faculdade é que a maioria das pessoas quer partir pra uma área de análise.

Eu não sei se o que motiva elas é o fato de não gostarem de programar ou o fato de o salário de analista ser maior.

Lembro do meu prof de analise I dizendo que o mais importante que deveríamos aprender seriam os métodos e técnicas, pois ferramentas (como linguagens de programacao) era passageiras, já o método (O que fazer) seria algo universal, pouco mutável. Porém ainda considero RUP mto chato hehe

abrass

ViniGodoy

Linguagem de programação é uma ferramenta, isso é fato.
Mas programar bem não se resume a dominar uma linguagem, e sim, técnicas de programação (padrões de projeto, desenvolvimento orientado a testes, refatoração, análises de requisitos, metodologias de desenvolvimento, etc).

Por isso costumo a brincar nos tópicos de gente que fez a certificação dizendo “java você já sabe, agora falta aprender a programar bem”.

x111

skaterzin:
Boa noite pessoal,

eu sei que há alguns topicos abordando o assunto Analise x programacao, porém eu queria saber a opinião de quem tá trabalhando com isso no seu dia a dia.

Faço o curso de Ciência da Computação.

Não gosto dessa parte de analise de requisitos, uml, rup…
No entanto, gosto muito de programar.

O que eu queria saber é:

Vocês que estão trabalhando na área como programadores, vocês consideram bastante importante aprender bem sobre essa área de análise?
Como isso funciona no dia a dia de vocês?

Eu acho muito chato ficar desenhado quadradinhos la da uml, fzendo aquelas regras de negocio e tauz.
Bem, há a chance deu não gostar por não ter visto isso de uma maneira tão legal na faculdade, mas mesmo assim ainda tenho maior enfase na parte de desenvolvimento.

Bem, eh isso

abrassss


A análise é fundamental para o desenvolvimento de qualquer software. O problema é que na faculdade o professor normalmente passa uma tarefa e o pessoal sai programando. Mas o professor sabe o que quer como produto final e o aluno sabe (ou devira saber) o que fazer.
No mundo real é bem diferente. Muitos programadores e analistas dizem que o cliente não sabe o quer! Normalmente os projetos de analise são enfadonhos com meses de levantamento de requisitos e depois mais meses de codificação aonde o programador não sabe “o que está fazendo”, sabe apenas que o analista quer aquilo. É como construir uma casa, sem saber que se está construindo uma casa. No final vem a entrega, o cliente olha e diz que não era bem aquilo que ele queria, volta para analise desenvolvimento, o projeto atrasa, etc.
Com métodos ágeis já é diferente! A análise é fundamental, mas o analista e o programador são a mesma pessoa ou os dois fazem o levantamento de requisitos juntos. Existe preocupação de entender o que o cliente quer e fazer um produto que atenda as necessidades dele. O sistema é feito de forma incremental.

Mas esse negócio de querer só programar é normal! Mas isso vai criar problemas para você no futuro, quando for trabalhar com desenvolvimento.
Eu aconselho a leitura de dois livros:
Programação Extrema Explicada
Domain Driven Design

douglaskd

Anime

douglaskd:

http://blogcmmi.com.br/images/reqs.gif

Legal… :stuck_out_tongue:

Sobre analise,aprendi e concordo que é a parte mais importante no desenvolvimento,pois nela definimos todas as características do software.
Infelizmente é uma pratica pouco aceita por programadores e por alguns clientes.

S

Então os métodos ágeis seriam mais eficazes do que usar outros tipo o RUP? Aqueles modelinhos de UML ou aquele grafico das baleias continua existindo?
Eles são mais ‘legais’ que toda aquela parte de gerênciamento de projetos também?

Já os métodos ágeis tendem a ir juntando os cargos de analista e programador, aquele cara que só é analista (não mexe com nda de programacao) não estaria numa situação ruim?

abrasss

ps - vou da uma lida nos livros depois.

douglaskd

acho que é bom saber os 2 e mais algumas coisas…

ultimamente eu tenho pensado em aprender um pouco de Direito, Contabilidade e B.I, mesmo não gostando dessas áreas

x111

Então os métodos ágeis seriam mais eficazes do que usar outros tipo o RUP? Aqueles modelinhos de UML ou aquele grafico das baleias continua existindo?
Eles são mais ‘legais’ que toda aquela parte de gerênciamento de projetos também?

Já os métodos ágeis tendem a ir juntando os cargos de analista e programador, aquele cara que só é analista (não mexe com nda de programacao) não estaria numa situação ruim?

abrasss

ps - vou da uma lida nos livros depois.

Você esta fazendo um pouco de confusão. Metodologias ageis não são sinonimos de não documentação, pelo contrário. A documentação continua existindo e é importante. Mas a documentação serve como forma de comunicação entre o cliente e o desenvolvedor. Ela não é utilizada para dizer o que programador deve fazer. Ela deve representar o problema do cliente, o que o cliente necessita! UML continua existindo, só que a função é representar uma idéia. Um diagrama de classes de um módulo deve representar a responsabilidade desse módulo e não conter informações de como esse módulo deve ser implementado.
Com relação ao gráfico, a tendência é o achatamento da curva, ou seja as alterações ao longo do tempo não tendem a impactar no desenvolvimento.
Um projeto Waterfall pode ter sucesso sim, já participei de ínumeros projetos (pequenos) que tiveram sucesso. O problema é a forma como ele é aplicado!
Recomendo que você leia os dois livros que indiquei, principalmente o do Evans (Domain Drive Design)

S

Entendo, então a documentação continua sendo feito pelo analista/programador, só que agora ela é feita de uma maneira mais prática?

Ela fiica menos extensa?

Agora o programador que decide como implementar?

Po, sou mesmo leigo nisso.

Qdo eu termina de ler os livros q peguei da amazon vou procurar ler esses que você recomendou

abrasss

x111

Pode-se dizer que sim, se não existe um fundamento para um documento existir ou se um documento não é mais atualizado, ele deve ser excluido!

Não necessáriamente.

Na verdade o modelo que você cria que diz qual o caminho que você deve seguir! O desenvolvimento é guiado pelo modelo. Agora não importa como um método de uma classe é implementado, desde que ele siga as regras do modelo!

S

HUm sakei,

isso tá ficando mais comum hoje em dia?

Tenho visto pouca coisa dessa aqui em brasilia, ainda vejo bem essa separacao – analista de requisitos, requisito de rup, essas coisas

abrass

douglaskd

acho que essa questão de colocar o programador também como analista de requisitos deve ser por teorias como:

pegue 2 profissionais, 1 programador e 1 analista de requisitos

e troque suas tarefas,

  1. o programador vai ser analista de requisitos por 6 meses

  2. o analista irá ser programador por 6 meses.

creio eu que o programador vai se adaptar a tarefa bem mais rápido, porém o analista não…

talvez…com esse pensamento empresas perceberam que programadores tem capacidades Exponencialmente maiores que analistas de requisitos… :lol: rs…essa frase me deixou feliz

CarlosEduardoDantas

http://blog.fragmental.com.br/2008/01/15/quando-eu-crescer-quero-ser-analista-de-sistemas/

S

douglaskd:
acho que essa questão de colocar o programador também como analista de requisitos deve ser por teorias como:

pegue 2 profissionais, 1 programador e 1 analista de requisitos

e troque suas tarefas,

  1. o programador vai ser analista de requisitos por 6 meses

  2. o analista irá ser programador por 6 meses.

creio eu que o programador vai se adaptar a tarefa bem mais rápido, porém o analista não…

talvez…com esse pensamento empresas perceberam que programadores tem capacidades Exponencialmente maiores que analistas de requisitos… :lol: rs…essa frase me deixou feliz

Acredito também nessa capacidade maior de adaptação do programador à um trabalho de análise.

O que eu vejo é tb eh que mta gnt q ker analise tá eh fugindo de códigos

M

skaterzin:
HUm sakei,

isso tá ficando mais comum hoje em dia?

Tenho visto pouca coisa dessa aqui em brasilia, ainda vejo bem essa separacao – analista de requisitos, requisito de rup, essas coisas

abrass

Hmm… depende. Existe um hype muito forte entre a comunidade de software, não entre as empresas. Consultores de processos e metodologias que vc vê por ai defendendo agile como se fosse “a maneira certa” em fóruns e conferências de programação têm como objetivo promoção pessoal, seja pra vender livros, cursos ou ferramentas. A audiência deles são outros programadores, não as empresas. Estes devem achar que adoção de agile ta aumentando.

As empresas em si são indiferentes a essa movimentação, elas apenas adaptam de forma a colher os benefícios sem ter que mudar os processos internos (por exemplo, rebatizando os velhos procedimentos como se fossem “agile-compatible”, mas com o intuito de atrair programadores para seus processos seletivos, não porque foram iluminados com os benefícios do agile).

S

Bem, quanto a isso ainda não sei. Vamos ver quando eu entrar no mercado hehe

W

Anime:
douglaskd:

http://blogcmmi.com.br/images/reqs.gif

Legal… :stuck_out_tongue:

Sobre analise,aprendi e concordo que é a parte mais importante no desenvolvimento,pois nela definimos todas as características do software.
Infelizmente é uma pratica pouco aceita por programadores e por alguns clientes.

Eu nao concordo que analise eh a parte mais importante no desenvolvimento. Eu acredito que ambas partes (programacao e analise) sao extremamente importantes.

Porque programacao eh tao importante quanto analise?? Pelo simples fato que se vc tiver uma analise perfeita, linda e etc… e a programacao eh um lixo, cheio de falhas de seguranca, faltando tratamento de erro, nao obedece nenhum padrao, nao se preocupa com performance, nao adianta nada a analise, porque vc pode ate ter um sistema que faz o que tem que fazer, mas eh um pesadelo pra dar manutencao, cheio de bugs, lento.

Acho engracado que no Brasil tem uma certa cultura que quanto mais se trabalha, menos importante a pessoa eh (nao que analistas nao trabalhem), mas eu tenho a impressao que as pessoas acham que se vc senta pra programar vc eh a mesma coisa que um peao de obra. Outro dia li num topico aqui no forum alguem falar “esse ai merece programar a vida inteira”. Porque ser desenvolvedor eh tao ruim assim??

Fora do pais todo mundo faz carreira como desenvolvedor, sem problemas. Ninguem te olha como um profissional de baixo escalao.

Eh tao ruim ser desenvolvedor ???

//Daniel

rogeriopaguilar

Tenho encontrado dificuldades em novas oportunidades por sempre ter trabalhado em ambientes de fábrica de software, onde existe a separação entre analistas e programadores (eu, no caso). Hoje, apesar de trabalhar com java há quase oito anos, eu tenho tido dificuldade nas entrevistas para novas oportunidades justamente pelo fato de não ter feito muito esta parte de análise. O que eu tenho mais dificuldade é entender o que as pessoas querem nos sistemas, pois elas falam uma coisa e depois mais pra frente falam a mesma coisa só que de uma forma diferente. Como não existe muito documentação (já trabalhei em projetos bem “go horse” mesmo, onde tudo era passado apenas conversando, sem registrar as decisões em lugar nenhum, mesmo eu querendo este registro devido a problemas anteriores), eu já tive muitos problemas com isso. Já fiz um pouco de análise em alguns projetos, mas nunca sozinho e tive um pouco de dificuldade em entender o que as pessoas queriam no sistema, então eu aconselho a quem está começando a se dedicar um pouco nisso, mas como eu disse antes, o que acho mais difícil não é a parte de desenhar diagramas e tal, pois a uml em si é fácil, mas o mais difícil é modelar o que o cliente queria de fato, e não o que você entendeu, que muitas vezes não reflete muito bem o que o cliente queria, por isso que eu acredito que a atividade de análise de requisitos deveria ser feita por um analista de requisitos, e não por nós, programadores, mas isso é discutível e acho que vai do perfil de cada um. No meu caso, eu tenho duas possibilidades. A primeira seria mentir e falar que sempre fiz tudo (incluindo a parte de requisitos e tal), o que eu não gostaria de fazer e a segunda é eu ser sincero nas entrevistas e deixar claro que não tenho muita experiência com essa parte de requisitos e especificação funcional, que é o que tenho feito ultimamente e mas tenho sido excluído do processo seletivo por isso. Uma terceira possibilidade seria eu aceitar um cargo de nível menor, pra melhorar esta parte de análise, mas aí o salário ia diminuir muito. Uma outra possibilidade que considero muito ultimamente é mudar de área…

douglaskd

desistir da área?, não desanima a galera não :cry:

rogeriopaguilar

Bom, a opção de sair da área é algo que considero, mas não quis dizer que é uma opção para todos. Na verdade algumas coisas me fazem pensar sobre isso:

1 - as empresas não te ajudam de forma alguma a se atualizar. A maioria não quer ter gastos com cursos de atualização. Como somos “recursos”, e não pessoas, é mais fácil trocar o recurso do que ajudá-lo a melhorar o seu conhecimento. Além disso, devido aos cronogramas malucos, normalmente criados por pessoas que “chutam” o tempo de desenvolvimento do projeto, acabamos tendo que trabalhar muito mais do que o número de horas que seria normal, e em muitos casos sem receber estas horas. Então temos que trabalhar de graça e nos atualizarmos sozinhos sem nenhum tipo de apoio, e mesmo que quisermos estudar e tal faremos isso que horas?

2 - Eu já vivenciei um caso em que o consultor descobriu que a consultoria não pagava as horas que ele ficava a mais alegando não receber estas horas, porém depois ele descobriu que a consultoria recebia as horas extras que ele ficava lá. Isso justificava a “avaliação” que era feita do profissional pela consultoria, ou seja, quem ficava mais horas sempre era considerado melhor e tinha o seu valor hora aumentado, mas na verdade isso ocorria porque a consultoria passaria a receber mais pelo profissional, que trabalhava de graça sem saber. Quando ele foi reclamar adivinha o que aconteceu? Trocaram o recurso.
Infelizmente eu tenho ouvido essa mesma história de avaliações melhores para quem fica mais de muitos outros conhecidos que trabalham em diversas empresas, então acho que essa “mutreta” deve acontecer em muitos lugares hoje em dia.

3 - não vou comentar muito a falta de preparo dos gerentes dos projetos pois acredito que nem é necessário, já que todos nós vemos isso todos os dias. Eu fico pensando, se nós formos incompetentes, logo seremos trocados, pois a falta de preparo será vista logo pela equipe, agora os gerentes podem enrolar e esconder a sua mediocridade e nada acontece a eles, e já vi muitas vezes algo que ocorreu por culpa do dito gerente, que no seu grande comprometimento com a equipe jogou a culpa em um dos desenvolvedores para livrar a sua cara. Adivinha quem foi trocado na equipe? O gerente? Até parece né?

4 - as metodologias ágeis surgiram para deixar o processo menos burocrático e quando aplicadas da forma correta elas são boas, porém o que tenho vivido ultimamente é o que eu poderia chamar de go horse disfarçado de ágil, pois muitas empresas que nunca tiveram metodologia nenhuma a não ser o go horse falam agora que utilizam metodologia ágil, quando na verdade elas continuam não tendo nada e a bagunça continua, só que agora com um nome chique;

5 - o acúmulo de funções a que somos expostos. Não apenas a parte de fazer análise e programação, mas eu acho que as empresas estão exagerando. Eu fui numa entrevista, por exemplo, que o cara me disse o que teria que fazer: levantamento de requisitos, especificação funcional, desenho das telas (não apenas o protótipo, mas criar o design do site, pois eles não iriam contratar nenhum webdesigner), criar e controlar o cronograma e os riscos do projeto, implementação, testes, implantação, suporte à produção, configuração do ambiente de produção (isso incluia configurar uma sub-rede nova que seria criada apenas para as máquinas do projeto. Como ele me disse que tinham uma equipe de rede questionei se eles nos ajudariam nisso e ele disse que não pois eram de uma equipe diferente) e depois de implantado suporte ao mesmo tempo que começaríamos um novo projeto, e tipo suporte ao usuário mesmo (acho que atenderia telefone até, rs), pois não teriam uma equipe de suporte. Eu respondi que aceitaria se eles me pagassem um valor absurdo que falei na hora lá. Ele disse que não entendia porque as pessoas queriam ganhar tanto e que não conseguiam ninguém há alguns meses já. Eu falei pra ele que ele precisava de pelo menos umas 4 pessoas pra esse projeto e fui embora de lá;

6 - frameworks e mais frameworks para aprender… cada vez que eu aprendo um, já tem mais uns dez novos pra aprender. Quando eu era mais novo não ligava de ficar estudando e tal, mas hoje já não aguento mais isso, eu quero utilizar minhas horas vagas para viver um pouco…

etc, etc, etc

Poderia ficar escrevendo muitas coisas aqui, mas ao meu ver, a maioria dos problemas ocorre devido a estas consultorias sangue-sugas que surgiram. Por isso que eu digo que talvez seja melhor eu mudar de área. Eu sei que vou ganhar menos no começo e tal, mas se eu puder viver em paz acho que vale a pena, e mesmo assim eu não vou parar de programar, só que farei apenas por hobby.

douglaskd

é osso cara…

tenta entrar em uma multinacional, que o knight da empresa não seja TI

Anime

Oi,

Quando vi o título do tópico fiquei animada rsrs, pensei tenho que participar, adoro análise… :stuck_out_tongue:
Ai vi que já participei, que pena é um tópico antigo… :cry:

Sinceramente eu não consigo imaginar um programador que não “consegue” ou não saiba fazer uma análise de sistemas e quanto ao banco de dados, também depende da análise, desculpe minha ignorância, mas o programador não desenvolve o projeto de BD, deve ser muito chato trabalhar em fábrica de software… :roll:

rogeriopaguilar

Bom, o projeto de banco de dados eu já fiz sim, e muitas vezes, mas sempre foi feito na fase de projeto e não na de análise de requisitos… O que eu não curto é a análise de requisitos, tipo ter que ficar indo a reuniões de entendimento e tal, acho isso muito chato. Uma vez os requisitos coletados, fazer os modelos, a arquitetura, montar o modelo do banco, etc tudo bem… e sim, trabalhar em fábrica de software foi muito ruim

Anime

Oi,

Acho que isso é normal, cada um tem uma preferência. Lembro que em uma prova de análise um menino olhou pra mim e disse que não sabia nada, eu falei jura rsrs, eu sei tudo, ai ele perguntou se eu era louca… :stuck_out_tongue:

Criado 23 de fevereiro de 2011
Ultima resposta 23 de jun. de 2011
Respostas 28
Participantes 10