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.
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.
É 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.
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
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”.
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
[/quote]
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
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.
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?
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.[/quote]
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)
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!
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,
o programador vai ser analista de requisitos por 6 meses
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
[quote=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,
o programador vai ser analista de requisitos por 6 meses
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[/quote]
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
Tenho visto pouca coisa dessa aqui em brasilia, ainda vejo bem essa separacao – analista de requisitos, requisito de rup, essas coisas
abrass[/quote]
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).
