O documento descreve o papel do analista de negócios no desenvolvimento de sistemas. O analista deve entender os requisitos do negócio e projetar soluções funcionais que atendam às necessidades do negócio dentro do escopo, prazo e orçamento. Além disso, o analista deve considerar todos os aspectos do sistema, como entrada e saída de dados, processamento, testes e qualidade.

1. 1
Lean TI
ALS
Lean TI
Analista de Negócios
Atuação Ativa e Não Reativa
Ademar Leal da Silva
Novembro 2015vida
www.ademarlealsilva @blogspot.com.br

2. 2
Lean TI
ALS
O Analista de Negócios
Motivação para elaborar este documento
Durante os últimos anos refleti muito sobre os erros de
sistemas, fracassos dos projetos e penso que grande
parte deste caos é devido principalmente aos sistemas
mal concebidos em seu inicio.
O sistema que nasce errado dificilmente tem conserto.
Constatei em observações que são muito poucos os
analistas de sistemas que conseguem fazer uma
concepção de projetos consistente de inicio ao fim.
A maioria dos profissionais de TI tem pouca visão geral
do todo e concebem sistemas que depois de implantado
passa-se o resto da vida agregando funcionalidades para
que o sistema cumpra com seus objetivos. Quando o
sistema está completo com as funcionalidades
operacionais já é uma colcha de retalhos com um sem
numero de interfaces, que inviabiliza sua execução.
Com este tipo de abordagem de TI, criamos a figura do
Analista que com anos ou décadas de trabalho só
desenvolveram um único sistema e ainda assim não ficou
bem feito.

3. 3
Lean TI
ALS
O Analista de Negócios
Motivação para elaborar este documento
Com as novas tecnologias ganhamos muito em
engenharia de software e hardware, mas perdemos
muito em concepção. A maioria dos profissionais de
TI , que estão na ativa são especialistas de
manutenção ou de sistemas periféricos, e lhes falta
experiência para conceber um sistema com todos os
seus processos agregados.
Temos que resgatar o Analista de Concepção, o
verdadeiro Analista Sênior, aquele que sabe
desenhar e projetar um sistema completo ,mesmo
que seja desenvolvido em fases, mas que sabe
exatamente o que o sistema vai fazer e ocmo vai
fazer.
Os próximos slides mostram a importância do
Analista de Negócios na área de TI para conseguir
conceber um sistema com menos risco de criar um
problema para os outros

4. 4
Lean TI
ALS
O Analista de Negócios
Papel que o Analista de Negocios desempenha no
desenvolvimiento de Sistemas
Sua principal função é prover solução funcional a um problema de negocio.
Seu primeiro objetivo é entender o que o negocio quer e desenhar a
a solução que satisfaça os requerimentos solicitados.
No decorrer do projeto deve ser capaz de saber se o que está sendo
desenvolvido irá satisfazer a expectativa do Negocio.
A solução funcional
Deve ser executada dentro dos prazos combinados.
Deve ser executada dentro dos custos contratados.
Deve ser cumprido o escopo e os objetivos acordados.

5. 5
Lean TI
ALS
O sistema e sua finalidade
Um sistema somente tem sentido se agrega valor ao negocio, ou seja, se produz
algo de valor para o cliente, se ajuda a vender mais, se ajuda reduzir custos,
ou atenda a algum disposto lega.
Um sistema que não se enquadra em nenhuma destas características,
deve ser categoricamente descartado.
Averiguar os Objetivos básicos do sistema
O primeiro passo fundamental e imprescindível será determinar o que que o
sistema irá produzir e para quem:
Questões : Base de dados, usabilidades, Informação de Gestão, etc las salidas se
Solución. Qual o valor que o sistema aporta, qual o ROI?
O Analista deve saber que funcionalidades o Negocio
necessita que seja atendida pelo Sistema
farmacia
Anatomía
Patológica
UTI
Aplicações
departamentais …
Radiología Imagen
digital
Enfermaria
Laboratorio
Historia
Clínica
Solicitações
Gestão
Pacientes
Sistema de Gestão
Hospitalar

6. 6
Lean TI
ALS
Que informação alimentará o sistema
Quando já se sabe quais são as saídas do sistema, o próximo passo será:
saber onde estão as fontes de dados que vão alimentar o sistema para produzir as
saídas desejadas:
Integração com outros sistemas …
Determinar os meios para a captura e integração com outros
sistemas
como e com que meios se produzirá a captura e
Integração desses dados?
Papel do Analista (Saber o que o negocio necesita)

7. 7
Lean TI
ALS
Transformar a informação de entrada em informação útil de
saída
Sabendo o que sai e que entra, a sequencia natural e saber como se processa a
metamorfoses, ou seja o que fazer para que os dados de entrada (inputs) se
transformem em informação de saída.
Descrever todos os passos da
transformação de entrada em
informação de saída.
Descrever todos os programas.
Descrever todos los modelos.
Muita Tecnología e complexidade mas tudo se resume em
Papel do Analista (Saber o que o negocio necesita)
Desenvolver a Analise
Funcional
Entrada Processamento Saída

8. 8
Lean TI
ALS
Cenário de uma área de Desenvolvimento que não
utiliza uma Metodologia
A cadeia de desenvolvimento é muito extensa, temos que interagir com muitas
pessoas e muitos departamentos :
Gerentes de projetos
Analistas Funcionais
Programadores
Fornecedores
Arquitetura
Testes
Produção
Em cada um desses grupos existem pessoas com diferentes níveis de
conhecimento e experiência.
Uso de uma Metodologia?
Funções e Cargos Idiomas
Torre de Babel
Torre de Babel

9. 9
Lean TI
ALS
Cenário de uma área de Desenvolvimento que sim utiliza uma
Metodologia
Porque?
O uso de uma metodologia seja qual for não deve ser encarada como um capricho ou una exigência
burocrática.
Sem uma metodologia a homogeneização da documentação
a comunicaçao entre os diferentes grupos que intervém
no desenvolvimento de sistemas seria una torre de babel.
Cada grupo faria a sua maneira e seria impossível
o entendimento entre todos os envolvidos.
Vantagens de usar una metodologia
A metodologia unifica e normaliza a comunicação.
Agiliza métodos de trabalho.
Unifica os termos utilizados.
Ajuda a estandardizar as soluções aplicadas.
RESULTADOS
Redução de custos.
Redução de tempos.
Melhores resultados.
Delimita o escopo do projeto.
Uso de uma Metodologia?

10. 10
Lean TI
ALS
Qualquer projeto de TI necessita una fase de:
Levantamento de Requisitos
Análise Funcional
Desenho de Integração
Construção
Testes
Implantação
Existem vários modelos de trabalho:
Somente uma pessoa faz todo o Projeto
Uma equipe exclusiva faz todos os trabalhos do Projeto
Um estrutura especializada que industrializa o software
Vários equipes cada uma com uma responsabilidade
Papel do Analista
(Não confundir metodologia con técnicas de desenvolvimento)
SCRUM,
JAD,
Método Iterativo,
Análise Estruturada,
Análise Modular etc,
Técnicas para abordar um projeto Metodologia de Desenvolvimento
Uma técnica de Desenvolvimento não é uma Metodologia
Todas as fases são comuns para todos os tipos de
projetos (seja para desenvolver um produto industrial,
construir um avião, uma casa, ou um projeto de TI).

11. 11
Lean TI
ALS
¿Qual é o melhor modelo de trabalho? Parece que depende de muitos fatores...
O melhor modelo de trabalho é o que produz melhores resultados para a Empresa
É necessário alguns cuidados:
Não escrever muito, pois os usuários e nem ninguém entende especificações escritas com
folhas e mais folhas de papel, o sistema para apresentação ao usuário deve ser prototipado
para que o efeito visual ajude o usuário a validar o sistema.
Com um protótipo o usuário saberá se o que vai ser desenvolvido é correto ou não.
Todo o projeto grande dever ser dividido em projetos pequenos
Papel do Analista
(Não confundir metodologia con técnicas de desenvolvimento)
Dividir o sistema em módulos que produzam algo tangivel para o usuario , no
máximo a cada 4 meses, se for um mês muito melhor, e
para cada módulo fazer:
Requisitos
Análise Funcional
Desenho de Integração
Construção
Testes
Implantação
.
Seja Scrum, Iterativo, Cascata, mas em hipótese alguma pode tardar
Mais que 4 meses para implantar módulos reais que produzam resultados

12. 12
Lean TI
ALS
Capacidades do Analista
Dominar a metodología:
Todos os analistas devem dominar perfeitamente todas as tarefas
de uma metodologia relativas a Elaboração de Requisitos,
Analise Funcional, Desenho de Integração, Testes e
implantação.
Dominar os estándares de Arquitetura:
Devem conhecer e dominar os estándares de arquitetura
(formulários, desenho de telas, impressão, interfaces, usabilidade)
e e representar as soluções estandarizadas.
Dominar os servicios:
Devem conhecer e dominar todos os serviços catalogados
(tecnológicos, arquitetura e negócios) para reutiliza-los e devem
criar novos serviços para futura reutilização.
A produtividade está na reutilização e na
estandardização assim de simples não existe nada
mágico
Papel do Analista (Uso de servicos estandarizados)

13. 13
Lean TI
ALS
A qualidade como solução
A qualidade deve estar presente em todas as soluções de TI.
Não se pode pensar em qualidade somente como o resultado
dos testes finais. A qualidade deve ser preocupação em toda a
cadeia de desenvolvimento desde o seu inicio.
Relevancia das fases iniciáis do
desenvolvimiento
Seguramente o problema da qualidade dos projetos não
está somente na construção mas também nas fases iniciais,
levantamento de Requisitos e Analise Funcional. Quando o
erro está na construção é mais fácil de consertar, mas quando o
erro é de concepção fica muito difícil salvar o sistema.
Papel do Analista (A qualidade da solução)

14. 14
Lean TI
ALS
Existem um conjunto de ferramentas e
técnicas na fase de Fase de Requisitos
que nos ajudam a aumentar a
qualidade na hora de especificar uma
boa solução para negócios.
Papel do Analista (A qualidade da solução)
Observação
Tabelas de Decisão
Fluxogramas
Histogramas
Diagrama de Espinha de Peixe
Diagramas de Pareto
5W1H (What, Why, When, Who, Where,How)
Es imprescindível que o
Analista conheça estas
ferramentais e técnicas
Técnicas e ferramentas para o levantamento de Requisitos
Análise de Valor
Poka-yoke
Custos e Benefícios da Solução
Escrever e Comunicar
UML

15. 15
Lean TI
ALS
A Analise Funcional é peça chave para o éxito de qualquer projecto informático.
Com um bom desenho funcional tudo funcionará, tudo se implantará. Com um mal desenho funcional não se
cobrirá as expectativas do usuários em prazos, nem em custos, e nem em funcionalidade.
Papel do Analista (A qualidade da solução)

16. 16
Lean TI
ALS
Não complique a construção
Papel do Analista (A qualidade da solução)
Faça Programas Simples com somente uma
função CRUD
(Create, Retrieve, Update,Delete)
Nunca use tecnologia desconhecida por sua
equipe
Re-utilize Rotinas e Serviços
Telas Padronizadas
Rotinas de Exceção Padronizadas
Serviços Estandarizados
Tudo Simples, se ficar complexo divida em
partes
Simples, fuja da complexidade
Somente isto , a simplicidade é a chave

17. 17
Lean TI
ALS
Os testes são o meio de avaliação da qualidade do sistema
Os teses funcionais são a fase final da qualidade. É na fase de testes onde se poderá ver a qualidade do
sistema. Se deve pensar nas provas com antecedência , ou melhor dito , assim que começar o
desenvolvimento já devemos fazer o plano de testes.
Não devemos de esquecer os procedimentos e instrução para passar para a produção para que se executem
conforme instruções. Outro fator importante a considerar é o ciclo de vida do sistema e dos dados,
identificando períodos de retenção, políticas de expurgo, políticas de Backup, etc.
Papel do Analista (A qualidade da solução)
Marco de
Proyecto
Toma de
Requisitos
Proceso
de Calidad

18. 18
Lean TI
ALS
Caso Pratico da Atuação do Analista
Papel do Analista (A qualidade da solução)

19. 19
Lean TI
ALS
Imagine que somos um Seguradora e um usuário nos solicite uma solução como a que descrevemos em
seguida:
A solicitação:
- Necessitamos desenvolver um sistema para suportar uma campanha comercial para oferecer a nossos
segurados, que possuem uma apólice de automóvel e não possuem uma apólice residencial , condições
especiais para que contratem conosco uma apólice de seguro residencial.
- Iremos enviar-lhes uma carta comunicando a oferta com boas condições
de contratação para o novo seguro de residencial.
- O segurado poderá devolver-nos a carta assinada , ou
aceitar as condições de contratação a través de Internet.
- Para todos os segurados que aceitarem a oferta, se emitirá una apólice de residencial
de acordo com as condições oferecidas.
Caso práctico (Exemplo Fictício)
“O analista deve projetar soluções completas
considerando o sistema e os processos”

20. 20
Lean TI
ALS
Caso de Uso 1 - Preparar_Envio_Cartas
Caso práctico (Solución habitual)
Extrair Apólices de
Residencial
Extrair Apólices de Autos
Selecionar Autos (sem
Residencial
Gerar Carta Internet Gerar Carta para Impressão
Canal

21. 21
Lean TI
ALS
CU-2 Preparar_Nova_Apólice
Caso prático (Solução habitual)
Introduzir Dados no Sistema
Canal
Atualizar Datos Realizar Emissão
Carta Aceitação
Internet Aceitação
Área de Digitação Sistema Área de Emissão
Se o segurado aceitou a proposta por carta, damos entrada no
sistema,se ele aceitou por internet, tb damos entrada no sistema
Processamos as aceitações e emitimos as apólices

22. 22
Lean TI
ALS
O Analista deve fazer mais que a solução habitual
Caso prático (Solução habitual)
Embora a solução apresentada esteja perfeita já que foi exatamente o que o
o usuário pediu....... Ela não é uma boa solução
Porque …….
não está completa.
O Analista deve oferecer mais. Sendo um técnico ele tem que identificar o que está
faltando no sistema, que o usuário não pediu expressamente , mas são funcionalidades
importantes que deverá fazer parte do sistema.
Existem questões que o usuário não expressa mas que o Analista deve
detectar, oferecendo um valor agregado a solução convencional.

23. 23
Lean TI
ALS
Completar o sistema
O sistema deve contemplar o que o usuário não pediu e que é importante para a funcionalidade. Somente
assim o sistema será completo, um bom analista não culpa o usuário dizendo que ele não sabe
o que quer, mas ajuda-o a encontrar as falhas de sua solicitação .
Un novo caso de uso de nosso exemplo.
Sabemos que muitos dos segurados que receberam a carta não a responderão.
Deveríamos propor que se realize uma nova execução recordando as condições da oferta para
aqueles que não responderam a carta.
Este processo poderá ser repetido quantas vezes for necessário
Portanto, aparece um novo caso de uso que chamaremos de Caso de Uso 3 - Recordatorio
Proatividade:
Mesmo que o usuário não
peça, devemos propor
CU003_Recordatorio
Caso prático (Valor Agregado da Solução )

24. 24
Lean TI
ALS
CU3_Recordatorio
Selecionar Autos (sem residencial) y que não
responderam
Caso pratico (Valor Agregado )
CU001_ Enviar_ Carta
Atentar que esta funcionalidade não requereu desenvolvimento
Reaproveitou os módulos anteriores agregando uma seleção

25. 25
Lean TI
ALS
Está bem…..Mas ....
Ainda falta
funcionalidades importantes
que o usuário não pediu…
E que o Analista deve oferecer.
Caso prático (Valor agregado )

26. 26
Lean TI
ALS
O que o usuário não ha pediu mas que deve ser feito…
Para que o sistema não fique “incompleto” desde o ponto de vista funcional
Situação não pedida pelo usuário : Sabemos que muitas cartas não chegam
aos destinatários por diferentes motivos:
Endereço errado ou incompleto
Clientee mudou de endereço, etc.
Então …
Teremos que desenvolver um processo para fazer uma analise de todas as cartas devolvidas com
o objetivo de atualizar o endereço.
Faremos esta tarefa consultando outras fontes de dados ou chamando
diretamente o segurado via telefone.
Os endereços que não seja possível atualizar se marcará como
endereço invalido com o objetivo de não voltar a enviar novas ofertas
a este mesmo endereço.
Posteriormente se destruirá as cartas devolvidas.
Despois de atualizar os dados devemos a repetir os processos CU-01 y el CU-02.
Caso prático (Valor agregado )

27. 27
Lean TI
ALS
Corrigir dados Introduzir Dados
Sistemas Terceiros
CU-04_Gestionar_Devolucão _Cartas
Marcar cliente para envío
CU001_Enviar_Carta
Caso prático (Valor Agregado )

28. 28
Lean TI
ALS
Mas…..
A solução ainda não está completa...
O Analista deve oferecer
as funcionalidades operacionais
que o usuário não costuma pedir.
Caso prático (Valor Agregado )

29. 29
Lean TI
ALS
Temos que pensar e oferecer as funcionalidades y facilidades operativas
do sistema:
Emissão de segunda via de uma carta-oferta especifica.
Consultas sobre a situação das cartas ofertas enviadas.
Eliminação de una oferta a pedido do segurado.
Ajustes de uma oferta.
Etc.
Caso pratico (Valor agregado – funcionalidades operativas)
Proatividade:
Mesmo que usuário não peça,
devemos propor
Funcionalidades operativas

30. 30
Lean TI
ALS
Mas…..
Mesmo assim,
a solução não está completa…
O Analista deve pensar y oferecer as funcionalidades de
gestão que o usuário não costuma pedir.
Caso prático (Valor agregado )

31. 31
Lean TI
ALS
Possivelmente:
Quantidade de ofertas geradas
Quantidade de ofertas aceitas
Quantidade de ofertas recusadas
Região
• Territorial
• Sucursal
Averiguar que informação de gestão será necessária
e quando deveremos ter-la:
on-line
Diario
Semanal
Mensal
Como será o informe:
Papel
Cubo
Tela
Caso prático (Valor Agregado – funcionalidades de gestão)
Proatividade:
Mesmo que o usuário não peça
devemos propor
Funcionalidades de gestão

32. 32
Lean TI
ALS
Recapitulemos
Mesmo concordando que o que temos até agora é suficiente para desenvolver o sistema e além disso foi
o que o usuário nos solicitou, é importante saber que , para tomar una decisão adequada é
necessário realizar um estudo de viabilidade técnica e económica que ajude a tomar a
decisão.
Sabemos que o custo total somente podemos obter depois da Analise Funcional
Completa.
Mas com um marco de projeto como o que foi apresentado , já se pode estimar
com relativa segurança o esforço necessário para construir um sistema com estas
características.
Podemos deduzir que para cada uma das funções teremos pelo menos 4 operações
(além das funcionalidades de gestão):
Inclusão
Alteração
Eliminação
Consultas
Com estes dados se pode estimar os Pontos de Função para um estudo de viabilidade
económica.
É importante que se aprofunde sobre a viabilidade técnica do projeto, que inclui, entre outros, a
volumetria, integração, rendimento y segurança, as quais também geram custos que afetam a
viabilidade económica. Estes dados se obtém a partir da Analise Funcional.
Caso prático (reflexões)

33. 33
Lean TI
ALS
Y mulitas coisas mais…
Como é impossível saber tudo devemos : desenvolver a capacidade de saber quem sabe de
cada coisa e buscar sua ajuda
Mais Reflexões
Capacidades do Analista de Negocios
A função dol Analista é muito complexa :
Deve saber de negócios
de Informática de Gestão
de Informática de Sistemas
de Gestão de Pessoas
de Matemática Financeira, Estatistica
Saber redatar
saber falar
saber vender
saber convencer
saber negociar

34. 34
Lean TI
ALS
Objetivo
Perguntamos : Com toda esta complexidade , Como podemos fazer bons sistemas ?...
A resposta é muito simples , fazendo tudo mais simples.
“o que quer o usuário é que se cumpra o orçamento de custos, prazos e alcance”
¿Como conseguir esto?
Não é tão fácil , mas tampouco é tão difícil”. Como conseguir?:
Utilizar soluções estándares
(telas, interfaces, programas pequenos (CRUD)
•Utilizar uma Metodología
Utilizar os Poka-Yoke para evitar erros
Reutilizar serviços catalogados
Gerar Serviços para que sejam reutilizados, pense SOA
Pensar, Lean – “Fazer certo da primeira vez.” fluxo continuo
Soluções Simples
Mais Reflexões ainda…

35. 35
Lean TI
ALS
O Analista não deve ser reativo
Se ele fizer somente o que o usuário pediu o sistema ficará incompleto.
O Analista deve conduzir o usuário para a melhor solução, não se deve restringir somente ao
processo da Empresa, deve investigar soluções alternativas e inovações ser um agente
inovador nos processos da companhia em que trabalha.
Fazendo somente o que se pede, não mudará nada, tudo continuará na mesma com pequenas
melhorias, as vezes é preciso romper com a situação atual e ter coragem de fazer tudo de novo
em relação aos processos.
Portanto é fundamental ser proativo e agente de mudança para construir sistemas admirados
por outros
Conclusões finais

36. 36
Lean TI
ALS
“É certo que nunca temos tempo de fazer corretamente as coisas corretamente, mas também é
certo que sempre temos que buscar tempo para conserta-las depois”
“Devemos mudar para fazer certo as coisas bem e completas na primeira vez para fazer uma coisa
somente uma vez”
Como dizia Einstein:
“louco é aquele que fazendo as coisas iguais
uma e outra vez espera resultados diferentes”
“Temos que ser Analista de Negocio, Consultores de Negócios, temos que
projetar soluções sempre completas, para poder fazer outras coisas,
senão passamos a vida toda consertando coisas que fizemos errado .”
Conclusão

37. 37
Lean TI
ALS
Obrigado pela Atenção
Ademar Leal da Silva
ademarleal197@gmail.com
www.ademarlealsilva@blogspot.com
As imagens foram
Copiadas do google
Desculpe pelos erros de português