Cargos de TI: O Analista de Sistemas

Na postagem anterior passei um pouco da minha visão sobre as atribuições do Analista de Suporte, e agora chegou a vez de falar do cargo que é o mais utilizado de forma errônea no mercado: o Analista de Sistemas.

Muitos profissionais - que apesar de serem sim analistas – recebem essa nomenclatura mas executam tarefas que muitas vezes passam longe da atribuição real de um Analista de Sistemas.  E isso se dá pelo fato de não existir um curso de graduação em “Análise de Suporte” ou “Análise de Processos”, por exemplo, que são áreas de atuação específicas mas que recebem muitos profissionais do curso de Análise de Sistemas.

O Analista de Sistemas, teoricamente, é o profissional que estará envolvido em projetos de desenvolvimento ou manutenção de sistemas, mas não necessariamente irá programar, ou seja, manipular diretamente os códigos-fontes que fazem um sistema 'rodar'. Essa é a atribuição do Desenvolvedor (ou Analista Desenvolvedor), cargo que será abordado em outra postagem. O Analista de Sistemas, no entanto, talvez seja o profissional que tenha mais interação com o Desenvolvedor (programador), pois é ele quem projeta o sistema, ao mesmo tempo que tem uma visão mais próxima à do usuário. Antes de um sistema começar a ser codificado, ou seja, construído, muitas informações são levantadas, no intuito de garantir que as necessidades do cliente vão ser atendidas, e de que os riscos (de erros ou da construção de um sistema pouco aderente) durante o projeto sejam minimizados.

Cabe ao Analista de Sistemas analisar os requisitos funcionais e não funcionais, ou seja, requisitos de funções que o sistema deverá ter, e requisitos de qualidade: performance do sistema, facilidade em seu uso (usabilidade!), proteção das informações, etc. Com essa frente junto ao usuário – ou ao Analista de Negócios, outro cargo que veremos mais para frente – o Analista de Sistemas deve interpretar de forma correta a necessidade do usuário, e mais importante, deve ter a capacidade de entender se o que o usuário está solicitando é coerente: praticamente todos os usuários não conseguem expressar tudo o que desejam, e quase sempre descrevem suas necessidades de maneira “traiçoeira”, pois, por já terem uma visão voltada para o negócio, não conseguem ter uma visão mais sistêmica para explicar o que realmente precisam.

Esses requisitos são coletados de diversas maneiras: por meio de questionários, por meio de estórias de usuários (uma tarefa dentro do processo de trabalho do usuário do sistema a ser construído), ou mesmo acompanhando o dia a dia do usuário, vendo de perto como o processo de trabalho dele é conduzido, ou seja, levantando o que chamamos de “as is”.

Além dos requisitos, que é a língua do usuário, o Analista de Sistemas desenha (modela) diagramas que facilitam o entendimento de quem vai desenvolver o sistema e focar na parte técnica: códigos, configurações, testes e lógica de programação. Alguns desses diagramas são:

Caso de Uso - onde são definidos todos os perfis de usuários e o papel de cada um dentro do sistema. Exemplo: Num sistema de hospital podem existir dois perfis: secretária e médico, onde a secretária vai agendar os pacientes para os médicos e os médicos por sua vez registrar o diagnóstico de cada paciente.

Diagrama de Classes – onde são definidos os conceitos do negócio e a relação entre eles. Exemplo: O sistema deverá guardar dados de Usuários, que podem ser médicos ou secretárias; deverá guardar dados do paciente, que só será vinculado a um médico após a geração de uma Ficha de Atendimento, que deverá conter informações pré-definidas de diagnóstico e assim por diante.

Diagrama de Atividades – onde são definidos fluxos de atividades (interações) a serem realizadas no sistema. Exemplo: Secretária agenda paciente para Médico (a), que gera Ficha de Atendimento (b) com determinado diagnóstico (c) e finaliza consulta (d) com a opção de imprimir uma receita (e).

Entre outros como Diagrama de Implantação, Diagrama de Fluxo de Dados, Diagrama de Componentes, etc.

O padrão mais difundido para modelagem desses diagramas é a UML (Unified Modeling Language), que possui duas categorias mais genéricas de diagramas: Os comportamentais e os Estruturais. Uma das ferramentas freeware (grátis!) mais conhecidas para modelagem em UML é o Astah Community, que possui interface amigável e ótima usabilidade.
A UML é definida pela OMG, que oferece certificações na área em três níveis: fundamental, intermediate e advanced.

Bom pessoal, procurei descrever de forma mais ilustrativa e abrangente as reais atribuições de um Analista de Sistemas, com uma abordagem diferente do que estamos já acostumados a ler em Wikipedias da vida. Essa é uma visão que eu tenho da atualidade, que pode continuar sofrendo alterações afinal TI é um mercado que sofre constantes mudanças. Pelo que leio, muitas das atribuições acima são conduzidas em várias situações pelos próprios Desenvolvedores; consequência da difusão de novas práticas, padrões de projetos e metodologias adotadas no mercado.

Quem for da área deixe sua opinião, e quem não for aponte no caso de algo não ter ficado claro!

Mais pra frente falarei um pouco dos seguintes cargos: Desenvolvedor, Analista de Teste, Analista de Implantação, Analista de Banco de Dados (DBA), Analista de Negócios, Analista de Projetos, Analista de Processos, Analista de Arquitetura de TI e Auditor de Sistemas.

Um abraço!