Dicas para Analista de Sistemas

vc encontra todas essas respostas em mais esse brilhante post do shoes:

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

Obrigado orlandocn!

Já tinha visto este post, achei bem interessante por sinal…

mas gostaria de saber mesmo se tem algum livro que diga os primeiros passos para se tornar um analista;…ou como fazer o levantamento de requisitos, o que considerar, o importante…o que deve ser levado em conta…esse tipo de coisa

mas obrigado pela dica!!!

Bom Debora Analista de Sistemas é um termo mais genérico… Talvez voce esteja se referindo ao cargo de Analista de Negócios. A Engenharia de Requisitos é função de um Analista de Negócios. Elaborar Modelos de Dominio Orientados a Objetos não é e nunca foi um requisito de um A.N.
Na verdade a maioria tem uma compreensão mto pífia do que é isso. A maioria nem sabe quem é Fowler, Craig Larman, Eric Evans, Rumbaugh, et al. Alguns Analistas de Negócio acumulam a função de Analista de Projeto. Estes se comunicam com a equipe de desenvolvedores através de um DER Físico e Casos de Uso.
Além da UML voce também deve conhecer notações e linguagens para Processos de Negócio como BPM e XPDL. Você sabe o que é Gerenciamente de Processos de Negócio?
Tambem deve ter bom nível de conhecimento sobre a Teoria Relacional.
O mais importante que entenda de Engenharia de Software. Conhecer metodologias como RUP e Scrum e gerenciamento de projetos com Redmine e MS Project, etc.
Mais importante do que ler livros de modelagem, padrões de projeto e de arquiteturas de sistemas corporativos seria estudar Eng. de Software com Pressman e Sommerville.

Tente isso: pegue o cliente, leve ele numa sala e de uma pilha de cartõezinhos pra ele. Daí diga: “escreva uma funcionalidade que o sistema deve ter nesse cartãozinho”. Ele vai lá e escreve. Daí dê outro… E assim por diante. Quando tiver uns 20, você coloca os 20, lado a lado e diz: “agora escolha os 7 mais importantes, mais cruciais do sistema, que não pode faltar e que você precisa pra ontem”. Daí ele escolhe. Daí você diz: “agora vamos detalhar o que cada um desses sete cartõezinhos vai fazer”. Depois disso, você pega o resto dos cartõezinhos, joga numa gaveta, pega os 7 detalhados, coloca num quadro branco numa coluna de “A Fazer” e pronto! Em 1 semana, o teu cliente volta e você mosta o que foi feito. Depois disso, o que ele não gostou você arruma e você vai pegando de 7 em 7 (ou 5 em 5) cartões por semana (dos que estavam na gaveta e deixa ele livre pra escrever novos). Mas se lembra de uma coisa: se ele chegar numa terça e depois voltar numa sexta-feira da outa semana, já deu crap. O importante é isso: feedback rápido.

Tente isso: pegue o cliente, leve ele numa sala e de uma pilha de cartõezinhos pra ele. Daí diga: “escreva uma funcionalidade que o sistema deve ter nesse cartãozinho”. Ele vai lá e escreve. Daí dê outro… E assim por diante. Quando tiver uns 20, você coloca os 20, lado a lado e diz: “agora escolha os 7 mais importantes, mais cruciais do sistema, que não pode faltar e que você precisa pra ontem”. Daí ele escolhe. Daí você diz: “agora vamos detalhar o que cada um desses sete cartõezinhos vai fazer”. Depois disso, você pega o resto dos cartõezinhos, joga numa gaveta, pega os 7 detalhados, coloca num quadro branco numa coluna de “A Fazer” e pronto! Em 1 semana, o teu cliente volta e você mosta o que foi feito. Depois disso, o que ele não gostou você arruma e você vai pegando de 7 em 7 (ou 5 em 5) cartões por semana (dos que estavam na gaveta e deixa ele livre pra escrever novos). Mas se lembra de uma coisa: se ele chegar numa terça e depois voltar numa sexta-feira da outa semana, já deu crap. O importante é isso: feedback rápido.

Não esqueça de falar pra ele colocar atrás dos cartões as regras de negócio e aceite.

[]s

Essa estória de feedback rápido das Metodologias Ágeis são mais convenientes em sistemas que voce não conhece seu tamanho e o seu grau de complexidade. O Processo Unificado também é iterativo e incremental, contudo é dividido em fases, sendo no meu ver, mais vantajoso no caso de já existir um know-how do problema e da solução.

Sim, mas os especialistas em RUP (ou UP) alertam que as iterações não devem ser encaradas como mini-waterfalls.

Bem, eu estava me segurando para não comentar neste tópico, mas como já o fiz foi postar tudo o que eu penso neste caso. O fato é que empresas que trabalham no modelo cascata, seja explicitamente ou mascarado com qualquer outro nome, geralmente são burocráticas, o que exige o papel do famigerado “analista de sistemas”. O fato é que no papel tudo é muito bonito, e com o mínimo de conhecimento sobre os requisitos ele desenvolve modelos “perfeitos”. Mas claro, tudo no papel. Quando a coisa chega na implementação, os programadores começam a notar os buracos no modelo e tem que correr atrás.No fim das contas, a “análise” no sentido literal da palavra fica por conta dos desenvolvedores. Eu posso até estar sendo otimista, mas na minha percepção cada vez mais as empresas estão percebendo isso, e por pura força do mercado, estão buscando metodologias mais eficientes. E o que eu vejo de comum nelas: desenvolvedor cara-a-cara com quem sabe o que quer do sistema, ou o que de fato precisa ser feito (por favor, não confundam essa pessoa com o usuário final). Assim, eu acho que é consenso entre os desenvolvedores que esse papel só tende a sumir, portanto, porque investir em algo que dá sinais de que vai desaparecer ?

Particularmente, eu acho um grande desperdício de talento uma pessoa largar o desenvolvimento de software e partir para a “análise”. Uma filosofia que tenho adotado, e que tem dado certo é a seguinte: concentre-se em entregar o software funcionando e tudo o mais vem junto. Quando você foca nisso, ao invés de simplesmente tocar a coisa pra frente em uma cadeia de processos, inevitavelmente você amadurece em como questionar o cliente ou o responsável sobre o que deve ser feito ou não, a procurar as pessoas certas que de fato detem esse conhecimento, sobre o que deve ser testado, você vai olhar para as metodologias com outros olhos, e entender porque a X funciona e a Y não, etc.

Se já existe know-how do problema e da solução, ser iterativo é contra-produtivo e ser incremental apenas faz mais sentido. E exatamente esse o papel das fases do RUP, implementar uma solução conhecida, que demoraria muito tempo, em incrementos. RUP não é um processo iterativo no sentido do agile.

Cara, não li os outros posts.

Mas nenhum livro ensina isso, só experiência mesmo.

Valeu.

Quem dera fosse sempre tão simples…