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.
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!