priscila daniele pivante...universidade de brasília faculdade de administração, contabilidade,...
TRANSCRIPT
Universidade de Brasília
Faculdade de Administração, Contabilidade, Economia e Gestão de Políticas Públicas
Departamento de Administração
PRISCILA DANIELE PIVANTE
GESTÃO DE PROJETOS E QUALIDADE: UM PLANO PARA
GERENCIAMENTO DA QUALIDADE EM UM PROJETO DE
BUSINESS INTELLIGENCE
Brasília – DF
2019
PRISCILA DANIELE PIVANTE
GESTÃO DE PROJETOS E QUALIDADE: UM PLANO PARA GERENCIAMENTO
DA QUALIDADE EM UM PROJETO DE BUSINESS INTELLIGENCE
Monografia apresentada ao
Departamento de Administração como
requisito parcial à obtenção do título de Pós-
Graduada em Gestão de Projetos.
Professor Orientador:
Dr., Rafael Rabelo Nunes
Brasília – DF
2019
GESTÃO DE PROJETOS E QUALIDADE: UM PLANO PARA GERENCIAMENTO
DA QUALIDADE EM UM PROJETO DE BUSINESS INTELLIGENCE
A Comissão Examinadora, abaixo identificada, aprova o Trabalho de Conclusão do Curso de
Gestão de Projetos da Universidade de Brasília do aluno
Priscila Daniele Pivante
Dr., Rafael Rabelo Nunes
Professor-Orientador
Prof Dra. Siegrid Guillaumon Dechandt Ms. João Rufino Sales
Professora-Examinador Coronel do EB-Examinador
Brasília, 09 de setembro de 2019
AGRADECIMENTOS
Meu sincero agradecimento ao Prof. Dr. Rafael Rabelo
Nunes, orientador deste trabalho, pela condução do
trabalho, pela adequação do tema para que eu pudesse
atender aos anseios dos meus superiores e pelas
orientações sempre objetivas e esclarecedoras. Agradeço
também à minha família, pela compreensão nos momentos
de ausência e por todo apoio para que eu pudesse concluir
este trabalho. Um agradecimento especial à minha filha,
Camila, que mesmo à distância, e com a pouca idade que
possui, foi capaz de me dirigir palavras de ânimo e
incentivo.
“O planejamento não é uma tentativa de predizer o que vai
acontecer. O planejamento é um instrumento para
raciocinar agora, sobre que trabalhos e ações serão
necessários hoje, para merecermos um futuro. O produto
final do planejamento não é a informação: é sempre o
trabalho.” - Peter Drucker
RESUMO
Este estudo propõe um plano de gerenciamento da qualidade no âmbito do painel de indicadores
do sistema de saúde do Exército. Por meio de um planejamento da qualidade, com base na
metodologia de pesquisa-ação, serão propostas ações que visam garantir a continuidade da
disseminação da informação precisa e em tempo hábil para auxiliar os gestores na tomada de
decisões. O estudo descreve o contexto atual do negócio, os problemas que enfrenta e as
soluções que foram identificadas. Para atender aos objetivos propostos, tanto o geral quanto os
específicos, o estudo foi dividido em cinco fases: revisão da literatura referente à qualidade de
software, testes e Business Intelligence; escolha e estruturação do método de pesquisa;
contextualização e o plano de ação que é a estruturação do plano de gerenciamento da qualidade
e conclusão. Durante a fase de revisão de literatura, foi realizado um amplo levantamento acerca
dos conceitos de planejamento, garantia e controle da qualidade. A escolha do método de
pesquisa se deu devido ao caráter imediatista de uma solução para o problema apresentado no
estudo, ela envolveu as partes interessadas e os especialistas da área de desenvolvimento do
Exército com a finalidade de se levantar a melhor hipótese a ser adotada para a solução do
problema. Por fim, a estruturação do plano de gerenciamento da qualidade levou em
consideração as melhores práticas adotadas no que tange aos projetos de Business Intelligence
no âmbito do Exército Brasileiro, a estrutura atualmente disponível, a capacidade de
desenvolvimento e a opinião especializada de pessoas engajadas nos projetos envolvidos nesse
estudo.
Palavras-chave:
Qualidade de software; Business Intelligence; Sistema de Saúde; Pesquisa-ação
SUMÁRIO
1. INTRODUÇÃO ........................................................................................................................................................ 1
1.1. Objetivo Geral ...................................................................................................................................................................... 2
1.2. Objetivos Específicos ......................................................................................................................................................... 3
2. REFERENCIAL TEÓRICO .................................................................................................................................... 4
2.1. Qualidade em Projetos de Software ............................................................................................................................ 4 2.1.1. Qualidade ........................................................................................................................................................................ 4 2.1.2. Qualidade de Software .............................................................................................................................................. 6 2.1.3. Gerenciamento da Qualidade ................................................................................................................................. 6 2.1.4. Planejamento da Qualidade .................................................................................................................................... 8 2.1.5. Garantia da Qualidade ............................................................................................................................................ 13 2.1.6. Controle da Qualidade ............................................................................................................................................ 15
2.2. Testes de Software .......................................................................................................................................................... 16 2.2.1. Sistemas de Informação......................................................................................................................................... 18
2.3. Business Intelligence ...................................................................................................................................................... 20 2.3.1. Modelagem dimensional ....................................................................................................................................... 20 2.3.2. Tomada de decisão .................................................................................................................................................. 21
3. MÉTODO E TÉCNICA DE PESQUISA ............................................................................................................ 23
3.1. Classificação da Pesquisa ............................................................................................................................................. 23
3.2. Etapas da pesquisa-ação .............................................................................................................................................. 24 3.2.1. Fase exploratória ...................................................................................................................................................... 24 3.2.2. O tema da pesquisa e o lugar da teoria ........................................................................................................... 24 3.2.3. Colocação dos problemas ..................................................................................................................................... 25 3.2.4. Hipóteses ...................................................................................................................................................................... 26 3.2.5. Seminários ................................................................................................................................................................... 26 3.2.6. Seleção de amostras ................................................................................................................................................ 27 3.2.7. Coleta e análise de dados ...................................................................................................................................... 27 3.2.8. Plano de ação .............................................................................................................................................................. 28 3.2.9. Divulgação dos Resultados ................................................................................................................................... 28
4. CONTEXTUALIZAÇÃO ..................................................................................................................................... 29
4.1. O Sistema de Saúde do Exército ................................................................................................................................. 29
4.2. A Gestão Financeira do SSEx e o SIRE ..................................................................................................................... 31
4.3. O SIRE e a necessidade de evolução ......................................................................................................................... 32
4.4. O Painel de Indicadores do SSEx................................................................................................................................ 33
4.5. O problema......................................................................................................................................................................... 34
5. ESTRUTURAÇÃO DO PLANO DE GERENCIAMENTO DA QUALIDADE ............................................. 36
5.1. Processos de Gerenciamento da Qualidade ........................................................................................................... 36
5.2. Controle de Qualidade ................................................................................................................................................... 36 5.2.1. Requisitos de sucesso do projeto ...................................................................................................................... 36 5.2.2. Métricas da Qualidade ............................................................................................................................................ 39 5.2.3. Ferramentas da Qualidade ................................................................................................................................... 41 5.2.4. Entregas do projeto e critérios de aceitação ................................................................................................ 41
5.3. Garantia de Qualidade .................................................................................................................................................. 42 5.3.1. Auditorias do Projeto e Revisões de Qualidade .......................................................................................... 42 5.3.2. Processos de melhoria contínua ........................................................................................................................ 43
5.3.3. Responsabilidades de Qualidade da Equipe do Projeto .......................................................................... 43
6. CONCLUSÃO ........................................................................................................................................................ 44
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................................................. 45
APÊNDICES ......................................................................................................................................................................... 49
1
1. INTRODUÇÃO
Considerando o cenário econômico, a inflação da saúde, que geralmente é mais alta que
a inflação normal, a necessidade de informações consistentes e a pressão por decisões que
surtam efeito produtivo e rentável, o Business Intelligence – BI, se tornou uma ferramenta
indispensável para os gestores como uma ferramenta de apoio à tomada de decisão.
No contexto do Exército Brasileiro, essa condição não é diferente. O Sistema de Saúde
do Exército possui um Fundo de Saúde próprio que pode ser comparado à um plano de saúde.
Ele possui duas vertentes, a saúde assistencial, que é aquela prestada ao militar e seus
dependentes em tempos de paz, e a saúde operacional que é aquela que presta assistência em
tempos de guerra ou em situações específicas.
O Sistema de Saúde do Exército possui, em média, 720 mil beneficiários e um
orçamento de, aproximadamente, 1,5 bilhão de reais divididos entre as 525 unidades que
prestam assistência à saúde da família militar.
As perspectivas futuras indicam um aumento da expectativa de vida da família militar
acompanhada de um progressivo aumento dos custos de tratamentos de saúde, decorrentes não
só do prolongamento da vida como também do crescente e consistente encarecimento dos
modernos tratamentos de saúde. Isso indica a necessidade de um eficaz sistema de
gerenciamento, que vise a redução dos custos futuros e a mitigação dos riscos ao sistema,
aumentando-se a sua efetividade. São vários os sistemas que trabalham conjuntamente para
operacionalizar a distribuição desse recurso, bem como as arrecadações a título de contribuição
ou de indenizações.
Devido à complexidade administrativa do Sistema de Saúde do Exército, percebeu-se a
necessidade de uma ferramenta que pudesse facilitar a visualização dos dados da saúde, bem
como reunisse, em uma única fonte de consulta, os dados advindos desses vários sistemas que
operacionalizam a execução da assistência à saúde. Nesse contexto, surgiu o Painel de
Indicadores do Sistema de Saúde do Exército – PI-SSEx, uma ferramenta de apoio à tomada de
decisão no nível estratégico do Exército Brasileiro.
O principal sistema que subsidia o painel de indicadores é o SIRE, esse sistema foi
desenvolvido há 12 anos para atender uma demanda essencial do sistema de saúde, que era a
2
de gerar e controlar as guias de encaminhamento para as organizações civis de saúde, daí seu
nome inicial – Sistema Interno de Registro de Encaminhamentos, essas organizações são
unidades de atendimento que prestam serviços aos militares quando a demanda é maior do que
a capacidade de atendimento, seriam as unidades conveniadas do fundo de saúde do Exército.
O objetivo real pretendido com esse controle é que os recursos descentralizados para que as
unidades emissoras dessa guia pudessem efetuar os pagamentos dos débitos junto à sua rede
credenciada, fossem efetivamente empregados para esse fim. Posteriormente, o SIRE foi
evoluído e começou a realizar outras funções, como a de controlar os atendimentos internos,
avaliar a produtividade das organizações militares de saúde e ainda controlar os agendamentos
para as consultas e procedimentos realizados nas organizações militares de saúde.
Devido à proporção que o SIRE tomou, a quantidade de transações realizadas
diariamente, o volume de dados armazenadas e a sua indispensabilidade para o Exército, viu-
se a necessidade de evoluir o sistema. No estudo de viabilidade realizado, decidiu-se que a
melhor estratégia seria a de desenvolver uma nova aplicação, já que ele havia evoluído de um
sistema de emissão de guias de encaminhamento para um sistema integrado de gestão
orçamentária. Como a rotina de processamento das informações orçamentárias e financeiras
inclui uma série de outros processos, a evolução do SIRE para o SIRE 2.0 também passou a
incluir a gestão financeira, de modo a concentrar todas as informações em um único sistema.
Considerando esse contexto de evolução do SIRE, este estudo visa trazer uma proposta
para um plano de gerenciamento da qualidade com vistas a dar continuidade às informações
apresentadas no painel de indicadores, uma vez que toda a estrutura será modificada sem perder
o histórico das informações geradas até o momento da “virada de chave”, já que não haverá
migração entre as bases e o SIRE legado ficará disponível apenas para consulta.
1.1. Objetivo Geral
O objetivo geral desta pesquisa é desenvolver um plano de qualidade para um projeto
de Business Intelligence - BI, considerando as boas práticas de gerenciamento de projetos de
software.
3
1.2. Objetivos Específicos
a) Evidenciar a necessidade de antecipação de realização dos trabalhos antes do fim da
operação do SIRE.
b) Fornecer os subsídios necessários para as áreas envolvidas, com o objetivo de que o
planejamento realizado nesse trabalho seja executado durante o desenvolvimento do SIRE
2.0.
4
2. REFERENCIAL TEÓRICO
2.1. Qualidade em Projetos de Software
Na década de 90, eram desperdiçados milhões de dólares em softwares que não
apresentavam as características e funcionalidades esperadas. A partir daí, surgiu a necessidade
de maior qualidade, uma vez que os softwares ficavam cada vez mais integrados às atividades
do cotidiano. (PRESMANN, 2016, p. 412).
Com base nessa necessidade, uma série de métodos e metodologias foram desenvolvidas
a fim de se atingir a qualidade nos projetos de software.
2.1.1. Qualidade
Garvin (1984), em seu artigo intitulado “What Does "Product Quality" Really Mean?”,
afirma que existem cinco abordagens para definir a qualidade, das quais destacam-se duas para
os fins deste estudo, são elas:
Abordagem baseada em produtos: Essa abordagem vê a qualidade como uma variável
precisa e mensurável. De acordo com o autor, “qualidade reflete a presença ou ausência
de atributos mensuráveis do produto, ela pode ser avaliada objetivamente e é baseada
apenas em preferências” (GARVIN, 1984).
Abordagem baseada no usuário: Essa abordagem tem como premissa que a qualidade
está nos olhos de quem vê, ou seja, é uma visão pessoal e subjetiva. De acordo com o
autor, existem conceitos distintos sobre essa abordagem na literatura, mas que ambos
enfrentam o mesmo problema. “O primeiro é prático - como agregar preferências
individuais amplamente variadas, para que elas levem a definições significativas de
qualidade no nível do mercado. O segundo é mais fundamental - como distinguir os
atributos do produto que denotam qualidade daqueles que simplesmente maximizam a
satisfação do consumidor” (Ibidem, 1984).
Segundo o autor, essas duas abordagens podem coexistir pois, embora seu foco seja
diferente, um produto que não atenda as especificações ou não atenda a finalidade do negócio
é um produto pouco confiável.
5
A ISO 9000 é um conjunto de normas e padronizações que tem como objetivo guiar
organizações na implementação de processos de Gestão da Qualidade e de Garantia da
Qualidade. Ela abrange pontos referentes à garantia da qualidade em projeto, desenvolvimento,
produção, instalação e serviços associados, visando a satisfação do cliente.
Criada pela International Organization For Standardization (ISO) ou Organização
Internacional de Normalização e lançada em 1987, ela progrediu ao longo dos anos, possuindo
várias versões e especializações de acordo com as necessidades apresentadas, ela estabelece os
conceitos, princípios e vocabulário fundamentais para sistemas de gestão da qualidade (SGQ)
e constitui a base de suporte para outras normas. O objetivo dessa norma é o de auxiliar as
organizações a compreenderem os conceitos, princípios e vocabulários fundamentais da gestão
da qualidade. A certificação ISO é o mecanismo para garantia da qualidade mais reconhecido
em todo o mundo. No Brasil, seu representante é a ABNT (Associação Brasileira de Normas
Técnicas) e quem fiscaliza é o INMETRO (Instituto Nacional de Metrologia).
De acordo com a NBR ISO 9000, na edição de 2015, a qualidade dos produtos e serviços
de uma organização é determinada pela aptidão para satisfazer os clientes e pelo impacto,
pretendido ou não, sobre outras partes interessadas relevantes. A qualidade dos produtos e
serviços incluem não só as funções e o desempenho pretendidos, mas também os valores
percebidos e os benefícios para o cliente.
Conceituar qualidade não é uma tarefa simples, ela pode ser percebida através de
diversos pontos de vista. A relevância de cada ponto de vista pode variar com o contexto e ao
longo do tempo, pois as pessoas podem mudar seu posicionamento e rever suas referências.
Sendo assim, a qualidade depende da perspectiva do avaliador.
Segundo Ribas (2001), “qualidade é conformidade com os requisitos, é um fator
atingível, mensurável com toda precisão e lucrativo, que pode ser estabelecido desde que haja
compromisso e compreensão. A não conformidade é a ausência de qualidade”. Ainda segundo
o mesmo autor, a qualidade é uma propriedade do produto (ou serviço) que se torna “adequado
ao uso”. E essa “adequação” existe, para ele, quando o produto (ou serviço) é confiável e atende
as necessidades de quem o utiliza (ou consome).
Segundo Da Silva (2001), para se ter um sistema de qualidade, o primeiro passo é fazer
com que a definição das especificações esteja de acordo com as necessidades do usuário. O
entendimento real das necessidades não é uma tarefa das mais simples. Muitas vezes, o usuário
6
não sabe exatamente o que deseja e nem como transformar processos manuais em processos
informatizados. A expertise da equipe de análise é um fator determinante para o sucesso do
projeto, bem como para a garantia da qualidade do produto.
2.1.2. Qualidade de Software
Segundo Bartié (2002), a qualidade possui 3 pilares fundamentais, o planejamento da
qualidade, a garantia da qualidade e o controle da qualidade, conforme a Figura 1:
Figura 1 – Pilares da qualidade de software – Fonte: BARTIÉ (2002)
2.1.3. Gerenciamento da Qualidade
Segundo o PMI (2018) o gerenciamento da qualidade tem o foco em três processos;
planejar o gerenciamento da qualidade, gerenciar a qualidade e controlar a qualidade. Planejar
o gerenciamento da qualidade consiste em identificar os requisitos e/ou padrões da qualidade
do projeto ou entregas, documentar como se dará a conformidade com os requisitos
especificados. Gerenciar a qualidade é o processo de executar o previsto transformando o
planejamento em atividades que incorporam no projeto as políticas de qualidade da
organização. Por fim, controlar a qualidade é o processo de monitorar e registrar os resultados
da execução das atividades para avaliar o desempenho e garantir que as saídas do projeto
atendam as expectativas dos clientes. A visão geral dos processos pode ser demonstrada
conforme a Figura 2:
7
Figura 2 – Visão geral do Gerenciamento da Qualidade – Fonte PMBOK 6ª Edição
Ainda segundo o PMI (2018) o gerenciamento da qualidade aborda o gerenciamento do
projeto, bem como das entregas do projeto. O planejamento deve ser seguido, uma vez que o
não cumprimento pode trazer consequências negativas para as partes interessadas. Por exemplo,
cumprir os requisitos sobrecarregando a equipe pode aumentar os níveis de riscos, gerar atritos
entre os funcionários, produzir erros ou retrabalho e reduzir os lucros. Apressar as inspeções de
qualidade com o objetivo de cumprir o cronograma pode resultar em erros não detectados,
aumentando os riscos pós-implementação.
Existem cinco níveis de gerenciamento da qualidade:
Deixar que o cliente encontre o erro é mais caro. Essa abordagem pode trazer como
consequência problemas de garantia, recalls, perda de reputação e custos de retrabalho.
Identificar e corrigir os defeitos antes que os clientes recebam as entregas.
Usar a garantia da qualidade para examinar e corrigir o processo como um todo, não
apenas defeitos pontuais.
Incorporar a qualidade no planejamento e design do projeto e do produto.
Envolver a organização em uma cultura, na qual todos estejam comprometidos com a
qualidade dos processos e produtos.
8
Atualmente, existem práticas e tendências que buscam minimizar a variação entre as
expectativas dos clientes e as entregas, elas não se limitam exclusivamente a essas abordagens,
são elas:
a) Satisfação do cliente.
b) Melhoria contínua.
c) Responsabilidade da gerência.
d) Parceria mutuamente benéfica com fornecedores.
e) Conformidade com políticas e auditoria.
f) Padrões e conformidade com regulamentações.
g) Engajamento das partes interessadas.
2.1.4. Planejamento da Qualidade
O objetivo pretendido ao se estabelecer metas para o atingimento de um produto ou
serviço com qualidade, pode ser alcançado e mensurado por diversas metodologias. É o que
podemos chamar de Gestão da Qualidade, nesse contexto existe o ciclo PDCA. Esse método
foi desenvolvido na década de 30 pelo americano Shewhart, mas foi Deming seu maior
divulgador, na década de 50. Demig ficou mundialmente conhecido ao aplicar os conceitos de
qualidade no Japão. Por isso, o Ciclo PDCA também é conhecido como Ciclo de Shewhart ou,
mais comumente, Ciclo de Deming (NEVES, 2007).
De acordo com Silva (2006), o PDCA é uma forma de praticar o controle. Segundo
Lima (2006) o Ciclo PDCA é utilizado para aplicar ações de controle dos processos, é o
estabelecimento de uma “diretriz de controle”, planejamento da qualidade, manutenção de
padrões e alteração da própria diretriz, quando necessário realizar melhorias. Ele consiste em
ações encadeadas para garantir a organização de processos. Ele é dividido em quatro fases:
Planejar (Plan), Fazer (Do), Checar (Check) e Agir (Action). Conforme Figura 3:
9
Figura 3 – Fases do Ciclo PDCA – Fonte: SILVA (2006)
Planejar (Plan) – É a fase na qual os objetivos de cada processo são definidos para
atender a necessidade do cliente. É nessa frase em que os problemas são identificados,
são definidas as metas, e são feitas a análise do processo e a elaboração da diretriz. É a
fase mais complexa e que exige mais esforços. Quanto maior o número de informações
utilizadas, maior a necessidade em emprego de ferramentas para coletar, processar e
dispor essas informações (WERKEMA, 1995).
Fazer (Do) – É a execução do plano. As pessoas envolvidas devem ser treinadas, antes
do início da execução para que haja comprometimento e a execução seja como
planejada. O que foi planejado na fase anterior é colocado em prática, é nesse momento
que informações são coletadas para dar subsídios para a próxima fase (Idem, Ibidem).
Checar (Check) – Após a implantação do processo, e com a utilização de ferramentas
próprias, é realizada a análise para a avaliar se cada processo cumpre aquilo que foi
proposto no planejamento, é quando os erros ou falhas são identificados (Ibid.).
Agir (Action) – É a fase na qual há a atuação no sentido de retomar o plano proposto
caso tenham ocorrido desvios. Ela identifica se os objetivos foram atingidos e, de acordo
com o resultado obtido na fase anterior, os possíveis erros ou falhas devem ser
corrigidos, os processos melhorados e, assim, as etapas se reiniciam (Ibid.
Para se definir o que é qualidade de software é necessário entender o ciclo de vida de
desenvolvimento de um produto. Para PRESSMAN (1995) o ciclo de vida do software é
dividido em seis parte, representado na Figura 4:
10
Figura 4 – Ciclo de vida do software – Fonte PRESSMAN (1995)
As atividades acima podem ser abordadas da seguinte forma:
Avaliação – estabelecimento dos requisitos. O software não é uma parte isolada de um
processo, é necessário avaliar, nessa etapa, o contexto ao qual ele se enquadra e a
finalidade a que ele se propõe.
Análise – é a análise dos requisitos de software de forma mais técnica, para entender o
produto que deve ser construído, sua função, desempenho e interface, de forma a atender
a necessidade do cliente.
Projeto – é dividido em quatro passos distintos: estrutura de dados, arquitetura de
software, detalhes procedimentais e caracterização da interface. É uma prévia da
avaliação da qualidade antes do início, propriamente dito, do desenvolvimento do
produto.
Implementação – é a transcrição da necessidade do usuário em linguagem de máquina.
É nessa fase que os requisitos levantados pelo analista serão transformados em um
software.
Teste – após a codificação se inicia a fase de testes, é nessa fase que aspectos técnicos
e negociais são avaliados. Os testes são o primeiro passo para a garantia da qualidade,
uma vez que é realizada a validação daquilo que foi solicitado pelo cliente. Testes
lógicos com vistas a identificar erros de programação e testes de regras negociais para
identificar se o software atende à necessidade levantada na fase inicial.
11
Manutenção – todo software sofre alterações depois de entregue, sejam elas por
adequação aos processos de trabalho ou por erros apresentados na sua operação, que
não foram percebidos inicialmente.
Fazendo uma correlação do que foi proposto por Pressman (1995) com o ciclo PDCA,
é possível obter a relação das atividades de acordo com o Quadro 1 abaixo:
Ciclo PDCA Ciclo de Vida do Software
Planejar Avaliação, Análise e Projeto
Fazer Implementação
Checar Teste
Agir Manutenção Quadro 1 – Correlação entre o ciclo PDCA e o ciclo de vida clássico
Apesar de ser um conceito antigo, podemos observar que o proposto por McCall e
Cavano (1978), ainda é usual para os dias de hoje, um software de qualidade pode ser avaliado
por três pontos distintos, conforme Figura 5: Transição do Produto, Revisão do Produto e
Operação do Produto.
Figura 5 – Os Fatores da Qualidade de McCall
De acordo com McCall e Cavano (1978), quanto à Revisão do produto:
Manutenção é o esforço necessário para identificar e corrigir um erro.
Flexibilidade é a possibilidade para modificar um programa em operação.
Testabilidade é o tempo necessário para realização de testes a fim de garantir que ele
atinja o objetivo.
12
Ainda de acordo com McCall e Cavano (1978), quanto à Transição do produto:
Portabilidade é o esforço para transferir um programa de um ambiente (hardware ou
software) para outro.
Reutilização é a possibilidade de aproveitamento do código ou de parte dele em outras
aplicações.
Interoperabilidade é o esforça de integração entre uma aplicação e outra.
De acordo com McCall e Cavano (Ibidem), quanto à Quanto à Operação do Produto:
Correção é o atendimento às especificações do cliente e os objetivos a que o programa
se propõe.
Confiabilidade é a correta execução da função pretendida com precisão.
Usabilidade é o esforço para operar o programa, aprender, preparar as entradas e
interpretar as saídas.
Integridade é o acesso controlado ao software ou aos dados que ele armazena.
Eficiência é a quantidade de esforço computacional e códigos exigidos para executar a
função a qual o software se propôs.
Uma definição mais completa para a qualidade de software pode ser a de Bartié (2002,
p. 16): “Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos
produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e
eliminando defeitos".
O desenvolvimento de um software com qualidade é crítico para a maioria das
organizações. O foco da qualidade do software deve ser o atendimento das necessidades do
cliente, conformidade dos requisitos funcionais e de desempenho explicitamente declarados,
padrões de desenvolvimento claramente documentados e as características implícitas que são
esperadas de todo software profissionalmente desenvolvido (DA SILVA, 2001; PRESSMAN,
1995).
Segundo o PMI (2018), planejar o gerenciamento da qualidade é realizar o levantamento
dos requisitos e/ou padrões de qualidade do projeto e das entregas, é demonstrar como se dará
13
a conformidade entre o que foi solicitado e o que foi entregue, se a finalidade dos requisitos de
negócio foi atendida. É um processo que acompanha todo o ciclo do projeto, sendo realizado
uma vez ou em pontos definidos. As entradas, ferramentas e técnicas podem ser observadas na
Figura 6:
Figura 6 – Planejamento da Qualidade – PMI
Todo o processo de gerenciamento proposto pelo PMI (2018) está alinhado com o ciclo
PDCA, que consiste em planejar, fazer, checar e agir, em um processo contínuo de controle e
avaliação.
2.1.5. Garantia da Qualidade
A fim de alcançar uma boa qualidade do produto, os processos de desenvolvimento
devem estar claramente definidos e documentados, e precisam ser rigorosamente seguidos pelas
pessoas que participarão do seu desenvolvimento.
A garantia de qualidade de software (Software Quality Assurance -
SQA) é um padrão sistemático e planejado de ações que são exigidas para
garantir a qualidade de software. Sendo uma atividade aplicada ao longo de
todo o processo de engenharia de software (PRESSMAN, 1995).
São tarefas associadas a sete grandes atividades:
14
Aplicação de métodos técnicos – A SQA tem início nesta atividade, ela consiste em
auxiliar o analista a especificar e o projetista a desenvolver um projeto com uma
qualidade alta.
Revisão técnica formal – São reuniões com uma equipe especializada com o objetivo
de descobrir problemas que possam impactar na qualidade do produto.
Atividade de teste de software – É uma série de métodos combinados com estratégia
para elaboração de casos de teste que possam identificar erros efetivamente.
Aplicação de padrões – Os clientes ou agências reguladoras têm a missão de
determinar os padrões que servirão como base para a qualidade.
Controle de mudanças – Avalia a natureza da mudança e controla o impacto que ela
causa no projeto, os pedidos devem ser formalizados e influenciam diretamente na
qualidade do produto.
Medição – a SQA tem como um dos objetivos principais avaliar o impacto das
mudanças metodológicas e procedimentais sobre a qualidade do software. Para isso, ela
se vale da utilização de métricas.
Manutenção de Registros – Garante a qualidade coletando, registrando e
compartilhando informações relevantes ao funcionamento e manutenção do software.
Para Gomes (2010), a Garantia da Qualidade tem como objetivo prover confiança sobre
a conformidade de produtos e serviços e requisitos especificados e que venham ao encontro das
necessidades dos usuários.
Para alcançar-se um produto de qualidade, os processos de desenvolvimento devem ser
definidos claramente e bem documentados, as pessoas que participam do processo devem ser
rigorosas no cumprimento daquilo que foi planejado (STAA, 2000).
Os processos e métodos que auxiliam no desenvolvimento devem ser efetivamente
seguidos ao longo do ciclo de vida do software e não somente mencionados nos planos de
projeto (TIAN, 2005).
15
2.1.6. Controle da Qualidade
Esse controle verifica se, durante o desenvolvimento, os resultados dos projetos atendem
os processos da qualidade, estabelecidos no planejamento. A medição é realizada por meio de
um acompanhamento da eficácia durante o desenvolvimento. Quando a qualidade não é
alcançada em algum ponto, há tempo hábil de executar ações de manutenção para manter o
correto nível de qualidade. (BARTIE, 2002).
Para um controle efetivo, é necessário que os requisitos funcionais e não funcionais
sejam claramente estabelecidos. É igualmente importante definir qual o grau de qualidade
esperado de determinadas características presentes nos artefatos. Com isso, os artefatos se
tornam um importante fator do controle da qualidade, as especificações precisam estar bem
definidas e devem ser mensuráveis, para que se possa realizar comparações de resultado ao final
de cada processo. (PRESSMAN, 2006).
Um erro que é frequentemente cometido pelas organizações que não possuem
metodologias definidas e processos com um certo nível de maturidade, é a confusão entre os
conceitos de Garantia da Qualidade e Controle da Qualidade. O Quadro 2 exibe o detalhamento
das principais diferenças:
Garantia da Qualidade Controle da Qualidade
Garante que o processo definido é
adequado.
As atividades visam a descobertas de
defeitos específicos.
Metodologia e padrões de
desenvolvimento garantem a qualidade.
Verifica se os requisitos definidos são os
apropriados.
É orientada a processo. É orientado a produto.
É orientada a prevenção. É orientado a detecção.
Foca na melhoria do processo e
monitoramento.
Inspeciona se o produto atende aos
requisitos especificados.
Foco nas atividades iniciais do ciclo de
vida no momento do desenvolvimento
do software.
Foco nas fases finais do
desenvolvimento do software.
Garante que os processos estão sendo
executados de maneira correta.
Garante que os resultados estão
conforme os requisitos.
Quadro 2 – Diferenças entre Garantia e Controle da Qualidade
16
2.2. Testes de Software
“Qualidade de Software é um processo sistemático que focaliza todas as etapas e
artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos,
prevenindo e eliminando defeitos”. (Bartié, 2002, p.16). Ainda de acordo com o mesmo autor,
os testes devem ser realizados desde o início do projeto, pois ao se identificar os erros nas fases
iniciais do desenvolvimento o custo de manutenção é reduzido.
Segundo Mathur (2009), a qualidade está fortemente ligada ao atendimento dos
requisitos do projeto por meio dos artefatos gerados com exatidão e confiabilidade.
Para Bartié (2002), muitas empresas de desenvolvimento acreditam que o processo é
composto por etapas, e desta forma aplicam os testes em um período determinado somente para
isso, porém, os testes devem ser realizados desde o início do projeto identificando erros nas
fases iniciais e reduzindo os custos com manutenção. Ele afirma que a “Qualidade não é uma
fase do desenvolvimento de software, é parte de todas as fases”.
Durante o ciclo de desenvolvimento, a atividade de teste tem como objetivo garantir o
comportamento do software conforme o esperado. Essa atividade pode ser dividida,
basicamente, em teste de requisitos funcionais e não funcionais.
Os testes realizados com os requisitos funcionais também são conhecidos como testes
de caixa preta e caixa branca. (Delamaro; Maldonado, 2007). O teste caixa preta, também
conhecido como “técnica funcional”, observa o resultado da saída dos dados. Sua aplicação tem
como origem os requisitos e funções do sistema. Já o teste caixa branca, também conhecida
como “teste estrutural”, observa a implementação do código fonte para identificar o que deve
ser testado.
Segundo Bastos et al. (2007), algumas técnicas de teste podem ser adotadas. São elas:
Técnica Estrutural:
Testes de Estresse: o software é submetido a condições extremas de execução, com
baixo recurso de hardware, altos volumes de dados e transações.
Testes de Execução: verifica os tempos de resposta, de processamento e de
desempenho.
17
Testes de Recuperação (Contingência): obriga o sistema a falhar de diversas maneiras
e verifica se sua recuperação é executada adequadamente.
Testes de Operação: o sistema deve ser integrado com o ambiente operacional.
Testes de Conformidade: verifica se a aplicação foi desenvolvida seguindo os padrões,
procedimentos e guias da área de processos.
Testes de Segurança: verifica os acessos ao sistema de forma a identificar se estão em
conformidade com o que foi estabelecido, garante a segurança do sistema e de seus
módulos.
Técnica Funcional:
Testes de Requisitos: verifica a correta execução das funcionalidades, sem a presença
de falhas, por um período pré-determinado.
Testes de Tratamento de Erros: verifica a capacidade de responder adequadamente a
transações incorretas.
Testes de Interconexão: verifica se a comunicação de dados entre os softwares está
apropriada e de acordo com o esperado.
Testes Paralelos: são utilizados para conferir se as funcionalidades existentes no
sistema antigo estão consistentes e definidas corretamente no novo sistema.
Rios e Moreira (2003) afirmam que o ciclo de vida do processo de teste envolve várias
etapas, como mostra a Figura 7:
18
Figura 7 – Modelo do ciclo de vida do processo de teste – Fonte: RIOS, E. & MOREIRA, T. (2003)
Procedimentos Iniciais: observa os requisitos do negócio.
Planejamento: define a estratégia que será adotada para o teste e para o plano de teste.
Especificação: elabora/revisa os casos e roteiros de testes.
Execução: executa os testes planejados.
Entrega: armazena os documentos de teste.
Preparação: define a preparação do ambiente de teste.
O ambiente de teste deve ser preparado para ficar o mais condizente possível com a
realidade do usuário, Bastos et al. (2007) afirma que é necessária “a descoberta de erros reais –
ou seja, aqueles que realmente ocorreriam na produção e que porventura não foram descobertos
em tempo de desenvolvimento”.
2.2.1. Sistemas de Informação
De acordo com O’Brien (2002), sistema é definido como um grupo de elementos inter-
relacionais, ou que interagem entre si, que formam um conjunto unificado com um objetivo
comum, ou seja, recebem insumos, processam a informação e produzem um resultado. São três
as funções em interação: entrada do dado, processamento e saída.
Segundo Turban et al. (2004), os sistemas de informação têm a finalidade de facilitar a
concretização de determinados objetivos, dentre eles, a transformação de dados em informações
e conhecimento.
Para Laudon & Laudon (2007), os sistemas de informação podem ser definidos como
um conjunto de componentes que coletam, processam, armazenam e distribuem informações
com o objetivo de auxiliar no planejamento, controle, coordenação, análise e no processo
decisório em empresas e organizações. Eles possuem informações sobre pessoas, lugares e
coisas da organização ou em seu ambiente. Ainda, segundo o autor, existe uma classificação
desses sistemas de acordo com sua finalidade. Eles podem ser: sistemas de nível operacional,
de conhecimento, gerencial ou de nível estratégico.
Os sistemas de informação necessitam de uma série de componentes para compor um
BI. São eles:
19
Banco de Dados: É uma coleção de dados inter-relacionados, são armazenados de
forma independente servindo, assim, para que mais de uma aplicação da mesma
organização possa utilizar os dados ali armazenados. Eles são projetados para
administrar um grande volume de dados, devem ser capazes de prover a segurança dos
dados armazenados, a integridade do dado e a confiabilidade nos resultados
apresentados. (TURBAN et al, 2004)
Extração, Transformação e Carga (ETL): O processo de ETL é um componente de
qualquer projeto centrado em dados. A extração é a leitura do banco de dados, podendo
ter como origem um ou mais bancos; A transformação consiste em trabalhar os dados a
fim de compatibilizá-los para serem colocados em um data warehouse ou em outro
banco de dados; e a carga é a disponibilização, de fato, dos dados no banco. (Turban et
al., 2009). Ainda de acordo com Turban et al. (2009), as ferramentas de ETL
transportam dados entre fontes e alvos, documentando como os elementos devem se
comportar desde a origem até o destino, além de terem a possibilidade de trocar
metadados com outras aplicações, operam todos os processos em tempo de execução.
A extensa realização de um ETL é sinal de dados mal gerenciados.
Data Warehouse (DW): é definido por Inmon (1997) como “[...] um conjunto de dados
baseado em assuntos, integrado, não-volátil, e variável em relação ao tempo, de apoio
às decisões gerenciais". Segundo Turban et al. (2009), esses bancos darão subsidio aos
gestores para análise de tendências históricas, melhorando os processos.
Data Mart (DM): tem a mesma finalidade do Data Warehouse, porém em uma escala
menor, ele é mais específico, podendo, em alguns casos, substituir o DW ou integrá-lo.
(TURBAN et al., 2009)
Processamento Analítico Online (OLAP): é uma tecnologia que possibilita visualizar
e acessar dados corporativos com uma grande flexibilidade na visualização e alta
performance. Com a globalização, os gestores têm a necessidade de tomar decisões
assertivas, para ajudá-los nessa tomada de decisão, o OLAP exibe informações por meio
de um modelo intuitivo e de fácil navegação. (O’Brien, 2001). Já para Turban et al.
(2004), o OLAP tem como objetivo analisar a relação de dados, procurar padrões,
tendências e exceções, além de responder às consultas dos usuários. É a ligação entre o
DW ou DM e o usuário. Exemplo de uma arquitetura de BI na Figura 9 abaixo:
20
Figura 9 – Arquitetura de uma estrutura básica de BI – Fonte: Diego Elias (2014)
2.3. Business Intelligence
Business Intelligence (BI) é uma ferramenta de apoio à tomada de decisão que abrange
ferramentas, arquitetura, bases de dados, data warehouse, gerenciamento de desempenho e
metodologias, o termo foi criado pelo Gartner Group em meados da década de 1990. Ele
possibilita que gestores acessem os dados de forma rápida e de fácil compreensão, permitindo
a manipulação desses dados com vistas a fornecer a possibilidade de uma análise adequada.
(TURBAN et al., 2009).
Ainda de acordo com o mesmo autor, o BI possui uma série de capacidades, tais como,
geração de relatórios, análises, datamining, análises preditivas, entre outras. Essas capacidades
têm como origem fontes de informações dos sistemas de informação, sistemas de apoio à
decisão, perguntas, fluxos de trabalho, pesquisas, visualizações, gerenciamento de operações e
inteligência artificial. O BI deve servir como uma ferramenta para evoluir a forma como a
organização conduz seu negócio.
Para Barbieri (2011, p.95) Business Intelligence é a “(...) utilização de variadas fontes
de informação para definir estratégias de competitividade nos negócios da empresa”. Para que
a ferramenta de BI possa ser eficiente, alguns conceitos devem ser levados em consideração, os
mesmos serão abordados nas seções a seguir.
2.3.1. Modelagem dimensional
É uma técnica que estrutura os dados de forma dimensional com o objetivo de permitir
que a informação seja exibida de maneira intuitiva com diferentes perspectivas, facilitando a
análise pelos gestores (Kimbal, 1998). Esse tipo de modelagem é um modelo conceitual,
21
formado por tabelas Fatos e tabelas Dimensões. A estrutura dessa modelagem é denominada de
estrela, nela a tabela Fato armazena os resultados dos fatos analisados associados ao negócio e
as Dimensões armazenam as características desses resultados, elas contribuem para o fato.
Exemplificado na Figura 8 abaixo:
Figura 8 – Modelo estrela (Kimball, 1998)
2.3.2. Tomada de decisão
Segundo Oliveira (2004), a tomada de decisão é a conversão das informações em ação,
ela é realizada com base na apreciação das informações. O processo de tomada de decisão não
é simples e se sujeita às características individuais do decisor, bem como às circunstâncias em
que ele está envolvido, a maneira como ele compreende a situação (Chiavenato, 1997). Este
autor divide o processo de decisão em sete etapas:
Percepção da situação problema;
Definição e diagnóstico do problema;
Definição dos objetivos;
Alternativas de solução;
Comparação das alternativas;
22
Escolha da alternativa;
Execução da alternativa escolhida.
A decisão pode ser distinguida por nível, ela está vinculada à atividade administrativa
exercida pelo decisor (Shimizu, 2006). Assim sendo, ela se divide em:
Nível Estratégico: decisões que compreendem um período de tempo de 2 a 5 anos;
Nível Tático: alguns meses até o limite de dois anos;
Nível Operacional: alguns dias ou meses;
Nível de despacho ou deliberação: algumas horas ou alguns dias.
23
3. MÉTODO E TÉCNICA DE PESQUISA
3.1. Classificação da Pesquisa
Esta pesquisa possui a seguinte classificação:
Quanto à natureza: é de natureza aplicada, uma vez que é direcionada à solução de um
problema específico.
Quanto à abordagem: é utilizado o método qualitativo devido à observação do caráter
singular do problema.
Quanto ao objetivo: é uma pesquisa exploratória devido ao caso estudado.
Quanto ao procedimento: é uma pesquisa-ação devido à proposta do trabalho como
um todo.
De modo a cumprir o objetivo proposto por este estudo, será utilizada a pesquisa-ação.
De acordo com Thiollent (1986), “... a pesquisa-ação, além da participação, supõe uma forma
de ação planejada de caráter social, educacional, técnico ou outro (...)”. Para o autor, essa
metodologia é uma forma inovadora de resolver problemas reais de forma prática e eficiente,
com a aplicação de uma ação transformadora. A pesquisa-ação é um pouco controversa no meio
acadêmico sobre o argumento de um rebaixamento do nível de exigência acadêmico, o que,
segundo o autor, não se justifica, uma vez que a pesquisa-ação mantém o embasamento teórico.
Seguindo a metodologia proposta por Gil (2008), com base na proposta de Thiollent
(1986), ela é subdividida em várias etapas que serão exploradas no decorrer deste estudo.
Apesar de alguns conceitos aqui apresentados serem voltados à pesquisa social, o autor afirma
que, esse método é uma “(...) alternativa metodológica aplicável em diferentes áreas do
conhecimento e de atuação” (GIL, 2008 apud THIOLLENT, 1986).
De acordo com Thiollent (1986), a diversidade das situações é grande, portanto, não é
possível determinar regras precisas para organizar os estudos nessa fase. Com o intuito de suprir
essa dificuldade e aplicar uma metodologia consistente ao presente estudo, será utilizada a
metodologia proposta pelo PMI no Guia PMBOOK, suas entradas, ferramentas e saídas, uma
vez que a estrutura proposta pelo guia vem ao encontro do objetivo proposto por este estudo.
Segundo o PMI (2018), o gerenciamento da qualidade suporta uma série de atividades que
visam melhorar continuamente o processo.
24
Uma analogia da proposta do Guia, aliada à estrutura da pesquisa-ação pode ser vista
no Quadro 3:
PMBOOK Pesquisa-ação
Planejar Qualidade
Fase Exploratória.
O tema da pesquisa e o lugar da teoria
Colocação dos problemas.
Hipóteses.
Seminários.
Gerenciar a Qualidade Seleção de amostras.
Coleta e análise de dados.
Controlar da Qualidade Plano de ação.
Divulgação dos resultados.
Quadro 3 – Analogia entre os processos do gerenciamento da qualidade do PMI e a pesquisa-ação.
3.2. Etapas da pesquisa-ação
3.2.1. Fase exploratória
De acordo com Thiollent (1986), essa fase consiste em “descobrir o campo de pesquisa,
os interessados, suas expectativas e estabelecer um primeiro levantamento da situação, dos
problemas prioritários e suas eventuais ações”. É o momento investigativo onde se busca
produzir conhecimento da realidade, compreender toda a problemática e a percepção da
realidade estudada. A execução dessa fase, que é diagnóstica, deve fornecer subsídios para a
elaboração dos principais objetivos que correspondem aos problemas considerados prioritários.
Para a execução dessa fase, serão utilizadas as entradas propostas pelo PMI (2018), tais como,
plano de gerenciamento do projeto, fatores ambientais da empresa, termo de abertura do projeto,
diretrizes, etc.
3.2.2. O tema da pesquisa e o lugar da teoria
Segundo Thiollent (Ibidem), essa fase tem por objetivo designar o problema prático e a
área de conhecimento a ser abordada, essa designação permite a seleção das áreas do
conhecimento e outras disciplinas que apoiem e subsidiem a pesquisa.
De acordo com Corrêa et al. (2018), ao propor um tema, ele deve ser estabelecido de
modo simples e apontar para os problemas, bem como o enfoque que serão escolhidos. Uma
25
vez que o tema e os problemas iniciais são definidos, há que se pensar em um marco referencial
amplo, de natureza teórica, essa teoria irá apoiar a realização da pesquisa, que não pode se
basear somente em dados e informações coletadas junto aos interessados na pesquisa.
Devido ao caráter empírico da pesquisa-ação pode-se ter a errônea ideia de que não há
a necessidade de aporte teórico, o bom-senso do pesquisador não é suficiente para identificar
os problemas e propor as soluções, pelo contrário, ela deve manter algumas condições e
exigências da própria pesquisa científica, conforme afirma Thiollent (1986): “um grande
desafio metodológico consiste em fundamentar a inserção da pesquisa-ação dentro de uma
perspectiva de investigação científica”. Ainda de acordo com o mesmo autor, “... o papel da
teoria consiste em gerar ideias, hipóteses ou diretrizes para orientar a pesquisa e as
interpretações” (THIOLLENT, 1986).
3.2.3. Colocação dos problemas
“Problema é qualquer questão não resolvida e que é objeto de discussão, em qualquer
domínio do conhecimento”, (GIL, 2008). De acordo com este autor, a formulação do problema
deve seguir algumas regras, são elas:
o problema deve ser elaborado como pergunta;
deve ser delimitado a uma dimensão viável;
deve ter clareza;
deve ser preciso;
deve conduzir a uma pesquisa factível;
deve ser ético.
Na pesquisa-ação, os problemas são apresentados de forma prática, com a intenção de
se procurar soluções para os mesmos, para alcançar um objetivo ou a transformação da situação.
Thiollent (1986) sugere uma forma de como os problemas podem ser colocados:
análise e delimitação da situação inicial;
delineamento da situação final, em função de critérios de desejabilidade e de passível
solução;
26
identificação de todos os problemas a serem resolvidos para permitir a passagem de (a)
a (b);
planejamento das ações correspondentes;
execução e avaliação das ações.
3.2.4. Hipóteses
Segundo Thiolland (1986), a hipótese é definida como uma proposta elaborada pelo
pesquisador a respeito de possíveis soluções para um problema, que foi o objeto de pesquisa.
Mesmo que a hipótese não leve em consideração variáveis quantificáveis, a formulação dela
deve ser clara e concisa, sem ambiguidades, designar objetos de estudo que possam fornecer
argumentos convincentes, sendo eles favoráveis ou não. A hipótese sob forma de diretriz é
utilizada para orientar a ação a ser adotada, observando aspectos estratégicos e táticos,
conduzindo o trabalho para alcançar os objetivos pretendidos com ações eficientes. Ainda de
acordo com o mesmo autor, uma hipótese é definida como “tentativa de resposta operativa à
questão contida no objeto” (THIOLLAND, 1986).
3.2.5. Seminários
Segundo Thiolland (Ibidem), o seminário tem por objetivo reunir os principais membros
da equipe e os pesquisadores para discutir e tomar decisões acerca do processo de investigação,
ele é considerado uma das fases mais importante da pesquisa-ação, centraliza as informações
coletadas e discute as interpretações. É a partir dessas informações que as diretrizes, de ação e
de pesquisa, são elaboradas. As ações adotadas serão testadas na prática e serão alvo de
permanente acompanhamento e avaliações periódicas. As principais tarefas de um seminário
são:
Definir o tema e delimitar os problemas que a pesquisa busca sanar;
elaborar a problemática e as hipóteses;
centralizar as informações das diversas fontes utilizadas;
realizar as interpretações;
buscar soluções e definir as diretrizes de ação;
27
avaliar e acompanhar as ações;
divulgar os resultados.
O papel do pesquisador, segundo Thiollend apud Ortsman (1978), consiste em
disponibilizar aos participantes os conhecimentos teóricos ou práticos para facilitar a discussão
dos problemas; elaborar as atas de reunião e registrar as informações coletadas; conceber e
aplicar as modalidades de ação, em conjunto com os demais participantes; refletir globalmente
sobre as generalizações e discutir os resultados num quadro mais abrangente das disciplinas
envolvidas no problema. O foco é privilegiar uma discussão qualitativa.
3.2.6. Seleção de amostras
Para esse estudo foi adotada a amostragem por acessibilidade ou conveniência, segundo
Gil (2008), são selecionados elementos que estão acessíveis e que representam, de alguma
forma, o universo pesquisado. São amostras que valorizam critérios de representatividade
qualitativa.
Segundo Thiollend (1986), elas se tratam de um pequeno universo que são selecionadas
intencionalmente em função da relevância que apresentam. Na pesquisa-ação essa
representatividade das amostras é decidida ao nível do seminário, a partir do consenso dos
pesquisadores e participantes.
3.2.7. Coleta e análise de dados
Segundo Corrêa et al (2018), a coleta de dados trata da captação de informação já
existente, é formada por observação, na qual o pesquisador procura a informação necessária
para o andamento da pesquisa cumprindo alguns passos, são eles: coleta de informação,
apresentação no seminário central, interpretação, discussão, análise coletiva do material. A
análise do material consiste, entre outras, na análise do conteúdo. Existe ainda outras técnicas,
que são as entrevistas e/ou questionários.
Thiollent (1986) afirma que: “Na pesquisa-ação nem sempre são aplicados questionários
codificados, pois, quando a população é de pequena dimensão e sua estruturação em grupos
permite a fácil realização de discussões, é possível obter informações principalmente de modo
coletivo, sem administração de questionários individuais”.
28
Para o presente estudo não serão utilizados questionários individuais, serão realizadas
entrevistas e discussões com o grupo interessado e os especialistas.
3.2.8. Plano de ação
Para que a pesquisa possa corresponder aos objetivos propostos, ela deve se concretizar
em alguma forma de ação planejada, que será objeto de análise, deliberação e avaliação
(Thiollent, 1986). Partindo desse ponto de vista, o plano de ação se torna uma exigência, na
qual pesquisadores e participantes promoverão uma ação. Thiollent (Ibidem) diz que um plano
de ação deve conter: quem são os atores envolvidos; como é o relacionamento dos atores com
a instituição; quem toma as decisões; quais são os objetivos; quais são os critérios de avaliação
e como dar continuidade à ação.
O papel do pesquisador é o de fornecer o assessoramento da pesquisa, participar da ação
promovendo a deliberação apresentando os problemas e buscando a forma de solucioná-los em
conjunto com os participantes (CORRÊA et al., 2018).
3.2.9. Divulgação dos Resultados
“O retorno é importante para estender o conhecimento e fortalecer a convicção e não
deve ser visto como simples efeito de propaganda. Trata-se de fazer conhecer os resultados de
uma pesquisa que, por sua vez, poderá gerar reações e contribuir para a dinâmica da tomada de
consciência e, eventualmente, sugerir o início de mais um ciclo de ação ou de investigação”
(THIOLLENT, 1986).
A divulgação dos resultados é o retorno da informação aos envolvidos na pesquisa e
para a população atingida, direta ou indiretamente pelos resultados.
29
4. CONTEXTUALIZAÇÃO
4.1. O Sistema de Saúde do Exército
O Sistema de Saúde do Exército (SSEx) possui a missão de prestar assistência médico-
hospitalar aos militares e aos seus familiares, além de fornecer o apoio logístico de saúde às
operações bélicas. A Diretoria de Saúde (D Sau) é o órgão técnico normativo integrante do
Departamento-Geral do Pessoal (DGP), ela é a responsável por gerenciar o SSEx, com a
atribuição de planejar, controlar, supervisionar e avaliar as atividades relativas à saúde no
âmbito do Exército Brasileiro (EB).
O SSEx possui hoje, em média, um universo de 720 mil beneficiários, entre militares da
ativa e da reserva; pensionistas; ex-combatentes; servidores civis e dependentes.
A estrutura organizacional do SSEx compreende 525 Organizações Militares de Saúde
(OMS), conforme o Quadro 4:
Organizações Militares de Saúde Quantidade
Hospital Central do Exército 01
Hospitais Gerais 07
Hospitais Militares de Área 06
Hospitais de Guarnição 29
Policlínicas Militares 04
Postos Médicos de Guarnição 29
OMS Especiais 05
Seções de Saúde de OM – UG Fusex 464
Total OMS 525
Quadro 4 – Estrutura Organizacional OMS – Fonte: Portal D Sau
Essas OMS estão distribuídas por todo o território nacional conforme o mapa
apresentado na Figura 10:
30
Figura 10 – Distribuição OMS – Fonte: Portal D Sau
As perspectivas futuras indicam um aumento da expectativa de vida da família militar
com o progressivo aumento dos custos de tratamentos de saúde, decorrentes não só do
prolongamento da vida como também do crescente e consistente encarecimento dos modernos
tratamentos de saúde. Isso indica a necessidade de um eficaz sistema de gerenciamento, que
vise a redução dos custos futuros e a mitigação dos riscos ao sistema, aumentando-se a sua
efetividade. O expressivo montante de recursos orçamentários administrado pelo Sistema de
Saúde do EB (SSEx), da ordem de 1,5 bilhão de reais, decorrentes dos recursos próprios e do
Tesouro, para atender cerca de 720 mil beneficiários, por si só já justifica todo e qualquer
esforço no sentido de melhor gerir e aplicar bem esses recursos. A recente mudança na
Constituição Federal (CF), que fixou limite de crescimento dos gastos do governo por 20 anos,
trará como consequência restrições à recomposição das receitas do SSEx.
Dentro das Organizações Militares de Saúde existem algumas situações nas quais o
beneficiário não consegue o atendimento necessário, seja por carência de profissionais,
ausência de equipamentos, necessidade de pronto atendimento, demanda reprimida, entre
outras. Para esses casos, o beneficiário é encaminhado à uma Organização Civil de Saúde
31
(OCS) ou para um Prestador de Serviço Autônomo (PSA) para atendimento. Esse procedimento
é chamado de Encaminhamento, atualmente é o SIRE que emite uma guia para que o
beneficiário apresente na OCS e realize o atendimento. Pode-se fazer uma analogia aos planos
de saúde que possuem sua rede credenciada. As OCS são a rede credenciada do FUSEX, que é
o fundo de saúde do Exército. No ato de emissão da guia, ela tem um valor pré-determinado
contratualmente para aquele procedimento, esse valor inicial, principalmente nos casos de
internação, nos quais a previsibilidade dos gastos é menor, pode ser alterado. Essa diferença
entre valor inicial e valor final é percebida no momento da auditoria da guia que foi emitida.
4.2. A Gestão Financeira do SSEx e o SIRE
A gestão financeira da Assistência à Saúde do Exército Brasileiro abrange as atividades
de distribuição e controle dos recursos financeiros necessários para prestação dos serviços de
saúde, bem como de arrecadação das contribuições devidas pelos beneficiários desses serviços.
Atualmente, essas atividades são apoiadas por um conjunto de sistemas de informações
implementados em diferentes plataformas de programação (COBOL, ASP, PHP e Visual Basic)
e não foram documentados (arquitetura, documentos de casos de uso e interações, modificações
no decorrer do tempo, etc.) nem efetuado o histórico e registro de: acessos, informações e
inserções na base de dados. Tal configuração impõe dificuldades de gestão do pessoal
necessário à manutenção dos sistemas, uma vez que é necessário dispor de especialistas
habilitados em cada uma das linguagens empregadas e provoca resultados difíceis de serem
avaliados e corrigidos.
Adicionalmente, a equipe de manutenção dos sistemas tem verificado deficiências
estruturais que tornam oneroso o acompanhamento da evolução das necessidades da Assistência
à Saúde. As dificuldades de manutenção dos sistemas são agravadas, ainda, pela ausência da
referida documentação, tanto dos sistemas em si como dos processos relacionados.
O processamento mensal das informações financeiras da Assistência à Saúde que devem
ser implantadas na folha de pagamento do pessoal do Exército é complexo, em função da
necessidade de integração de diferentes plataformas (Oracle, SQL Server, arquivos-texto). Em
consequência, a ocorrência de erros e atrasos no processamento tem sido frequente. Além disso,
o planejamento orçamentário ainda não faz parte do SIRE.
A contribuição dos beneficiários titulares ao Fundo de Saúde do Exército (FUSEx) é
prevista em legislação específica e tem, atualmente, três valores distintos – 3%, 3,4% e 3,5% –
32
de acordo com a quantidade e definição de seus dependentes. Esses valores são validados e
comprovados por meio do Boletim de Inclusão de Dependentes (BID/on-line) e processados
pelos aplicativos e Jobs em COBOL.
A contribuição da PASS é voluntária e depende de valores percebidos como
remuneração e da idade do beneficiário titular. Não existe contribuição vinculada ao
SAMMED.
As indenizações – tanto do FUSEX, como da PASS – provêm do SIRE, por
intermediação de aplicativo que transmite informações a outros aplicativos e Jobs em COBOL,
onde são realizadas todas as transações geradoras das informações a serem enviadas para
inclusão em contracheque, por meio de arquivos de texto, que são transmitidos para o Centro
de Pagamento do Exército (CPEx), para processamento e implantação em contracheque.
4.3. O SIRE e a necessidade de evolução
Boa parte das informações necessárias ao SSEx tem origem no Sistema de Registro de
Encaminhamentos (SIRE). O atual modelo de gestão não permite ou não favorece a adoção das
medidas de: redução de custos; ampliação da satisfação dos beneficiários; apoio oportuno ao
processo decisório; eliminação de perdas financeiras; unificação e validação do cadastro de
beneficiários; avaliação periódica do desempenho administrativo das OMS; efetividade da
auditoria de contas médicas; aderência aos princípios básicos da administração pública.
Diante desse contexto, podemos concluir que o SSEx não possui um adequado suporte
de Tecnologia da Informação e Comunicação (TIC), dificultando, desta forma, iniciativas que
poderiam contribuir tanto com o incremento da satisfação dos beneficiários e do corpo clínico,
com redução de custos e aumento de qualidade nos procedimentos administrativos e
atendimentos médico-hospitalares.
Com a finalidade de corrigir os problemas existentes de inconsistência de dados,
necessidades gerenciais e de gestão, é necessário atualizar a linguagem dos aplicativos, o que
permitirá sua adequada manutenção. Migrar essas informações e processos para uma linguagem
mais atual, com uma maior facilidade de manutenção, permitirá incluir funcionalidades de
controle de maior amplitude e com diversas otimizações, que agilizarão e darão maior
confiabilidade às informações enviadas ao CPEx.
Com a evolução do SIRE para o SIRE 2.0, novas funcionalidades serão agregadas ao
sistema, que passará a realizar a gestão, não só financeira, como ocorre atualmente, mas também
33
a orçamentária. Apesar do nome ter se mantido (SIRE 2.0), por questões culturais, o nome do
sistema passará a ser – Sistema Integrado de Gestão Orçamentária e Financeira. Serão incluídas
diversas otimizações, tais como: adequação à arquitetura do banco de dados do DGP (base de
dados corporativa), histórico de acesso, registro de acesso, registro de inserção e de alteração
de informações já existentes, criação de relatórios específicos e necessários. Incluirá, também,
as alterações na legislação que estão em estudo e as alterações que já foram efetuadas nos
diversos front-ends dos sistemas vinculados. Tudo isso, de forma a facilitar e antecipar
atividades que facilitarão o acesso ao direito de uma assistência à saúde de qualidade.
4.4. O Painel de Indicadores do SSEx
O Painel de Indicadores do Sistema de Saúde do Exército (PI-SSEx) é uma ferramenta
de Business Intelligence (BI), desenvolvido com o apoio do Centro de Desenvolvimento de
Sistemas do Exército (CDS), mais especificamente na Divisão de Administração de Dados
(DAAD). Ele tem o objetivo de proporcionar aos gestores dos níveis tático, operacional e
estratégico do SSEx informações precisas, oportunas e úteis às tomadas de decisões. Para
facilitar o acesso e a obtenção das informações, o PI-SSEx possui uma tela principal que
organiza os 14 módulos disponíveis, agilizando o acesso aos 50 relatórios existentes.
Atualmente, o Sistema de Registro de Encaminhamentos (SIRE) é a principal fonte de consulta
do Painel. A Figura 11 mostra a tela principal do PI-SSEx.
Figura 11 – Página inicial do Painel de Indicadores do SSEx
34
A implementação do Data Mart de Saúde, a partir de junho de 2018, tornou possível a
criação de relatórios/painéis de indicadores (PI) necessários às análises descritiva, diagnóstica
e preditiva destinadas a apoiar o processo decisório dos níveis estratégico, tático e operacional,
fornecendo uma visão histórica dos dados e respostas a questionamentos de baixa, média e alta
complexidade. Outro benefício foi o de proporcionar a realização de uma inferência analítica
gerencial a curto, médio e longo prazo. O PI-SSEx tem como principal objetivo apoiar as
decisões de gestores de todos os níveis, relacionadas às ações de planejamento e execução das
diversas atividades do SSEx.
4.5. O problema
Diante da contextualização exposta nos itens anteriores, fica evidente a importante
contribuição que o PI-SSEx possui na gestão do Sistema de Saúde do Exército Brasileiro; além
de fornecer informações relevantes para o gestor no cotidiano, ele também orienta ações
estratégicas do alto escalão do Exército.
Uma das principais fontes que subsidiam o PI-SSEx é o SIRE. Como exposto
anteriormente, o SIRE está em processo de modernização e evolução. Por meio dos estudos
realizados para a solução de problemas apresentados pela atual versão do SIRE, decidiu-se que
o novo SIRE 2.0 teria que ser completamente reestruturado, desde a modelagem do banco até
a apresentação final ao usuário, bem como agregar processos que atualmente são realizados por
outras rotinas e sistemas paralelos.
Diante dessa situação, surgiu a preocupação do gestor quanto à continuidade do
funcionamento do PI-SSEx, sem que houvesse perda das informações geradas no sistema
legado. Como garantir que o PI-SSEx continue funcionando? Como será realizada a transição
do sistema legado para o SIRE 2.0, de forma transparente para os usuários?
Para responder aos questionamentos do gestor, será desenvolvido um Plano de Ação,
como prevê a metodologia de pesquisa-ação, com base no processo de Planejar o
Gerenciamento da Qualidade proposto pelo PMI (2018).
Como mencionado anteriormente, o PI-SSEx possui aproximadamente 50 relatórios
divididos, de acordo com a área de interesse, dentro dos 14 módulos disponíveis. Esses
relatórios contemplam diversas informações com cruzamentos de dados, porém a grande
maioria deles possuem os mesmos dados que geram informações diferentes, de acordo com o
cruzamento que é realizado. Para o contexto desse trabalho foram selecionados 4 relatórios
35
principais que concentram a maioria das informações disponíveis e são os de maior interesse
da autoridade patrocinadora do projeto. São eles:
Módulo Atendimento: apresenta o valor e a quantidade de atendimentos internos e
externos emitidos no EB, na RM ou OMS/UG Fusex, de acordo com o período
selecionado. Dentro desse módulo serão utilizados, para este estudo, os relatórios de
Avaliação da Auditoria Prévia dos Encaminhamentos e Maiores Gastos por
Beneficiário.
Módulo Comparação de Gastos: compara os gastos do(s) ano anterior(es) com os do
ano atual, por RM e/ou OMS/UG Fusex, de acordo com o período selecionado. Dentro
desse módulo serão utilizados, para este estudo, os relatórios de Comparação de gastos
Encaminhados e Comparação de Gastos Auditados.
Módulo Internação e Home Care: apresenta o valor gasto com internações e Home Care
por beneficiários e por RM ou OMS/UG Fusex, de acordo com o período selecionado.
Dentro desse módulo serão utilizados, para este estudo, o relatório Gastos com Home
Care.
36
5. ESTRUTURAÇÃO DO PLANO DE GERENCIAMENTO DA QUALIDADE
De acordo com a metodologia proposta para este trabalho, para elaborar o planejamento
da qualidade, foram executadas as fases da pesquisa-ação: “Fase Exploratória”, “O tema da
pesquisa e o lugar da teoria”, “Colocação dos Problemas”, “Hipóteses” e “Seminários”. Aliada
a essas fases, foram utilizados os documentos de entrada proposto pelo PMI (2018), bem como
as ferramentas e técnicas descritas no Guia PMBOK 6ª edição.
5.1. Processos de Gerenciamento da Qualidade
O Plano de gerenciamento da qualidade define requisitos e padrões da qualidade
aplicáveis ao projeto e às suas entregas, além de descrever como será verificada a conformidade
das entregas respeitando a política de qualidade da empresa.
5.2. Controle de Qualidade
Monitoramento e registro dos resultados da execução das atividades de qualidade para
avaliar o desempenho e recomendar as mudanças necessárias.
5.2.1. Requisitos de sucesso do projeto
O projeto terá obtido sucesso se atender a todos os critérios de aceitação das entregas,
respeitar as restrições e cumprir o cronograma de execução e, principalmente, atender os
requisitos e padrões de qualidade detalhados nesse plano. Os requisitos detalhados abaixo foram
levantados por meio de entrevistas não estruturadas com os gestores e com o patrocinador do
projeto, atas de reuniões e documentações do projeto. Para atender a esses requisitos, além do
ETL já existente, que recupera as informações do SIRE, deverá ser desenvolvido um novo ETL,
que recupere as mesmas informações do SIRE 2.0.
Conforme verificado na literatura, existem dois tipos de requisitos, os funcionais e não
funcionais. Requisitos funcionais, segundo Sommerville (2007), descrevem o que o sistema
deve fazer, enquanto os requisitos não funcionais descrevem as qualidades do sistema, não estão
diretamente ligados às funções específicas.
Os requisitos funcionais de sucesso são:
37
1. Avaliação da Auditoria Prévia dos Encaminhamentos. Esse relatório permite ao
gestor avaliar a variação percentual de uma guia emitida e o valor final dela após
a auditoria. São requisitos desse relatório:
a. Permitir a comparação entre os valores iniciais e finais das guias de
encaminhamentos emitidas;
b. Permitir a visualização da variação percentual entre valores iniciais e
finais por RM, escalonando as mesmas por cores diferentes conforme
critério a ser definido pela autoridade patrocinadora.
c. Os valores devem estar alinhados com os do SIRE e do SIRE 2.0;
d. Os dados disponíveis para avaliação devem considerar o início da
operação do SIRE, ou seja, a partir de 2008, e agregar os dados
disponíveis do SIRE 2.0 quando do início da sua operação.
e. Todos os filtros existentes atualmente (ano, mês, RM, grupo de
especialidades médicas) deverão ser mantidos quando do início da
operação do SIRE 2.0.
2. Maiores Gastos por Beneficiário. Este relatório permite ao gestor identificar, por
meio de um ranking, onde estão os beneficiários que mais oneram o SSEx. São
requisitos desse relatório:
a. Permitir a visualização das iniciais do beneficiário;
b. Permitir a identificação da RM a qual o beneficiário está vinculado;
c. Exibir a OCS onde o beneficiário foi atendido;
d. Exibir as especialidades para o atendimento;
e. Exibir os procedimentos realizados dentro de cada especialidade;
f. Todos os filtros existentes atualmente (ano, mês, RM e descrição do
grupo de atendimento) deverão ser mantidos quando do início da
operação do SIRE 2.0.
g. Deve permitir ao gestor visualizar tanto os encaminhamentos quanto os
atendimentos internos na OMS.
h. Os requisitos não funcionais são: Disponibilidade, desempenho e
usabilidade, os níveis aceitáveis estarão detalhados nas métricas de
qualidade.
3. Comparação de Gastos: Este relatório permite ao gestor realizar uma análise
histórica dos gastos realizados com o SSEx, tanto os encaminhamentos quanto
os atendimentos internos. São requisitos desse relatório:
38
a. Exibir os gastos agrupados por RM e detalhados pela UG Fusex;
b. Os dados disponíveis para análise devem considerar o início da operação
do SIRE, ou seja, a partir de 2008, e agregar os dados disponíveis do
SIRE 2.0 quando do início da sua operação;
c. Permitir ao gestor visualizar tanto os encaminhamentos quanto os
atendimentos internos realizados nas OMS;
d. Todos os filtros existentes atualmente (ano, mês, RM e descrição do
grupo de atendimento) deverão ser mantidos quando do início da
operação do SIRE 2.0;
e. Exibir o percentual da variação do gasto entre os anos selecionados,
comparando sempre com o anterior;
f. Exibir uma previsão de gastos futuros com base na análise do gasto
anterior.
g. Destacar, na coluna “valor”, por cores diferentes, a variação dos gastos
das unidades de acordo com critério a ser definido pela autoridade
patrocinadora.
h. Os requisitos não funcionais são: Disponibilidade, desempenho e
usabilidade, os níveis aceitáveis estarão detalhados nas métricas de
qualidade.
4. Gastos com Home Care: Esse relatório permite ao gestor realizar uma análise
histórica dos gastos realizados com as internações em Home Care, tanto os
encaminhamentos quanto os atendimentos internos. São requisitos desse
relatório:
a. Os dados disponíveis para análise devem considerar o início da operação
do SIRE, ou seja, a partir de 2008, e agregar os dados disponíveis do
SIRE 2.0 quando do início da sua operação;
b. Permitir ao gestor visualizar tanto os encaminhamentos quanto os
atendimentos internos na OMS;
c. Exibir os dados agrupados por RM;
d. Todos os filtros existentes atualmente (ano e mês) deverão ser mantidos
quando do início da operação do SIRE 2.0;
e. Os requisitos não funcionais são: Disponibilidade, desempenho e
usabilidade, os níveis aceitáveis estarão detalhados nas métricas de
qualidade.
39
Para todos os relatórios mencionados acima, são aplicáveis os requisitos não funcionais:
disponibilidade, desempenho e usabilidade, os níveis aceitáveis estarão detalhados nas métricas
de qualidade.
5.2.2. Métricas da Qualidade
Os critérios definidos abaixo se aplicam a todos os relatórios.
Requisito de Qualidade Ações para atingimento Indicadores
Mapeamento dos campos de origem
(SIRE, SIRE 2.0) para os campos de
destino (PI-SSEx).
À medida que os módulos
do SIRE 2.0 forem
entregues, realizar o de-
para de todos os campos
disponíveis no relatório,
conforme levantamento
anexo.
IQ01: 100%
informações
agregadas nas tabelas
fato e dimensões.
Agregação dos dados do SIRE e
SIRE2.0
Desenvolvimento de um
novo ETL para recuperar
os dados do SIRE 2.0
recuperando as mesmas
informações do SIRE
IQ02: 100% dos
dados utilizados
atualmente.
disponíveis no PI-
SSEx.
Confiabilidade na informação
apresentada.
1. Realizar testes
utilizando a técnica
funcional:
a. Testes de requisitos;
b. Testes de tratamento
de erros;
c. Testes de
interconexão;
d. Testes paralelos;
2. Homologação do
resultado dos testes
pelo gestor.
IQ03: 100% dos
requisitos atendidos;
IQ04: 100% dos
erros conhecidos
tratados;
IQ05: 100% de
alinhamento dos
dados entre os SIRE
e o SIRE 2.0 com
reflexo no PI-SSEx;
IQ06: 100% dos
filtros ativos e
funcionais;
40
IQ07: 100% de
aceitação dos
resultados pelo
gestor.
Critérios de avaliação quantitativa das
OMS
Realizar reuniões com os
gestores e patrocinadores
para definição dos valores e
escalas.
IQ08: 100% dos
critérios definidos,
implementados e
escalonados por
cores.
Critérios de disponibilidade 1. Realizar testes
utilizando a técnica
estrutural:
a. Testes de estresse;
b. Testes de
recuperação.
IQ09: 80% de
disponibilidade.
Critérios de desempenho Utilizando a técnica
estrutural, realizar testes de
execução.
IQ10: quando do
primeiro acesso,
máximo de 8
segundos para
relatório menos
complexos e de 30
segundos para
relatórios mais
complexos.
Critérios de usabilidade Utilizando a técnica
estrutural, realizar testes de
conformidade.
IQ11: 100% dos
padrões de
desenvolvimento
atendidos;
IQ12: 90% de
aceitação pelos
gestores.
41
5.2.3. Ferramentas da Qualidade
Ferramenta Descrição da
aplicação
Quando aplicar Responsável
Fluxograma Aplicável nas
entregas dos novos
módulos do SIRE
2.0.
Ao final do
desenvolvimento
de cada módulo
do SIRE 2.0.
Equipe de
desenvolvimento do
Departamento de
Administração de
Dados do Pessoal –
DADPESS/CDS
CheckList Aplicável em todas
as entregas do
projeto.
Ao término da
realização dos
testes.
Divisão de
Administração e
Análise de Dados –
DAAD/CDS
Diagrama de Pareto Aplicável em caso
de recorrentes
problemas em
determinado
relatório.
De acordo com a
necessidade.
Divisão de
Administração e
Análise de Dados –
DAAD/CDS em
conjunto com o
Departamento de
Administração de
Dados do Pessoal –
DADPESS/CDS
Auditoria do Processo Aplicável a todos os
relatórios alterados
no período.
Trimestralmente Gerente do projeto do
DAAD/CDS
5.2.4. Entregas do projeto e critérios de aceitação
Entrega Critérios de aceitação Quando será
verificado
De-para dos Campos e Tabelas Todos os campos mapeados
nas origens (SIRE e SIRE
2.0) e o destino (PI-SSEx).
Ao final do
desenvolvimento de
42
cada novo módulo do
SIRE 2.0
ETL Recuperando todas as
informações da origem para
o destino.
Ao final do
desenvolvimento.
Testes realizados Resultados de acordo com
os Indicadores de Qualidade
definidos.
Ao final da realização.
Relatórios prontos 100% dos requisitos
funcionais e não funcionais
atendidos. Podendo ser por
etapas, de acordo com o
desenvolvimento de novas
funcionalidades do SIRE
2.0.
Ao final da
implementação.
5.3. Garantia de Qualidade
É percebida por meio da auditoria dos requisitos de qualidade e dos resultados das
medições do controle da qualidade para garantir que sejam usados os padrões de qualidade e
definições operacionais apropriadas.
5.3.1. Auditorias do Projeto e Revisões de Qualidade
Revisões de Qualidade Data Prevista Auditor
Responsável
Comentários
Conferência dos dados A cada nova carga
realizada no painel.
Gerente do
projeto
Batimento dos dados
carregados no PI-SSEx
com os dados do SIRE
e SIRE 2.0.
43
5.3.2. Processos de melhoria contínua
Execução do ciclo PDCA, incluindo possibilidade de melhoria do ETL para dar maior
agilidade na execução dos relatórios ou melhorias de interface. Esse processo deverá ser
realizado anualmente caso não haja alterações negociais, e em caso de alterações deverá ser
executado sob demanda.
5.3.3. Responsabilidades de Qualidade da Equipe do Projeto
Membro da Equipe Responsabilidades
Gestor Acompanhamento dos indicadores IQ09, IQ10 e IQ11.
Identificar possíveis melhorias.
Indicar necessidade de desenvolvimento de novas
funcionalidades ou relatórios.
Gerente do projeto Acompanhar, mensalmente, a pertinência dos valores e
quantidades disponibilizados no PI-SSEx.
Desenvolvedores Buscar otimizar, sempre que possível, o desempenho do
PI-SSEx, agregando novas tecnologias e processos de
melhoria.
Correções de falhas ou informações incorretas no prazo
máximo de 2 dias úteis.
Registros das lições aprendidas em ferramenta própria de
controle.
44
6. CONCLUSÃO
A gestão do sistema de saúde do Exército é complexa e envolve uma série de sistemas
paralelos. Devido ao tamanho do seu orçamento, ao universo atendido pelo sistema de saúde e
a complexidade que envolve a gestão financeira e orçamentária, ferramentas que auxiliem no
trabalho dos gestores são imprescindíveis.
O presente estudo teve como objetivo geral propor um plano de gerenciamento da
qualidade para o Painel de Indicadores do Sistema de Saúde do Exército, com vistas a dar
continuidade à apresentação das informações disponíveis atualmente, quando do início da
operação do SIRE 2.0, sem impacto para os gestores que utilizam a ferramenta para auxiliar nas
tomadas de decisão.
Qualquer falha na operação desses sistemas de gestão pode impactar diretamente nas
decisões que são tomadas pelo alto escalão do Exército. A evolução do SIRE se mostrou
extremamente necessária para a continuidade e melhoria dos processos de gestão.
Consequentemente, essa evolução impacta diretamente no Painel de Indicadores, uma vez que
ele é o sistema que subsidia a maior parte das informações disponíveis no painel.
Visando minimizar os impactos dessa evolução, este estudo buscou evidenciar, por meio
da revisão de literatura, as melhores práticas quanto ao gerenciamento da qualidade, propondo
ações efetivas que possam, de fato, conduzir as atividades futuras quando da integração dos
sistemas, legado e novo, para que as informações de hoje continuem disponíveis para o gestor.
Uma das dificuldades encontradas para o desenvolvimento desse trabalho foi a ausência
de documentos técnicos sobre o projeto do SIRE 2.0. Os documentos de planejamento do
projeto estão altamente alinhados com a metodologia proposta pelo PMI, o que favoreceu o
desenvolvimento das ações aqui propostas e forneceram todos os subsídios aqui explicitados.
Os conhecimentos técnicos sobre o SIRE 2.0, necessários para a realização deste estudo, foram
oriundos de entrevistas com especialistas de cada área e por meio de atas de reunião, não há,
ou não foi disponibilizado, documentos técnicos como casos de uso, diagramas de entidade
relacionamento, fluxogramas, etc.
Para que essa proposta de plano de gerenciamento da qualidade surta os efeitos
esperados, é necessário um profundo envolvimento das áreas responsáveis pelo
desenvolvimento, tanto do painel, quanto do SIRE 2.0, bem como o acompanhamento ativo do
gerente do projeto e a participação dos gestores contribuindo com sugestões de melhoria.
Por último cabe ressaltar que é necessário criar um ambiente exclusivo de testes para
que as ações propostas nas métricas de qualidade sejam realizadas.
45
REFERÊNCIAS BIBLIOGRÁFICAS
BARBIERI, Carlos. BI2 – Business Intelligence: Modelagem & Qualidade. Rio de Janeiro:
Editora Elsevier, 2011.
BARTIE, Alexandre. Garantia de Qualidade de Software. Campus, 2002.
BASTOS, Aderson; RIOS Emerson; CRISTALLI Ricardo; MOREIRA Trayahú. Base de
conhecimento em teste de Software. Martins, 2007.
BECK, K. S. K. S. J. E. A.; Manifesto para desenvolvimento ágil de software. Disponível
em: <http://agilemanifesto.org/iso/ptbr/manifesto.html> Acessado em 30/07/2019.
BECK, K.; Extreme Programming. Addison-Wesley, 1999.
BOEHM, B.; TURNER, R.; Balancing Agility and Discipline. AddisonWesley, 2003.
CAVANO, J. P., & MCCALL, J. A. A framework for the measurement of software quality,
SIGSOFT, 1978.
CHIAVENATO, Idalberto. Introdução à Teoria da Administração. 5 ed., São Paulo, Makron
Books, 1997.
CORRÊA, G. C. G.; CAMPOS, I. C. P.; ALMAGRO, R. C.; Pesquisa-ação: uma abordagem
prática de pesquisa qualitativa. Sorocaba, Ensaios Pedagógicos, 2018. Disponível em: <
http://www.ensaiospedagogicos.ufscar.br/index.php/ENP/article/download/60/89 >. Acessado
em: 16 ago 2019.
DA SILVA, M. (2001) O Comprometimento com a Qualidade dos Sistemas de
Informação: Um Enfoque nas Competências das Pessoas. Dissertação (Mestrado 153 em
Engenharia de Produção) – Santa Catarina-RS, Universidade Federal de Santa Catarina –UFSC,
110p.;
DELAMARO M. E., MANDONADO, J. C. Introdução ao teste de software. Elsevier, 2007.
DIEGO, Elias. Conhecendo a arquitetura de Data Warehouse, 2014. Disponível em <
https://canaltech.com.br/business-intelligence/conhecendo-a-arquitetura-de-data-warehouse-
19266/>. Acessado em 29/07/2019.
46
GARVIN David A.; What Does "Product Quality" Really Mean?. Revista Fall, 1984.
Disponível em < https://sloanreview.mit.edu/article/what-does-product-quality-really-mean/>.
Acessado em 30/08/2019.
GIL, Antônio Carlos. Métodos e Técnicas de Pesquisa Social. 6. ed. São Paulo, Atlas, 2008.
GOMES N. S., 2010. Disponível em
<http://www.fazenda.gov.br/ucp/pnafe/cst/arquivos/Qualidade_de_Soft.pdf >. Acessado em
27/07/2019.
INMON, Willian H. ROSS, Margy. Como construir o DataWarehouse. Tradução de Ana
Maria Netto Guz. Rio de Janeiro: Campus, 1997.
KIMBALL, Ralph. Data Warehouse Toolkit: Técnicas para Construção de Data
Warehouses Dimensionais. São Paulo, Makron Books, 1998.
LAUDON, Kenneth C.; LAUDON, Jane P.; Sistemas de Informações Gerenciais. 7 ed., São
Paulo, Pearson Prentice Hall, 2007.
LUIS, G.; Organisational Mastery Blueprint. Ebook, 2019.
MATHUR, A. P. Foundations of software testing. 2. Ed. Pearson, 2009.
NEVES, Thiago Franca. Importância do ciclo PDCA para garantia da qualidade do
produto. Disponível em
<http://www.ufjf.br/ep/files/2009/06/tcc_junho2007_thiagoneves.pdf>. Acessado em
29/07/2019.
O’BRIEN, James A.; Sistemas de Informação e as Decisões Gerenciais na Era da Internet.
São Paulo, 9 ed., Saraiva, 2001.
OLIVEIRA, D. P. R.; Sistemas de Informações Gerenciais: Estratégicas, Táticas,
Operacionais. 9 ed, São Paulo, Atlas, 2004.
PMI. Um Guia de Conhecimentos em Gerenciamento de Projetos - Guia PMBOK. EUA,
PMI, 6ª edição, 2018.
47
Portal da Diretoria de Saúde. Serviço de Saúde. Disponível em <
http://www.eb.mil.br/saude1>. Acessado em 28/08/2019.
Portal ISO, ISO 9000. Edição 2015. Disponível em: < https://iso9001.portaliso.com/iso-
9000/>. Acessado em: 29/07/2019.
PRESSMAN, R.. Engenharia de Software. McGraw-Hill Interamericana do Brasil Ltda,
2006.
PRESSMAN, ROGER S.; MAXIN BRUCE R. Engenharia de Software: uma Abordagem
Profissional. 8ª Edição, 2016.
RIBAS, M. (2001) Avaliação do Curso de Graduação em Administração da Universidade
Estadual de Maringá a Partir da Percepção dos Alunos: Um Estudo de Caso. Dissertação
(Mestrado em Engenharia de Produção) – Santa CatarinaRS, Universidade Federal de Santa
Catarina – UFSC,
RIOS, Emerson & MOREIRA, Trayahú. Teste de Software. Alta Books, 2003.
SCHWABER, K.; Agile Project Management with Scrum. Microsoft Press, 2004.
SHIMIZU, T.; Decisão nas Organizações. 2 ed., São Paulo, Atlas, 2006.
SILVA, Jane Azevedo da; Apostila de Controle da Qualidade I. Juiz de Fora: UFJF, 2006.
SOMMERVILLE, Ian, Engenharia de Software, 8ª ed, tradução de Selma Melnikof,
Reginaldo Arakaki e Edilson de Andrade Barbosa. São Paulo, Pearson Addison Wesley, 2007.
STAA, A. Programação Modular. Editora Campus, 2000.
THIOLLENT, M. Metodologia da pesquisa-ação. São Paulo, Cortez, 1986
TIAN, J. Software Quality Engineering. John Wiley Sons, 2005.
TURBAN, E.; MCLEAN, E.; WETHERBE, J.; Tecnologia da Informação para Gestão:
Transformando os Negócios na Economia Digital. Porto Alegre, 3 ed., Bookman, 2004.
48
TURBAN, Efrain; SHARDA, Ranesh; ARONSON, Jay E.; KING, David. Business
Intelligence – Um Enfoque Gerencial para a Inteligência do Negócio. Porto Alegre:
Bookman, 2009.
WERKEMA, M. C. C. As ferramentas da qualidade no gerenciamento de processos. Belo
Horizonte : Fundação Christiano Ottoni, UFMG, 1995.
49
APÊNDICES
1. Apêndice 1: Modelo lógico de dados do Painel de Indicadores do SSEx -
Encaminhamentos
50
2. Apêndice 2: Modelo lógico de dados do Painel de Indicadores do SSEx - Procedimentos