Universidade Federal do ABC Centro de Matemática, Computação e Cognição (CMCC) Paulo Cesar Angelo

Transcrição

1 Universidade Federal do ABC Centro de Matemática, Computação e Cognição (CMCC) Pós-Graduação em Ciência da Computação Paulo Cesar Angelo MÉTODO DE ENGENHARIA DE REQUISITOS BASEADO EM BPMN E CASO DE USO Dissertação de Mestrado Santo André - SP 2014

2 Paulo Cesar Angelo MÉTODO DE ENGENHARIA DE REQUISITOS BASEADO EM BPMN E CASO DE USO Dissertação de Mestrado Dissertação de Mestrado apresentada ao Curso de Pós-Graduação da Universidade Federal do ABC como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientador: Prof. Dr. Francisco de Assis Zampirolli Coorientador: Prof. Dr. Guiou Kobayashi Santo André - SP 2014

3 Dedicatória à minha familia: Helio Angelo, Rosa Maria e Ana Paula Angelo, por todo o apoio, carinho e amor.

4 Agradecimentos Primeiramente agradeço aos meus pais Helio Angelo e Rosa Maria por me mostrarem bons valores como pessoa e por apoiarem meus caminhos e desafios. Também agradeço a minha irmã Ana Paula e minha namorada Eliane Espanha que sempre estiveram presentes nos momentos mais difíceis. Aos docentes da UFABC, em especial aos meus orientadores Guiou Kobayashi, Francisco de Assis Zampirolli e Fabiana Santana por terem sempre me acolhido, pela paciência, amizade e dedicação. Ao meu professor, orientador e amigo da graduação Luis Antonio de Lima pela inspiração, por sempre ter sido um exemplo a ser seguido, apoiar minhas pesquisas e fornecer ótimas dicas de vinhos. Aos meus amigos do mestrado, em especial aos mais próximos que são a Andreia Gusmão, Eduardo Moreira, Sheila Leal, Cleber Silva, Silvia Scheunemann, Jhon Franko, Alisoli Pretel, Júlio Cotta, Renata Ferrari, Lidia Rodrigues e Genesis Duarte. Aos meus grandes amigos Dangelo, Gilberto, Nakano, Katherine Voi, Tiago Costa, Petrokas e aos amigos do M.C. Brisa da Noite. À Prevent Senior, em especial aos colegas Thiago Dias, Fernando Evangelista, Daniel Badawi, Pedro Sousa, Sheila, Luan Ibarra, Eduardo Parrilo e Fernando Parrilo pela parceria e apoio. Agradeço a UFABC por fornecer as bibliotecas, laboratórios, centros de pesquisas e a oportunidade de fazer o curso de mestrado em um ambiente de ensino de excelência. E, sobretudo, agradeço a Deus por tudo!

5 Ficha Catalográfica Angelo, Paulo Cesar. Método de engenharia de requisitos baseado em BPMN e Caso de Uso / Paulo Cesar Angelo. Santo André, SP: UFABC, p.

6 Resumo Métodos e Processos de Engenharia de Software têm se tornado foco de pesquisas científicas, onde a qualidade, estimativa de custos e prazos são trabalhadas como boas práticas em desenvolvimento. A construção de um produto de software envolve algumas etapas, e a mais complexa é saber precisamente o que construir. A precisão nesta etapa do projeto é essencial, pois se houver falha na especificação, haverá maior prejuízo ao final do projeto do sistema de software. A principal razão para as falhas de projeto de software é o gerenciamento inadequado dos requisitos do sistema, gerando custos elevados para serem corrigidos nas fases seguintes ao levantamento de requisitos e insatisfação para todos os envolvidos. Deste modo, produzir software com qualidade é uma tarefa complexa, que demanda entender, planejar e atender, provendo soluções necessárias. Este trabalho tem como objetivo, apresentar uma metodologia para o desenvolvimento de especificação de requisitos, com uma abordagem orientada ao alinhamento entre TI e Negócio, por meio de um processo de engenharia de requisitos, integrando diagramas de Caso de Uso com o Business Process Modeling Notation (BPMN). Por meio de estudos de caso aplicados a uma empresa operadora de planos privados de assistência à saúde. A metodologia se mostrou eficaz, com melhoria de 69,68% na redução dos custos no orçamento acordado. Além disso, este trabalho de pesquisa encontra-se em funcionamento na empresa citada, otimizando recursos e atingindo melhores resultados para a organização. Palavras-Chave: Engenharia de Requisitos, Business Process Modeling Notation, Diagramas de Caso de Uso, Saúde Suplementar.

7 Abstract Requirement Engineering Methods and Processes have become a focus point for scientific research, in which quality, cost estimates and time frames are elaborated as good practices in development. Building a software product includes several phases, and the most complex is to know exactly what to build. Precision is essential during this phase of the project, because if the specification fails, there will be greater loss at the end of the software system project. The main reason for software project failures is inept management of system requirements, generating high costs that have to be corrected in the phases following requirement survey, and creating dissatisfaction for all those involved. Thus, producing quality software is a complex task, which demands understanding, planning, and compliance to provide the necessary solutions. This paper presents a methodology for developing requirement specifications, with an approach directed towards aligning IT and Business through a requirement engineering process integrating Use Case with Business Process Modeling Notation. Through case studies presented and applied at a private health care insurance company, the methodology proved to be effective, by reducing exceeding the agreed-upon budget by 69.68%. Additionally, this study is still on-going at the abovementioned company, optimizing resources and reaching better results for the organization. KeyWords: Requirement Engineering, Business Process Modeling Notation, Use Case, Supplemental Health Care

8 Lista de Figuras 2.1 Os cinco níveis de representação do RM-ODP SOA como modelo de alinhamento entre negócio e TI. Fonte: Adaptado de Marzullo (2009) [41] Elementos do Caso de Uso Delineamento Esquematizado do Estudo de Caso Proposta Metodológica: Integração das metodologias de Engenharia de Requisitos com Processos BPMN e Caso de Uso Diagrama Caso de Uso do Sistema Blindagem Jurídica SUS Integração do Caso de Uso Cadastrar ABI com o processo BPMN Especificação Textual do Caso de Uso Cadastrar ABI Protótipos de telas da Especificação Textual do Caso de Uso Cadastrar ABI Gráfico com o Custo Planejado e Custo Não Planejado do Projeto de Vendas e Acordos Gráfico com o Custo Planejado e Custo Não Planejado do Projeto de Blindagem Jurídica SUS Gráfico com análise comparativa de custo Gráfico de Quantidade Total de Horas estimadas X trabalhadas e Quantidade de horas para realizar um Ponto de Função do Estudo de Caso de Controle Científico Gráfico de Quantidade Total de Horas estimadas X trabalhadas e Quantidade de horas para realizar um Ponto de Função do Estudo de Caso com a Metodologia Proposta Delineamento comparativo do Estudo de Caso do Controle Científico com a Metodologia Proposta

9 4.7 Gráfico de avaliação comparativa das horas necessárias para produzir um Ponto de Função Gráfico comparativo de horas por Ponto de Função Gráfico comparativo de horas por ponto de função considerando o Fator de Maturidade Análise do escopo Gráfico da área de atuação dos profissionais que responderam ao questionário Gráfico comparativa entre o estudo de caso de Controle Científico e o Método Proposto por meio da aplicação do questionário Gráfico da análise de estimativa de prazos Gráfico da análise do desempenho por ponto de função Gráfico da análise do desempenho de planejamento de custo Gráfico da análise do desempenho da identificação do escopo Eventos: Início, Intermediário e Fim Evento: Atividade Evento: Gateway Evento: Objetos de Conexão: Fluxo de sequência Objetos de Conexão: Fluxo de Mensagem Objetos de Conexão: Fluxo de Associação Swimlanes: Pool Swimlanes: Exemplo BPD usando Pool: Paciente - Consultório Médico. Adaptação de White [56] Swimlanes: Lane

10 Lista de Tabelas 4.1 Cálculo do valor Homem/Hora Médio do Projeto de Vendas e Acordos Custo Planejado e Custo Não Planejado do Projeto de Vendas e Acordos Cálculo do valor Homem/Hora Médio do Projeto Blindagem Jurídica SUS Custo Planejado e Custo Não Planejado do Projeto Blindagem Jurídica SUS Análise comparativa de custo Ponto de Função Estudo de Caso de Controle Científico Ponto de Função Estudo de Caso da Proposta Metodológica Avaliação do Estudo de Caso de Controle Científico em comparação com a Metodologia Proposta Cálculo do Fator de Maturidade da Análise Comparativa do Ponto de Função Análise do escopo Análise comparativa entre o estudo de caso de Controle Científico e o Método Proposto por meio da aplicação do questionário Cálculo da nota média geral do questionário referente às caracteristicas de TI

11 Lista de Abreviaturas e Siglas ANS Agência Nacional de Saúde Suplementar BPD Business Process Diagram BPEL Business Process Execution Language BPM Business Process Management BPMI Business Process Management Initiative BPMN Business Process Modeling Notation CMMI R Capability Maturity Model R Integration ER Engenharia de Requisitos IEEE The Institute of Electrical and Electronics Engineers, Inc. OMG Object Management Group KPI Key Performance Indicator RM-OPD Reference Model for Open Distributed Processing SOA Service-oriented Architecture TI Tecnologia da Informação TISS Troca de Informação em Saúde Suplementar WS Web Service SI Sistema de Informação

12 Sumário 1 Introdução Problema Justificativa Objetivo Hipóteses Organização do Texto Revisão Bibliográfica Engenharia de Requisitos Processo de Engenharia de Requisitos Modelagem de Processos BPMN - Notação de Modelagem de Processos de Negócios Arquitetura Orientada a Serviços SOA como modelo de alinhamento entre negócio e TI Caso de Uso Documentação do Caso de Uso Caso de Uso Integrado ao BPMN Metodologia Estudo de Caso de Controle Científico Fontes de Requisitos Técnicas de Elicitação Análise de Requisitos

13 SUMÁRIO Especificação de Requisitos Validação dos Requisitos O Documento de Requisitos Estudo de Caso da Metodologia Proposta Detalhamento da Metodologia Proposta Avaliação da Metodologia Resultados Resultados dos Custos Análise de Custos do Estudo de Caso de Controle Científico Análise de Custos do Estudo de Caso com a Metodologia Proposta Análise Comparativa dos Custos dos Projetos Resultados de Prazo por Análise de Ponto de Função Resultados de Ponto de Função Estudo de Caso Controle Científico Resultados de Ponto de Função Estudo de Caso Proposta Metodológica Comparação dos Resultados das Análises de Ponto de Função Comparação dos Resultados das Análises de Ponto de Função Com Fator de Maturidade das Equipes Resultados da Análise de Escopo Resultados do Questionário Aplicado na Equipe Técnica Análise dos Resultados Reduzir as horas trabalhadas para executar cada ponto de função Reduzir a Ultrapassagem do Orçamento Acordado Proporcionar Maior Clareza e Precisão na Especificação das Características Necessárias aos Projetos de TI Conclusão Recursos Disponíveis Trabalhos Futuros Referências 85

14 6 Apêndices Especificação BPMN Apêndice - Estudo de Caso do Projeto de Vendas Apêndice - Documento de Requisitos do Estudo de Caso do Projeto de Vendas Apêndice - Documento de BPMN do Estudo de Caso do Projeto de Vendas Apêndice - Documento de Análise por Ponto de Função do Projeto de Vendas Documentos do Estudo de Caso do Projeto Blindagem Jurídica SUS Documento de Requisitos do Estudo de Caso do Projeto Blindagem Jurídica SUS Apêndice - Documento BPMN do Estudo de Caso do Projeto Blindagem Jurídica SUS Apêndice - Documento de Análise por Ponto de Função do Projeto de Blindagem Jurídica SUS Apêndice - Questionário Pesquisa sobre Documentação de Requisitosdos Projetos de Vendas e Acordos e o Blindagem Jurídica Sus Apêndice - Respostas do Questionário Pesquisa sobre Documentação de Requisitosdos Projetos de Vendas e Acordos e o Blindagem Jurídica Sus Apêndice - Escopo - WBS Projeto de Vendas e Acordos Apêndice - Escopo - WBS Projeto Blindagem Jurídica SUS

15 Capítulo 1 Introdução Métodos e Processos de Engenharia de Software têm se tornado foco de pesquisas científicas, onde a qualidade, estimativa de custos e de esforços são trabalhadas como boas práticas em desenvolvimento. Um fator relevante está relacionado à correção de erros, de tal forma que é recomendado um processo de levantamento de requisitos para reparar um erro no momento em que o produto está na fase de definição, tornando o processo mais eficiente e menos custoso do que a correção em seu estado final [15]. A construção de um produto de software envolve algumas etapas e a mais difícil é saber precisamente o que construir [33, 50], incluindo levantamento de requisitos técnicos detalhados e todas as interfaces para usuários, equipamentos e outros sistemas de software. A precisão nesta etapa do projeto é essencial, pois gera maior prejuízo ao final do projeto do sistema de software se houver falha na especificação. A principal razão para as falhas de projeto de software é o gerenciamento inadequado dos requisitos do sistema, gerando custos elevados para serem corrigidos nas fases seguintes ao levantamento de requisitos [8]. A engenharia de software é uma área da computação considerada ampla e difícil, pois, os usuários geralmente não compreendem o benefício da melhoria de um sistema de software em relação à eficiência de seu trabalho, da mesma forma que um cliente não sabe explicitar o que gostaria de obter como produto de software [50]. Produzir software com qualidade é uma tarefa complicada, que demanda: identificar, 1

16 CAPÍTULO 1. INTRODUÇÃO 2 entender, planejar e atender a demanda, provendo soluções necessárias. Atrasos na entrega de projetos de Tecnologia de Informação (TI) têm sido apontada como principal falha [8]. Apenas 9% dos projetos são entregues dentro do prazo e do orçamento planejado, e apenas cerca de 16% dos projetos entregam todo o escopo que foi planejado. Atrasos como estes, geram prejuízos financeiros e insatisfação para todas as partes envolvidas. Nos últimos anos, uma série de pesquisas vêm sendo realizadas em todo o mundo pelo Standish Group International denominada Chaos Report, com publicações periódicas (a cada 2 anos). Em sua publicação realizada no ano de 2013 [24] foram apresentados alguns fatores que continuam sendo as principais falhas em projetos: prazo acordado, orçamento e qualidade de projetos em TI. No ano de 2012, a taxa de projetos bem sucedidos (entregues no prazo, dentro do orçamento e com todas as funcionalidades necessárias) chegou a 39%; projetos com sucesso parcial (com atraso no prazo, orçamento acima do estimado ou com falta de funcionalidade necessária) chegaram a 43%; e 18% dos projetos avaliados foram cancelados (cancelados antes da conclusão ou nunca foram utilizados), deixando evidente que as falhas na realização dos projetos de TI continuam sendo uma preocupação [24]. Os atrasos nos projetos de TI podem ter diversas causas, dentre elas: o gerenciamento inadequado dos requisitos do sistema [8], o planejamento inadequado, novas tecnologias que geram incertezas quanto as complexidades, as mudanças no escopo do projeto e a comunicação inadequada com os stakeholders [38] 1. De acordo com Books (1986) [33], a falta de especificação detalhada do sistema ou a especificação gerada da forma incorreta poderá gerar grandes prejuízos. Dentro deste contexto, este trabalho de pesquisa avaliou diversas pesquisas referentes ao levantamento de requisitos com o intuito de identificar a melhor maneira de se trabalhar com o levantamento e representação de requisitos para este trabalho, de modo a atender todas as necessidades do novo sistema. Dentre os trabalhos pesquisados, podem-se citar algumas metodologias que geram 1 Stakeholder compreende todos os envolvidos em um processo.

17 CAPÍTULO 1. INTRODUÇÃO 3 comparativos entre a usabilidade de Unified Modeling Language (UML) e Business Process Modeling Notation (BPMN) [22, 2] possibilitando uma visão dos pontos fortes e fracos de cada método. Além disso, existem pesquisas que sugerem que uma plataforma de integração e de manutenção baseada em uma metodologia que utiliza os padrões abertos de referência baseada em diagramas UML- BPMN pode ser explorada [39]. Em outra linha de pesquisa, existe um trabalho com a proposta de uma metodologia que integra duas notações, o BPMN e o Diagrama de Caso de Uso, unindo ambas em um único diagrama, sendo nomeada de Use Processes [26]. No presente trabalho, a abordagem selecionada foi a implementação de um estudo de caso de engenharia de requisitos baseada na integração de duas metodologias: BPMN e Diagrama de Caso de Uso da UML. Porém, diferente da abordagem sugerida no Use Processes, que utiliza um único diagrama para documentar os requisitos, foi feito um estudo de caso prático por meio de processo de Engenharia de Requisitos, com os diagramas de Caso de Uso e BPMN separados, de forma que o diagrama com foco em Engenharia de Software complemente o entendimento do diagrama com foco em processos de negócios, gerando um documento de requisito detalhado com protótipos para todas as telas. O objetivo deste trabalho de pesquisa é a definição de uma metodologia de desenvolvimento de especificação de requisitos apropriada a um processo de negócio. Para validar a proposta, serão implementados dois estudos de caso em uma empresa operadora de planos privados de assistência à saúde, em que serão comparados os desempenhos a partir da metodologia proposta. Em um primeiro momento, é apresentado o estudo de caso com a metodologia usualmente aplicada, o qual é citado como Estudo de Caso de Controle Científico. Em seguida, o segundo estudo demonstra a implementação da metodologia proposta nesta neste projeto, este foi nomeado como Estudo de Caso com a Metodologia Proposta. Ambos os estudos foram desenvolvidos de forma sistemática, com resultados de desempenho monitorados e após isso, foi feita a análise comparativa de ambos estudos.

18 CAPÍTULO 1. INTRODUÇÃO Problema O problema estudado nesta pesquisa considera o grande número de projetos de software que apresentam falhas gerando atrasos e gastos desnecessários, que poderiam ser reduzidos com a compreensão das necessidades na fase de entendimento do software que será construído. A premissa da pesquisa é que, a utilização de metodologia integrada que forneça apoio sistematizado com etapas ordenadas e bem definidas para a especificação de requisitos de software de um projeto pode influenciar no desempenho do desenvolvimento do mesmo. 1.2 Justificativa O gerenciamento inadequado dos requisitos gera prejuízo considerável na fase de concepção de um produto de software. Atualmente, a proporção de projetos de software que apresentam falhas ou são cancelados atingem números consideráveis. No ano de 2013, pesquisas realizadas revelaram que apenas 39% dos projetos avaliados no ano de 2012 foram bem sucedidos, já os 61% restantes apresentaram alguma falha, foram cancelados antes do término ou nunca chegaram a ser utilizados [24]. A possibilidade de descobrir a falha no desenvolvimento de software na fase de construção viabiliza que o prejuízo seja reduzido de modo significativo [8]. Desta maneira, melhorar o processo de desenvolvimento de software é um passo fundamental para suprimir altos índices de improdutividade e atraso na entrega de projetos. Baseando-se nesta fundamentação, foram encontradas metodologias que visam tratar este problema, porém, os resultados encontrados não foram tão abrangentes, considerando que houveram alguns pontos de melhorias e outros inalterados. Uma das metodologias foi a Use Processes [26], que trata a integração de duas notações, o BPMN e o Diagrama de Caso de Uso, ambas em um único diagrama. Esta proposta tem a intenção de unir o conhecimento dos processos do negócio e também fornecer informações com relação ao comportamento do sistema e seus usuários. Apesar de ser interessante, falha no quesito

19 CAPÍTULO 1. INTRODUÇÃO 5 de usabilidade por introduzir métodos de áreas de conhecimentos distintas em um mesmo diagrama, sendo difícil para os usuários validarem os requisitos e entenderem os modelos gerados. Assim, a metodologia proposta fornece uma solução completa de alinhamento entre negócio e TI, por meio de camadas de conhecimento que são aprofundadas de acordo com a evolução do levantamento de requisitos. A possibilidade de visualizar somente uma camada detalhada simplifica o entendimento e permite que o sistema seja compreendido desde a macro visão até a micro, sem perda de generalidade. Todas essas camadas são construídas a partir dos principais processos de Engenharia de Requisitos, seguindo adaptações dos padrões IEEE (Seção 2.1.1), para obter o entendimento completo dos requisitos. O domínio escolhido para aplicação e teste foi em uma grande empresa operadora de planos privados de assistência à saúde brasileira, com sede em São Paulo. Este cenário representa um ambiente com desenvolvedores, analistas, especialistas, usuários e necessidades reais, o que se mostrou um atrativo ao estudo de caso, considerando que, possibilita o estudo dados reais, em ambiente real e com a infra-estrutura necessária. Adicionalmente, a diretoria da organização e a gestão de TI desta empresa demonstrou interesse e colaborou de modo efetivo, cedendo todos os dados necessários ao estudo. Apesar da aplicação ter sido realizada em um ambiente de uma grande empresa operadora de planos privados de assistência à saúde brasileira, espera-se que os bons resultados obtidos com esta metodologia sejam replicados em demais ambientes e domínios de ambientes de desenvolvimento de software. 1.3 Objetivo O objetivo desta pesquisa é propor uma metodologia que contribua com a Engenharia de Requisitos no processo de documentação dos requisitos de software. Esta metodologia permitirá que a documentação seja facilmente compreensível aos usuários, clientes e

20 CAPÍTULO 1. INTRODUÇÃO 6 especialistas em negócios, e simultaneamente, agregará detalhes técnicos necessários para que a equipe de desenvolvimento compreenda de forma precisa o escopo do projeto, auxiliando no entendimento do software construído e reduzindo falhas, as quais são parte de um prejuízo considerável Hipóteses A proposta de metodologia baseada na integração da área de processos Business Process Model and Notation (BPMN), atuando de forma integrada com o Diagrama de Caso de Uso e metodologias da área de Engenharia de Software pode trazer benefícios para o projeto de desenvolvimento de software nos seguintes aspectos: Reduzir as horas trabalhadas para executar cada ponto de função; Reduzir a ultrapassagem do orçamento acordado; Proporcionar maior clareza e precisão na especificação das características necessárias aos projetos de TI. 1.4 Organização do Texto O Capítulo 1 apresenta a introdução. O Capítulo 2, mostra conceitos teóricos essenciais para a área de pesquisa, com o embasamento teórico necessário para o desenvolvimento do trabalho, compondo assim a Revisão Bibliográfica. O Capítulo 3 aborda a forma de trabalho adotada e o modo como foi desenvolvida a metodologia proposta. Os capítulos 4 e 5, respectivamente, compõem os resultados obtidos e a conclusão do trabalho de pesquisa realizado.

21 Capítulo 2 Revisão Bibliográfica A Seção 2.1 apresenta os fundamentos da Engenharia de Requisitos. A Seção 2.2 descreve conceitos de Modelagem de Processos e a Notação de Modelagem de Processos (BPMN). A Seção 2.3 apresenta a definição do Diagrama de Caso de Uso. E, encerrando o capítulo, a Seção 2.4 aborda o Caso de Uso Integrado ao BPMN. 2.1 Engenharia de Requisitos De acordo com Sommerville [53], a Engenharia de Software é a disciplina da engenharia que engloba pesquisa e desenvolvimento de teorias, métodos e recursos, com o objetivo de produzir software de forma eficiente. O processo de software é composto por atividades, sendo quatro delas consideradas fundamentais e frequentemente são utilizadas [53]: 1) Especificação de software; 2) Desenvolvimento de software; 3) Validação de software; 4) Evolução de software. Na especificação de software (1) o objetivo é compreender e definir o software a ser produzido, compreendendo as condições e restrições aplicáveis. Esta atividade é desen- 7

22 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 8 volvida pela Engenharia de Requisitos (ER), com o objetivo de estabelecer a fundação sólida para viabilizar o projeto e construção de um software com maior probabilidade de atender as necessidades do cliente [50]. A ER é composta por processos para descobrir, analisar, documentar e verificar as funções e restrições dos requisitos para o sistema de software [52, 53]. Compreender a natureza dos problemas pode ser muito difícil, principalmente para sistemas novos [33, 52, 50]. Esta é a fase do processo de desenvolvimento de software mais complexa para corrigir ao final do projeto e esse é o trabalho que gera maior prejuízo ao projeto do sistema se houver falha de especificação [33, 8]. Devido à complexidade das atividades relacionadas ao entendimento dos requisitos, a ER surgiu a partir da área da Engenharia de Software (ES), com a proposta de sistematizar estas atividades [14]. Cada sistema tem um objetivo que geralmente é expresso em termos do que o sistema pode fazer. Um requisito de software pode ser a descrição de uma característica ou algo que o sistema tem potencial para realizar [47]. Os processos de ER visam obter o entendimento completo dos requisitos de um produto de software de forma clara e precisa [13]. As definições de requisitos bem aceitas na comunidade são as compatíveis com as terminologias propostas pelo CMMI [9] e os padrões IEEE [28]: Condição ou potencialidade que viabilize ao usuário resolver um problema ou atingir um objetivo; Condição ou potencialidade que um sistema, componente ou produto precisa ter para que atinja as expectativas e seja aceito (ou seja, satisfaça a um contrato, padrão, especificação ou algum outro documento formalmente imposto); Documentação dessa característica.

23 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA Processo de Engenharia de Requisitos O termo Engenharia de Requisito é amplamente utilizado para indicar o tratamento sistemático de requisitos [5]. A ER ocorre por meio da comunicação com a área cliente e segue até a modelagem do software [50]. A área de ER tem a preocupação com a elicitação, análise, especificação, validação dos requisitos de software e a gestão de requisitos durante todo o ciclo de vida do desenvolvimento do software. É amplamente reconhecida entre os pesquisadores e profissionais da indústria de software que os projetos de software se tornam extremamente vulneráveis quando o levantamento de requisitos não é bem executado [5]. Na presente pesquisa foram estudados os principais autores da área e suas propostas de processos. As propostas são similares, porém, possuem pequenas diferenças em suas divisões. Em geral, são dividas em: (1) Estudo de viabilidade, (2) Elicitação, (2) Levantamento, Detalhamento e Análise de requisitos, (3) Inspeção e Validação de requisitos, (4) Gerenciamento de requisitos e (5) Publicação dos requisitos pode ser executada quando for necessário a especificação documentada [52, 53, 13, 49, 51]. Pressman (2011) [50] defende que os estudos de ER são conduzidos por sete processos: Concepção, levantamento, elaboração, negociação, especificação, validação e gestão pelos membros da equipe de software. Para este projeto de pesquisa, a abordagem que foi adotada como padrão, com algumas adaptações é a definição de processos publicada no ano de 2014 pelo SWEBOK (2014) [5], desenvolvida pelo IEEE Computer Society. Tal publicação estabelece as seguintes fases do processo de ER: (1)Fundamentos Requisitos de Software; (2)Processo de Requisitos; (3)Elicitação Requisitos; (4)Análise de Requisitos; (5)Especificação de Requisitos;

24 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 10 seguir: (6)Validação de Requisitos; (7)Considerações Práticas; (8)Ferramentas de Requisitos de Software. Esta pesquisa utilizará as fases (1) até a (6) e a descrição delas será apresentada a (1) Fundamentos de Requisitos de Software O requisito de software é uma necessidade que deve ser exibida por algo para resolver alguns problemas no mundo real, e são tipicamente a combinação de várias pessoas, em diferentes níveis de uma organização, envolvidos ou se relacionando com o ambiente no qual o software irá operar. Desta forma, deve considerar todas as exigências do produto, tratando-as como necessidades ou restrições em relação ao software a ser desenvolvido, garantindo assim que todos os pré-requisitos necessários para um processo sejam executados antes de permitir que o mesmo seja feito [5]. Os requisitos geralmente são classificados da seguinte forma: Requisitos funcionais: descrevem todas as funções, capacidades ou recursos do software. Também pode ser descrito como aquela para a qual um conjunto finito de passos de ensaio pode ser escrito para validar o seu comportamento. Requisitos Não Funcionais: são aqueles que restringem a solução devido a requisitos relacionados a qualidade do software. Estes, podem ser classificados de acordo com os requisitos de desempenho, os requisitos de manutenção, requisitos de segurança, requisitos de confiabilidade, requisitos de interoperabilidade ou um dos muitos outros tipos de requisitos software [5]. Requisitos de Propriedades Emergentes: representam as restrições relacionadas ao sistema de forma geral, envolvendo todos os componentes do software. Tais propriedades estão vinculadas ao relacionamento de todos os componentes do processo em questão, gerando assim a interoperação. Um exemplo seria aumentar o rendimento de um Call Center, onde haveria dependência do sistema de telefonia, sistema de

25 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 11 informação e operadores do sistema, todos interagindo em condições de operação real para atingir o aumento de rendimento [5]. Os Requisitos de Software precisam ser declarados de forma bastante objetiva e clara, e, se possível, de forma quantitativa. É importante evitar requisitos vagos e não verificáveis que dependem de julgamento subjetivo para sua interpretação. Para isso, o engenheiro de software deve preferir definições de requisitos como por exemplo: O Software do Call Center deve aumentar o rendimento da Central em 20% [5]. Requisitos do Sistema e Requisitos de Software Os Requisitos do Sistema, se referem à combinação de todos os elementos de hardware, software, firmware, pessoas, informações, técnicas, instalações e serviços, interagindo como um todo para atingir o objetivo definido. Já os Requisitos de Software são relacionados aos clientes e usuários finais do software, focando na abrangência das necessidades dos usuários e requisitos de outras partes interessadas [5]. (2) Processo de Requisito Esta seção apresenta o processo para levantamento de requisitos de software, relacionando os processos do levantamento de requisitos com o processo geral da engenharia de software [5]. Modelos de Processo O objetivo deste tópico é fornecer uma compreensão de todo o processo de requisitos: O processo de levantamento de requisitos é feito no início do projeto e continua sendo refinado ao longo de todo o ciclo de vida do mesmo; Tem como objetivo, identificar e gerenciar os itens que configuram os requisitos de software a partir de práticas de gerenciamento dos processos de ciclo de vida do software; Deve ser adaptado para os contextos da organização onde o projeto acontecerá, havendo a necessidade de observar principalmente as atividades de elicitação, análise,

26 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 12 especificação e validação para diferentes tipos de projetos e restrições [5]. Atores do Processo Este tópico apresenta os papéis das pessoas que participam do processo de requisitos, o qual é fundamentalmente interdisciplinar e muitas vezes envolve diversas pessoas. O objetivo do especialista em requisitos é fazer a mediação entre o domínio da parte interessada, que pode ser composta por usuários, clientes especialistas, e o domínio da engenharia de software [5]. Suporte de Processos e Gestão Esta seção apresenta os recursos necessários e consumidos pelo gerenciamento de projetos, estabelecendo o contexto para iniciação e definição de escopo do Gerenciamento da Engenharia de Software. O principal objetivo é relacionar os processos de atividades identificadas na Seção de Modelos de Processos e as questões de custos, recursos humanos, treinamento e ferramentas[5]. Qualidade e Melhoria de Processos Este é um tópico que está intimamente relacionado com o setor da qualidade, tendo como objetivo, a avaliação da qualidade e melhoria do processo de levantamento de requisitos, enfatizando o papel fundamental que este processo desempenha em termos de custos, qualidade do software e satisfação do cliente [5]. (3) Elicitação de Requisitos A Elicitação de Requisitos é a primeira etapa para o entendimento do problema que o software deverá resolver. Neste momento, o engenheiro de software precisa identificar os stakeholders da área cliente e estabelecer o relacionamento entre eles e a área de desenvolvimento de software [5]. Um dos princípios fundamentais para um processo de Elicitação de Requisitos satisfatório é o bom relacionamento e comunicação com todos os stakeholders, e essa comunicação seguirá por todo o processo de ciclo de vida de desenvolvimento de software. Os enge-

27 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 13 nheiros de software também devem intermediar a relação entre os usuários especialistas e outros stakeholders, construindo assim um canal de comunicação com a equipe de desenvolvimento de software por meio de modelos para representar os diferentes níveis de abstração, facilitando a comunicação entre todos os participantes do processo. Alguns elementos críticos da elicitação de requisitos são: o estabelecimento do escopo do projeto a ser especificado, compreender e elaborar a priorização das entregas mais importantes para satisfazer as necessidades do cliente. Este direcionamento do trabalho reduz o risco de o engenheiro de software investir muito tempo em requisitos de pouca relevância para o software. Entretanto, este direcionamento precisa ser escalável e extensível para que outros requisitos ainda não identificados possam ser adicionados futuramente. Fontes de Requisitos Existem muitas fontes de informação para identificar os requisitos de software. Desta maneira, é essencial identificar, gerenciar e avaliar todas as fontes potenciais. Os principais tópicos de Fontes de Requisitos são: Identificar a motivação, os fatores críticos de sucesso e os objetivos globais de alto nível do software. Realizar um estudo de viabilidade é uma forma relativamente econômica de validar custos e retornos; Conhecimento de domínio: O engenheiro de software precisa adquirir ou ter conhecimento sobre o domínio da aplicação. Para isso, relações entre os conceitos relevantes no domínio de aplicação devem ser identificados; Stakeholders: Muitos softwares falharam e foram considerados insatisfatórios por priorizar alguns requisitos de uma parte interessada em detrimento de outros requisitos de outras partes interessadas. O engenheiro de software precisa identificar, representar e gerir os pontos de vistas de muitos tipos diferentes de partes interessadas; As regras de negócios: São declarações para definir ou limitar algum aspecto da estrutura ou o comportamento da empresa;

28 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 14 O ambiente operacional: O levantamento de requisitos depende do ambiente em que o software será executado e suas particularidades devem ser identificadas, pois podem afetar os custos e a viabilidade do software, além de restringir as escolhas de design; O ambiente organizacional: O engenheiro de software deve ser capaz de perceber a estrutura e cultura organizacional para que o novo software não force uma mudança não planejada no processo de negócio. Técnicas de Elicitação Uma vez que as fontes de requisitos foram identificadas, o engenheiro de software pode começar o levantamento dos mesmos. Esta é uma tarefa muito difícil, pois os usuários podem ter dificuldades para descrever suas tarefas, esquecer de declarar informações importantes ou demonstrar relutância para cooperar com o processo de levantamento. Este tópico concentra-se em técnicas para obter os requisitos e informações relevantes por meio de entrevistas [5]. Existem várias técnicas para elicitação de requisitos, as principais são: Entrevista: Esse é um meio tradicional de identificar requisitos fazendo entrevistas com as partes interessadas; Cenários: Fornecem uma forma valiosa para contextualizar e compreender as necessidades dos usuários, permitindo que o engenheiro de software forneça um quadro geral com perguntas e condições para compreender a situação onde o sistema será utilizado. O Diagrama de Caso de Uso é a metodologia mais comum para modelagem de software para a elicitação de requisitos; Prototipagem: Técnica que visa esclarecer os requisitos ambíguos e atua de forma semelhante ao cenário, fornecendo o contexto necessário para o usuário compreender melhor se o sistema irá suprir todas as suas necessidades. Existem diversos tipos de técnicas de prototipagem, como, maquetes de papel e design de telas em versão beta. Estes protótipos podem ser utilizados para elicitação e validação dos requisitos;

29 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 15 Reuniões com facilitador: Acontecem em grupo e podem trazer conhecimentos, aperfeiçoando ideias sobre os requisitos do software, os quais não seriam encontrados nas entrevistas individuais. Outra vantagem é que viabiliza compreender o conflito de requisitos ao colocar pessoas com diferentes pontos de vista sobre o sistema; Observação: Dentro do ambiente organizacional, é uma forma de compreender todo o contexto, possibilitando a elicitação dos requisitos. A partir da observação, o engenheiro de software pode aprender sobre as atividades do usuário, imergindo em seu ambiente real de trabalho. Essa técnica é custosa mas pode ser útil para identificar processos sutis e complicados, que seriam difíceis de compreender de outra forma; Histórias de usuário: Técnica utilizada em métodos ágeis da engenharia de software. Se destina a contar apenas as informações necessárias, de modo que os desenvolvedores possam produzir uma estimativa razoável do esforço para implementar essa solução. O objetivo é evitar alguns dos resíduos que muitas vezes acontecem em projetos, em que os requisitos detalhados estão reunidos no início, mas tornam-se inválidos antes do início do projeto; Outras técnicas: Existem diversas outras técnicas para apoiar a elicitação de requisitos, desde a análise de produtos dos concorrentes, aplicação de técnicas de mineração de dados ou utilização de banco de dados com pedidos dos clientes. (4) Análise de Requisitos Este assunto está relacionado com o processo de análise requisitos, de modo a [5]: Detectar e resolver conflitos entre requisitos; Descobrir os limites do software e como deve acontecer a interação com a sua organização e o ambiente operacional; Elaborar os requisitos do sistema para derivar requisitos de software.

30 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 16 É importante que na fase de análise de requisitos, alguns cuidados sejam tomados para descrevê-los com precisão suficiente, permitindo a validação dos requisitos, a validação da implementação dos requisitos e a estimativa dos seus custos. Classificação de Requisitos Os requisitos são classificados como [5]: A exigência pode ser funcional, que define uma função ou componente de um sistema de software ou não funcional, que define o uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, etc; A exigência pode ser derivada de um ou mais requisitos de alto nível ou de uma propriedade emergente; O requisito pode ser focado no produto ou no processo; O escopo da exigência se refere ao alcance que uma exigência pode afetar o software e componentes de software. Alguns requisitos, particularmente os não-funcionais têm um alcance global, para satisfazer estes requisitos é necessário uma adaptação global do software; O requisito que tem potencial de sofrer mudança durante o ciclo de vida do software ou mesmo durante o desenvolvimento do processo é classificado como requisito volátil. A sinalização potencial de requisitos voláteis é importante e pode ajudar o engenheiro de software a estabelecer um projeto que é mais tolerante à mudança. Modelagem Conceitual O foco da análise de requisitos de software está no desenvolvimento de modelos conceituais para problemas do mundo real, e a sua finalidade é ajudar a compreender a situação em que o problema ocorre, descrevendo a solução ao problema. Os modelos de engenharia de software estão relacionados a estes tópicos e, frequentemente são utilizados para descrever os cenários e situações de interação entre os atores e o sistema. Diversos modelos podem ser usados para modelar a realidade, como, por exemplo: Modelos de Caso de

31 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 17 Uso, Modelo de Fluxo de Dados, Modelos de Estado, entre outros que fazem parte da Unified Modeling Language (UML). Existem alguns fatores que influenciam na escolha da modelagem da notação, sendo eles: A natureza do problema: Alguns tipos de demanda de software podem exigir uma análise mais rigorosa do que outros; A experiência do engenheiro de software: Geralmente é mais produtivo adotar a modelagem que o engenheiro já tem experiência; Os requisitos do processo do cliente: Os clientes podem exigir que a análise seja feita seguindo seus modelos preferidos. Neste caso, poderá haver conflitos com o fator anterior. Na maioria dos casos torna-se eficiente iniciar a modelagem focando no contexto do software, fornecendo assim a conexão entre o software planejado e o seu ambiente externo [5]. Negociação de Requisitos Esta negociação visa compreender e resolver problemas de conflitos entre os stakeholders que exigem mutuamente características incompatíveis entre requisitos funcionais ou não funcionais. É comum, por razões contratuais, que tais decisões relacionadas a solução do conflito seja documentada para que haja rastreabilidade. Outra negociação importante é a priorização de requisitos que, além de filtrar os requisitos de maior importância, também resolve conflitos relacionados ao planejamento das entregas [5]. Análise Formal A utilização de uma análise formal para os requisitos tem duas vantagens: (1) Permite que os requisitos sejam expressos no idioma dos usuários, viabilizando que sejam especificados com precisão e de forma inequívoca, evitando o potencial para erros

32 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 18 de interpretação. (2) Os requisitos fornecerão fundamentação para permitir que todas as propriedades planejadas do software sejam validadas de acordo com o documento de requisitos pelos engenheiros de software, clientes e usuários [5]. (5) Especificação de Requisitos Em Engenharia de Software, o termo especificação de requisitos de software, refere-se ao desenvolvimento de um documento que pode ser sistematicamente revisto, avaliado e aprovado [5]. Documentos de Definição do Sistema Este documento especifica os requisitos de alto nível do sistema e é utilizado pelos usuários e clientes do sistema, portanto, o conteúdo deste documento deve ser escrito utilizando termos de domínio do usuário. O documento deve descrever a lista dos requisitos do sistema, declaração de restrições, requisitos não funcionais, informações sobre os objetivos globais do sistema e ambiente. Especificação de Requisitos de Software Tem por objetivo estabelecer a base para um acordo entre clientes e consultorias de desenvolvimento de software, a respeito do que deverá fazer ou não parte do escopo do software. Da mesma forma, viabiliza uma avaliação rigorosa dos requisitos antes do início do projeto, evita o retrabalho e possibilita uma base realista para estimar os custos do software, riscos e prazos. Além disso, as organizações podem usar o documento de especificação de requisitos de software como a base para a validação do sistema e de informação para a transferência de um produto de software para novos usuários ou plataformas, além de proporcionar uma base para a melhoria do software. Os indicadores para o documento de especificação de requisitos de software incluem tamanho, legibilidade, especificação, profundidade e estrutura do texto [5].

33 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 19 (6) Validação dos Requisitos A validação de requisitos tem a preocupação com o processo de examinar e documentar os requisitos, de forma a assegurar a definição adequada do software. Tem por objetivo identificar quaisquer problemas antes que os trabalhos sejam iniciados. Os documentos de requisitos podem ser validados visando garantir que a compreensão feita pelo engenheiro de software está de acordo com as necessidades reais do cliente. O processo de validação, deve verificar se o documento é compreensível, consistente, completo e está em conformidade com as normas da organização. A revisão dos documentos, geralmente é feita pelos stakeholders, incluindo representantes do cliente e do desenvolvedor [5]. Revisão de Requisitos O meio mais comum de validação é a revisão dos documentos de requisitos. Na revisão, um grupo de colaboradores trabalham junto com o engenheiro de software para encontrar os erros, suposições equivocadas e falta de clareza nos documentos de requisitos. Este grupo deve ser composto por pelo menos um representante do cliente para fornecer orientações sobre o que deve ser revisado [5]. Prototipação É um meio comum para validar a interpretação que o engenheiro de software identificou com relação as necessidades do software a ser construído e levantar novos requisitos. A vantagem em utilizar protótipos está na facilidade de interpretar as suposições do engenheiro de software, gerando maior assertividade na revisão ao solicitar a avaliação dos usuários e clientes, para identificar possíveis erros de entendimento. A volatilidade de um requisito após a prototipagem de um projeto é extremamente baixa, portanto, essa é uma ferramenta importante, justificando facilmente os custos com a prototipação, já que evita o desperdício de recursos causados pelas tentativas de satisfazer os requisitos errados [5]. Testes de Aceite

34 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 20 Uma propriedade essencial de um requisito de software é que o mesmo possa ser validado ao término do software, observando se está satisfazendo as necessidades iniciais do cliente. Uma tarefa importante é, portanto, o planejamento de como verificar cada requisito. Na maioria dos casos, os testes de aceite são feitos com os usuários finais do software, utilizando o sistema [5]. 2.2 Modelagem de Processos A Modelagem de Processos de Negócios é a atividade corporativa que visa documentar a modelagem de recursos, fluxos de informação e operações dos negócios que ocorrem na empresa. Com esta atividade bem definida, é possível ter melhor compreensão acerca da organização, bem como identificar melhorias em processos existentes, controlar qualidade e reduzir custos [44, 19]. O desenvolvimento pode ser realizado com a parceria de profissionais de TI que trabalham de forma colaborativa com profissionais da área de negócios. Essa modelagem pode ser composta por processos de negócios, políticas de negócio e indicadores de desempenho, os quais são conhecidos como KPIs, do inglês, Key Performance Indicator [20]. 1 Os princípios de modelagem de processos segundo Vernadat (1996) [55] são: (1) Segmentar em partes menores para simplificar a compreensão; (2) Fazer a decomposição funcional para gerar modularidade e com isso promover o reuso; (3) Desvincular os recursos dos processos; (4) Promover rigor na representação; (5) Decompor dados e controle; (6) Visualização do modelo [44, 55]. Os principais objetivos da modelagem de processos são [44, 12]: Promover comunicação de forma fácil: Utilizar um modelo representativo único que possa ser compreendido por todos os stakeholders envolvidos no processo, inclusive a 1 KPIs permitem medir diretamente o desempenho do negócio, alguns exemplos são: valor médio de compra, porcentagem de lucro, satisfação do cliente, etc.

35 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 21 equipe de desenvolvedores; Melhoria de processos: A partir do processo documentado, é possível identificar focos de melhoria; Reutilização: Um mesmo processo pode ser utilizado em diferentes momentos, evitando retrabalho; Gerenciamento de processos: Fazer planejamento, estimar prazos e sequenciar atividades, torna-se viável com base no processo finalizado e documentado; Automatizar processos: Alguns processos ou subprocessos bem definidos podem ser automatizados; Controle: Processos bem definidos podem ter controles de métricas automatizados para garantir integridade e qualidade no processo. Duas abordagens para a modelagem e documentação são descritas a seguir, a RM-OPD e a BPM. RM-OPD O Modelo de Referência para Processamento Distribuído Aberto (do inglês Reference Model for Open Distributed Processing-RM-ODP) teve seu desenvolvimento com o objetivo de ser o modelo de referência para descrever sistemas distribuídos abertos, e segundo BLAIR (1996) [3], foi aceito como um padrão nos anos seguintes [11, 3]. O Modelo de referência ODP é baseado em conceitos precisos, derivados do desenvolvimento de processamento distribuído, e torna possível o uso formal de técnicas descritivas para especificação da arquitetura [31]. De acordo com ISO/IEC [30], o modelo de referência é padronizado e define cinco níveis que precisam ser seguidos. A Figura 2.1 define os níveis existentes. Os cinco níveis são descritos a seguir:

36 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 22 Figura 2.1: Os cinco níveis de representação do RM-ODP I. Nível de Empresa (Enterprise Viewpoint): Neste nível deve ser feita a descrição do Sistema de Informação (SI) sob o aspecto de seus objetivos, descrevendo o que o sistema deve fazer para atender as necessidades administrativas e técnicas, de modo a justificar o projeto; II. Nível de Informações (Information Viewpoint): Neste nível, o SI deve descrever os fluxos, estruturas de informações e restrições; III. Nível Computacional (Computational Viewpoint): Descreve as operações e características computacionais do processo e mudança de informação; IV. Nível Tecnológico (Technological Viewpoint): Neste nível a descrição dos componentes do sistema são construídas; V. Nível de Engenharia (Engineering Viewpoint): O enfoque do nível de engenharia é descrever os recursos de engenharia que fornecem suporte para a natureza distribuída do processamento.

37 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 23 Business Process Management O Termo BPM (do Inglês Business Process Management), é uma solução tecnológica que tem a intenção de viabilizar integração e gestão dos processos de negócios [16]. De acordo com Ryan (2009) [36], o BPM tem por objetivo, alinhar os processos organizacionais com as necessidades dos stakeholders, promovendo integração e otimização nos processos da empresa, além de trazer maior eficiência e flexibilidade para a empresa BPMN - Notação de Modelagem de Processos de Negócios O BPMN, do inglês Business Process Modeling Notation [7], é um padrão de modelagem de processos que foi desenvolvido pelo Business Process Management Initiative [6]. No ano de 2005 ocorreu uma fusão entre essa entidade e a Object Management Group (OMG) que a incorporou. Nas últimas décadas, as operações empresariais têm convergido para a integração de informações, e controle de fluxos. Nos últimos anos tem ocorrido um crescimento de programação automatizada para integração de aplicações visando retirar as etapas manuais, gerando assim, grandes melhorias na confiabilidade e eficiência na integração de aplicações [20]. Segundo Nomura (2008) [44], o BPMN surgiu com o objetivo de se estabelecer como padrão para o BPM (Business Process Management) e tem as seguintes motivações: 1) Fornecer uma notação que facilite a compreensão de todos os stakeholders envolvidos com processos, com uma linguagem acessível tanto para os profissionais da área de TI como para os usuários especialistas em negócios, que conseguem ler um modelo em BPMN; 2) O BPMN também é composto por recursos opcionais que viabilizam a modelagem de processos complexos, permitindo uma modelagem bastante refinada do comportamento do processo. Além disso, possui informações técnicas que permitem o mapeamento automá-

38 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 24 tico para padrões de execução de processos, como, por exemplo, o WS-BPEL, abreviação do inglês Web Services Business Process Execution Language, que tem como objetivo gerar padronização para a automação dos processos entre serviços [34]; 3) Definir a unificação do Diagrama do Processo de Negócio (do inglês Business Process Diagram - BPD). Essa técnica se baseia em um fluxograma adaptado para a criação de modelos gráficos de operações de processos de negócios. Este modelo de processo de negócios é uma rede de objetos gráficos, que representam as atividades (ou seja, o trabalho) e controla o fluxo para definir a ordem de que tais atividades são executadas [56]. Para um conhecimento mais aprofundado em BPMN, o Apêndice 6.1 fornece toda a especificação do BPMN Arquitetura Orientada a Serviços Orientação a serviços é uma filosofia que vem sendo utilizada na sociedade há muito tempo [57, 17]. A Arquitetura Orientada a Serviços é um modelo conceitual que permite à organização, permanecer alinhada com o que há de mais atual na área de software, promovendo maior integração com outras organizações (B2B) com diferentes técnicas e tecnologias, gerando soluções competitivas. A especialização de atividades surgiu com a evolução da sociedade, com o objetivo de reduzir custos e aumentar conhecimento sobre atividades específicas. Essa linha evolutiva é bastante parecida com a filosofia de Dividir para Conquistar que foi estabelecida pelos antigos romanos [57, 18]. A Tecnologia da Informação (TI) absorveu os conceitos de orientação a serviços, e os sistemas de informação passaram a ser considerados como consumidores e fornecedores de serviços especializados, se relacionando com outros sistemas, permitindo que os recursos existentes fossem reutilizados. Essa estrutura baseada em sistemas fornecedores de serviços, deu origem à Arquitetura Orientada a Serviços. A origem do termo que representa a Arquitetura Orientada a Serviços (do inglês

39 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 25 Service-oriented Architecture - SOA) passa por algumas especulações. Alguns pesquisadores sugerem que o termo foi desenvolvido por Alexander Pasik em 1994, quando atuava como analista do Gurpo Gartner, outros dizem que indícios relacionados a teoria de SOA foram gerados a partir de estudos da IBM, Microsoft e outras empresas, sobre a tecnologia de Web Service no ano de O que pode ser afirmado é que, independente de quem foi o criador e em qual período o termo foi criado, atualmente SOA é reconhecido pelos profissionais da área como uma técnica robusta para o desenvolvimento de sistemas [41]. Diante de uma proliferação de desinformações e confusão, SOA tem passado por muitas controvérsias, porém, cabe-se pontuar que, SOA significa apenas uma abordagem para desenvolvimento de software onde todos os subsistemas estão disponíveis como serviços externos, o que significa que outros podem recombina-los de diferentes maneiras [46]. Algumas definições mais consideradas de SOA são: De acordo com OASIS (2007) [21, 45], SOA é o paradigma que viabiliza compartilhamento de capacidades distribuídas entre organizações parceiras por meio de soluções que promovem a reutilização, crescimento e interoperabilidade. De acordo com The Open Group (2009) [42], SOA é uma arquitetura orientada a serviço, ou seja, fornece uma forma de raciocinar, desenvolver e avaliar resultados baseados em serviços. Um serviço é uma tarefa de negócio com definição de serviço que representa um contrato entre o fornecedor e o consumidor do serviço, o serviço pode encapsular outros serviços de forma transparente para quem o utiliza. SOA, segundo IBM HIGH JR et al. (2005) [27], tem como principal objetivo alinhar a área dos negócios com a área da Tecnologia da Informação (TI) de uma forma eficaz, gerando alinhamento, sinergia e resultados valiosos que jamais foram alcançados no passado. Para isso, utiliza-se de um estilo arquitetural, com princípios de orientação a serviço, ou seja, integração do negócio como um conjunto de serviços integráveis. Uma premissa fundamental para utilizar SOA é que o processo de negócio deve ser mapeado com o conjunto real de procedimentos diários, gerando potencial para alavancar o negócio. Mesmo que os processos de negócios não sejam usados posteriormente para a

40 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 26 comunicação entre as empresas e as organizações de TI, ainda poderão ser ferramentas valiosas para ajudar as empresas a entenderem o que e como eles estão fazendo suas atividades. A documentação gerada no projeto pode ser usada para justificar mudanças nos processos de negócio, para ganhar maior consistência em toda a organização e educar os Stakholders sobre como a organização opera [27]. A SOA viabiliza renovação na forma como a TI apoia o processo de alinhamento estratégico da organização, permitindo que a organização se adapte às mudanças exigidas em seu ambiente de negócio sem sobrecarregar recursos de TI. Baseado nessa abordagem, pode-se identificar benefícios provenientes da utilização de SOA, como a segmentação das responsabilidades, organização lógica e facilidade de uso [41] SOA como modelo de alinhamento entre negócio e TI Segundo Marzullo (2009) [41], SOA pode ser usado como estratégia competitiva, permitindo uma visão mais abrangente do uso de TI como ferramenta para alinhamento estratégico, viabilizando estratégias mais adaptáveis. SOA oferece visões abstratas de como o arquiteto pode modelar soluções baseadas em software, proporcionando sistemas flexíveis e com baixo acoplamento, com potencial para manter a aderência do sistema às mudanças dos processos e regras de negócio, otimizando recursos e atingindo melhores resultados para a organização. Após levantar os processos de negócios de uma organização e compreender todos os seus elementos, é possível fazer o alinhamento entre o negócio e a TI utilizando SOA. O mapeamento dos processos deve ser conduzido no ambiente organizacional e deve considerar processos e subprocessos com regras de negócios até o nível de atividades que os stakeholders realizam. Os serviços de TI são projetados com base no mapeamento da organização, desenvolvendo os componentes e módulos que serão compostos pelo conjunto de serviços que irão interagir uns com os outros e se ajustar a realidade da empresa. A função do modelo de alinhamento é justamente identificar quais atividades de negócio são críticas e devem ser priorizadas para direcionar os esforços de desenvolvimento

41 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 27 Figura 2.2: SOA como modelo de alinhamento entre negócio e TI. Fonte: Adaptado de Marzullo (2009) [41]. de serviços de TI que atendam a essas necessidades. Toda a priorização deve ser feita respeitando critérios limitadores como orçamento, prazo, disponibilidade de equipe qualificada e apoio da alta gerência, reduzindo assim os riscos e gerando melhores resultados à organização.

42 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 28 O modelo geral de alinhamento entre negócio e a TI por intermédio de arquitetura SOA (Figura 2.2), apresenta o processo que o arquiteto de software deve seguir ao projetar sistemas corporativos. No domínio de negócio deve-se fazer a identificação de macroprocesso, subprocesso, tarefas e atividades por intermédio da modelagem de processos e, a partir deste modelo, identificar a infraestrutura que será utilizada para a construção de serviços para atender as necessidades dos processos da organização.

43 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA Caso de Uso O Diagrama de Caso de Uso é um dos diagramas da UML (Unified Modeling Language) utilizado para modelar os aspectos dinâmicos de sistemas com foco no comportamento do sistema e tem o objetivo de definir um conjunto orientado de interações que ocorrem entre os atores, que são agentes externos e o sistema que está sendo modelado [4]. De acordo com Pressman (2011) [50] e Cockburn (2001) [10], o Caso de Uso permite capturar um contrato que define o comportamento do sistema e todos os seus usuários, representando o sistema ou software da perspectiva do usuário final. Para isso, o Caso de Uso conta uma história estilizada sobre a interação do usuário final do sistema desempenhando os possíveis papéis relacionados ao sistema. As sequências de ações e interações entre usuário e sistema são modeladas para descrever os resultados esperados pelo usuário em cada história do Caso de Uso [4]. Os elementos de um modelo de Caso de Uso são: Ator: Descreve o papel que geralmente gera ou solicita ações e recebe reações do sistema. Cada Ator pode ser participante de mais de um Caso de Uso [4]; Caso de Uso: É a funcionalidade e descreve a sequência de eventos realizados pelo ator ao utilizar o sistema e as reações do sistema [4, 48]; Sistema: Descreve o sistema que será modelado [4]; Relacionamento: Descreve a comunicação do ator e o Caso de Uso, representado por um segmento de reta ligando estes elementos. O Ator pode ser relacionado à vários Casos de Uso em um mesmo diagrama [4]. Estes elementos são modelados de acordo com o exemplo da Figura 2.3), no qual, descreve o Ator com relacionamento com o Caso de Uso 1 e o Caso de Uso 2 do Sistema X. Para construir um Diagrama de Caso de Uso, deve-se seguir os seguintes processos: identificar as pessoas que utilizarão o sistema ou produto que está sendo modelado, as

44 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 30 Figura 2.3: Elementos do Caso de Uso. quais são conhecidas como Atores do Caso de Uso e representam qualquer coisa que utiliza ou se comunica com o sistema de forma externa [50, 10]. De acordo com Pressman (2011) [50] e Jackson (1992) [32], após a identificação dos atores, a próxima etapa é desenvolver perguntas que o Caso de Uso deve responder para ser considerado completo: Como definir e classificar os atores enquanto primários e secundários? Quais são as metas de cada ator? Existe a necessidade de precondições antes de uma história começar? Quais as principais funções exercidas por cada ator no software? Existem exceções que precisam ser consideradas? Quais? Quais as informações são inseridas, consultadas, alteradas ou excluídas pelo ator? O ator precisa fornecer informações relacionadas a mudanças no ambiente externo para o sistema? Quais as expectativas que o ator tem com relação ao software?

45 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA Documentação do Caso de Uso A Documentação do Caso de Uso, ou Especificação Textual do Caso de Uso, geralmente é uma descrição realizada, utilizando-se de linguagem simples, tendo como objetivo, fornecer informações importantes, como: as funções do sistema e as etapas que precisam ser sequenciadas pelos atores; quais os atores que interagem com cada função; quais os parâmetros, restrições e validações são necessárias para o Caso de Uso [25, 1]. Não existe uma descrição específica que precisa ser seguida em relação ao Caso de Uso. Para esse projeto serão adaptados e utilizados alguns dos itens descritos por Bezerra (2007) [1]: Precondições: Alguns Casos de Uso só fazem sentido se forem executados após alguma outra ação ou quando o sistema estiver em um determinado estado, com propriedades específicas. Neste caso, este campo pode ser adicionado na documentação do Caso de Uso; Fluxo Principal: Também pode ser nomeado de fluxo básico. Corresponde ao fluxo que normalmente acontece no momento em que o Caso de Uso é utilizado; Ator Primário: O nome do ator que inicia o Caso de Uso; Atores Secundários: São elementos externos que podem participar do Caso de Uso, sendo este um item opcional; Fluxo Alternativo: Este é um item opcional que somente é utilizado quando o Caso de Uso pode ser utilizado de diversas formas, neste caso, os cenários alternativos que são modelados dentro do mesmo Caso de Uso são descritos como Fluxo Alternativo. 2.4 Caso de Uso Integrado ao BPMN Sabe-se que uma adequada definição de requisitos, conduz a um produto de qualidade. Estudos realizados por Kamata (2007) [35], sugerem que há uma relação entre a qualidade

46 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 32 da especificação de requisitos do software e o resultado de um projeto, assim como a participação e o envolvimento dos clientes e usuários no desenvolvimento de software, aumenta a probabilidade de sua satisfação. Neste estudo, foram pesquisados diversos artigos e métodos focados no entendimento, representação e documentação de requisitos de software focados em duas notações gráficas que são muito utilizadas: o Caso de Uso da UML e o BPMN. O artigo Towards a BPMN Semantics Using UML Models descreve justamente o rumo a uma semântica BPMN usando modelos UML. Segundo o artigo, a sintaxe gráfica fornecida pelo BPMN é intuitiva, mas há um certo limite de dados que podem ser expressos, e acima deste limite, a sintaxe gráfica carece de precisão e se mostra incapaz de modelar requisitos complexos. O estudo sugere que no futuro a integração do BPMN com a modelagem de alto nível da UML será necessária para complementar e fornecer compreensão detalhada de requisitos complexos [43]. Os modelos de Diagramas de Objetos da UML e BPMN podem ser utilizados em conjunto para integração de software de maneira eficiente. No artigo com o título de Modelling using UML and BPMN the integration of open reliability, maintenance and condition monitoring management systems: An application in an electric transformer system, os pesquisadores demonstram um método inovador para otimizar a integração de três sistemas proprietários de prestígio internacional [39]. Lübke et al. (2008) [40] apresenta uma abordagem para visualizar dependências e ordenação de conjuntos de Caso de Uso da UML para criar modelos BPMN que sugere facilitar a identificação de erros durante o processo de elicitação de requisitos. Atualmente, existem técnicas e métodos que permitem elaborar requisitos com qualidade, como abordado por Li et al. (2008) [37, 26], mas, nenhuma das metodologias apresenta uma abordagem orientada a Processos de Negócios no levantamento de requisitos. Esta é uma importante abordagem, pois os clientes, geralmente, se sentem mais confortáveis quando trabalham visualizando os processos de negócios em fluxogramas [7, 26]. Hernandez et al.(2010) [26] apresentou uma abordagem chamada Use Processes, que se

47 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 33 baseia em elementos BPMN e o Diagrama de Caso de Uso em um único diagrama. Segundo o autor, essa abordagem promove a satisfação do cliente e do usuário, por permitir a sua participação na definição dos requisitos.

48 Capítulo 3 Metodologia Este trabalho tem a finalidade de atuar na área de Engenharia de Requisitos, elaborando um estudo das metodologias representativas neste segmento, de modo a definir e validar uma metodologia eficiente e estruturada. A metodologia proposta por Hernandez et al. (2010) [26] foi a principal fonte de embasamento para a realização deste trabalho. Sendo assim, inicialmente foi realizado um estudo de revisão bibliográfica que forneceu o conhecimento necessário para elaborar a proposta metodológica, o qual poderá ser melhor visualizado no Capítulo 2. Para validar as hipóteses, a modalidade de pesquisa selecionada foi o estudo de caso, pois ele permite o conhecimento com maior profundidade e detalhamento, focando em poucos objetos de estudo, e proporciona o entendimento de um fenômeno contemporâneo dentro de seu contexto real [23]. O desenho metodológico existente por trás deste estudo de caso está representado na Figura 3.1, onde foram analisados dois estudos de caso de projetos de desenvolvimento de software. Um dos estudos de caso recebe a denominação de controle e este projeto não foi exposto à metodologia proposta, enquanto o outro projeto, foi denominado estudo de caso e foi exposto à metodologia proposta. A partir daí, foi avaliado, retrospectivamente, se o projeto exposto a metodologia proposta apresenta os resultados sugeridos nas hipóteses deste trabalho de pesquisa. 34

49 CAPÍTULO 3. METODOLOGIA 35 Figura 3.1: Delineamento Esquematizado do Estudo de Caso. A validação das hipóteses deste trabalho foi feita através da comparação dos resultados destes dois estudos que foram implementados no mesmo contexto, em ambiente controlado e com implementação sequencial, sendo que primeiro foi feita a implementação do estudo de controle, por meio do Projeto de Vendas, e, em seguida, foi feita a implementação do estudo de caso utilizando a metodologia proposta, por meio do Projeto Blindagem Jurídica. Ambos projetos foram desenvolvidos em uma grande empresa operadora de planos privados de assistência à saúde, com sede em São Paulo. O estudo experimental de controle científico por meio do Projeto de Vendas e acordos teve início em Junho de 2013 e está detalhado na Seção 3.1. O segundo estudo de caso, que teve a aplicação da metodologia proposta por meio do Projeto Blindagem Jurídica SUS, foi iniciado em Abril de 2014 e está detalhado na Seção 3.2, permitindo um estudo experimental por vez. Para reduzir a variação da produtividade devido ao desempenho da equipe envolvida, o engenheiro de software e os desenvolvedores que atuaram no projeto de controle científico também participaram do projeto que utilizou a metodologia proposta.

50 CAPÍTULO 3. METODOLOGIA Estudo de Caso de Controle Científico Esta seção apresenta a formalização da metodologia aplicada no estudo de caso de controle para o desenvolvimento de software em um ambiente corporativo do segmento de operadora de planos privados de assistência à saúde. Para o estudo de caso de Controle Científico, foi selecionado o Projeto de Vendas e Acordos de planos de saúde. A metodologia proposta para este estudo foi a implementação de um projeto de engenharia de requisitos, utilizando os métodos que tradicionalmente já eram utilizados no ambiente de trabalho para gerar um documento de Requisitos de Software. Os métodos utilizados para levantamento de requisitos do presente estudo foram baseados em adaptações nos principais Processos de Engenharia de Requisitos encontrados na publicação do SWEBOK [5], no qual a Elicitação de Requisitos é apresentada (Seção 2.1.1) Fontes de Requisitos A primeira parte do trabalho foi a identificação das fontes de informação. Desta forma, foi possível identificar os requisitos de software seguindo a metodologia conforme os itens: Identificação da motivação, fatores críticos de sucesso e objetivos globais de alto nível do software; O engenheiro de software adquiriu o conhecimento sobre o domínio da aplicação; O engenheiro de software fez o entendimento visando definir ou limitar algum aspecto da estrutura ou o comportamento da empresa; Em seguida, fez a análise do ambiente operacional, identificando as particularidades do ambiente; O ambiente organizacional foi mapeado pelo engenheiro de software por meio de entrevistas com usuários-chave. Para finalizar, o engenheiro de software realizou a análise das informações para compreender a estrutura e cultura organizacional. Este

51 CAPÍTULO 3. METODOLOGIA 37 procedimento foi importante para evitar que o novo software force uma mudança não planejada no processo de negócio Técnicas de Elicitação Com as fontes de requisitos identificadas, o próximo processo de levantamento de requisitos se deu através de algumas adaptações das Técnicas de Elicitação, as quais foram adaptadas, e, as que foram utilizadas encontram-se listadas a seguir: Entrevista: O engenheiro de software fez entrevistas tradicionais com as partes interessadas para identificar os requisitos; Protótipos: Esta técnica foi aplicada somente nos casos mais complicados, que poderiam gerar requisitos ambíguos. Neste projeto, os protótipos foram criados em um software livre e foram utilizados para a elicitação e validação dos requisitos; Reuniões com o facilitador: Essa técnica aconteceu em grupo composto de usuários e do engenheiro de software, o qual teve como responsabilidade, inclusive, ser o facilitador. Essa técnica ajudou a compreender os conflitos de requisitos, por permitir a validação simultânea de diferentes pontos de vistas sobre o sistema. Um exemplo de conflito de requisitos que ocorreu foram solicitações de mudanças em processos operacionais que estavam em desacordo com as estratégias organizacionais e necessidades dos gestores. Observação: Essa técnica foi aplicada dentro do ambiente organizacional para que o engenheiro de software tivesse a oportunidade de compreender todo o contexto do ambiente organizacional para fazer a elicitação de requisitos, aprendendo sobre as atividades do usuário, imergindo em seu ambiente de trabalho e observando como os usuários realizam as suas atividades.

52 CAPÍTULO 3. METODOLOGIA Análise de Requisitos Após aplicar as Técnicas de Elicitação, o próximo processo implementado foi o desenvolvimento da Análise de Requisitos, o qual foi adaptado do processo, e poderá ser visualizado na Seção Nesta adaptação, os itens que foram implementados neste projeto foram: Detectar e resolver conflitos entre requisitos; Descobrir os limites do software, bem como a forma com que a interação entre a organização e o ambiente operacional deve ocorrer. Nessa etapa da análise de requisitos, também foram tomadas as devidas precauções para descrevê-los, de forma a permitir a futura validação dos requisitos e a estimativa de prazo e custos do projeto. Classificação de Requisitos Os requisitos foram classificados nas seguintes dimensões: Funcional e não funcional; Em alguns casos, o escopo da exigência foi classificado; A sinalização potencial de alguns requisitos voláteis foi identificada para ajudar o engenheiro de software a estabelecer um projeto mais tolerante a mudança, por exemplo, criando painel de controle para configurar prazos, comissões e outros campos com maior potencial de mudanças futuras. Modelagem Conceitual A Modelagem Conceitual ajuda a compreender a situação em que o problema ocorre, auxiliando na descrição da solução do mesmo. Os modelos de engenharia de software estão relacionados a estes tópicos e, frequentemente, são utilizados para descrever os

53 CAPÍTULO 3. METODOLOGIA 39 cenários e situações de interação entre os atores e o sistema. Os fatores que influenciaram na escolha da notação da modelagem foram: A natureza do problema: Alguns tipos de demanda de software podem exigir uma análise mais rigorosa do que outros; A experiência do engenheiro de software: Geralmente é mais produtivo adotar a modelagem da qual engenheiro já tem experiência. Baseado nos fatores acima, a modelagem selecionada para este projeto foi a Notação de Modelagem de Processos de Negócios (BPMN), conforme descrito na Seção Outra modelagem utilizada foi o protótipo para descrever as interfaces mais complexas que poderiam gerar problemas de compreensão por parte da área usuária, cliente ou desenvolvimento. Negociação de Requisitos Visando resolver problemas de conflitos entre os stakeholders, devido a solicitações de requisitos mutuamente incompatíveis, houveram reuniões para identificar e tratar estes conflitos. A priorização de requisitos também foi desenvolvida através de reuniões entre setores, utilizando os processos baseados no PMBOK Fifth Edition [29] para gestão de prazo, gestão de risco e gestão de custos do projeto. A documentação para identificar o escopo e os entregáveis foi feita através de Work Breakdown Structure (WBS) [29], por meio da ferramenta WBS Chart Pro 1, onde todos os componentes foram identificados e agrupados. Em um segundo momento, o MS Project foi utilizado para identificar a ordem das atividades, de acordo com suas prioridades e dependências no projeto, gerando um gráfico de Gantt 2 para gestão de prazo. 1 Pode ser encontrado neste website: 2 O diagrama de Gantt é um gráfico usado para ilustrar o avanço das diferentes etapas de um projeto.

54 CAPÍTULO 3. METODOLOGIA 40 Análise Formal Para realizar a análise dos requisitos, utilizou-se a técnica da análise formal, podendo ser observado duas vantagens: O Engenheiro de Software pode descrever os requisitos utilizando o idioma dos usuários, tornando a especificação precisa e evitando potenciais erros de interpretação entre todos os stakeholders do projeto; Esta documentação servirá de embasamento para que as propriedades planejadas para o software sejam validadas no momento da entrega, de acordo com o documento de requisitos, pelos engenheiros de software, clientes e usuários. A documentação de requisitos do projeto de controle científico que foi abordada nesta seção pode ser consultada no Apêndice - Estudo de Caso do Projeto de Vendas (Seção 6.2) Especificação de Requisitos Após aplicar os processos de Análise de Requisitos, foi implementado o processo de desenvolvimento da Especificação de Requisitos, o qual foi adaptado, e poderá ser verificado na Seção De acordo com SWEBOK (2014) [5], para definir sistemas complicados, geralmente são utilizados três tipos de documentos de requisitos: definição do sistema, requisitos de sistema e requisitos de software. Para os sistemas simples, somente o documento de requisito de software é utilizado, como é considerado o presente projeto. Portanto, o requisito de software desenvolvido pode ser sistematicamente revisto, avaliado e aprovado [5]. O Documento de Especificação de Requisitos foi desenvolvido de acordo com as definições de Especificação de Requisitos de Software (Seção 2.1.1). Este documento estabeleceu a base para o acordo e as negociações entre os clientes e o setor de Desenvolvimento de Software, com o intuito de determinar o escopo do software, estimar prazo, riscos e custos,

55 CAPÍTULO 3. METODOLOGIA 41 além disso, o documento foi utilizado para a validação do sistema Validação dos Requisitos Após aplicar os processos e desenvolver o documento de Especificação de Requisitos, o próximo processo implementado foi a Validação dos Requisitos, a qual foi adaptada e encontra-se descrita na Seção Nesta etapa do trabalho, o documento de requisito foi examinado para assegurar que a definição estava de acordo com as reais necessidades dos stakeholders do projeto. Para isso, foi desenvolvida a seguinte fase metodológica: O Engenheiro de Software conduziu a reunião para revisão dos documentos com os representantes do cliente, do usuário e do desenvolvedor. Prototipação A prototipação foi implementada somente com relação aos requisitos de interfaces e componentes mais complicados. A realimentação fornecida pelos usuários e clientes, no momento da revisão do documento de requisitos ajudou a identificar possíveis erros de entendimento por meio da prototipação, gerando aumento na assertividade do documento de requisitos. Os testes de aceite também foram executados ao final do projeto pelos usuários finais do software utilizando o sistema O Documento de Requisitos A documentação de requisitos gerada com base na metodologia proposta nesta seção pode ser consultada no Apêndice - Estudo de Caso do Projeto de Vendas na Seção 6.2, e a documentação de todos os processos BPMN que foram utilizadas para auxiliar no processo de levantamento de requisitos pode ser encontrada no Apêndice - Documento de BPMN do Estudo de Caso do Projeto de Vendas na Seção

56 CAPÍTULO 3. METODOLOGIA Estudo de Caso da Metodologia Proposta Esta seção apresenta a formalização da metodologia proposta, aplicada no estudo de caso para o desenvolvimento do Projeto do Software Blindagem Jurídica SUS, no mesmo ambiente corporativo do segmento de operadora de planos privados de assistência à saúde, em condições similares, mantendo a mesma equipe de engenheiros de software, desenvolvedores e gestor de projeto do estudo de caso de controle apresentado na Seção 3.1. A metodologia proposta neste trabalho de pesquisa concentra-se na especificação de requisitos de software. Para Tal, o método proposto permite que especialistas em negócios possam modelar processos de negócio, cientes da qualidade dos dados, e engenheiros de software possam obter artefatos úteis para a criação de software. Para atingir essas características, a metodologia proposta foi baseada em processos de Engenharia de Requisitos integrada a metodologia de Caso de Uso da UML, a qual fornece os aspectos dinâmicos de sistemas, com foco na modelagem do comportamento do sistema [4], integrada com os processos BPMN, que viabiliza fazer o alinhamento entre negócio e TI [41]. Este método proposto, fornece uma perspectiva com requisitos detalhados, para serem utilizados como documento de alinhamento para a equipe de desenvolvimento de software e validação dos requisitos, e uma visão de negócios, que viabiliza o entendimento de todos os outros stakeholders, como, por exemplo, os clientes e usuários do sistema que está sendo projetado. A Figura 3.2 descreve de forma simplificada as fases propostas nesta metodologia. Uma característica relevante acerca desta metodologia é a apresentação do conhecimento dos Requisitos do Software, que parte de uma visão mais geral para a mais específica, de forma a interligá-las, encadeando visões. A cada etapa que o entendimento destes requisitos avança, as especificações naturalmente se tornam cada vez mais detalhadas. Cada etapa da metodologia proposta neste estudo de caso foi descrita nas etapas abaixo:

57 CAPÍTULO 3. METODOLOGIA 43 Figura 3.2: Proposta Metodológica: Integração das metodologias de Engenharia de Requisitos com Processos BPMN e Caso de Uso. Engenharia de Requisitos: Nesta fase, o engenheiro de software utilizou os processos de Engenharia de Requisitos para definir o objetivo, os Stakeholders, as principais características e os requisitos funcionais e não funcionais do sistema; Diagrama de Caso de Uso: Após adquirir estes conhecimentos globais com relação aos requisitos do sistema, o engenheiro de software modelou o Diagrama de Caso de Uso, sendo esta uma forma valiosa para contextualizar e compreender as necessidades dos usuários; BPMN: Após a compreensão de contexto do sistema, o engenheiro de software executou o mapeamento dos processos de negócios baseados na metodologia de SOA como modelo de alinhamento entre negócio e TI. Para cada Caso de Uso, o Engenheiro de Software fez o mapeamento do processo utilizando BPMN, gerando um vínculo, que proporcionou o entendimento mais aprofundado do negócio e dos requisitos do sistema que está sendo projetado;

58 CAPÍTULO 3. METODOLOGIA 44 Caso de Uso Textual: Após a contextualização e o entendimento dos fluxos e processos por meio do BPMN, a próxima fase foi a elaboração da Especificação Textual do Caso de Uso. Esta, foi realizada individualmente para cada Caso de Uso e foi desenvolvida com base no processo BPMN, identificado na etapa anterior. Essa descrição forneceu informações importantes e detalhadas do Caso de Uso, com todas as etapas que precisam ser sequenciadas pelos atores, quais os atores que interagem com essas funções, quais parâmetros, restrições e validações são necessárias para o Caso de Uso [25, 1]; Protótipos: Apesar de todo o conhecimento adquirido nas fases citadas anteriores, a visão mais detalhada do requisito é feita por meio da técnica de protótipos, que define com exatidão os requisitos, fornecendo um documento bastante claro e detalhado do projeto do software. Essa documentação foi utilizada para elicitação de requisitos e também para validá-los. Neste estudo de caso foi desenvolvido um protótipo para cada uma das telas previstas no projeto do sistema Detalhamento da Metodologia Proposta Neste estudo de caso, a metodologia proposta seguiu a mesma sequência de processos propostos no Estudo de Caso de Controle Científico (Seção 3.1), com adição ou modificação de algumas atividades, ou seja, a metodologia utilizada para levantamento de requisitos do estudo de caso com a Proposta Metodológica também foi baseada em adaptações nos principais Processos de Engenharia de Requisitos [5] (Seção 3.1). Todos os passos metodológicos serão descritos, incluindo as fases que foram implementadas de maneira diferente: Fontes de Requisitos Na proposta metodológica, a primeira parte do trabalho também foi a identificação das fontes de informação seguindo os mesmos processos descritos na Seção

59 CAPÍTULO 3. METODOLOGIA 45 Técnicas de Elicitação Após identificar as fontes de requisitos, o próximo passo do processo foi o levantamento de requisitos, utilizando Técnicas de Elicitação, as quais foram mencionadas anteriormente na Seção Além dessas técnicas, foi implementada a metodologia de Diagrama de Caso de Uso como técnica de cenário, a qual forneceu uma ferramenta valiosa para contextualizar e compreender as necessidades dos usuários. A Figura 3.3 apresenta o Diagrama de Caso de Uso do Projeto Blindagem Jurídica SUS. Figura 3.3: Diagrama Caso de Uso do Sistema Blindagem Jurídica SUS. O ator primário do Diagrama de Caso de Uso é o Jurídico e tem o papel de importar

60 CAPÍTULO 3. METODOLOGIA 46 os arquivos disponibilizados pela ANS no sistema de cadastro Blindagem Sistêmica SUS, preparar as defesas para ABIs que sejam consideradas impugnáveis utilizando o sistema Blindagem Sistêmica SUS e preparar a defesa contra fraudes potenciais; O ator secundário CPD, tem o papel de levantar todas as documentações necessárias para embasar a defesa do jurídico, ou seja, digitalização dos documentos do cadastro do beneficiário utilizando o referido sistema para digitalização eletrônica, organizar/indexar todo o conteúdo e controlar acessos somente aos setores autorizados; O ator secundário Med. Aud. Técnico tem o papel de investigar todos os ABIs que não foram classificados automaticamente como impugnáveis pelo sistema Blindagem Sistêmica SUS, encontrando cobranças indevidas do ponto de vista médico técnico; O ator secundário Auditor de Fraude tem o papel de investigar fraudes potenciais, utilizando o sistema Blindagem Sistêmica SUS para encontrar todos os beneficiários que o SUS alega ter passado em atendimento em suas unidades médicas. O Auditor de Fraude entra em contato com o beneficiário por meio de telefone para confirmar a realização do atendimento no SUS ou identificar indícios de fraudes e fornecer tais informações tratadas ao Jurídico; O ator secundário Financeiro tem o papel de efetuar o pagamento das ABIs, digitalizar o boleto de pagamento com data de início e fim de parcelamento, enviar documentação de pagamento à ANS e notificar o Jurídico no momento em que o processo estiver encerrado para acompanhamento das datas de pagamento;

61 CAPÍTULO 3. METODOLOGIA 47 Após a implementação do Diagrama de Caso de Uso ser usada para contextualizar o software e definir todos os Atores e Casos de Uso necessários para o sistema, a próxima etapa da metodologia proposta foi a de identificar o fluxo, utilizando a metodologia BPMN conforme apresentado na Seção 2.4 a qual descreve o Diagrama de Caso de Uso Integrado ao BPMN. Para cada Caso de Uso foi desenvolvido um fluxo BPMN para identificar todas as atividades daquele processo. A Figura 3.4 descreve o processo BPMN do Caso de Uso Cadastrar ABI. Figura 3.4: Integração do Caso de Uso Cadastrar ABI com o processo BPMN.

62 CAPÍTULO 3. METODOLOGIA 48 Baseado no Diagrama de Caso de Uso e BPMN, a próxima etapa foi gerar a especificação textual do Caso de Uso. A Figura 3.5 descreve a especificação Textual do Caso de Uso Cadastrar ABI com a sua pré-condição, fluxo principal e Fluxo alternativo. Figura 3.5: Especificação Textual do Caso de Uso Cadastrar ABI.

63 CAPÍTULO 3. METODOLOGIA 49 Com base na Especificação Textual, a próxima etapa da metodologia proposta foi gerar todos os protótipos de telas que o usuário teria acesso para executar um determinado Caso de Uso. Usando como exemplo a Especificação Textual do Caso de Uso Cadastrar ABI, os protótipos que foram gerados podem ser visualizados na Figura 3.6. Figura 3.6: Protótipos de telas da Especificação Textual do Caso de Uso Cadastrar ABI.

64 CAPÍTULO 3. METODOLOGIA 50 Análise de Requisitos Após aplicar as Técnicas de Elicitação, o próximo processo implementado foi o desenvolvimento da Análise de Requisitos, o qual foi implementado com os mesmos processos descritos na Seção 3.1.3, referente a Análise de Requisitos do Estudo de Caso de Controle Científico. Especificação de Requisitos Após aplicar os processos de Análise de Requisitos, o próximo processo implementado foi o desenvolvimento da Especificação de Requisitos, implementado com os mesmos processos descritos na Seção 3.1.4, referente a Especificação de Requisitos do Estudo de Caso de Controle Científico. Validação dos Requisitos Após aplicar os processos da Especificação de Requisitos, o próximo processo implementado foi o desenvolvimento da Validação dos Requisitos, também implementado conforme o processo anterior, descrito na Seção 3.1.5, referente a Validação dos Requisitos do Estudo de Caso de Controle Científico. O Documento de Requisito A documentação de requisito gerada com base na metodologia proposta nesta seção pode ser consultada no Apêndice Documento de Requisitos do Estudo de Caso do Projeto Blindagem Jurídica SUS na Seção 6.3.1, e a documentação de todos os processos BPMN que foram utilizadas para auxiliar no processo de levantamento de requisitos pode ser encontrada no Apêndice - Documento BPMN do Estudo de Caso do Projeto Blindagem Jurídica SUS na Seção

65 CAPÍTULO 3. METODOLOGIA Avaliação da Metodologia Em cada estudo de caso foi aplicada a metodologia científica a seguir para comprovar as hipóteses proposta neste estudo: Reduzir as horas trabalhadas para executar cada ponto de função: A medição foi feita baseada em escopo original, com as estimativas de prazos e dificuldades (em horas e pontos de função) em comparação com a quantidade de horas de desenvolvimento executadas para finalizar o projeto devido a solicitações de alterações do escopo após o desenvolvimento. Tais dados foram obtidos em sistema de controle de tempo por atividade por desenvolvedor (timesheet); Reduzir a ultrapassagem do orçamento acordado: A medição foi feita utilizando o documento de gestão de custo que foi estimado no início do projeto e comparado com o custo que o projeto foi realizado efetivamente após todas correções e adaptações ao final do projeto; Proporcionar maior clareza e precisão na especificação das características necessárias aos projetos de TI: A medição foi feita comparando o escopo original do projeto por meio do WBS e o escopo entregue ao final do projeto, contemplando todas as alterações que foram acusadas pela área usuária como necessárias e identificando a quantidade de características que não foram mapeadas na fase de engenharia de requisitos e de Questionário Aplicado na Equipe Técnica.

66 Capítulo 4 Resultados Esta seção apresenta os principais resultados obtidos durante os experimentos que foram baseados em dois estudos de caso da seguinte forma: A Seção 4.1 aborda os resultados de Custos dos Projetos do Estudo de Caso, a Seção 4.2 aborda os resultados das Análises por Ponto de Função, a Seção 4.3 fornece a Análise dos resultados do escopo dos projetos e a Seção 4.4 descreve a Análise do Questionário Aplicado na equipe técnica envolvida em ambos projetos. 4.1 Resultados dos Custos Nesta seção, os resultados que foram documentados durante o desenvolvimento dos dois estudos de caso foram analisados. Inicialmente foi abordada a Análise do Projeto de Controle Científico e na sequência foi abordada a análise do Projeto com a Metodologia Proposta, por fim, foi feita a Análise Comparativa dos Custos dos dois projetos. 52

67 CAPÍTULO 4. RESULTADOS Análise de Custos do Estudo de Caso de Controle Científico O primeiro trabalho feito foi a análise de custos estimados e custos executados do projeto de controle científico. Inicialmente, foi feito um estudo para avaliar o valor médio da hora trabalhada pela equipe de desenvolvimento da empresa, a Tabela 4.1 mostra os cálculos utilizados para encontrar o Valor Médio por hora trabalhada no projeto de controle científico. Tabela 4.1: Cálculo do valor Homem/Hora Médio do Projeto de Vendas e Acordos. Na primeira coluna chamada Profissional, foram estipulados os cargos dos profissionais envolvidos no desenvolvimento do projeto. Na coluna nomeada Quantidade foi apresentado o número de profissionais com cada cargo estipulado que participaram do projeto, a coluna Horas Trabalhadas Mês considerou a quantidade média de horas que são trabalhadas em um mês, ou seja, foram consideradas 4 semanas de trabalho com 44 horas trabalhadas por semana. A coluna nomeada como Salário Bruto foi calculada com base no salário líquido do profissional, acrescido pela a taxa de encargos previstas no regime de Consolidação das Leis Trabalhistas (CLT), que são considerados em 88%. O cálculo da coluna Valor Hora Médio é o resultado do Salário Bruto dividido pelas Horas Trabalhadas Mês e multiplicado pela Quantidade de profissionais com aquele cargo. Baseado nesses dados, na linha Total foi feita a somatória da coluna Valor Hora Médio, e por fim, esse valor foi dividido pela Quantidade total de profissionais envolvidos no projeto, gerando o resultado da linha Média do Valor Hora Equipe, que é utilizado nas próximas análises de custos deste projeto. A Figura 4.1 mostra o gráfico com o Custo Planejado e o Custo Não Planejado do

68 CAPÍTULO 4. RESULTADOS 54 Projeto de Vendas e Acordos e, baseado neste gráfico, observa-se que o custo estimado inicialmente para o desenvolvimento deste projeto foi no valor de R$ ,70. Ao final do projeto, o custo total do desenvolvimento chegou a R$ ,20, ou seja, o custo não planejado para este projeto chegou a R$ ,50. Figura 4.1: Gráfico com o Custo Planejado e Custo Não Planejado do Projeto de Vendas e Acordos. Para compreender os dados que foram utilizados para gerar este gráfico, é necessário observar a coluna denominada TIPO (Tabela 4.2), a qual destaca se o custo foi Planejado ou Não Planejado. A coluna Horas Totais mostra a quantidade de horas totais que foram Planejadas ou Não Planejadas. A coluna Valor(Homem/Hora), utiliza como base o valor médio da hora de desenvolvimento, conforme já foi demonstrado na Tabela 4.1, que se refere ao Cálculo do valor Homem/Hora Médio do Projeto de Vendas e Acordos. A coluna Custo, apresenta o custo total, que é o resultado da coluna Horas Totais multiplicado pela coluna Valor(Homem/Hora), e por fim, na última coluna é apresentada a porcentagem do custo do projeto que foi Planejada, que ficou em 45% e a porcentagem que Não foi Planejada, ou seja, 55%.

69 CAPÍTULO 4. RESULTADOS 55 Tabela 4.2: Custo Planejado e Custo Não Planejado do Projeto de Vendas e Acordos Análise de Custos do Estudo de Caso com a Metodologia Proposta O estudo que feito nesta seção é a definição do custo planejado e executado do estudo de caso que utilizou a metodologia proposta. Este estudo é baseado no valor/hora médio do projeto. A Tabela 4.3 apresenta os cálculos que foram utilizados para encontrar o Valor Médio por hora trabalhada no projeto do Estudo de Caso com a Metodologia Proposta. Tabela 4.3: Cálculo do valor Homem/Hora Médio do Projeto Blindagem Jurídica SUS. Baseado nestes dados, na linha Total foi realizada a somatória da coluna Valor Hora Médio, e por fim, esse valor foi dividido pela Quantidade total de profissionais envolvidos no projeto, gerando o resultado Média do Valor Hora Equipe de R$60,89, o qual é utilizado nas próximas análises de custos deste projeto. A Figura 4.2 mostra o gráfico com o Custo Planejado e o Custo Não Planejado do Projeto de Blindagem Jurídica SUS. De acordo com o gráfico, o custo estimado inicialmente para o desenvolvimento deste projeto foi no valor de R$ ,09, chegando ao final do projeto ao valor de R$ ,55, ou seja, o custo não planejado para este projeto chegou a R$22.631,46. Este gráfico foi gerado baseado na Tabela 4.4. A coluna TIPO destaca se o custo foi Planejado ou Não Planejado. A coluna Horas Totais mostra a quantidade de horas totais que foram Planejadas ou Não Planejadas. A coluna Valor (Homem/Hora), utiliza

70 CAPÍTULO 4. RESULTADOS 56 Figura 4.2: Gráfico com o Custo Planejado e Custo Não Planejado do Projeto de Blindagem Jurídica SUS. como base o valor médio da hora de desenvolvimento, conforme já foi discutido na Tabela 4.3, que se refere ao Cálculo do valor Homem/Hora Médio do Projeto com a Metodologia Proposta. A coluna Custo, apresenta o custo total, que é o resultado da coluna Horas Totais multiplicado pela coluna Valor (Homem/Hora), e por fim, na última coluna é apresentada a porcentagem do custo do projeto que foi Planejada (83%) e a porcentagem que Não foi Planejada (17%.) Tabela 4.4: Custo Planejado e Custo Não Planejado do Projeto Blindagem Jurídica SUS.

71 CAPÍTULO 4. RESULTADOS Análise Comparativa dos Custos dos Projetos Esta seção aborda uma breve comparação dos resultados relacionadas aos custos do estudo de caso de Controle Científico e o estudo de caso que utilizou a Metodologia Proposta. Na Tabela 4.5, pode-se observar os resultados a partir da análise comparativa. Neste estudo, foram avaliados os custos planejados e custos não planejados para os projetos. Ambos os projetos foram finalizados com o custo além do estimado no momento do planejamento, porém, o projeto de controle ultrapassou o custo estimado em 128% e o projeto que utilizou a metodologia proposta ultrapassou o custo estimado em 20%. Tabela 4.5: Análise comparativa de custo. A Figura 4.3 representa estes valores graficamente por meio de um gráfico de barras. Figura 4.3: Gráfico com análise comparativa de custo. A metodologia proposta reduziu a quantidade de retrabalhos e aumentou o desempenho da equipe de desenvolvimento, produzindo como resultado a redução de custo e maior precisão na estimativa de custo, aproximando o custo final do projeto ao custo planejado. A primeira barra horizontal representa a Metodologia Proposta, que teve o custo planejado em R$ ,09 e um custo não planejado de R$22.631,46. A Segunda barra horizontal representa o estudo de caso de Controle Científico, que teve o custo planejado no valor de R$ ,70 e o custo não planejado no valor de R$ ,50.

72 CAPÍTULO 4. RESULTADOS Resultados de Prazo por Análise de Ponto de Função Nesta seção, o resultado estudado foi baseado na Análise por Ponto de Função (APF), a qual é considerada uma técnica de medição do ponto de vista do usuário do software, com relação as funcionalidades do sistema, independente da tecnologia utilizada. O processo de medição gerado pela APF é feito com base em uma avaliação padronizada dos requisitos lógicos, e como resultado se tem os Pontos de Função que representam a dificuldade e o tamanho do projeto de software. Essa é uma medida importante para derivar informações como: estimativa de esforço, prazo, e consequentemente custo do projeto [54]. Neste estudo, foi avaliado o desempenho do desenvolvimento de acordo com a quantidade de horas necessárias para desenvolver um ponto de função, ou seja, o projeto que terminasse com a menor quantidade de horas necessárias para executar um ponto de função, considerando o melhor desempenho nos processos de software. Na Seção estão apresentados os resultados referentes ao estudo de caso de controle, implementado por meio do projeto de engenharia de requisitos e implementação do Sistema de Vendas e Acordos; na Seção foram apresentados os resultados referentes ao estudo de caso com a proposta metodológica, implementada por meio do projeto de engenharia de requisitos e implementação do Sistema Blindagem Jurídica SUS. Por fim, na Seção foram apresentadas as comparações dos resultados de ambos projetos Resultados de Ponto de Função Estudo de Caso Controle Científico Após o entendimento das necessidades do projeto (Apêndice 6.2.1), e com base no documento de requisitos, foi implementada a Análise por Ponto de Função, seguindo a metodologia proposta por Pressman (2011) [50], que encontra-se descrita no capítulo de Métricas do Produto. A análise do ponto de função do Estudo de Caso de Controle Científico pode ser consultada no Apêndice do Ponto de Função do Projeto de Vendas na

73 CAPÍTULO 4. RESULTADOS 59 Seção Tabela 4.6: Ponto de Função Estudo de Caso de Controle Científico. A Tabela 4.6 mostra um comparativo da estimativa versus realização. Na linha estipulada com o nome Estimado, em relação a coluna Pontos de Função, observa-se a quantidade de pontos de função para o projeto de controle científico, o resultado foi arredondado para 310. Na coluna Quantidade Total de Horas, o campo mostra a estimativa de tempo que foi planejada para o desenvolvimento deste projeto em horas, ou seja, a estimativa foi de que o projeto seria desenvolvido em 2937 horas. Na coluna Horas Por Ponto de Função, o gráfico mostra a estimativa de que a equipe desenvolveria um ponto de função a cada 9,48 horas trabalhadas, para chegar a este resultado a coluna Quantidade Total de Horas foi dividida pela coluna Pontos de Função. Já na linha Realizado, a coluna Pontos de Função exibe novamente a quantidade calculada de ponto de função, com o valor de 310, a coluna Quantidade Total de Horas exibe o tempo total utilizado para o desenvolvimento do projeto e, na coluna Horas por Ponto de Função observa-se o resultado da Quantidade Total de Horas dividida pela coluna Pontos de Função, totalizando 21,59 horas para realizar cada ponto de função. A Figura 4.4 exibe essas informações em gráficos de barra, sendo que o primeiro gráfico exibe a Quantidade Total de Horas Realizadas em comparação com a Quantidade Total de Horas Estimadas para o Estudo de Caso de Controle Científico. O segundo gráfico demonstra a a quantidade de horas que foram estimadas para a realização de cada ponto de função em comparação com a quantidade de horas que foram necessárias para desenvolver cada ponto de função. Na Seção são apresentados os resultados da metodologia proposta por meio da implementação do projeto Blindagem Jurídica SUS, e na Seção está apresentada a

74 CAPÍTULO 4. RESULTADOS 60 Figura 4.4: Gráfico de Quantidade Total de Horas estimadas X trabalhadas e Quantidade de horas para realizar um Ponto de Função do Estudo de Caso de Controle Científico. análise do resultado de ambos estudos de caso, visando identificar se as hipóteses propostas foram atingidas.

75 CAPÍTULO 4. RESULTADOS Resultados de Ponto de Função Estudo de Caso Proposta Metodológica Nesta seção estão apresentados os resultados referentes a implementação deste projeto de engenharia de requisitos, seguindo os processos disponíveis em Estudo de Caso da Metodologia Proposta que são descritos na Seção 3.2. Para avaliar os resultados, foi aplicada a Análise por Ponto de Função [50], a qual gerou como resultado o documento que está disponível no Apêndice Ponto de Função do Projeto de Blindagem Jurídica SUS na Seção Para elaborar a Análise por Ponto de Função, foram necessários: o documento de requisitos, que pode ser encontrado no apêndice com o título de Documento de Requisitos do Estudo de Caso do Projeto Blindagem Jurídica SUS (Seção 6.2.1) e os processos que estão disponíveis no Apêndice, com o título de Apêndice - Documento BPMN do Estudo de Caso do Projeto Blindagem Jurídica SUS (Seção 6.2.2). A Tabela 4.7 mostra os dados do planejamento de horas trabalhadas para o projeto Blindagem Jurídica SUS, baseado na estimativa de ponto de função em comparação com as horas trabalhadas em que o projeto foi realizado. Tabela 4.7: Ponto de Função Estudo de Caso da Proposta Metodológica. A Linha chamada Estimado, na coluna Pontos de Função, mostra a quantidade de pontos de função para o projeto de controle científico, que neste projeto, de acordo com a planilha de ponto de função tem como resultado o valor arredondado de 196 pontos, na coluna Quantidade de Total de Horas mostra a estimativa de 1814 horas para que o projeto seja concluído e na coluna Horas Por Ponto de Função que foi calculada baseada na Quantidade Total de Horas dividida pela coluna Pontos de Função, totalizando 9,28 horas para realizar cada ponto de função.

76 CAPÍTULO 4. RESULTADOS 62 Na linha Realizado a coluna Pontos de Função exibe novamente a quantidade calculada de ponto de função, com o valor de 196 pontos de função, a coluna Quantidade Total de Horas exibe o tempo total utilizado para o desenvolvimento do projeto e a coluna Horas por Ponto de Função representa o desempenho da equipe, que é representada nesta tabela pela Quantidade Total de Horas dividida pela coluna Pontos de Função, totalizando 11,18 horas para realizar cada ponto de função. A Figura 4.5 exibe essas informações em gráficos de barra, sendo que o primeiro gráfico exibe a Quantidade Total de Horas Realizadas em comparação com a Quantidade Total de Horas Estimadas para o Estudo de Caso da Metodologia Proposta. O segundo gráfico exibido pela figura demonstra a quantidade de horas que foram estimadas para a realizado de cada ponto de função em comparação com a quantidade de horas que foram necessárias para desenvolver cada ponto de função. Figura 4.5: Gráfico de Quantidade Total de Horas estimadas X trabalhadas e Quantidade de horas para realizar um Ponto de Função do Estudo de Caso com a Metodologia Proposta. Na Seção serão discutidas a comparação dos resultados dos dois estudos de caso.

77 CAPÍTULO 4. RESULTADOS Comparação dos Resultados das Análises de Ponto de Função Nesta Seção foi feita a avaliação do Estudo de Caso de Controle Científico em comparação com o desempenho do Estudo de Caso com a Metodologia Proposta. A comparação é baseada em ponto de função, conforme descrito em Resultados Estudo de Caso Vendas e Acordos na Seção e Resultados Estudo de Caso Blindagem Jurídica SUS na Seção 4.2.2, respectivamente. A Figura 4.6 descreve a metodologia da comparação do desempenho do Estudo de Caso de Controle Científico, por meio da implementação do projeto de Vendas e Acordos e do Estudo de Caso com a Metodologia Proposta, por meio do projeto Blindagem Jurídica SUS. A metodologia com o delineamento comparativo de prazo por ponto de função seguiu os itens abaixo: Figura 4.6: Delineamento comparativo do Estudo de Caso do Controle Científico com a Metodologia Proposta. Inicialmente foi desenvolvida a análise por ponto de função do projeto de Controle Científico, gerando a quantidade total de pontos de função para o projeto;

78 CAPÍTULO 4. RESULTADOS 64 O projeto de Controle Científico foi implementado e durante o desenvolvimento todas as informações de atividades executadas foram capturadas utilizando software para gerenciamento de projetos, contabilizando assim a quantidade total de horas utilizadas para finalizar o projeto; Ao final do projeto de controle científico foram feitos cálculos para identificar a quantidade de horas trabalhadas que foram necessárias para concluir cada ponto de função; Foi desenvolvida a análise por ponto de função do projeto que implementou a Metodologia Proposta, gerando a quantidade total de pontos de função para este projeto; O projeto com a Metodologia Proposta foi implementado e durante o desenvolvimento todas as informações de atividades executadas foram capturadas utilizando software de gestão de projetos para identificar a quantidade total de horas utilizadas no projeto; Ao final do projeto com a Metodologia Proposta foram feitos cálculos para identificar a quantidade de horas trabalhadas que foram necessárias para concluir cada ponto de função; Após a finalização dos projetos, foram feitos os cálculos para comparar a quantidade de horas necessárias para executar um ponto de função no projeto de Controle Científico e a quantidade de horas necessária para executar um ponto de função no projeto utilizando a Metodologia Proposta. A Tabela 4.8 descreve os dados utilizados para avaliação do Estudo de Caso de Controle Científico em comparação com a Metodologia Proposta e com a média apresentada pela International Software Benchmarking Standards Group (ISBSG) [54]. A primeira parte da tabela exibe informações relacionadas ao planejamento do projeto. A coluna Pto Função representa a quantidade de ponto de função para cada um dos projetos, a coluna Hr/Pto de Função representa a quantidade de horas estimadas para executar cada ponto de função, e a coluna Total Hr representou a quantidade total

79 CAPÍTULO 4. RESULTADOS 65 Tabela 4.8: Avaliação do Estudo de Caso de Controle Científico em comparação com a Metodologia Proposta. de horas estimadas para executar os projetos. As colunas seguintes representaram o Desenvolvimento Executado, ou seja, a quantidade real de horas necessárias para executar cada ponto de função e a quantidade total de horas para executar o projeto e nas duas últimas colunas foram apresentadas a quantidade média de horas para desenvolver cada ponto de função de acordo com a ISBSG e a estimativa de horas necessárias de acordo com o ISBSG. Uma informação importante encontrada na tabela é a diferença de horas planejadas e as horas executadas em cada estudo de caso. No estudo de caso de controle científico com relação ao estudo de caso que utilizou a metodologia proposta a diferença proporcional é significativa. Para facilitar a visualização dessa informação a Figura 4.7 descreve a variação da quantidade de horas necessárias para desenvolver um ponto de função nas seguintes situações: Controle Científico, onde por meio da implantação do projeto de Vendas e Acordos foi identificado que o desempenho da equipe para produzir um ponto de função exigia 21,58 horas; Metodologia Proposta neste trabalho de pesquisa por meio da implementação do estudo de caso do Projeto Blindagem Jurídica SUS, a quantidade de horas utilizadas para produzir um ponto de função baixou para 11,18 horas; Referência baseada na média de horas para desenvolver cada ponto de função de acordo com a ISBSG que é estimada em 19,6. A estimativa que havia sido estabelecida para os projetos não foi alcançada em nenhum dos estudos de caso, porém, o projeto que utilizou a Metodologia Proposta mostrou um

80 CAPÍTULO 4. RESULTADOS 66 Figura 4.7: Gráfico de avaliação comparativa das horas necessárias para produzir um Ponto de Função. desempenho vantajoso com relação ao estudo de caso de Controle Científico. A Figura 4.8 apresenta a análise comparativa dos pontos de função que evidencia este resultado. Figura 4.8: Gráfico comparativo de horas por Ponto de Função. O estudo de caso que utilizou a Metodologia Proposta ultrapassou o planejamento em 1,90 horas por ponto de função, representando 21% do tempo trabalhado além do planejado, o estudo de caso de Controle Científico ultrapassou o planejamento em 12,11 horas por ponto de função, representando 128% de tempo trabalhado além do planejado. Este resultado foi analisado de forma isolada e apresentou um viés nos resultados por desconsiderar o fator de maturidade das equipes. A Seção fará uma análise para corrigir este viés.

81 CAPÍTULO 4. RESULTADOS Comparação dos Resultados das Análises de Ponto de Função Com Fator de Maturidade das Equipes No estudo anterior, apresentado na Figura 4.8, foi considerado somente a quantidade de horas que foram utilizadas em média para executar o trabalho relativo a um ponto de função de forma isolada, porém, a equipe que trabalhou no projeto que utilizou a metodologia proposta era composta por profissionais com mais experiência, impactando diretamente na produtividade. Para adequar estes resultados, foi feito um ajuste baseado no custo médio da equipe que foi apresentado na Seção 4.1. A Tabela 4.9 apresenta o aumento percentual do valor médio da equipe que utilizou a Metodologia Proposta com relação à equipe que trabalhou no estudo de caso de Controle Científico, como resultado, o valor do fator de ajuste de Maturidade das Equipes que foi considerado é de 3,64%. Tabela 4.9: Cálculo do Fator de Maturidade da Análise Comparativa do Ponto de Função. A Figura 4.9 apresenta o mesmo gráfico comparativo apresentado anteriormente, mas considerando também o Fator de Maturidade, onde o planejamento foi mantido em 9,28 horas por Ponto de Função, porém, a quantidade de horas não planejadas, após a soma de 3,64%, teve um aumento que elevou de 1,90 horas por Ponto de Função para 2,31 horas por Ponto de Função. Sendo assim, considerando o Fator de Maturidade, o estudo de caso que utilizou a Metodologia Proposta ultrapassou o planejamento representando uma falha de planejamento de 25% e o estudo de caso de Controle Científico manteve os dados anteriores, ou seja, ultrapassou o planejamento em 12,11 horas por ponto de função, representando uma falha de planejamento de 128%.

82 CAPÍTULO 4. RESULTADOS 68 Figura 4.9: Gráfico comparativo de horas por ponto de função considerando o Fator de Maturidade. 4.3 Resultados da Análise de Escopo Esta seção descreve os resultados relacionados ao entendimento do escopo dos estudos de caso. Conforme anteriormente exposto, estabelecer o escopo do projeto especificado e compreender os entregáveis mais importantes para satisfazer as necessidades do cliente é um elemento crítico da Elicitação de Requisitos e reduz o risco de investir tempo em requisitos de pouca relevância para o software [5]. Nesta análise foi utilizada a ferramenta básica para descrever o escopo do trabalho, que é a Work Breakdown Structure (WBS) [29] dos projetos de Controle Científico e do Projeto que utilizou a Metodologia Proposta. A WBS de ambos os estudos de caso foi adaptada para identificar e classificar os entregáveis em três categorias: Identificados Corretamente: representando todos os entregáveis que foram identificados na fase de levantamento de requisitos e ao final do projeto fizeram parte do projeto de software satisfazendo as necessidades do cliente; Não Identificados: representando todos os entregáveis que não foram identificados na fase de levantamento de requisitos e ao final do projeto fizeram parte do projeto

83 CAPÍTULO 4. RESULTADOS 69 de software para satisfazer as necessidades do cliente; Desnecessários: representando todos os entregáveis que foram identificados como necessários na fase de levantamento de requisitos e ao final do projeto foram cancelados ou de alguma forma não fizeram parte do projeto de software entregue. Para representar essas classificações a WBS de cada projeto foi colorida da seguinte forma: entregáveis coloridos na cor branca para representar os entregáveis que foram classificados como Identificados Corretamente, destacados na cor amarela os entregáveis que foram classificados como Não Identificados e destacados na cor vermelha os entregáveis que foram classificados como Desnecessários. A WBS do projeto de Controle Científico, ou seja, do projeto de Vendas e Acordos que foi utilizada como base para a análise está disponível no Apêndice - Escopo - WBS Projeto de Vendas e Acordos que fica na Seção O elemento Construção da WBS representa todos os componentes necessários para a entrega completa do desenvolvimento do projeto de software. Dos sessenta e nove elementos contidos na construção do software, cinquenta e quatro elementos foram classificados como Identificados Corretamente, nove elementos foram classificados como Não Identificados e seis elementos foram classificados como Desnecessários. A WBS do estudo de caso com a Metodologia Proposta, ou seja, do projeto de Blindagem Jurídica SUS que foi utilizada como base para a análise está disponível no Apêndice - Escopo - WBS Projeto Blindagem Jurídica SUS que fica na Seção Neste estudo o elemento Construção da WBS é representado por treze elementos e onze elementos foram classificados como Identificados Corretamente, dois elementos foram classificados como Não Identificados e nenhum dos elementos foram classificados como Desnecessários. As informações referentes aos projetos de Controle Científico e de Metodologia Proposta estão resumidas na Tabela Em azul estão as informações do projeto de Controle Científico, de acordo com o quadro

84 CAPÍTULO 4. RESULTADOS 70 Tabela 4.10: Análise do escopo. houve 78% dos elementos que foram classificados como Identificados Corretamente, 13% Não Identificados e 9% foram classificados como Desnecessários. A Metodologia Proposta foi destacada com a cor laranja e de acordo com o gráfico apresentou 85% dos elementos classificados como Identificados Corretamente, 15% dos elementos classificados como Não Identificados e nenhum dos elementos foi considerado Desnecessário. A Figura 4.10 apresenta estes resultados por meio de um gráfico comparativo. Figura 4.10: Análise do escopo. Neste gráfico foi observado que o projeto de Controle Científico teve 9% dos elementos identificados classificado como desnecessários enquanto que o projeto com a metodologia proposta não apresentou elementos classificados como desnecessários. Este tipo de falha pode gerar retrabalho, reduzindo a produtividade e aumentando o prazo e custo do projeto conforme exposto na Seção de Especificação de Requisitos de Software. Com relação aos elementos classificados como Não Identificados o projeto de Controle Científico apresentou 13% de ocorrências enquanto o projeto que utilizou a metodologia proposta apresentou 15%. Este tipo de falha pode gerar um planejamento incorreto, comprometendo a estimativa de prazo e custo do projeto. Com relação aos elementos classificados

85 CAPÍTULO 4. RESULTADOS 71 como Identificados Corretamente o estudo de caso de Controle Científico apresentou 78% e o estudo de caso com a Metodologia Proposta apresentou 85% dos elementos. Essa é uma medida que pode ser usada para avaliar a eficiência geral da metodologia aplicada para levantar os requisitos de software, ou seja, quanto mais o documento de requisitos se aproxima do modelo final, mais este modelo representa a necessidade real do cliente e usuário do software.

86 CAPÍTULO 4. RESULTADOS Resultados do Questionário Aplicado na Equipe Técnica Este estudo teve como objetivo, identificar se a metodologia proposta forneceu documento de requisito com maior precisão. Para validar esta hipótese, foi desenvolvido um questionário estruturado, o qual foi aplicado a oito profissionais da área de TI, os quais participaram ativamente do desenvolvimento dos dois projetos de software que foram utilizados como estudo de caso desta pesquisa. As questões do questionário aplicado avaliaram a experiência dos profissionais com relação ao estudo de caso de Controle Científico, bem como o estudo de caso com a metodologia proposta. O relatório com todas as questões propostas pode ser visualizado no Apêndice Questionário Pesquisa sobre documentação de Requisitos dos projetos de Vendas e Acordos e o Blindagem Jurídica SUS na Seção As respostas de todas as questões estão disponíveis no Apêndice - Respostas do Questionário Pesquisa sobre documentação de Requisitos dos Projetos de Vendas e Acordos e o Blindagem Jurídica SUS na Seção A primeira página do questionário tem o objetivo de identificar o cargo e a área de atuação do profissional. O questionário foi respondido por oito profissionais, sendo cinco profissionais da área de negócios e três profissionais da área de programação, conforme a Figura Destes profissionais, três são analistas júnior, um é analista pleno, três são líderes de projeto e um é gerente de projeto. A segunda parte da pesquisa abordou os principais itens de engenharia de requisitos, abordadas na Seção do Processo de Engenharia de Requisitos por meio de questões relacionadas às seguintes propriedades: Identificação da motivação, fator crítico de sucesso e objetivos globais do software; Escopo e compreensão das entregas mais importantes;

87 CAPÍTULO 4. RESULTADOS 73 Figura 4.11: Gráfico da área de atuação dos profissionais que responderam ao questionário. Entendimento com precisão para gerar a Estimativa de Prazos; Conhecimento de domínio, identificação dos Stakeholders e regras de negócios; Detecção e resolutividade de conflitos entre requisitos; Sinalização do potencial de requisitos voláteis; Possibilidade de validar sistema de acordo com o documento de requisitos. A Figura 4.12 apresenta os resultados das respostas ao questionário em formato de gráfico de barras. O gráfico foi feito por meio da comparação dos resultados obtidos para cada um dos itens de engenharia de requisitos, com relação ao projeto de Controle Científico e o Método Proposto. Em azul está representada as respostas do projeto de Controle Científico e em laranja está representada as respostas com relação ao projeto utilizando a Metodologia Proposta. A partir das informações do gráfico, pode-se observar que os entrevistados informaram que as propriedades de Possibilidade de validar o sistema de acordo com o documento

88 CAPÍTULO 4. RESULTADOS 74 Figura 4.12: Gráfico comparativa entre o estudo de caso de Controle Científico e o Método Proposto por meio da aplicação do questionário. de requisitos, Entendimento com precisão para gerar a Estimativa de Prazos e Escopo e compreensão das entregas mais importantes, foram os itens que apresentaram a maior taxa de melhoria de acordo com a opinião geral dos profissionais que responderam ao questionário. A Tabela 4.11 fornece um quadro detalhado com a análise geral das respostas ao questionário. A primeira coluna apresenta o item que está sendo avaliado, a coluna Controle Científico apresenta a média geral das respostas para o projeto de Vendas e Acordos, a coluna Metodologia Proposta apresenta a média geral das respostas para o projeto Blindagem Jurídica SUS e a coluna Melhoria, apresenta o percentual de melhoria que o método proposto de acordo com a opinião dos profissionais que responderam ao questionário. Tabela 4.11: Análise comparativa entre o estudo de caso de Controle Científico e o Método Proposto por meio da aplicação do questionário. A propriedade Possibilidade de validar sistema de acordo com o documento de requi-

89 CAPÍTULO 4. RESULTADOS 75 sitos, teve o maior percentual de melhoria, representando 50% de melhoria com relação ao estudo de caso usado como controle científico. De acordo com a Seção 2.1.1, no item de Testes de Aceite, a possibilidade de validar se o software finalizado atende a todas as necessidades do cliente é uma propriedade essencial para um requisito de software. A propriedade que teve o segundo maior percentual de melhoria foi o Entendimento com precisão para gerar a Estimativa de Prazos. Esta propriedade obteve melhoria de 49% na concepção da equipe. A Seção 2.1.1, no item Especificação de Requisitos de Software, sugere que se este trabalho for bem feito, pode servir de base realista para estimar os custos, riscos e prazos do software, representando uma das propriedades mais importantes do documento de requisitos. Com relação a propriedade Escopo e compreensão das entregas mais importantes, citada na Seção como um elemento crítico de Elicitação de Requisitos, apresentou 33% de melhoria no projeto que aplicou a metodologia proposta. Das outras três propriedades analisadas, a Detecção e resolutividade de conflitos entre requisitos apresentou 24% de melhoria, a Identificação da motivação, Fator Crítico de Sucesso e Objetivos globais do software, apresentou 20% de melhoria e a Sinalização do potencial de requisitos voláteis apresentou 10% de melhoria.

90 CAPÍTULO 4. RESULTADOS Análise dos Resultados Nesta seção, os resultados obtidos com o projeto que utilizou a metodologia proposta são analisados e comparados com o projeto de controle científico para validar as hipóteses: Reduzir as horas trabalhadas para executar cada ponto de função Para validar a hipótese de que a proposta metodológica poderia reduzir as horas trabalhadas para executar cada ponto de função foi feito o estudo de prazo e os resultados foram obtidos na seção de Resultados de Prazo por Análise de Ponto de Função. A Figura 4.13 apresenta o percentual de atraso do estudo de caso que utilizou a metodologia proposta com relação à metodologia de Controle Científico. A metodologia proposta reduziu em 81% o atraso ocorrido no estudo de caso com a metodologia proposta com relação ao controle científico, evidenciando a melhoria na estimativa de horas trabalhadas. Figura 4.13: Gráfico da análise de estimativa de prazos. A metodologia proposta também apresentou desempenho superior no tempo utilizado para executar cada ponto de função, sendo que o projeto de controle utilizou 21,58 horas

91 CAPÍTULO 4. RESULTADOS 77 para executar cada ponto de função e o estudo de caso com a metodologia proposta reduziu para 11,59 horas o tempo utilizado para executar cada ponto de função. O gráfico que está disponível na Figura 4.14 mostra que o tempo gasto para executar cada ponto de função no estudo de caso com a metodologia proposta foi otimizado, utilizando somente 46% do tempo necessário para executar cada ponto de função com relação ao tempo usado no estudo de caso de Controle Científico. Figura 4.14: Gráfico da análise do desempenho por ponto de função. Estes resultados são confirmados e explicados na análise do questionário aplicado na equipe técnica 4.4, de acordo as respostas do questionário apresentado na Tabela 4.11, que exibe a análise comparativa entre Controle Científico e o método proposto, o método proposto apresentou uma melhoria de 49% para o Entendimento com precisão para gerar a estimativa de prazos Reduzir a Ultrapassagem do Orçamento Acordado Para validar a hipótese de que utilizando a metodologia proposta poderia reduzir a ultrapassagem do orçamento acordado, foram desenvolvidos os estudos na Seção 4.1 que trata os Resultados dos Custos. Os resultados apresentados na Tabela com análise comparativa de custo na Figura 4.3, mostrou que o estudo de caso de controle científico havia previsto somente 44% de todo o custo necessário para desenvolver o projeto, enquanto o

92 CAPÍTULO 4. RESULTADOS 78 estudo que utilizou a metodologia proposta previu 83% de todo o custo necessário para o desenvolvimento do projeto. O gráfico contido na Figura 4.15 relaciona essas informações demonstrando que o projeto que utilizou a metodologia proposta apresentou uma melhoria de 69,68% na assertividade do planejamento de custos de todo o projeto. Estes resultados sugerem que a hipótese de que um projeto que utilize a metodologia proposta poderia reduzir a ultrapassagem do orçamento acordado é verdadeira. Figura 4.15: Gráfico da análise do desempenho de planejamento de custo Proporcionar Maior Clareza e Precisão na Especificação das Características Necessárias aos Projetos de TI Para validar a hipótese de que utilizando a metodologia proposta poderia proporcionar maior clareza e precisão na especificação das características necessárias aos projetos de TI, a Seção 4.3 que trata dos Resultados da Análise de Escopo e foi desenvolvida para identificar se a metodologia proposta apresenta melhoria com relação ao escopo do projeto. O gráfico apresentado na Figura 4.16 mostra que houve uma melhora na identificação do escopo de 7%, já que no projeto de Controle Científico o percentual das entregas que foram identificados corretamente foi de 78% e no projeto que utilizou a Metodologia

93 CAPÍTULO 4. RESULTADOS 79 Proposta, este percentual subiu para 85% dos entregáveis identificados corretamente. Figura 4.16: Gráfico da análise do desempenho da identificação do escopo. A principal limitação com relação a esta medição foi que durante o planejamento do projeto do estudo de caso de controle científico, ao gerar a WBS para fazer o mapeamento dos entregáveis optou-se por fazer o escopo mais detalhado, enquanto ao elaborar o planejamento do projeto do estudo de caso com a metodologia proposta, optou-se por fazer uma WBS sem detalhamento, gerando poucas entregas com detalhamentos encapsulados, já que o detalhamento foi introduzido somente ao migrar a WBS para o cronograma que foi feito utilizando o MS Project. Sendo assim, esta análise de escopo sofreu um viés que penalizou o estudo de caso com a metodologia proposta, já que neste estudo foram identificados dois pequenos entregáveis que não haviam sido previstos no início do projeto e estes tiveram a mesma proporção do que os grandes entregáveis que foram identificados no escopo inicial do projeto. Outra limitação importante é que nesta análise, só foram considerados os entregáveis desnecessários ou os que não foram identificados no momento de levantamento de requisitos, desconsiderando os entregáveis que foram identificados corretamente mas que durante o processo de desenvolvimento tiveram muitas características e regras de negócios alteradas gerando retrabalhos. Este é outro fator que penaliza a análise do desempenho da metodologia proposta, já que o projeto de controle científico apresentou muitas falhas desta categoria enquanto o estudo de caso com a metodologia proposta apresentou poucas falhas da mesma categoria.

94 CAPÍTULO 4. RESULTADOS 80 Se essas duas limitações apresentadas forem consideradas, possivelmente os resultados do desempenho para identificação do escopo apresentado para o estudo de caso com a metodologia proposta seria ainda melhor. Para compensar essas limitações, foi aplicado um questionário em toda a equipe envolvida no desenvolvimento do projeto, visando compreender as opiniões desta equipe e identificar se a metodologia proposta forneceu estimativas das características necessárias nos projetos de TI com maior precisão. Para isso, foi considerado os resultados referentes a Seção 4.4, referente aos Resultados do Questionário Aplicado na Equipe Técnica. A pesquisa solicitou notas de 0 a 10, sendo 0 a pior nota e 10 a melhor nota, para as seguintes questões referentes as estimativas das características necessárias aos projetos de TI: Identificação da motivação, Fator Crítico de Sucesso e objetivos globais do software; Escopo e compreensão das entregas mais importantes; Entendimento com precisão para gerar a Estimativa de Prazos; Conhecimento de domínio, identificação dos Stakeholders e regras de negócios; Detecção e resolutividade de conflitos entre requisitos; Sinalização do potencial de requisitos voláteis; Possibilidade de validar sistema de acordo com o documento de requisitos. Os resultados detalhados são apresentados na Seção 4.4. Tabela 4.12: Cálculo da nota média geral do questionário referente às caracteristicas de TI. A Tabela 4.12 apresenta o resultado médio geral das respostas para cada um dos estudos de caso, sendo que o estudo de caso de controle científico apresentou a nota de

95 CAPÍTULO 4. RESULTADOS 81 5,98 enquanto o estudo de caso com a metodologia proposta apresentou a nota média de 7,66, ou seja, a metodologia proposta teve uma melhoria na nota média geral de 28,06%. Estas análises dos resultados sugerem que a hipótese de que utilizar a metodologia proposta poderia Proporcionar maior clareza e precisão na especificação das características necessárias aos projetos de TI é verdadeira.

96 Capítulo 5 Conclusão Este trabalho de pesquisa propôs uma metodologia integrada, fornecendo apoio sistematizado com etapas ordenadas e bem definidas para a especificação de requisitos de software de um projeto, de modo a influenciar positivamente no desempenho do desenvolvimento de software no ambiente de saúde suplementar. Para isso, a solução proposta permitiu integrar o alinhamento de Tecnologia da Informação às necessidades do Negócio. Tal alinhamento é descrito por meio de um processo de engenharia de requisitos que integrou diagramas de Caso de Uso com a notação BPMN, gerando documentação de requisitos com precisão. A implementação dessa proposta metodológica foi conduzida de forma prática no ambiente organizacional de uma empresa operadora de planos privados de assistência à saúde, por meio de estudos de caso. Após toda a análise dos resultados e comparação entre os dados e características dos projetos aplicados, foi possível observar que, este trabalho de pesquisa apresenta uma solução eficiente e prática, proporcionando a redução de falhas no decorrer do projeto, produzindo os resultados esperados, principalmente com relação a redução das horas trabalhadas para executar cada ponto de função e redução na ultrapassagem do orçamento acordado, sem abrir mão da qualidade final do software, que forneceu todos os requisitos necessários ao usuários e clientes do produto. Além disso, a metodologia proposta pode ser estendida a outros domínios do conhe- 82

97 CAPÍTULO 5. CONCLUSÃO 83 cimento, como, por exemplo, a aplicação em outros segmentos. Este fato reforça a importância e mostra a abrangência desta solução, seja para o problema de modelagem de requisitos de software, seja por problemas relacionados a gestão de projetos de software. Atualmente a metodologia proposta neste trabalho de pesquisa encontra-se funcionando na empresa descrita, otimizando recursos e resultados da organização. Conclui-se, portanto, que a metodologia proposta neste trabalho atende aos requisitos identificados na definição de domínio do problema com relação aos resultados esperados. 5.1 Recursos Disponíveis Este trabalho foi realizado em parceria com uma grande organização de Plano Privado de Assistência à Saúde com sede em São Paulo que permitiu acesso livre aos Bancos de Dados e Sistemas de Informações para elaborar o estudo de caso. Além disso, os especialistas da organização auxiliaram na avaliação e interpretação do estudo de caso focado no sistema de saúde suplementar. No desenvolvimento deste projeto foram utilizados os recursos disponíveis na biblioteca e nos Laboratórios do CMCC - Centro de Matemática, Computação e Cognição da Universidade Federal do ABC. 5.2 Trabalhos Futuros Esta pesquisa analisou a comparação entre dois projetos em ambiente controlado, o que torna insuficiente para generalizar. Os resultados mostram o potencial dessa metodologia, que poderá ser objeto de trabalhos futuros, tanto para validação da hipótese, quanto para aperfeiçoar a metodologia. Um possível aperfeiçoamento para a metodologia proposta é a adição da prototipação de processos. Essa proposta tem como foco a fase de elicitação de requisitos e é baseada no desenvolvimento evolutivo, onde o mapeamento e implementação do processo a

98 CAPÍTULO 5. CONCLUSÃO 84 ser automatizado seria desenvolvido utilizando WS-BPEL, definido na Seção 2.2.1, utilizando a característica de padronização para a automação dos processos entre serviços do WS-BPEL para garantir que o processo documentado é adequado. Como recurso adicional, essa solução provê potencial para melhoria contínua dos processos por meio dos metadados, que viabilizam o entendimento e evolução do processo automatizado.

99 Referências Bibliográficas [1] Eduardo Bezerra. Princípios de análise e projeto de sistemas com UML. Elsevier, [2] Dominik Birkmeier, Sebastian Klockner, and Sven Overhage. An empirical comparison of the usability of bpmn and uml activity diagrams for business users. In European Conference on Information Systems., volume 18, [3] G. Blair, G. Coulson, and N. Davies. Standards e platforms for open distributed processing. Technical report, Electronics Communication Engineering Journal., [4] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Addison Wesley, [5] Pierre Bourque and Richard E. (Dick) Fairley. Software engineering body of knowledge (swebok 3.0). Technical report, IEEE Computer Society, Disponível em:< Acesso em: 21 Abr [6] BPMI. Bpmi, business processs management initiative. Technical Report 1, BPMI, Disponível em:< Acesso em: 02 nov [7] BPMN. Bpmn, business processs management notation. Technical Report 1, BPMN, Disponível em:< Acesso em: 02 nov [8] Joseph J. Carr. Requirements engineering and management: the key to designing quality complex systems. In The TQM Journal., volume 12, pages ,

100 REFERÊNCIAS BIBLIOGRÁFICAS 86 [9] CMMI. Cmmi for development, version 1.3. Technical report, CMMI - Carnegie Mellon, Disponível em:< Acesso em: 21 Abr [10] A. Cockburn. Whiting Effective Use-Cases. Addison Wesley, [11] Carlos Alberto Costa. A aplicação da linguagem de modelagem unificada (uml) para o suporte ao projeto de sistemas computacionais dentro de um modelo de referência. Technical report, Departamento de Engenharia Mecânica Universidade de Caxias do Sul (UCS), [12] B. et al. CURTIS. Process modelling. Communications of the ACM, New York, 35(9), [13] Wilson de Pádua Paula Filho. Engenharia de Software - Fundamentos, Métodos e Padrões. LTC, 3 edition, [14] Eston Almança dos Santos. Reduzindo a Volatilidade de Requisitos com o volare. PhD thesis, Escola Politécnica da Universidade de São Paulo, [15] Armin Eberlein and Julio Cesar Sampaio do Prado Leite. Agile requirements definition: A view from requirements engineering. In International Workshop on Time- Constrained Requirements Engineering 2002., [16] Cesar Enoki. Gestão de processos de negócio: uma contribuição para a avalição de soluções de business process management (bpm) sob a ótica da estratégia de operações. Dissertação, Escola Politécnica da Universidade de São Paulo, [17] Thomas Erl. Service-Oriented Architecture: Concepts, Technology and Design.2. Prentice Hall, [18] Thomas Erl. SOA Design Patterns. Prentice Hall, [19] M. Huhns et al. Enterprise information modeling and model integration, in: Proceedings of the first international conference integration modeling techniques. Dissertação, ICEIMT), South Carolina, MIT Press, 1992.

101 REFERÊNCIAS BIBLIOGRÁFICAS 87 [20] Donald F. Ferguson and Marcia Stockton. Enterprise business process management - architecture, technology and standards. Technical Report 1, Business Process Management 4th International Conference BPM Vienna, Austria, [21] OASIS Organization for the Advancement of Structured Information Standards. Web services business process execution language v2.0. Technical Report 1, OASIS Standard -, 11 April Disponível em: wsbpel-v2.0.pdf Acesso em: 18 out [22] Cristina Venera Geambasu. Bpmn vs. uml activity diagram for business process modeling. In Accounting and Management Information Systems., volume 11, pages , [23] Antonio Carlos Gil. Como Elaborar Projetos de Pesquisa. Editora Atlas, [24] Standish Group. Chaos manifesto Technical report, Standish Group International, Disponível em < Acesso em: 05 Abril de [25] Gilleanes T. A. Guedes. UML 2 Uma Abordagem Prà tica. Novatec, [26] Ulises Ibarra Hernandez, Francisco J. Alvarez Rodriguez, and Miguel Vargas Martin. Use processes - modeling requirements based on elements of bpmn and uml use case diagrams. In International Conference on Software Technology and Engineering(ICSTE)., [27] R. High Jr, S. Kinder, and S. Graham. Ibm s soa foundation: An architectural introduction and overview. Technical Report 1, IBM Version 1.0. IBM, White Paper, Disponível em: dw/webservices/ws-soa-whitepaper.pdf Acesso em: 18 out [28] IEEE. Ieee recommended practice for software requirements specifications. Technical report, Software Engineering Standards Committee of the IEEE Computer Society,

102 REFERÊNCIAS BIBLIOGRÁFICAS Disponível em:< Acesso em: 21 Abr [29] Project Management Institute. A guide to the project management body of knowledge (pmbok guide) - fifth edition. Technical report, Project Management Institute, Disponível em: edicao-do-guia-pmbok-em-portugues-esta-disponivel-para-download Acesso em: 28 Maio de [30] ISO/IEC. Information technology-basic reference model of open distributed processing. Technical report, British Standard Implementation of ISO/IEC , [31] ISO/IEC. Information technology-open distributed processing-reference modelenterprise language iso/iec itu-t recommendation x.911. Technical report, ISO/IEC , [32] I. Jackson. Object-Oriented Software Engineering. Addison Wesley, [33] Frederick P. Brooks Jr. No silver bullet - essence and accident in software engineering. In IFIP Tenth World Computing Conference., volume 8, pages , [34] M. B. Juric. A hands-on introduction to bpel. Technical report, Oracle Corporation, Disponível em < Acesso em: 30 nov [35] M.I. Kamata and T. Tamai. How does requirements quality relate to project success or failure? Technical report, Requirements Engineering Conference, [36] Ryan K. L. Ko. A computer scientist s introductory guide to business process management (bpm). Technical Report 4, ACM Crossroads 15, ACM Press, [37] L. Li and H. Miao. An approach to modeling and testing web applications based on use cases. Technical report, ISISE, 2008.

103 REFERÊNCIAS BIBLIOGRÁFICAS 89 [38] Leonardo Lopes and Antonio Vico Manas. Atrasos em projetos de ti causados por falhas na gestão dos stakeholders. In Future Studies Research Journal: Trends and Strategies., volume 5, [39] Mônica A. Lopez-Campos, Adolfo Crespo Marquez, and Juan F. Gimez Fernandez. Modelling using uml and bpmn the integration of open reliability, maintenance and condition monitoring management systems: An application in an electric transformer system. In Computers in Industry., volume 64, pages , [40] D. Lubke, K. Schneider, and M. Weidlich. Visualizing use case sets as bpmn processes. Technical report, Requirements Engineering Visualization, [41] Fabio Perez Marzullo. Soa Na Prática. Inovando seu negócio por meio de soluções orientadas a serviço. Novatec, [42] OSIMM The Open Group Service Integration Maturity Model. The open group - the open group soa working group. service-oriented architecture (soa). document: W074. Technical Report 1, OASIS Standard -, Disponível em: 1_ _Review.doc Acesso em: 17 out [43] Oana Nicolae, Mirel Cosulschi, Adrian Giurca, and Gerd Wagner. Towards a bpmn semantics using uml models. Technical report, Springer-Verlag Berlin Heidelberg, [44] Luzia Nomura. Definição e estabelecimento de processos de fábrica de software em uma organização de ti do setor público. Dissertação, Escola Politécnica da Universidade de São Paulo, [45] Alberto Yoshinobu Onoe. Proposta de governança soa utilizando capacidades dinâmicas: uma aplicação em centro de comunicação digital universitário. Tese, Escola Politécnica da Universidade de São Paulo, [46] David Patterson. Engineering Long-Lasting Software: Na Agile Approach Using SaaS and Cloud Computing. Alpha Edition, 2012.

104 REFERÊNCIAS BIBLIOGRÁFICAS 90 [47] Shari Lawrence Pfleeger. Engenharia de Software - Teoria e Prática. Prentice Hall, 2 edition, [48] Dan Pilone and Neil Pitman. UML 2 Rà pido E Prà tico Guia De ReferÃa ncia. Alta Books, [49] R. S. Pressman. Software engineeering: a practioner s approach. McGraw-Hill, 5. ed. edition, [50] Roger S. Pressman. Engenharia de Software: uma abordagem profissional. Mc Graw Hill e Bookman, [51] Marco Aurélio Graciotto Silva. Uma ferramenta web colaborativa para apoiar a engenharia de requisitos em software livre. Master s thesis, Escola Politécnica da Universidade de São Paulo - S ao Carlos, [52] Ian Sommerville. Engenharia de Software. Addison Wesley, 6 edition, [53] Ian Sommerville. Engenharia de Software. Addison Wesley, 8 edition, [54] Carlos Eduardo Vazquez, Guilherme Siqueira Simões, and Renato Machado Albert. Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software. Editora Érica, [55] F. B. Vernadat. Enterprise Modeling and Integration: Principles and Applications. London: Chapman e Hall, [56] Stephen A. White. Bpmn, business processs management notation. Technical Report 1, IBM Corporation, Disponível em:< Acesso em: 09 nov [57] Luiz Paulo Rocha Yanai. Mislp: Método de identificação de serviços baseado em linguagem de padrões. Dissertação, Escola Politécnica da Universidade de São Paulo, 2010.

105 Índice Remissivo (5) Especificação de Requisitos, 18 (6) Validação dos Requisitos, 19 Análise Formal, 17 Arquitetura Orientada a Serviços, 24 Atores do Processo, 12 BPD, 24 BPM, 23 BPMN, 23 Business Process Management Initiative, 23 Business-to-business, 96 Caso de Uso, 29 Classificação de Requisitos, 16 CMCC, 83 Documentação do Caso de Uso, 31 Documentos de Definição do Sistema, 18 Elicitação de Requisitos, 12 Engenharia de Requisitos, 8 Especificação de Requisitos de Software, 18 Especificação Textual do Caso de Uso, 31 Evento End, 94 Intermediate, 94 Start, 94 Fontes de Requisitos, 13 Lane Lane, 96 Pool, 96 Modelagem Conceitual, 16 Modelos de Processo, 11 Negociação de Requisitos, 17 Objetos de Conexão, 94 Associação, 95 Fluxo de mensagem, 95 Fluxo de sequência, 94 Objetos de Fluxo, 93 Atividade, 94 Evento, 93 Gateway, 94 OMG, 23 Prototipação, 19, 41 Qualidade e Melhoria de Processos, 12 Requisitos de Propriedades Emergentes, 10 Requisitos de Software, 11 Requisitos do Sistema, 11 Requisitos Funcionais, 10 91

106 ÍNDICE REMISSIVO 92 Requisitos Não Funcionais, 10 Revisão de Requisitos, 19 RM-ODP, 21 SOA, 25 Suporte de Processos e Gestão, 12 Swimlanes, 95 Técnicas de Elicitação, 14 Testes de Aceite, 19 UML, 29 WS-BPEL, 24

107 Capítulo 6 Apêndices 6.1 Especificação BPMN 1.0. Esta seção descreve os princípios básicos da notação BPMN, ou seja, os tipos de objetos gráficos que compõem a notação e como eles funcionam para compor um Business Process Diagram. De acordo com White [56], o BPD é composto por um conjunto simples de elementos gráficos que permitem o desenvolvimento de diagramas familiares para a maioria dos analistas de negócios. Os elementos tem formas gráficas bem definidas que são familiares para a maioria dos modeladores. Por exemplo, as atividades são representadas por retângulos, já as decisões são representadas por diamantes. O Desenvolvimento do BPMN tem ênfase em comportar mecanismos simples para criação de modelos de processos de trabalho enquanto paralelamente é capaz de lidar com a complexidade inerente aos processos de negócio. As quatro categorias básicas de elementos são as seguintes: Objetos de Fluxo Evento Os objetos de fluxo representam uma ação que ocorre durante um processo do negó- 93

108 CAPÍTULO 6. APÊNDICES 94 Figura 6.1: Eventos: Início, Intermediário e Fim. cio. Tais eventos afetam o fluxo do processo e geralmente têm uma causa (trigger) ou um impacto (result). A Figura 6.1, descreve os três tipos de eventos que afetam o fluxo: início, intermediário e final (do inglês Start, Intermediate, e End ). Atividade Figura 6.2: Evento: Atividade. Uma atividade é representada por um retângulo com os cantos arredondados (Figura 6.2), e é um termo genérico para um trabalho executado, os tipos de atividades podem ser compostas ou atômicas. As compostas são tratadas como sub-processo e as atômicas como tarefas. O sub-processo pode ser decomposto e é distinguido por uma pequeno sinal de adição no centro inferior da figura. Gateway Figura 6.3: Evento: Gateway. O Gateway é representado pela Figura 6.3 e é usado para controlar a divergência ou a convergência de um fluxo determinando decisões tradicionais, como juntar ou dividir trajetos do processo. Objetos de Conexão

109 CAPÍTULO 6. APÊNDICES 95 Fluxo de seqüência Figura 6.4: Evento: Objetos de Conexão: Fluxo de sequência. Um fluxo de sequência é representada por uma linha com uma seta sólida (Figura 6.4) e é usada para estabelecer a ordem sequencial que as atividades serão executadas em um processo. Fluxo de mensagem Figura 6.5: Objetos de Conexão: Fluxo de Mensagem. O fluxo de mensagem é representada por uma linha tracejada com uma seta (veja a Figura 6.5). Esta figura é usada para mostrar o fluxo de mensagens enviadas ou recebidas entre dois participantes em processos separados (entidades empresariais ou funções de negócio). No BPMN, dois Pools separados no diagrama representam os dois participantes. Associação Figura 6.6: Objetos de Conexão: Fluxo de Associação. A associação é representada por uma seta com linha pontilhada (Figura 6.6) e é usada para associar dados, texto e outros artefatos com os objetos de fluxo. As associações são usadas para mostrar as entradas e as saídas das atividades. Swimlanes Muitas metodologias de modelagem de processos utilizam o conceito de raias como mecanismo para organizar atividades em categorias visuais separadas, a fim de ilustrar

110 CAPÍTULO 6. APÊNDICES 96 diferentes capacidades funcionais ou responsabilidades. Os dois tipos principais de raias que tem suporte em BPMN são: Pool Figura 6.7: Swimlanes: Pool. Um pool tem a função de representar um participante de um processo atuando como um container gráfico para dividir um conjunto de atividades de outros pools (Figura 6.7)), geralmente no contexto de situações de Business-to-business 1. Figura 6.8: Swimlanes: Exemplo BPD usando Pool: Paciente - Consultório Médico. Adaptação de White [56] Um exemplo de processo utilizando pool entre Paciente e o Consultório Médico é exibido na Figura Business-to-business é a denominação do comércio estabelecido entre empresas através da Internet ou através da utilização de redes privadas partilhadas entre duas empresas, substituindo os processos físicos que envolvem as transacções comerciais.

111 CAPÍTULO 6. APÊNDICES 97 Lane Figura 6.9: Swimlanes: Lane. Uma lane é uma subdivisão dentro de um pool usado para organizar e categorizar as atividades (Figura 6.9). 6.2 Apêndice - Estudo de Caso do Projeto de Vendas Apêndice - Documento de Requisitos do Estudo de Caso do Projeto de Vendas. Neste estudo de caso a metodologia proposta não foi aplicada, ele serviu de Controle Científico. Este projeto foi desenvolvido utilizando BPMN para mapear os processos do negócio e gerando um documento de requisitos descritivo com prototipação das telas na fase de análise de requisitos.

112 Visão e Escopo Especificação Funcional do módulo de vendas. Projeto: Nº 001 Versão

113 Histórico de Alterações Data Versão Descrição Autor 11/06/ Documento Inicial Paulo Cesar Sumário 1. REQUISITOS ESPECÍFICOS FINALIDADE MÓDULO VENDAS PAINEL VENDAS VENDA Triagem Pré-cadastro Ações de tela: CADASTRO / EDIÇÃO DE CLIENTE Cadastrar novo cliente Editar/Finalizar venda de cliente já cadastrado Campos: Fases: Validação relacionada ao preenchimento de contrato Itinerário Perfil Cliente Seleciona dono da venda Conferência da Proposta Impressão Aprovação de Atendimento Transferido *Exemplo: Pode ser usada para transferir venda para o vendedor que recebe a transferência do cliente possa bater a meta do mês. (Geralmente só autorizado até 3 transferências por vendedor.) Assinatura Entrega Contrato / Recolher documentos APROVAÇÃO Conferência e Aprovação da supervisão de contratos Aprovação CPD Contabilizar Comissão venda/meta Contador MÓDULO ACORDO PROCESSO DE GERAR LISTA INADIMPLENTE/CANCELADO AUTOMATICAMENTE SOLICITAR INADIMPLENTE/CANCELADO PROTÓTIPO DA TELA: Painel de Acordos Lista de Tarefas Painel de Acordos - Triagem Painel de Acordos - Dados do Cliente Painel de Acordos Histórico de negociações: Painel de Acordos - Parcelas CONTABILIZAR COMISSÃO ACORDO/META CONTADOR MÓDULO PAINEL DE CONTROLE Parâmetro de Comissão: Configuração de Parâmetro dos documentos necessários para compra do plano de saúde: Parâmetro de Descontos Parâmetro Bônus por Indicação Parâmetro de cobrança de inadimplente (Vendas por telefone)

114 4.1.6 Parâmetro Tolerância Não Atendeu RELATÓRIOS GERENCIAIS Bordero Redução Interna Propostas Fechadas Relatório Fechamento RELATÓRIO VENDAS PLATAFORMA (CORRETOR EXTERNOS) Plataformas Processo: PAPÉIS E RESPONSABILIDADES USUÁRIOS MODELO DE EQUIPE CRONOGRAMA INICIAL

115 Especificação de Requisitos de Software 1. Requisitos Específicos 1.1Sumario Executivo O sistema de Blindagem Jurídica SUS trata-se de uma aplicação para proteger a organização Prevent Senior de cobranças indevidas que são feitas pela ANS. Historicamente tais cobranças alcançam um valor médio de 2,8 milhões por trimestre que tem sido realizada de forma retroativa gerando tais cobranças mensais. Tal idéia surgiu da oportunidade identificada de desenvolver um sistema que atue como intermediário no processo de levantamento de dados e requisitos necessários para que o jurídico possa atuar de forma eficiente em duas frentes: Identificar e Impugnar cobranças indevidas por utilização do SUS. Atualmente sem o sistema, o setor jurídico da Prevent Senior tem tido um retorno satisfatório de cerca de R$ ,00 mensais em suas defesas contra cobranças indevidas, isso representa cerca de 28,57% de defesa. Há indícios de que tal acurácia pode ser alavancada de forma expressiva com um mapeamento e otimização de processos e um sistema de informação que automatize atividades burocráticas tornando o processo mais eficiente. Espera-se que com essa implementação sistêmica a organização tenha potencial para aumentar o percentual de impugnações para cerca 57,14% de defesa, com um ROI estimado em R$ ,00. Para sustentar essa hipótese será feito um trabalho multidisciplinar com os setores de qualidade e planejamento com avaliação quantitativa baseada em 6Sigma. 1.2 Custo Estimado 1.3Finalidade Esse artefato consiste em um pacote contendo requisitos do modelo de casos de uso, especificações suplementares aplicáveis e outras informações de suporte com objetivo de definir o escopo do projeto. Também será descrito o comportamento externo do aplicativo assim como seus requisitos não funcionais, restrições de design e outros fatores necessários para fornecer uma visão completa e abrangente dos requisitos do software. 101

116 2. Módulo Vendas 2.1 Painel Vendas Este painel permite que o vendedor tenha acesso a: -Venda: Permite seguir todo o fluxo normal de vendas, editar, etc. -Acordo: permite realizar todo o fluxo de acordo com cliente inadimplente ou com contrato cancelado. -Configurações: Permite configurar substitutos, pausar atividades, e avisar que hoje não estou disponível como suplente. -Agenda: Permite agendar retorno, atendimento, lembrete, etc. -Alerta: Gera alertas (1X dia) na tela do consultor de venda de acordo com agenda ou eventos específicos como: um dia antes de enviar documento para cliente para lembrar, quando outro vendedor transfere um cliente para ser atendido o dono da conta recebe um aviso, um dia depois de um acordo (caso o cliente não tenha pago o boleto conforme combinado) aparecer um aviso na tela do consultor de vendas, etc. > Possibilitar desativar o alerta -Lista de tarefas: Exibe todas as tarefas/atividades agendadas ou sugeridas que exigem alguma ação do consultor de vendas. -Central de Relatórios: Relatórios relacionados a venda. >Relatório de vendas: possibilita gerar relatório por vendedor logado com os seguintes parâmetros: Data De/Até, Tipo de operação (venda, acordo). >Gerar boleto Manualmente: Permite gerar boleto para clientes que não tem acesso à internet. -Transferência(doar): Permite doar venda(comissão) para outro vendedor. 2.2 Venda 2.2.1Triagem Pré-cadastro Ator: consultor de vendas Edson Nascimento de Souza Consultores de vendas: Edson Nascimento de Souza 1151 / Paulo 1153/ Cilene Lozano, ramal 1185/ Fernando Luiz de Oliveira, ramal: comercial.vendas@preventsenior.com.br, Quézia Rocha 1042, Andrea 1034, Eliane 1033 Atividade: 102

117 No momento do primeiro contato do cliente com o consultor de vendas a primeira atividade será identificar quem é o consultor responsável, se o responsável for outro vendedor o atendimento será redirecionado/transferido para o consultor de vendas responsável Ações de tela: Buscar cliente por um campo único que procura nos seguintes campos de forma dinâmica: CPF Nome Telefone Endereço Data de nascimento Ações: -Buscar -Novo -Editar -Transferir -Excluir(lógica) -Atendimento por internet (enviar link por ) Questionário Prevent Permite identificar como o cliente chegou até a Prevent Senior para determinar quais mídias e estratégias estão sendo mais eficientes. Os campos da pesquisa será igual ao histórico de vendas, localizado na parte inferior do formulário Transferir Atendimento Possibilita que o corretor de vendas faça a transferência de atendimento para outro corretor (mantendo histórico da operação) e preenchimento de campo de comentário descritivo. Após atendimento ser feito essa atividade deve passar por aprovação da supervisora. Essa funcionalidade poderá ser usada quando o consultor de vendas que é o responsável por um cliente não pode fazer o atendimento, então outro vendedor precisa assumir essa responsabilidade. Outra função para essa tela é quando precisa bater meta. 2.3 Cadastro / Edição de Cliente Ator: consultor de vendas Edson Nascimento de Souza 103

118 Telefone: Cadastrar novo cliente Se o cliente não for encontrado no sistema o mesmo poderá ser cadastrado e ficará vinculado ao consultor de vendas que será o responsável e terá prioridade nos atendimentos futuros deste cliente. Ações: -Salvar. -Reagendar. -Cancelar Editar/Finalizar venda de cliente já cadastrado O consultor de vendas pode alterar o cliente sob sua responsabilidade ou solicitar uma transferência de cliente (exige aprovação). Ações na tela: -Editar -Transferir. - Cancelar. (cancelar e salvar motivo). OBS: *No termo de opção tem que usar a mesma cidade usada no campo endereço residencial(acima). *Sistema sempre gerar a data do próximo dia útil ou opção de alterar data da visita/fechamento. *Possibilitar que o vendedor coloque data de vencimento do boleto(5,10,15,20,25,30)> Somente libera até 5 dias (para frente além da data de assinatura).> Na geração do boleto a data será alterado. * Quando cheque for pré-datado, permitir que a data do contrato seja a mesma data do cheque no período de até 7 dias (no futuro). *Possibilitar que haja troca de vendedor na venda realizada (relacionada para bater meta), geralmente até 3 vendas pode ser feito isso para bater meta. > Vai para tela de aprovação de transferência de venda. 104

119 2.3.3 Campos: - Ficha de histórico de vendas - Portabilidade (Intermédica/ 01/08/2008)> Se faltar documentação> preencher protocolo(fichinha) que substitui dados de adesão/boletos "de solicitação de redução de portabilidade" e anexa no histórico de vendas> para Eliete confirmar essa fichinha. - Dados da declaração de saúde ANS. Ação: -Agenda uma data para levar a documentação - Possibilitar upload de arquivos: cópia do rg, cpf, comprovante de residência, carteirinha do sus. E se houver portabilidade (Plano de carência): 3 últimos boletos do plano anterior e carteirinha Fases: O cliente passa pelas seguintes fases: 1) Pré-cadastro: Só tem algumas informações importantes do cliente. 2) Proposta: (Validar e confirma proposta) Valida todos os campos obrigatórios. 3) (Conferencia supervisor) Aprovação da proposta/contrato: Cliente tem aprovação proposta 4) Finalizado: Após conferencia do cpd e pagamento efetuado com sucesso: gera matricula, carteirinha e boleto e cliente passa a ser tratado como beneficiário Validação relacionada ao preenchimento de contrato Ator: consultor de vendas Edson Nascimento de Souza comercial.vendas@preventsenior.com.br Telefone: Página 1 - Os dados da venda Proposta de admissão No momento do preenchimento do contrato: NÃO É OBRIGATÓRIO: Nome da mãe -nome do responsável(todos campos relacionados ao responsável: grau de parentesco etc) -Endereço de correspondência (todos campos relacionados) -Cartão nacional de Saúde(CNS/SUS) *PIS não usa * (campo responsável) não usa atualmente e não será obrigatório. 105

120 APÓS OS ESCLARECIMENTOS A RESPEITO DOS PLANOS ABAIXO ESCOLHIDO: *(PRECISA OBRIGAR A EXCOLHER UM DOS CHECKBOX(um dos 3 itens)). *O campo redução de carência não é obrigatório (somente se tiver apresentar a folha 2 do contrato) *Na área do corretor (todos campos são obrigatório) e o restante da primeira página é tudo obrigatório *Ao preencher a data inicial, todas as datas seguintes serão iguais a esta Página 2 Termo aditivo de redução de carências Se tiver redução de carência preencher tudo, senão desconsiderar todos campos Página 3 Termo - explicação do que é a declaração de saúde. Tudo obrigatório Página 4 - Declaração de saúde Não permitir que nenhuma desses radio fiquem em branco, validar sim ou não de cada um. Se tiver um sim, obrigar a especificação da doença preexistente. Assinatura obrigatório Obs: Se colocar algum SIM, obrigar o preenchimento da página 5 TERMO DE OPÇÃO (SOMENTE NOS CASOS DE DOENÇAS PREEXISTENTES) Página 5 - declaração de que respondeu corretamente ao contrato Página 5A - Declaração de que respondeu corretamente ao contrato Local e data preenchido automaticamente Página 5B Termo de opção (somente exige preencher o termo de opção (Agravo e cobertura parcial) quando tem alguma declaração de doença pré-existente na página 4. Preencher tudo é obrigatório 106

121 2.3.6 Itinerário Ator: consultor de vendas Edson Nascimento de Souza Telefone: 1151 Consultor de vendas prepara o itinerário do motoboy com dados da entrega, adiciona região e pontos de referência (usar formulário atual de itinerário de exemplo). Possibilidade de colocar região de entrega: norte, sul, leste, oeste, centro e fora de perímetro com campo para observação. Um exemplo seria: fora de perímetro - São Bernardo do Campo. Quando for fazer a impressão do itinerário: deve aparecer os campos de checkbox manual para o cliente assinalar os documentos que está entregando e assinar Perfil Cliente Um campo simples que permite ao vendedor selecionar o tipo de perfil do cliente. Essa funcionalidade serve para que os próximos atendimentos sejam feitos de acordo com o perfil do cliente e também para identificar a evolução do cliente em seu ciclo de vida dentro da empresa Seleciona dono da venda Permite ao vendedor que finaliza a venda escolher quem será beneficiado com a comissão da venda que ele acaba de fazer. Ele pode assumir a comissão ou devolver a comissão para o vendedor que havia iniciado a venda, de acordo com seu julgamento Conferência da Proposta Ator: consultor de vendas Edson Nascimento de Souza comercial.vendas@preventsenior.com.br Telefone: 1151 Essa tela deve exibir todas os campos para que o consultor de vendas possa conferir os dados: principalmente as datas e dados do beneficiário, se algo estiver incorreto a tela permite correção e aprovação Impressão Ator: Auxiliar Vendas Natiele Carvalho Ramal:

122 Tela lista todas as impressões conferidas e previstas para o dia seguinte(por padrão). A tela também permite que outra data seja colocada como parâmetro para filtrar e também possibilita imprimir somente alguns documentos por checkbox. *Por região: Interessante organizar impressão por região de entrega (norte, sul, leste, oeste, centro e fora de perímetro Aprovação de Atendimento Transferido. Listagem de todas as solicitações de transferência de comissão(doar) para a sua conta, a lista permite aprovar (transfere para novo vendedor) ou reprovar (mantém a comissão para o vendedor original como responsável pelo cliente) *Exemplo: Pode ser usada para transferir venda para o vendedor que recebe a transferência do cliente possa bater a meta do mês. (Geralmente só autorizado até 3 transferências por vendedor.) Assinatura Ator: consultor de vendas Edson Nascimento de Souza comercial.vendas@preventsenior.com.br Telefone: 1151 Neste processo manual o auxiliar de impressão recolhe assinatura de todos corretores para todas as vias dos contratos, aditivos, etc Entrega Contrato / Recolher documentos Ator: Transportadora Marquinhos Gestor dos motoboys Entrega de documentos: O Motoboy vai até a o cliente para entregar documentos e solicitar assinatura do contrato, cópia do rg, cpf, comprovante de residência, carteirinha do sus, pagamento(dinheiro/cheque). E se plano de carência: 3 últimos boletos do plano anterior e carteirinha do plano anterior. (se não tiver carteirinha, solicita a carta de permanência. 2.4 Aprovação Ator: Supervisor de vendas 108

123 Eliete Telefone: 1046 As aprovações são feitas pelo supervisor/auxiliar de vendas Conferência e Aprovação da supervisão de contratos. Uma listagem com todos documentos que foram impressos. Funcionalidades: Detalhes: Exibe todas informações em uma tela de edição equivalente a tela usada pelo vendedor. *(Pode ser interessante reaproveitar tela). Aprovar: Modifica o status do cliente contrato aprovado e segue o de aprovação do CPD. Desaprovar: abre nova tela que permitirá que o supervisor informe a página e os itens que estão incorretos, para cada item incorreto será possível colocar uma observação descritiva do problema. Conferir Bônus: permite ver, editar, conferir e enviar alerta para vendedor adicionar dados para efetivar o bônus(nome, Matricula ou Registro Funcionário e telefone) Reprovar: a) Se for por causa de contrato incorreto permite informar o local e motivo do erro b) Se for problemas de documentação pendente permite escolher os documentos que estão faltando e aprovar. Neste caso o processo segue para o CPD e em paralelo para o auxiliar de vendas para providenciar estas documentações que serão entregues diretamente para o CPD Aprovação CPD Ator: Cadastramento Zuleide Telefone: 9042 A tela igual a de conferência e aprovação da supervisão de contratos mas que apresenta somente os contratos que já foram aprovados pela supervisão de contratos e permite que ao aprovador do CPD. Funcionalidades: Detalhes/Editar: Exibe todas informações em uma tela de edição equivalente a tela usada pelo vendedor. *(Pode ser interessante reaproveitar tela). Aprovar: Modifica o status do cliente contrato aprovado e faz a integração com o sistema Fácil insere os dados financeiros no módulo da fácil e também alimente o cadastro do fácil mantendo sincronismo das informações. Atualmente a tela de cadastro relacionada a essa integração pode ser acessada pela Zuleide (Ramal 9042) pelo fácil no seguinte caminho: Modulo de cadastro> Cadastro de usuário(321)> 109

124 2.4.3 Contabilizar Comissão venda/meta Contador Ator: Processo Automático Após contrato ser assinado e passar por todas fases de validação o sistema deve computar uma venda (enfermaria/apartamento/acordo). *no caso da venda ser feita dentro do período de repique ela gera uma comissão no valor de R$0,00 mas conta na soma total de itens vendidos para bater meta. 3.Módulo acordo 3.1 Processo de gerar lista inadimplente/cancelado automaticamente. Ator: CPD Zuleide Telefone: 9042 Este módulo deve gerar uma listagem de inadimplentes/cancelado pelo webservice(integração). O webservice (*Atualmente essa lista é gerado pelo Fácil no seguinte caminho modulo relatório> inadimplentes (35)) deve fornecer a possiblidade de listar com os seguintes parâmetros: Status: inadimplente ou cancelado. Dias: (Parâmetro) quantidade de dias de atraso/padrão (de acordo com painel de controle). Sinistralidade: Indicador do tipo de cliente (relacionado ao custo do cliente para empresa), por porcentagem de sinistralidade? Com isso no futuro haverá a possibilidade de filtrar clientes que usam pouco o plano e ou pagam em dia e geram maior lucro e priorizar as ligações de recuperação de credito para eles. Essa listagem deve vir ordenada da seguinte forma: 1) Ordenar por data de inadimplência (do mais antigo para o mais novo). 2) Merge: Deve-se retirar dessa lista todos os clientes que já estiverem dentro do período de atendimento (com data de pagamento agendada ou atendimento reagendado) 3) Pool: Forma-se um pool e reserva os repiques para serem atendidos pelos vendedores que não estiverem pausados. 3.2 Solicitar inadimplente/cancelado Ator: consultor de vendas Edson Nascimento de Souza comercial.vendas@preventsenior.com.br 110

125 Telefone: 1151 Tela: Inicialmente exibe um botão para solicitar próximo inadimplente. Ao clicar neste botão a tela é populada com todas informações relacionadas ao cliente e as parcelas pendentes. Esta tela permite visualizar dados do cliente e dados do pagamentos/acordo pendente de pagamento: Permite que o consultor de vendas liste todos os clientes que agendaram pagamento(acordo) para o dia anterior e ainda não efetuaram o pagamento, para que ele possa entrar em contato e reagendar o acordo. Campos usuário: Nome, contrato, DT Cliente, Telefone, Campos Tabela: Código da parcela Valor Vencimento Original Data Acordo (previsão pagamento) Data Negociação (só exibe) Status (pago/ não pago) Vendedor responsável Funções: imprimir/enviar Observação relacionada ao atendimento Funcionalidade: Permite agendar múltiplas datas para pagamento, ex: o primeiro para dia 20 e o segundo para o dia 05. Botão Reagendar atendimento : usado quando o Beneficiário não atendeu, ou não está disponível no momento. Exibir campo para descrever o motivo. (Mantém o cliente pausado por mais X dias) Botão Contato Impossível (cliente não mora mais aqui, telefone errado, etc). -vendedor pode reagendar atendimento. Todo atendimento deve gerar um histórico de negociação. *quando for impossível por X vezes considerar o cliente como sem contato? Se for cancelado: A mesma tela também pode ser usada para recuperar cancelamento de contrato conforme item abaixo: 111

126 Recuperar Cancelamento de contrato e Recompra de plano (Sem Carência) Quando não é possível efetuar o pagamento de todas as dívidas, ainda é possível após o cancelamento do contrato que seja feita uma nova venda para o cliente com a redução de carência (aproveitando o plano anterior da própria Prevent Senior) e fazendo uma nova venda do plano, aproveitando todos dados que já estão cadastrados no sistema. Quando for cancelar e refazer novo contrato zerando a dívida: Campo para justificar o motivo da liberação e Quando for para refazer um contrato cancelado (eliminar dívidas) do cliente> solicitar cancelamento do contrato atual e já vai para tela de contrato novo. > (neste caso não é tratado como acordo e sim como vendas para contabilizar comissão). 3.3 Protótipo da tela: 112

127 3.3.1 Painel de Acordos Lista de Tarefas Painel de Acordos Triagem 113

128 3.3.3 Painel de Acordos - Dados do Cliente Painel de Acordos Histórico de negociações: 114

129 3.3.5 Painel de Acordos - Parcelas 3.4 Contabilizar Comissão Acordo/Meta Contador Ator: Processo Automático Após acordo ser feito com sucesso e o beneficiário efetuar o pagamento de todas dívidas o sistema deve computar um acordo. *no caso do acordo ser feito dentro do período de repique ele gera uma comissão no valor de R$0,00 mas conta na soma total para bater meta. 4. Módulo Painel de controle Parâmetro de Comissão: Ator: Supervisor de vendas /Gerente? Eliete / Flavia? 115

130 Telefone: 1046 A comissão é paga de acordo com a quantidade da somatória de planos de enfermaria + apartamentos + acordos vendidos no período de um mês. Esmeralda Enfermaria De 01 a 15 planos 24 Por Proposta De 16 a 30 planos 29 Por Proposta De 31 a 34 planos 34 Por Proposta Acima de 34 planos 45 Por Proposta Acima de 44 planos 55 Por Proposta Acima de 54 planos 65 Por Proposta Esmeralda Apartamento De 01 a 15 planos 27 Por Proposta De 16 a 30 planos 32 Por Proposta De 31 a 34 planos 37 Por Proposta Acima de 34 planos 45 Por Proposta Acima de 44 planos 55 Por Proposta Acima de 54 planos 65 Por Proposta Acordos De 01 a 15 planos 10 Por Proposta De 16 a 30 planos 15 Por Proposta De 31 a 34 planos 20 Por Proposta Acima de 34 planos 45 Por Proposta Acima de 44 planos 55 Por Proposta Acima de 54 planos 65 Por Proposta *Importante: Quando uma venda é feita para um cliente existe o repique que tem a duração de 90 dias. Durante este período, se o vendedor efetuar uma nova venda para o mesmo cliente contará como venda mas a comissão por essa venda será 0. **Mesmo oferecendo desconto a comissão do consultor de vendas continua inalterada. 116

131 4.1.2 Configuração de Parâmetro dos documentos necessários para compra do plano de saúde: Valor original: Assinatura do contrato, cópia do rg, cpf, comprovante de residência, carteirinha do sus. E se houver portabilidade (Plano de carência): 3 últimos boletos do plano anterior e carteirinha Parâmetro de Descontos Para clientes externos: -varia de 10% ao máximo de 50% > só na primeira parcela. -No contrato coloca o valor total da mensalidade e o desconto (somente para primeira parcela) Para Clientes Internos(funcionários). -Desconto de 100% primeira parcela. : Processo: Envia para Adelaide(DP) para confirmação de que o usuário é um funcionário com os seguintes dados: -Nome completo, rg, cpf Parâmetro Bônus por Indicação Quando funcionário ou beneficiário indica um novo cliente, ele recebe bonificação que atualmente tem o valor de R$50,00 (ficha de bônus funcionários) Parâmetro de cobrança de inadimplente (Vendas por telefone) Ligação 1: Atualmente a cobrança de inadimplente é feita pelo setor de vendas após 15 dias Ligação 2: Se ainda não pagou é gerada nova lista de inadimplente após 35 dias de atraso no pagamento Carta de cobrança Gera automático pelo fácil: atualmente a cobrança por carta é feita após 45 dias de atraso: gera uma carta oficial de inadimplência com prazo de 10 dias corridos após o recebimento para quitar todo o débito, se não quitar o plano será automaticamente cancelado. (Atualmente com 61 dias de atraso, independente de voltar o AR(Aviso de Recebimento) Parâmetro Tolerância Não Atendeu Na tela de atendimento de inadimplente, quando o vendedor tenta atender um beneficiário inadimplente e por algum motivo não consegue falar com o cliente e clica no botão Beneficiário não atendeu o sistema oferece uma tolerância de X dias até que o vendedor tente agendar uma nova data de acordo para pagamento. (X é o valor deste parâmetro.) 117

132 5.Relatórios 5.1Gerenciais Atualmente existem 3 relatórios que precisam ser gerados de acordo com os modelos em anexo dentro do diretório \Documentos\relatórios: Bordero Ator: Gerente Vendas Flavia Modelo Exemplo: -Gera relatório Bordero (1PlanilhaBordero ) Redução Interna Ator: CPD Zuleide Telefone: 9042 Modelo Exemplo: - redução interna (2Reduções Internas- 2013) Propostas Fechadas Ator: CPD Zuleide Telefone: 9042 Modelo Exemplo: -Propostas fechadas (3Relatório de Propostas Fechadas 2013) Relatório Fechamento Ator: Gerente Vendas (Checar se relatório é importante.) Flávia Parâmetros: período de fechamento (Mês/ ano) 118

133 Resultado: relatório ordenado por vendedor com todas vendas e acordos sumarizados por totais de venda por enfermaria, apartamento, acordos e total geral. 5.2 Relatório Vendas Este relatório pode trazer informações relacionadas as vendas do vendedor sumarizadas por tipo de venda (enfermaria, apartamento e acordo). Parâmetros: Período De/Até, Tipo(Tudo, vendas, acordos) 6.Plataforma (corretor externos) Contato:Gabriela(apoia as plataformas) ramal 1047/comercial.suporte@preventsenior.com.br, junto com a Flavia(gerente) Plataformas Trabalha com as seguintes plataformas: Novo Ciclo(código 59), Neovita(código 05), Qualiplan(código 62), melhor opção(best Option) (código 61), Senior Cor(Santos)(código 56), Senior Cor(Santo André) (código 56) * O código que internamente é tratado como 01(prevent), quando é feito pelos parceiros, utiliza os códigos acima Processo: Plataforma faz pos venda> envia para analise/conferência da prevent(geovana e Gislene)> CPD Para cadastro> CPD Envia boleto/carteirinha. Corretor de uma plataforma efetua a venda> envia toda documentação e contratos para a plataforma> cadastra e faz pós venda(confere/confirmar Dados) *Se for sem redução de carência > Após a data de adesão, a plataforma tem até 5 dias úteis para entregar o contrato e documentação para a prevent senior. Se falhar: é considerada uma proposta administrativa.(corretor não recebe comissão) *Se for com compra de carência > Após a data de adesão, a plataforma tem até 10 dias corridos para entregar o contrato e documentação para a prevent senior. Se falhar: é considerada uma proposta administrativa.(corretor não recebe comissão) *(importante)as plataformas tem até dia dias úteis para a entrega de toda documentação/contrato. Se falhar: será necessário refazer o contrato com data do próximo mês, ou será uma proposta administrativa e o corretor não recebe a comissão dela. 119

134 Quando a proposta chega na prevent> é feita uma conferência interna (Geovana ou Gislene do CPD). Se for uma proposta recusada ela devolve para plataforma. * O Sr. Fernando ou Dr. Eduardo(Presidentes)> Checar de que forma haverá a integração: corretor tem acesso? Ou somente as plataformas? 7.Papéis e responsabilidades Esta seção apresenta os participantes iniciais do projeto. 7.1 Usuários Nome Cargo Contato Edson Nascimento de Souza Consultor Vendas 1151 Paulo Consultor Vendas 1153 Eliete Supervisão 1046 Zuleide Supervisora CPD 9042 Flavia Gerente Modelo de Equipe Nome Papel Contato Thiago Dias Analista / DB / Negócios Daniel Arquiteto de sistemas Paulo Cesar Angelo Analista Sistemas Marcos Gerente Projeto Luan Patrocinador 120

135 8. Cronograma inicial Esta seção apresenta um cronograma inicial para o projeto, destacando quais serão os principais marcos do projeto, o seu conteúdo e quando eles ocorrerão. Marcos do projeto Deliverables Data de início prevista Data de término prevista Planejamento Desenvolvimento Estabilização Plano de Projeto Cronograma detalhado Definições funcionais e de testes Aplicação desenvolvida Aplicação testada 121

136 CAPÍTULO 6. APÊNDICES Apêndice - Documento de BPMN do Estudo de Caso do Projeto de Vendas.

137 PropostaAdmissao4 Bizagi Process Modeler 123

138 124

139 Table of Contents PROPOSTAADMISSAO4...1 BIZAGI PROCESS MODELER APROVAÇÃO CPD APROVAÇAO CPD(FACIL) Process Elements None Integração com sistema Fácil Todos dados do Contrato válidos? editar/corrigir proposta Aprovação Cadastro Parallel Gateway Gerar Boleto None Gerar Carteirinha PREVENDAS PREVENT Process Elements Chamada com número de matricula referenciando idprevenda PAINEL VENDEDOR PAINEL VENDEDOR Process Elements None Parallel Gateway Fazer Acordo Atender (Venda) Listar Tarefas Agendar Timer Alertar /05/

140 Central de Relatórios Parallel Gateway Relatório Vendas Gerar Boletomanualmente para clientes sem internet Configurações Transferência Consultor de Vendas PROCESSO AUTOMÁTICO REDIRECIONAMENTO DE ATENDIMENTO Process Elements None Timer Usuário pausado? Distribuir atividades para outros consultores de venda Login foi feito hj? CONFIGURAÇÕES VENDEDOR CONFIGURAÇÕES Process Elements None Parallel Gateway Pausar automáticamente TRANSFERÊNCIA TRANSFERÊNCIA Process Elements None Exclusive Gateway Presente: Doar Comissão VENDAS PROCESSO DE VENDA Process Elements /05/

141 None Triagem Pré-cadastro: Solicita dados pré-cadastrais ao cliente Valida Transfere Vendedor Usuário tem acesso a internet? Envia link de acesso para usuário por Cadastra/edita Página 1 - dados da venda / Proposta de admissão Portabilidade redução de carência? Página 2 Termo aditivo de redução de carências Exclusive Gateway Página 4 - Declaração de saúde B Termo de opção Agendar Data para assinatura/ entrega documentos e local Preparar Itinerário Validar e confirma proposta Proposta válida? Agendar data para colher assinatura e documentos(dia -1) Lote para Gerar e Imprimir por zona Envia contrato, solicitar assinturas e documentos Conferir e Aprovar Documentação Válida? CPD aprovação e Integração paginas e motivo do ítem inválido Exclusive Gateway Cliente /05/

142 Consultor Vendas Transportador Supervisor Existe problema de saúde? Informação Contato Transfere Contato Questionario Como chegou a Prevent Acesso via web? Pergunta perfil Cliente Seleciona quem será o dono da venda(comissão) alerta para vendedor ligar para avisar o cliente confirmar dt de colher assinatura? Assinatura Consultor Vendas Conferir e solicitar entrega Precisa Reagendar? Solicitar reagendamento Upload Documentos Agendar tarefa vendedor Responsável / Alertar Adicionar valor relativo ao transporte(debitar comissão Vendedor) None Parallel Gateway Contabilizar Vendas prazo de 1 dia toda documentação ok dentro do prazo? /05/

143 Solicitar Documentos necessários para completar o contrato Precisa retirar no local? A qualquer momento o consultor pode: Parar atendimento e Reagendar data para contato(com alerta) Problema é de contrato? Auxiliar Vendas MAIN PROCESS Process Elements Tela para equipe de Cadastro acompanhar processo FECHAMENTO FECHAMENTO Process Elements None Agendar fechamento Aguardar data fechamento Contabilizar todas vendas e acordos de planos por consultor de vendas no período Aplicar regras de comissão(parametro) Persistir quantidades de planos/comissões por vendedor Integração / Alimentar sistema fácil None Gerente vendas Sistema Fácil ESTORNO Process Elements None Seleciona vendedor Seleciona matricula Estornar /05/

144 None TRANSFERÊNCIA DE CONTATO TRANSFERE CONTATO Process Elements None Transfere Contato para dono da conta Seleciona responsável e Transfere no sistema Transfere ligação para o Responsável Exibir alerta e colocar na lista de tarefa do responsável Gera log None Corretor Vendas Atual Consultor Responsável PAINEL DE CONTROLE PAINEL DE CONTROLE Process Elements None Configuração de parametros de sistemas Comissão Documentos necessários para efetivar compra Descontos de venda Bônus por indicação Dias decobrança de inadimplente / Cancelamento Acordo>Dias de Tolerância enquanto vendedor Não Atendeu Ativar cobrança transportador por erro de contrato Prazo Alteração Bonus Hora da pausa automática /05/

145 9 RELATÓRIOS GERENCIAIS RELATÓRIOS Process Elements None Parallel Gateway Bordero Reduções Internas Gestor Relatório de fechamento? Relatório Proposta Fechada: de total de resgate do acordo ACORDO ACORDO Process Elements None Gerar Lista Inadimplente Pool: Distribuição de inadimplente para consultores(automática) Entra em contato com cliente(acordo) Avalia Acordo Cliente solicita cancelamento ou vendedor vai regerar contrato? Abrir chamado para cobrança cancela contrator Cancelamento contrato Se quiser agendar pagamento Agenda data para efetuar pagamento Aguardar Data do acordo para pagamento + 1 para validar Validar Pagamento Acordo TODAS dívidas ok? /05/

146 Valida prazo de tentativas de acordo <60 dias= Dentro do prazo de atendimento Vendedor? Cancelar Contrato Após cancelado por X dias até o fim do mês de cancelamento Gerar listagem de cancelados para rematricula Contabiliza comissão/meta contador None Efetua Pagamento CPD/Cobrança Supervisor de vendas Consultor Vendas Cliente Diariamente Solicitar Atendimento Dt Agendada Sistema envia com boleto para data agendada Selecionar quem ganhará a comissão no fechamento passar informações para fácil(integração) APROVACAO BONUS APROVAÇÃO BONUS Process Elements None Listar Bonus Pendente aprovação Editar/Add Bônus Aprovado? Aprovado/ status(permite ir para financeiro) /05/

147 Volta para vendedor ou cancela bonus MAIN PROCESSO VENDAS Process Elements None Login Menu Painel de Controle Relatórios Gerenciais Fechamento Painel Vendedor Consultor Vendas Login Supervisor / Gerente Gerente Lista Gestão Bonus para pagamento Aprovação Bonus Financeiro /05/

148 1 APROVAÇÃO CPD 08/05/

149 Version: 1.0 Author: Paulo 1.1 APROVAÇAO CPD(FACIL) Description PROCESS ELEMENTS None Integração com sistema Fácil Todos dados do Contrato válidos? Gates Não Sim editar/corrigir proposta Aprovação Cadastro Parallel Gateway Gerar Boleto None 08/05/

150 Gerar Carteirinha 1.2 PREVENDAS PREVENT PROCESS ELEMENTS Chamada com número de matricula referenciando idprevenda 08/05/

151 2 PAINEL VENDEDOR 08/05/

152 Version: 1.0 Author: Paulo 2.1 PAINEL VENDEDOR PROCESS ELEMENTS None Parallel Gateway Fazer Acordo Description Process Acordo - PosVendas Atender (Venda) Description Process Vendas - Processo de venda Listar Tarefas Agendar 08/05/

153 Timer Alertar Central de Relatórios Parallel Gateway Relatório Vendas Gerar Boletomanualmente para clientes sem internet Configurações Description Process Configurações Vendedor - Configurações Transferência Description Process Transferência - Transferência Consultor de Vendas 08/05/

154 2.2 PROCESSO AUTOMÁTICO REDIRECIONAMENTO DE ATENDIMENTO Description PROCESS ELEMENTS None Timer Gates Sim Usuário pausado? Distribuir atividades para outros consultores de venda Implementation WebService Gates Não Login foi feito hj? 08/05/

155 3 CONFIGURAÇÕES VENDEDOR 08/05/

156 Version: 1.0 Author: Paulo 3.1 CONFIGURAÇÕES PROCESS ELEMENTS None Parallel Gateway Pausar automáticamente 08/05/

157 4 TRANSFERÊNCIA 08/05/

158 Version: 1.0 Author: Paulo 4.1 TRANSFERÊNCIA PROCESS ELEMENTS None Gates Exclusive Gateway Presente: Doar Comissão Presente: Doar Comissão 08/05/

159 5 VENDAS 08/05/

160 Version: 1.0 Author: Paulo 5.1 PROCESSO DE VENDA PROCESS ELEMENTS None Triagem Pré-cadastro: Solicita dados pré-cadastrais ao cliente Description Valida Transfere Vendedor Gates Não Questionario Como chegou a Prevent Usuário tem acesso a internet? Gates Não Sim Envia link de acesso para usuário por Cadastra/edita Página 1 - dados da venda / Proposta de admissão Gates Portabilidade redução de carência? 08/05/

161 Não SIm Página 2 Termo aditivo de redução de carências Gates Exclusive Gateway Página 4 - Declaração de saúde Página 4 - Declaração de saúde Description B Termo de opção Agendar Data para assinatura/ entrega documentos e local Preparar Itinerário Description Validar e confirma proposta Proposta válida? Gates não Agendar data para colher assinatura e documentos(dia -1) 08/05/

162 Agendar data para colher assinatura e documentos(dia -1) Lote para Gerar e Imprimir por zona Envia contrato, solicitar assinturas e documentos Conferir e Aprovar Description Documentação Válida? Gates Não Sim Process CPD aprovação e Integração Aprovação CPD - Aprovaçao CPD paginas e motivo do ítem inválido Gates Exclusive Gateway Cadastra/edita Página 1 - dados da venda / Proposta de admissão Cliente Consultor Vendas 08/05/

163 Transportador Supervisor Existe problema de saúde? Gates Sim Não Informação Contato Transfere Contato Description Process Transferência de contato - Transfere Contato Questionario Como chegou a Prevent Acesso via web? Gates Não Sim Pergunta perfil Cliente Seleciona quem será o dono da venda(comissão) 08/05/

164 alerta para vendedor ligar para avisar o cliente confirmar dt de colher assinatura? Gates sim não Assinatura Consultor Vendas Conferir e solicitar entrega Gates Sim Precisa Reagendar? Solicitar reagendamento Upload Documentos Agendar tarefa vendedor Responsável / Alertar Adicionar valor relativo ao transporte(debitar comissão Vendedor) None Parallel Gateway Contabilizar Vendas 08/05/

165 prazo de 1 dia toda documentação ok dentro do prazo? Gates Não Sim Solicitar Documentos necessários para completar o contrato Precisa retirar no local? Gates Não Sim A qualquer momento o consultor pode: Parar atendimento e Reagendar data para contato(com alerta) Problema é de contrato? Gates Sim Não(faltou documentação) Auxiliar Vendas 5.2 MAIN PROCESS PROCESS ELEMENTS Tela para equipe de Cadastro acompanhar processo 08/05/

166 6 FECHAMENTO 08/05/

167 Version: 1.0 Author: Paulo 6.1 FECHAMENTO PROCESS ELEMENTS None Agendar fechamento Aguardar data fechamento Contabilizar todas vendas e acordos de planos por consultor de vendas no período Description Aplicar regras de comissão(parametro) Persistir quantidades de planos/comissões por vendedor Integração / Alimentar sistema fácil Description Implementation WebService None 08/05/

168 Gerente vendas Sistema Fácil 6.2 ESTORNO PROCESS ELEMENTS None Seleciona vendedor Seleciona matricula Estornar None 08/05/

169 7 TRANSFERÊNCIA DE CONTATO 08/05/

170 Version: 1.0 Author: Paulo 7.1 TRANSFERE CONTATO PROCESS ELEMENTS None Transfere Contato para dono da conta Seleciona responsável e Transfere no sistema Transfere ligação para o Responsável Exibir alerta e colocar na lista de tarefa do responsável Gera log None Corretor Vendas Atual Consultor Responsável 08/05/

171 8 PAINEL DE CONTROLE 08/05/

172 Version: 1.0 Author: Paulo 8.1 PAINEL DE CONTROLE PROCESS ELEMENTS None Configuração de parametros de sistemas Comissão Documentos necessários para efetivar compra Descontos de venda Bônus por indicação Description Dias decobrança de inadimplente / Cancelamento Acordo>Dias de Tolerância enquanto vendedor Não Atendeu Ativar cobrança transportador por erro de contrato Description 08/05/

173 Prazo Alteração Bonus Hora da pausa automática 08/05/

174 9 RELATÓRIOS GERENCIAIS 08/05/

175 Version: 1.0 Author: Paulo 9.1 RELATÓRIOS PROCESS ELEMENTS None Parallel Gateway Bordero Reduções Internas Gestor Relatório de fechamento? Description Relatório Proposta Fechada: de total de resgate do acordo 08/05/

176 10 ACORDO 08/05/

177 Version: 1.0 Author: Paulo 10.1 ACORDO Description PROCESS ELEMENTS None Gerar Lista Inadimplente Description Processo Geração de lista de inadimplentes Zuleide Ramal 9042 Para gerar inadimplência(facplan): modulo relatório> inadimplentes (35) (Geração automática) Geralmente a lista é gerada com 35 dias para não gerar carta de inadimplência, porém as vezes o responsável por vendas solicita após 15 dias de atraso Pool: Distribuição de inadimplente para consultores(automática) Entra em contato com cliente(acordo) Avalia Acordo Description 08/05/

178 Gates Não Sim Cliente solicita cancelamento ou vendedor vai regerar contrato? Abrir chamado para cobrança cancela contrator. Description Cancelamento contrato Gates Sim Se quiser agendar pagamento Agenda data para efetuar pagamento Aguardar Data do acordo para pagamento + 1 para validar Validar Pagamento Acordo TODAS dívidas ok? Gates Nâo Sim Valida prazo de tentativas de acordo 08/05/

179 Gates Sim Não <60 dias= Dentro do prazo de atendimento Vendedor? Cancelar Contrato Após cancelado por X dias até o fim do mês de cancelamento Gerar listagem de cancelados para rematricula Contabiliza comissão/meta contador None Efetua Pagamento CPD/Cobrança Supervisor de vendas Consultor Vendas Cliente Diariamente 08/05/

180 Solicitar Atendimento Description Dt Agendada Sistema envia com boleto para data agendada Selecionar quem ganhará a comissão no fechamento passar informações para fácil(integração) 08/05/

181 11 APROVACAO BONUS 08/05/

182 Version: 1.0 Author: Paulo 11.1 APROVAÇÃO BONUS PROCESS ELEMENTS None Listar Bonus Pendente aprovação Editar/Add Bônus Aprovado? Gates Sim Não Aprovado/ status(permite ir para financeiro) Volta para vendedor ou cancela bonus 08/05/

183 12 MAIN 08/05/

184 Version: 1.0 Author: Paulo 12.1 PROCESSO VENDAS PROCESS ELEMENTS None Login Menu Painel de Controle Description Process Painel de Controle - Painel de controle Process Relatórios Gerenciais Relatórios Gerenciais - Relatórios Fechamento Description Process Fechamento - Fechamento 08/05/

185 Painel Vendedor Description Process Painel Vendedor - Painel Vendedor Consultor Vendas Login Supervisor / Gerente Gerente Lista Gestão Bonus para pagamento Aprovação Bonus Description Process Aprovacao Bonus - Aprovação Bonus Financeiro 08/05/

186 CAPÍTULO 6. APÊNDICES Apêndice - Documento de Análise por Ponto de Função do Projeto de Vendas.

187 Contagem de Pontos de Função Identificação da Contagem Projeto : Vendas Responsável : Paulo Cesar Angelo Data : 22/04/2014 Revisor : Sheila Leal Data : 23/04/2014 Tipo de Contagem : Projeto de Desenvolvimento Projeto de Melhoria Aplicação ( Baseline ) UFPB : Propósito da Contagem Elaboração da estimativa do Projeto de Vendas Escopo da Contagem Elucid Solutions Contagem por Pontos de Função Vendas v4.xlsx - Tipo de Contagem 173

188 Projeto : Vendas Data : 22/04/14 Revisor : Sheila Leal Responsável : Paulo Cesar Angelo Data Revisão : 00/01/00 # Processo Elementar ou Grupo de Dados Tipo Depois da Melhoria A TD AR/TR ctl C Complex. PF TD 1 VENDAS.TELEFONE ALI BAIXO 7 2 VENDAS.OPERADORA_TELEFONE ALI BAIXO 7 3 VENDAS.PRE_BENEFICIARIO_ENDERECO ALI BAIXO 7 4 VENDAS.PRE_BENEFICIARIO_RESPONSÁVEL ALI BAIXO 7 5 VENDAS.ITINERARIO ALI BAIXO 7 6 VENDAS.PRE_BENEFICIARIO ALI COMPLEXO 15 7 VENDAS.OPERADORA ALI BAIXO 7 8 VENDAS.TRANSFERENCIA_VENDA ALI BAIXO 7 9 VENDAS.PRE_BENEFICIARIO_CONFERENCIA ALI BAIXO 7 10 VENDAS.PRE_BENEFICIARIO_ANEXO ALI BAIXO 7 11 VENDAS.ACESSO_PRE_BENEFICIARIO ALI BAIXO 7 12 VENDAS.PRE_BENEF_DECLA_SAUDE ALI BAIXO 7 13 VENDAS.DECLARACAO_SAUDE ALI BAIXO 7 14 VENDAS.ACORDO_EXPIRADO ALI BAIXO 7 16 VENDAS.INFO_VENDA ALI BAIXO 7 17 VENDAS.FECHAMENTO ALI BAIXO 7 18 VENDAS.VENDA ALI BAIXO 7 19 VENDAS.CONTATO ALI BAIXO 7 20 VENDAS.PRODUTO ALI BAIXO 7 21 VENDAS.CAMPANHA ALI BAIXO 7 22 VENDAS.INADIPLENTE ALI BAIXO 7 23 VENDAS.PARCELA_ACORDO ALI BAIXO 7 24 VENDAS.COMISSAO ALI BAIXO 7 25 VENDAS.PARCELA_INADIMPLENTE ALI BAIXO 7 26 VENDAS.COMO_CONHECEU ALI BAIXO 7 27 VENDAS.DOC_NECES_CONTRATO ALI BAIXO 7 28 VENDAS.HISTORICO_ACORDO ALI BAIXO 7 29 VENDAS.HISTORICO_CONTATO ALI BAIXO 7 30 VENDAS.HISTORICO_VENDA ALI BAIXO 7 31 VENDAS.PRE_BENEFICIARIO_PERFIL ALI BAIXO 7 32 ITINERÁRIO CE BAIXO 3 29 RELATÓRIO BORDERO SE BAIXO 4 Contagem por Pontos de Função Vendas v4 174

189 30 RELATÓRIO REDUÇÃO INTERNA SE BAIXO 4 31 RELATÓRIO PROPOSTAS FECHADAS SE BAIXO 4 32 RELATÓRIO FECHAMENTO SE BAIXO 4 33 PAINEL DE VENDAS EE BAIXO 3 34 PRÉ-CADASTRO CLIENTE EE MÉDIO 4 35 CADASTRO CLIENTE EE COMPLEXO 6 36 EDITAR / FINALIZAR VENDA EE BAIXO 3 37 SELECIONAR DONO DA VENDA EE BAIXO 3 38 ASSINATURA EE BAIXO 3 39 ENTREGAR CONTRATO / RECOLHER DOCUMENTOS EE BAIXO 3 40 APROVAÇÃO EE BAIXO 3 41 PAINEL DE ACORDO - LISTA TAREFA EE BAIXO 3 42 PAINEL DE ACORDO - TRIAGEM EE MÉDIO 4 43 PAINEL DE ACORDO - DADOS DO CLIENTE EE BAIXO 3 44 PAINEL DE ACORDO - HISTÓRICO DE NEGOCIAÇÕES EE MÉDIO 4 45 PAINEL DE ACORDO - PARCELAS EE BAIXO 3 46 PARÂMETRO COMISSÃO EE BAIXO 3 47 PARÂMETRO DESCONTO EE MÉDIO 4 48 PARÂMETRO BÔNUS POR INDICAÇÃO EE BAIXO 3 49 PARÂMETRO COBRANÇA DE INADIMPLENTE EE BAIXO 3 50 PARÂMETRO TOLERÂNCIA - NÃO ATENDEU EE BAIXO 3 Contagem por Pontos de Função Vendas v4 175

190 Cálculo do Fator de Ajuste Projeto : Vendas Data : 22/04/14 Revisor : Sheila Leal Responsável : Paulo Cesar Angelo Data Revisão: 00/01/00 Depois da Melhoria Antes da Melhoria Características Gerais de Sistema DI Características Gerais de Sistema 01 - Comunicação de Dados Comunicação de Dados 02 - Processamento Distribuído Processamento Distribuído 03 - Performance Performance 04 - Configuração Altamente Utilizada Configuração Altamente Utilizada 05 - Volume de Transações Volume de Transações 06 - Entrada de Dados On-line Entrada de Dados On-line 07 - Eficiência do Usuário Final Eficiência do Usuário Final 08 - Atualização On-Line Atualização On-Line 09 - Processamento Complexo Processamento Complexo 10 - Reusabilidade Reusabilidade 11 - Facilidade de Instalação Facilidade de Instalação 12 - Facilidade de Operação Facilidade de Operação 13 - Múltiplos Locais Múltiplos Locais 14 - Modificação Facilitada Modificação Facilitada Total dos Níveis de Influência (TDI) 39 Total dos Níveis de Influência (TDI) Valor do Fator de Ajuste (VAF) 1,04 Valor do Fator de Ajuste (VAF) Elucid Solutions Contagem por Pontos de Função 176

191 Totalização das Informações Pontos de função 309,92 Linguagem: Java Web (J2EE) Pontos Quantidade de horas 2479,36 Tipo de Contagem: Desenvolvimento Quanti Váriáveis da Contagem [UFPB] PF não Ajustados antes da manutenção 0 [ADD] PF não Ajustados das novas funcionalidades 298 [CHGA] PF não ajustados da func. alteradas - após 0 [CHGB] PF não ajustados das func. alteradas - antes 0 [DEL] PF não ajustados das funcionalidades exluídas 0 [VAF] Valor do Fator de Ajuste 1,04 [VAFA] Valor do Fator de Ajuste - Depois 1,04 [VAFB] Valor do Fator de Ajuste - Antes 1,00 Iniciação (2%) 49,59 Planejamento (16%) 396,70 Projeto (2%) 49,59 Execução (50%) 1239,68 Monitoramento e Controle (10%) 247,94 Testes (10%) 247,94 Homologação (10%) 247,94 Total (100%) 2479,36 Plataforma Desenvolvimento Melhoria C++ 8,8 4,4 Oracle (forms) 8 4 Java Web (J2EE) 8 4 Java Socket (J2SE) 4 2 Net Pocket 10 5 Net 7 3,5 177

192 CAPÍTULO 6. APÊNDICES Documentos do Estudo de Caso do Projeto Blindagem Jurídica SUS Neste estudo de caso a metodologia proposta foi aplicada. Esta metodologia concentra-se na especificação de requisitos de software, com especial atenção na qualidade dos dados. Para este efeito, o método proposto viabiliza que especialistas em negócios possam modelar processos de negócio cientes da qualidade dos dados e engenheiros de software possam obter artefatos úteis para a criação de software. Estes requisitos foram capturados a partir de modelos de processos de negócios descritos com BPMN integrados aos Casos de Uso da UML com prototipação para gerar o documento de requisitos na fase de análise de requisitos Documento de Requisitos do Estudo de Caso do Projeto Blindagem Jurídica SUS

193 Visão e Escopo Especificação de Blindagem Sistêmica SUS. Projeto: Nº 003 Versão

194 Histórico de Alterações Data Versão Descrição Autor 21/02/ Documento Inicial Paulo Cesar 21/02/ Revisão Use Case Paulo Cesar 25/02/ Revisão Protótipos Pedro 28/02/ Revisão Geral Paulo 28/02/ Revisão de Evolução dos Protótipos Pedro 05/03/ Revisão Geral + add BPMN Paulo 06/03/ Aprovação do documento de requisito Paulo/Rafael 06/03/ Aprovação do documento de requisito Paulo/Juliana 07/03/ Aprovação do documento de requisito Paulo/Pedro 180

195 LISTA DE SIGLAS ABI: Aviso de Beneficiários CPD: Centro de Processamento de Dados PTA: Programa de Transmissão de Arquivo SLA: Solicitação Caixa na Acopfiles SUS: Sistema Único de Saúde XML: Extensible Markup Language 181

196 Conteúdo 1. INTRODUÇÃO DO BLINDAGEM SISTÊMICA SUS SUMÁRIO EXECUTIVO FINALIDADE ENGENHARIA DE SOFTWARE USE CASE (CASO DE USO) Atores Atores do sistema Blindagem Sistêmica SUS Jurídico Prevent CPD Médico Auditor Técnico Auditor Fraude Financeiro Diagrama Global da Blindagem Sistêmica SUS Especificação Textual dos Casos de uso Especificação textual do caso de uso Cadastrar ABI Especificação textual do caso de uso Preparar Defesa para Impugnáveis Automáticos Especificação textual do caso de uso Preparar Defesa para Impugnáveis Técnicos Especificação textual do caso de uso Preparar Defesa Contra Fraude Especificação textual do caso de uso Avaliação técnica de ABIs Não Impugnáveis Especificação textual do caso de uso Digitalizar Documentação Especificação textual do caso de uso Identificar ABIs com Fraude Preparar lote de impugnação Especificação textual do caso de uso Pagamentos Informações Gerenciais(relatórios) Parametrizar sistema (Painel de Controle) PAPÉIS E RESPONSABILIDADES USUÁRIOS MODELO DE EQUIPE ANÁLISE/ENGENHARIA EQUIPE QUALIDADE/PLANEJAMENTO MODELO DE EQUIPE DESENVOLVIMENTO ANÁLISE DE RISCOS GESTÃO DE CUSTOS GESTÃO DE PRAZO ANEXOS

197 1. Introdução do Blindagem Sistêmica SUS 1.1 Sumário Executivo O sistema de Blindagem Sistêmica SUS trata-se de uma aplicação para proteger a organização Prevent Senior de cobranças indevidas que são feitas pela ANS. Historicamente tais cobranças alcançam um valor médio de 2,8 milhões por trimestre que tem sido realizada de forma retroativa gerando tais cobranças com periodicidade Mensal ou Bimestral. Tal ideia surgiu da oportunidade identificada de desenvolver um sistema que atue como intermediário no processo de levantamento de dados e requisitos necessários para que o jurídico possa atuar de forma eficiente em duas frentes: 1) Identificar e Impugnar cobranças indevidas por utilização do SUS. Atualmente sem o sistema, o setor jurídico da Prevent Senior tem tido um retorno satisfatório de cerca de R$ ,00 mensais em suas defesas contra cobranças indevidas, isso representa cerca de 28,57% de eficiência defesa. Há indícios de que tal acurácia pode ser alavancada de forma expressiva com um mapeamento e otimização de processos e um sistema de informação que automatize atividades burocráticas tornando o processo mais eficiente. Espera-se que com essa implementação sistêmica a organização tenha potencial para aumentar o percentual de impugnações para cerca 57,14% de defesa, com um ROI estimado em R$ ,00. Para sustentar essa hipótese será feito um trabalho multidisciplinar com os setores de qualidade e planejamento com avaliação quantitativa baseada em 6Sigma. 2) Identificar possíveis fraudes geradas contra a Prevent Senior e elaborar uma defesa para bloquear ou até mesmo cancelar o pagamento referente as cobranças indevidas que são feitas. Se essa hipótese for bem sucedida a organização pode ter um grande retorno financeiro evitando em até 100% dos custos relacionado as cobranças do SUS, ou seja, o ROI em torno de R$ ,00 por trimestre retroativo. 1.2 Finalidade Esse artefato consiste em um pacote contendo requisitos do modelo de casos de uso, especificações suplementares aplicáveis e outras informações de suporte com objetivo de definir o escopo do projeto. E também deve descrever totalmente o comportamento externo do aplicativo com seus requisitos não funcionais, restrições de design e outros fatores necessários para fornecer uma visão completa e abrangente dos requisitos do software. 183

198 2. Engenharia de Software 2.1 Use Case (Caso de Uso) Na Engenharia de Software, um caso de uso é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por sequências de mensagens intercambiáveis entre os sistemas e um ou mais atores. Neste documento de especificação, este diagrama descreverá todas as interações entre os atores e o Blindagem Sistêmica SUS Atores Ator é algo que interage com o sistema, mas sobre o qual não se tem controle. Ele está fora da influência do sistema. Os atores têm um papel externo e são quem iniciam (e quem respondem) aos casos de uso. São os atores que: Utilizam o sistema. Inicializam o sistema. Fornecem os dados. Usam as informações do sistema Atores do sistema Blindagem Sistêmica SUS Jurídico Prevent Tem o papel de importar os arquivos disponibilizados pela ANS no sistema de cadastro Blindagem Sistêmica SUS, preparar e as defesas para ABIs que sejam consideradas impugnáveis utilizando o sistema Blindagem Sistêmica SUS e preparar a defesa contra fraudes potenciais CPD Tem o papel de levantar todas as documentações necessárias para embasar a defesa do jurídico, ou seja, digitalização dos documentos do cadastro do beneficiário utilizando o sistema Blindagem Sistêmica SUS para digitalização eletrônica, organizar/indexar todo o conteúdo e controlar acessos somente aos setores autorizados Médico Auditor Técnico Tem o papel de investigar todos os ABIs que não foram classificados automaticamente como impugnáveis pelo sistema Blindagem Sistêmica SUS, encontrando cobranças indevidas do ponto de vista médico técnico. 184

199 Auditor Fraude Tem o papel de investigar fraudes potenciais utilizando o sistema Blindagem Sistêmica SUS para encontrar todos os beneficiários que o SUS alega atendimento em suas unidades médicas. O Auditor de Fraude entra em contato com o beneficiário por meio de telefone para confirmar a realização do atendimento no SUS ou identificar indícios de fraudes e fornecer tais informações tratadas ao Jurídico Financeiro Tem o papel de efetuar o pagamento das ABIs (tipos: sem razão para impugnar, segunda ou terceira instância), digitalizar o boleto de pagamento com data de início e fim de parcelamento, enviar documentação de pagamento à ANS e notificar o Jurídico quando o processo estiver encerrado para acompanhamento das datas de pagamento. 185

200 2.1.2 Diagrama Global da Blindagem Sistêmica SUS. Este diagrama visa representar a visão global e de alto nível com todas interações dos atores com o Sistema Blindagem Sistêmica SUS. Esse artefato permite a definição clara das fronteiras do sistema, exibindo onde se inicia e termina cada uma das atividades e responsabilidades de cada ator. 186

201 2.1.3 Especificação Textual dos Casos de uso Na Especificação Textual dos Casos de uso deve-se especificar o comportamento de um caso de uso descrevendo textualmente um ou mais fluxos de ações, de modo que um usuário não técnico possa entender sem dificuldade. Tal especificação deve incluir: Como e quando o caso de uso começa e termina. Quando é que o caso de uso interage com os atores. Que objetos são trocados. Cenário, e Cenários Alternativos (ex: Situações de exceção) Especificação textual do caso de uso Cadastrar ABI PRÉ-CONDIÇÕES 1) Qualquer um dos usuários deverá ter efetuado o seu login no Sistema Blindagem Sistêmica SUS. Fluxo Principal Jurídico 1-Receber Aviso de Beneficiários Identificados (ABI) 2-Exportar pelo programa PTA a listagem de ABIs para XML da ANS Sistema 3-Importar ABI no formato XML 4-Validar ABI no formato XML 5-Fornece aviso de importação concluída (Passo 5) Fluxos Alternativos - Erro Importação Jurídico 2-Retornar ao Fluxo Principal Sistema 1-Fornece aviso de erro na importação do arquivo (Passo 1 Fluxo Alternativo) 187

202 PROTÓTIPOS Passo 3 Passo 5 Passo 1- Fluxo Alternativo 188

203 Especificação textual do caso de uso Preparar Defesa para Impugnáveis Automáticos. PRÉ-CONDIÇÕES 1) Qualquer um dos usuários deverá ter efetuado o seu login no Sistema Blindagem Sistêmica SUS. 2) Jurídico já deve ter concluído com sucesso o caso de uso Cadastrar ABI. Jurídico 4- Visualizar lista de atividades. (Passo 4) 5- Selecionar atividade e visualizar todos dados necessários (Passo 5) 6- Preparar impugnações e contestar pagamento referente ao AIH. 8-impugnado/não impugnado (pode defender até 3 instância) Fluxo Principal Sistema 1- Processar ABIs cadastrados e gerar um pool de atividades de impugnáveis automaticamente. * 2- Executar com sucesso o caso de Preparar de todos ABIs listados na atividade Exibir todas ABIs impugnadas automaticamente com todos os seus subsídios na fila de atividades do ator Jurídico. 7-Adicionar status aguardando 9-Provisionar recursos para pagamento de AIH no financeiro;(integração com facplan) *Será considerado impugnado automaticamente qualquer AIH que preencher os requisitos abaixo: Beneficiário em carência (abaixo de 180 dias entra como carência). Usuário não é o beneficiário da operadora (no período). Atendimento fora da abrangência geográfica do contrato. Atendimento já pago pela operadora (mesmo cliente, data e local). Validar valor do procedimento (checar mesmo procedimento anterior para avaliar se houve aumento no mesmo). Buscar data de óbito (alterar cockpit para buscar essa informação). Procedimento incompatível com o sexo do beneficiário. 189

204 PROTÓTIPOS Passo 4 190

205 Passo

206 192

207 Passo 6- Tela com campos para gerar impugnação de acordo com modelo: modeloimpugnacao. 193

208 Especificação textual do caso de uso Preparar Defesa para Impugnáveis Técnicos PRÉ-CONDIÇÕES 1) Qualquer um dos usuários deverá ter efetuado o seu login no Sistema Blindagem Sistêmica SUS. 2) Médico Aud. Téc. deve ter concluído com sucesso o caso de uso Avaliação técnica de ABIs Não Impugnáveis. 3) CPD deve ter concluído com sucesso o caso de uso Digitalizar Documentação. Jurídico 2- Visualizar lista de atividades. 3- Selecionar atividade pendente. 4- Visualizar informações inseridas pelo Médico Aud. Téc e Preparar impugnações e contestar pagamento referente ao AIH. 5- Selecionar atividade e visualizar todos dados necessários (Passo 5) 6- Preparar impugnações e contestar pagamento referente ao AIH. Fluxo Principal Sistema 1- Processar ABIs avaliados pelo Médico Aud. Téc que foram considerados impugnáveis com todos os seus subsídios na fila de atividades do ator Jurídico. 194

209 PROTÓTIPOS Passo 2 195

210 Passo

211 197

212 Passo 6 198

213 Especificação textual do caso de uso Preparar Defesa Contra Fraude PRÉ-CONDIÇÕES 1) Qualquer um dos usuários deverá ter efetuado o seu login no Sistema Blindagem Sistêmica SUS. 2) Auditor de Fraude deve ter concluído com sucesso o caso de uso Identificar ABIs com Fraude. 3) CPD deve ter concluído com sucesso o caso de uso Preparar. Jurídico 2- Visualizar lista de atividades (Passo 2) 3- Selecionar atividade pendente (Passo 3) 4- Visualizar informações inseridas pelo Auditor de Fraude e Preparar Defesa contra ANS. < não é atividade de sistema> (Passo 4) Fluxo Principal Sistema 1- Processar ABIs avaliados pelo Auditor de Fraude considerados Fraude com todos os seus subsídios na fila de atividades do ator Jurídico (Passo1) 199

214 PROTÓTIPOS Passo 2 200

215 Passo 3 e

216 202

217 Especificação textual do caso de uso Avaliação técnica de ABIs Não Impugnáveis PRÉ-CONDIÇÕES 1) Qualquer um dos usuários deverá ter efetuado o seu login no Sistema Blindagem Sistêmica SUS. 2) O Jurídico já deve ter concluído com sucesso o caso de uso Cadastrar ABI. Fluxo Principal Médico Aud. Téc. 3- Visualizar total de avaliações (Passo 3) 4- Selecionar próxima avaliação (Passo 4) 5- Avaliar AIH com parecer médico técnico (Passo 5) Sistema 1- Processar ABIs cadastrados e gerar um pool de atividades de não impugnáveis automaticamente. * (Passo 1) 2- Exibir todas ABIs não impugnadas automaticamente com todas as informações necessárias para a análise técnica. ** (Passo 2) *Será considerado não impugnado automaticamente qualquer AIH que não preencher os requisitos abaixo: Beneficiário em carência (abaixo de 180 dias entra como carência). Usuário não é o beneficiário da operadora (no período). Atendimento fora da abrangência geográfica do contrato. Atendimento já pago pela operadora. ** Levantar informações necessárias para avaliação técnica (carência, dados do beneficiário, histórico médico e dados da AIH) para que o médico possa avaliar as impugnações técnicas: Procedimento considerado desnecessário. Procedimento não realizado. Quantidade do procedimento considerada desnecessária. 203

218 PROTÓTIPOS Passo 3 e 4 204

219 Passo 5 205

220 Passo 5b 206

221 Especificação textual do caso de uso Digitalizar Documentação PRÉ-CONDIÇÕES 1) Qualquer um dos usuários deverá ter efetuado o seu login no Sistema Blindagem Sistêmica SUS. 2) Jurídico já deve ter concluído com sucesso o caso de uso Cadastrar ABI. Fluxo Principal CPD 3- Ezuleide avaliará digitalização (Passo 3) 4- Visualizar lista de atividades (Passo 4) 5- Selecionar atividade pendente (Passo 5) 6- Digitalizar documentos pendentes (Passo 6) Sistema 1- Processar ABIs de todos beneficiários que tem necessidade de subsídios para defesa do jurídico (Preparar Defesa para Impugnáveis Automáticos, Preparar Defesa para Impugnáveis Técnicos, Preparar Defesa Contra Fraude) (Passo 1). 2- Identificar na listagem 1- todos os beneficiários que não tem todos documentos digitalizados (Passo 2) (Sistema apresenta: checklist com checkbox de todos documentos necessários, enquanto tiver todos, não sai da lista de atividades do operador do CPD); 207

222 PROTÓTIPOS Passo 3 Passo 4 208