1
GOVERNANÇA
BPM
UM GUIA DE BOAS PRÁTICAS PARA GERENCIAMENTO
DE SERVIÇOS DE TIC ORIENTADO A PROCESSOS
eBook
2
UM GUIA PRÁTICO PARA GERENCIAMENTO DE SERVIÇOS DE
TIC ORIENTADO A PROCESSOS
Versão 1.0 Primeira liberação
eBook desenvolvido pela Pós-Graduação em Qualidade e Governança em Tecnologia
da Informação como requisito parcial para aprovação no módulo de Gestão da
Qualidade de Serviços
Os seguintes profissionais participaram do desenvolvimento do eBook:
ANDREA RODRIGUES DE VASCONCELOS
CAIO HENRIQUE MONTEIRO BARROSO DE MORAES
CLEUDIMAR GALINDO E SILVA
EDER RICARDO DE MELO FERREIRA
FABIO JOSÉ BEZERRA ARIMATEIA
GILBERTO JOÃO DE LIMA JUNIOR
JACKSON DANIEL ALMEIDA DO NASCIMENTO
JUCYELLE CAVALCANTE DA SILVA
LIVIO SCILAS JERONIMO E SILVA
LUCIANO PAULINO DA SILVA FILHO
RAPHAEL PÉRICLES FALCÃO LORENA
RÔMULO CÉSAR DIAS DE ANDRADE
3
Sumário
SUMÁRIO .......................................................................................................................................................... 3
CAPÍTULO 1 ................................................................................................................................................... 19
GERENCIAMENTO DE SERVIÇOS: INTEGRAÇÃO DO BANCO DE DADOS ENTRE EMPRESAS DE
DIAGNÓSTICOS NA CIDADE DE CARUARU ........................................................................................... 19
1. INTRODUÇÃO ...................................................................................................................................... 20 1.1. MOTIVAÇÃO ........................................................................................................................................... 20 1.1.2. OS PROBLEMAS IDENTIFICADOS .......................................................................................................... 20 1.1.3. SOBRE A ORGANIZAÇÃO ...................................................................................................................... 20 1.1.4. PROPOSTAS PARA INTEGRAÇÃO DO BANCO .......................................................................................... 21
1.1.5. CONVENÇÕES PARA IDENTIFICAÇÃO DOS REQUISITOS ......................................................... 21
1.1.6. CONVENÇÕES PARA IDENTIFICAÇÃO DOS CASOS DE USO .................................................... 21 1.1.7. ESTRUTURA DOS CASOS DE USO ........................................................................................................... 21 1.1.8. PRIORIDADES DOS CASOS DE USO ........................................................................................................ 21 1.1.9. DESCRIÇÃO DOS ATORES ..................................................................................................................... 22
1.2. REQUISITOS ORGANIZACIONAIS ...................................................................................................... 22
1.2.1. REQUISITOS DO SISTEMA ............................................................................................................ 22 1.2.2. [RF01] EFETUAR LOGON ..................................................................................................................... 22 1.2.3. [RF02] EFETUAR LOGOFF .................................................................................................................... 23 1.2.4. [RF03] CRIAR XML ............................................................................................................................ 23 1.2.5. [RF05] VERIFICAR ERROS ANTES DA CRIAÇÃO DO XML ..................................................................... 23 1.2.6. REQUISITOS NÃO FUNCIONAIS ............................................................................................................. 24 1.2.7. REQUISITOS DE PROCESSO ................................................................................................................... 24 1.2.8. [NFR01] – INTERAGIR COM O SQLSERVER ......................................................................................... 24 1.2.9. REQUISITOS DE EXTERNOS .................................................................................................................. 24 1.2.10. [NRF02] - CONEXÃO ......................................................................................................................... 24 1.2.11. REQUISITOS DE PRODUTO .................................................................................................................. 25 1.2.12. [RNF03] - PERMISSÃO ....................................................................................................................... 25
ANEXO A – STATUS DAS PROPOSTAS E CONTROLE ATUAL ............................................................ 25
ANEXO B – DESCRIÇÃO DOS CASOS DE USO ....................................................................................... 25 [UC01] EFETUAR LOGON .............................................................................................................................. 25 [UC02] EFETUAR LOGOFF ............................................................................................................................. 26 [UC03] INSERIR NÚMERO DA FATURA A SER GERADA ................................................................................... 26 [UC04] REMOVER DE XML .......................................................................................................................... 27 [UC05] ATUALIZAR XML ............................................................................................................................. 28
1.3. GERÊNCIA DE CONFIGURAÇÃO ........................................................................................................ 29
INTRODUÇÃO ................................................................................................................................................ 29 OBJETIVOS .................................................................................................................................................... 29
PAPEIS E RESPONSABILIDADES ............................................................................................................... 30
A) PLANO DE CONFIGURAÇÃO............................................................................................................. 30
B) VERFICAR QUAL SERÁ A ALTERAÇÃO A SER REALIZADA. .................................................... 30 POLÍTICA DE SEGURANÇA .............................................................................................................................. 30
MÉTODOS DE IDENTIFICAÇÃO ................................................................................................................. 32
4
DOCUMENTOS ............................................................................................................................................... 32
CONTROLE DE MUDANÇAS ....................................................................................................................... 33
1.4. NÍVEL DE SERVIÇO ............................................................................................................................... 37
1.5. GERENCIAMENTO DE SERVIÇO AUTOMATIZADO – BPMS ......................................................... 42
1.6 CONCLUSÃO ............................................................................................................................................ 48
APÊNDICE A - PROTOTIPAGEM DE TELA .............................................................................................. 49
APÊNDICE B - MODELAGEM DO PROCESSO ......................................................................................... 52 1.1 AVALIAÇÃO ........................................................................................................................................ 53
1.1.1 Elementos do processo ........................................................................................................... 53
1.1.1.1 Event....................................................................................................................... 53
1.1.1.2 Verificar necessidades do cliente ........................................................................... 53
1.1.1.3 Analisar Requisitos ................................................................................................. 53
1.1.1.4 Gateway .................................................................................................................. 53
1.1.1.5 Validar Requisitos .................................................................................................. 54
1.1.1.6 Organizar Backlog .................................................................................................. 54
1.1.1.7 Priorizar Backlog .................................................................................................... 54
1.1.1.8 Executar Sprint ....................................................................................................... 54
1.1.1.9 Testar Sprint ........................................................................................................... 54
1.1.1.10 Gateway ................................................................................................................. 54
1.1.1.11 Implementar Sistema no Cliente ............................................................................ 55
1.1.1.12 Event ..................................................................................................................... 55
1.1.1.13 Analista.................................................................................................................. 55
1.1.1.14 Gestão .................................................................................................................... 55
1.1.1.15 Desenvolvimento ................................................................................................... 55
1.1.1.16 Tester ..................................................................................................................... 55
1.1.1.17 Suporte .................................................................................................................. 55
2 DIAGRAM 1 .......................................................................................................................................... 56
2.1 GERENCIA DE CONFIGURAÇÃO ................................................................................................. 57
5
2.1.1 Process Elements .................................................................................................................... 57
2.1.1.1 IDENTIFICAR TIPO DE CONFIGURAÇÃO ...................................................... 57
2.1.1.2 VERIFICAR CRITÉRIOS À SEREM CONFIGURADOS................................... 57
2.1.1.3 ESTABELECER CRITÉRIOS PARA CONFIGURAÇÃO ................................... 57
2.1.1.4 CONCEDER ACESSO DE ARMAZENAMENTO DAS CONFIGURAÇÕES E
MANUSEIO À QUEM SE FIZER NECESÁRIO ............................................................................. 57
2.1.1.5 AS MODIFICAÇÕES DE ITENS SERÃO CONTROLADAS ............................. 57
2.1.1.6 CONTROLAR A LIBERAÇÃO DOS ITENS DE CONFIGURAÇÃO POR
QUEM FOR AUTORIZADO. ........................................................................................................... 57
2.1.1.7 AUDITORIA DOS ITENS DOS ITENS DE CONFIGURAÇÕES E ASSEGURAR
INTEGRIDADE DAS MESMAS. ..................................................................................................... 57
2.1.1.8 AS INFORMAÇÕES DE CONFIGURAÇÃO SERÃO ENTREGUES AS
PARTES QUE SE FIZEREM DE DIREITO. .................................................................................... 57
2.1.1.9 IDENTIFICAÇÃO ................................................................................................. 57
2.1.1.10 ARMAZENAMENTO E ITENS DE CONFIGURAÇÃO .................................... 58
2.1.1.11 AUDITORIA ......................................................................................................... 58
ANEXO C – GLOSSÁRIO .............................................................................................................................. 58
CAPÍTULO 2 ................................................................................................................................................... 59
GERENCIAMENTO DE SERVIÇOS: CONTROLE DE EQUIPAMENTOS ................................................ 59
2.1. INTRODUÇÃO ...................................................................................................................................... 60
2.2. REQUISITOS DO SISTEMA - PROCESSO DE CONTROLE DE EQUIPAMENTOS ....................... 60
2.2.1. INTRODUÇÃO ...................................................................................................................................... 60
2.2.2. MOTIVAÇÃO ........................................................................................................................................ 60
2.2.3. O PROBLEMA IDENTIFICADO .......................................................................................................... 60
2.2.4. SOBRE O DEPARTAMENTO DE T.I. ................................................................................................. 61
2.2.5. CONVENÇÕES PARA IDENTIFICAÇÃO DOS REQUISITOS .......................................................... 61
2.2.6. CONVENÇÕES PARA IDENTIFICAÇÃO DOS CASOS DE USO ..................................................... 61
2.2.7. ESTRUTURA DOS CASOS DE USO ................................................................................................... 61
2.2.8. PRIORIDADES DOS CASOS DE USO ................................................................................................ 62
2.2.9. DESCRIÇÃO DOS ATORES ................................................................................................................. 62
2.3. REQUISITOS ORGANIZACIONAIS .................................................................................................... 62
2.4. REQUISITOS FUNCIONAIS ................................................................................................................ 63
6
2.4.1. [RF01] EFETUAR LOGON ................................................................................................................... 63
2.4.2. [RF02] EFETUAR LOGOFF .................................................................................................................. 63
2.4.3. [RF03] INSERIR USUÁRIO .................................................................................................................. 63
2.4.4. [RF04] REMOVER USUÁRIO .............................................................................................................. 64
2.4.5. [RF05] ATUALIZAR USUÁRIO ........................................................................................................... 64
2.4.6. [RF06] LISTAR USUÁRIOS ................................................................................................................. 64
2.4.7. [RF07] ALTERAR SENHA ................................................................................................................... 65
2.4.8. [RF08] INSERIR EMPRESA ................................................................................................................. 65
2.4.9. [RF09] REMOVER EMPRESA ............................................................................................................. 65
2.4.10.[RF10] ATUALIZAR EMPRESA ......................................................................................................... 66
2.4.11.[RF11] LISTAR EMPRESAS ............................................................................................................... 66
2.4.12.[RF12] INSERIR PERFIL ..................................................................................................................... 66
2.4.13.[RF13] REMOVER PERFIL ................................................................................................................. 67
2.4.14.[RF14] ATUALIZAR PERFIL .............................................................................................................. 67
2.4.15.[RF15] LISTAR PERFIS ...................................................................................................................... 68
2.4.16.[RF16] INSERIR EQUIPAMENTO ..................................................................................................... 68
2.4.17.[RF17] REMOVER EQUIPAMENTO ................................................................................................. 68
2.4.18.[RF18] ATUALIZAR EQUIPAMENTO .............................................................................................. 69
2.4.19.[RF19] LISTAR EQUIPAMENTOS ..................................................................................................... 69
2.4.20.[RF20] SOLICITAR EQUIPAMENTO ................................................................................................ 70
2.4.21.[RF21] DEVOLVER EQUIPAMENTO ............................................................................................... 70
2.4.22.[RF22] ENVIAR À ASSISTÊNCIA ..................................................................................................... 70
2.4.23.[RF23] RETORNAR DE ASSISTÊNCIA ............................................................................................ 71
2.4.24.[RF24] RELATÓRIO DE EQUIPAMENTO ........................................................................................ 71
2.5. REQUISITOS NÃO FUNCIONAIS ....................................................................................................... 72
2.5.1. REQUISITOS DE PROCESSO .............................................................................................................. 72
2.5.1.1.[RNF01] UTILIZAR SCRUM COMO METODOLOGIA DE DESENVOLVIMENTO .................... 72
2.5.1.2.[NFR02] - DESENVOLVIMENTO EM JAVA ................................................................................... 72
2.5.1.3.[NFR03] – UTILIZAR BANCO DE DADOS MYSQL ....................................................................... 72
2.5.2. REQUISITOS DE EXTERNOS ............................................................................................................. 73
2.5.2.1.[NRF04] - TEMPO DE DESENVOLVIMENTO ................................................................................ 73
2.5.2.2.[RNF05] - CUSTO DE DESENVOLVIMENTO ................................................................................. 73
2.5.3. REQUISITOS DE PRODUTO ............................................................................................................... 73
2.5.3.1.[RNF06] - PERMISSÃO ...................................................................................................................... 73
2.5.3.2.[RNF07] - BACKUP ............................................................................................................................ 74
2.5.3.3.[RNF08] - MENSAGENS DE RETORNO .......................................................................................... 74
7
2.5.3.4.[RNF09] - MENUS BEM ESTRUTURADOS .................................................................................... 74
2.6. CONCLUSÃO ........................................................................................................................................ 75
REFERÊNCIAS ............................................................................................................................................... 75
RELATÓRIO DA EQUIPE .............................................................................................................................. 75
2.7. ANEXO A – REALIZAÇÃO DE CADASTROS E MANUTENÇÃO DE REGISTROS ..................... 76
2.8. ANEXO B – DESCRIÇÃO DOS CASOS DE USO ............................................................................... 76 [UC01] CADASTRAR UM EQUIPAMENTO ........................................................................................................ 76 [UC02] EXCLUIR O CADASTRO DE UM EQUIPAMENTO ................................................................................... 77
2.9. ANEXO C – GLOSSÁRIO ..................................................................................................................... 77
2.10.APÊNDICE – IMAGENS ........................................................................................................................ 78
2.1. GERÊNCIA DE CONFIGURAÇÃO ...................................................................................................... 82
2.1.1.INTRODUÇÃO ....................................................................................................................................... 82
2.1.2.OBJETIVOS............................................................................................................................................ 82
2.1.3.ORGANIZAÇÃO DO DOCUMENTO ................................................................................................... 82
2.1.4.PAPEIS E RESPONSABILIDADES ...................................................................................................... 82
2.1.5.PLANO DE CONFIGURAÇÃO ............................................................................................................. 83 TIPOS DE CONFIGURAÇÃO ............................................................................................................................. 83
2.1.6.CONTROLE DE CONFIGURAÇÃO ..................................................................................................... 84
2.1.7.ESTRUTURA DO REPOSITÓRIO DE GERÊNCIA DE CONFIGURAÇÃO ...................................... 85
2.1.8.POLÍTICA DE SEGURANÇA ............................................................................................................... 86
2.1.9.MÉTODOS DE IDENTIFICAÇÃO ........................................................................................................ 87 DOCUMENTOS ............................................................................................................................................... 87
2.1.10.CONFIGURAÇÃO BASE .................................................................................................................... 88 DOCUMENTOS DE ANÁLISE DE SOFTWARE .................................................................................................... 89
2.1.11.DOCUMENTOS DE PROJETO DE SOFTWARE .............................................................................. 89
2.1.12.CONTROLE DE MUDANÇAS ............................................................................................................ 89
2.1.13.AMBIENTE, FERRAMENTAS E INFRAESTRUTURA .................................................................... 93 PLANO DE SOFTWARE .................................................................................................................................... 93
2.1.14.COMISSÃO DE CONTROLE DE MUDANÇAS ................................................................................ 94
2.1.15.APROVAÇÃO FORMAL ..................................................................................................................... 94
2.1.16.ANEXOS ............................................................................................................................................... 95 PEDIDO FORMAL DE MUDANÇA – PFM ......................................................................................................... 95 SOLICITAÇÃO DE ANÁLISE DE IMPACTO......................................................................................................... 97
2.4. NÍVEL DE SERVIÇO ............................................................................................................................ 99
2.4.1.ACORDO GERAL .................................................................................................................................. 99
2.4.2.METAS E OBJETIVOS .......................................................................................................................... 99
2.4.3.RESPONSÁVEIS .................................................................................................................................. 100
2.4.4.AMBIENTE DE SERVIÇO .................................................................................................................. 100
2.4.5.REVISÃO PERIÓDICA ........................................................................................................................ 102
8
2.4.6.CONTRATO DE SERVIÇO ................................................................................................................. 102
2.4.6.1.ESCOPO DO SERVIÇO .................................................................................................................... 102
2.4.6.2.RESPONSABILIDADES DO CLIENTE .......................................................................................... 103
2.4.6.3.RESPONSABILIDADES DO PROVEDOR DE SERVIÇOS ........................................................... 103
2.4.6.4.SERVIÇOS PRESSUPOSTOS .......................................................................................................... 104
2.4.7.GERENCIAMENTO DO SERVIÇO .................................................................................................... 104
2.4.7.1.DISPONIBILIDADE DO SERVIÇO ................................................................................................. 104
2.4.8.MEDIÇÃO DOS SERVIÇOS ............................................................................................................... 105
2.4.9.RELATÓRIO EM NÍVEL DE SERVIÇO ............................................................................................ 105
2.4.10.PEDIDOS DE SERVIÇOS .................................................................................................................. 106
2.4.11.MANUTENÇÃO DOS SERVIÇOS .................................................................................................... 106
2.4.12.CUSTOS DOS SERVIÇOS ................................................................................................................. 106
2.5. GERENCIAMENTO DE SERVIÇO AUTOMATIZADO – BPMS .................................................... 113
2.6. CONCLUSÃO ...................................................................................................................................... 119
2.7. APÊNDICE ........................................................................................................................................... 120
2.7.1. SCRUM ................................................................................................................................................ 120 2.2 SCRUM ............................................................................................................................................ 120
2.2.1 Process Elements .......................................................................................... 120
2.2.1.1 None ................................................................................................ 120
2.2.1.2 Solicitar solução .............................................................................. 120
2.2.1.3 Identificar Problemática .................................................................. 120
2.2.1.4 Coletar Requisitos ........................................................................... 120
2.2.1.5 Documentar Requisitos .................................................................. 121
2.2.1.6 Analisar Proposta ............................................................................ 121
2.2.1.7 Decisão de aprovação ao reprovação .............................................. 121
2.2.1.8 Revisar problemática ....................................................................... 121
2.2.1.9 Compor Product Backlog ................................................................ 121
2.2.1.10 Priorizar Histórias (Definir Sprint Backlog) .................................. 121
2.2.1.11 Desenvolver Sprint .......................................................................... 122
2.2.1.12 Avaliar Sprint .................................................................................. 122
9
2.2.1.13 Inclusive Gateway ........................................................................... 122
2.2.1.14 Enviar Sprint ................................................................................... 122
2.2.1.15 Receber Sprint ................................................................................. 122
2.2.1.16 Sprint Retrospective ........................................................................ 123
2.2.1.17 Exclusive Gateway .......................................................................... 123
2.2.1.18 None ................................................................................................ 123
2.2.1.19 Parallel Gateway .............................................................................. 123
2.2.1.20 Cliente ............................................................................................. 123
2.2.1.21 Product OWNER ............................................................................. 123
2.2.1.22 Equipe de Desenvolvimento + Scrum Master ................................. 123
2.7.2. GERÊNCIA DE CONFIGURAÇÃO .................................................................................................... 124 2.1 GERÊNCIA DE CONFIGURAÇÃO ............................................................................................ 124
2.1.1 Process Elements .......................................................................................... 124
2.1.1.1 Definir as diretrizes do gerenciamento ............................................ 124
2.1.1.2 Estabelecer e manter um sistema de gerenciamento de configuração
124
2.1.1.3 Estabelecer os critérios dos itens de configuração .......................... 124
2.1.1.4 Identificar os itens de configuração ................................................. 125
2.1.1.5 Criar uma Baseline dos itens de configuração sujeitos a controle . 125
2.1.1.6 Criar registros das baselines dos itens de configuração ................. 125
2.1.1.7 Disponibilizar os registros das baselines de configuração .............. 125
2.1.1.8 Criar controle de alterções dos itens de configurção ....................... 125
2.1.1.9 Armazenar as alterações feitas nos itens de configuração e baselines
125
2.1.1.10 Realizar auditoria das configurações .............................................. 125
2.1.1.11 Entregar os intens de configurção aos envolvidos no projeto. ........ 125
10
2.1.1.12 None ................................................................................................ 126
2.1.1.13 L1 .................................................................................................... 126
2.1.1.14 l2 ...................................................................................................... 126
2.1.1.15 None ................................................................................................ 126
2.1.1.16 L1 .................................................................................................... 126
2.1.1.17 l2 ...................................................................................................... 126
2.1.1.18 PLANEJAMENTO ......................................................................... 127
2.1.1.19 EXECUÇÃO ................................................................................... 127
2.1.1.20 ENTREGA ...................................................................................... 127
2.7.3. MONITORAMENTO ........................................................................................................................... 127 2.1 SLA SGE ....................................................................................................................................... 127
2.1.1 Process Elements .......................................................................................... 127
2.1.1.1 None ................................................................................................ 127
2.1.1.2 Verificar Disponibilidade do Sistema ............................................. 127
2.1.1.3 Exclusive Gateway .......................................................................... 127
2.1.1.4 Verificar Provedor de Hospedagem da Aplicação .......................... 128
2.1.1.5 Exclusive Gateway .......................................................................... 128
2.1.1.6 Verificar Aplicação SGE ................................................................. 128
2.1.1.7 Exclusive Gateway .......................................................................... 128
2.1.1.8 Prestar Suporte à Aplicação ............................................................ 128
2.1.1.9 1 ....................................................................................................... 128
2.1.1.10 None ................................................................................................ 129
2.1.1.11 Contactar Provedor de Hospedagem ............................................... 129
2.1.1.12 Tempo de Solução ........................................................................... 129
2.1.1.13 Receber resposta de provedor .......................................................... 129
11
2.1.1.14 1 ....................................................................................................... 129
2.1.1.15 None ................................................................................................ 129
2.1.1.16 1 ....................................................................................................... 130
2.1.1.17 Monitoramento de ........................................................................... 130
CAPÍTULO 3 ................................................................................................................................................. 131
GERENCIAMENTO DE SERVIÇOS: PROCESSO E-COMMERCE .......................................................... 131
3.1. INTRODUÇÃO ....................................................................................................................................... 132
3.2. REQUISITOS DO SISTEMA (PROCESSO X) ..................................................................................... 132
3.2.1 REQUISITOS FUNCIONAIS ............................................................................................................... 132
3.2.1.1. [RF01] EFETUAR LOGON .............................................................................................................. 132
3.2.1.2. [RF02] EFETUAR LOGOFF ............................................................................................................ 132
3.2.1.3. [RF03] CADASTRAR PERFIL DO CLIENTE ................................................................................ 132
3.2.1.4. [RF04] CONSULTAR PRODUTOS ................................................................................................. 133
3.2.1.5. [RF05] ADICIONAR PRODUTOS À LISTA DE COMPRAS ........................................................ 133
3.2.1.6. [RF06] REMOVER PRODUTOS DA LISTA DE COMPRAS ........................................................ 133
3.2.1.7. [RF07] FINALIZAR COMPRA ........................................................................................................ 133
3.2.1.8. [RF08] CADASTRAR PRODUTO ................................................................................................... 134
3.2.1.9. [RF09] ALTERAR PRODUTO ........................................................................................................ 134
3.2.1.10. [RF10] INATIVAR PRODUTO ..................................................................................................... 134
3.2.1.11. [RF11] CONSULTAR PEDIDOS ................................................................................................... 135
3.2.1.12 [RF12] CANCELAR PEDIDO ......................................................................................................... 135
3.2.2. REQUISITOS NÃO FUNCIONAIS .................................................................................................... 135
3.2.2.1 REQUISITOS DE PROCESSO ......................................................................................................... 135
3.2.2.1.1. [RNF01] UTILIZAR SCRUM COMO METODOLOGIA DE DESENVOLVIMENTO .............. 135
3.2.2.1.2. [NFR02] - DESENVOLVIMENTO EM JAVA ............................................................................. 135
3.2.2.1.3. [NFR03] – UTILIZAR BANCO DE DADOS MYSQL ................................................................. 136
3.2.2.2. REQUISITOS DE EXTERNOS ........................................................................................................ 136
3.2.2.2.1. [NRF04] - TEMPO DE DESENVOLVIMENTO .......................................................................... 136
3.2.2.2.2. [RNF05] - CUSTO DE DESENVOLVIMENTO ........................................................................... 136
3.3. GERÊNCIA DE CONFIGURAÇÃO ...................................................................................................... 142
3.3.1 CONTROLE DE CONFIGURAÇÃO ................................................................................................... 142
3.3.1.1. PROCEDIMENTOS DE MUDANÇA .............................................................................................. 142
TODA E QUALQUER MODIFICAÇÃO NOS ITENS DE CONFIGURAÇÃO DEVE SER ABERTA UMA
CR CONFORME DESCRITO NA SEÇÃO 1.3.1.1.1. ................................................................................... 142
12
3.3.1.1.1. CRIANDO SOLICITAÇÃO DE MUDANÇA ............................................................................... 142
AS SOLICITAÇÕES DE MUDANÇAS DEVEM SER CRIADAS ATRAVÉS DE ABERTURA DE
CHAMADO PELO ADMINISTRADOR. OS SEGUINTES DADOS DEVEM SER INFORMADOS: ....... 142
3.3.2. AUDITORIA DE CONFIGURAÇÃO ................................................................................................. 143
3.3.3. PLANO DE CONTINGÊNCIA ........................................................................................................... 143
3.3.4. FERRAMENTAS ................................................................................................................................. 143
3.3.5. PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO ........................................................................ 144
3.4. NÍVEL DE SERVIÇO ............................................................................................................................. 144 3.4.3.2 MEDIÇÃO DOS SERVIÇOS ................................................................................................................. 146 3.4.3.3. RELATÓRIO EM NÍVEL DE SERVIÇO ................................................................................................. 147 3.4.3.4. PEDIDOS DE SERVIÇOS ................................................................................................................... 147 3.4.3.5. MANUTENÇÃO DOS SERVIÇOS ........................................................................................................ 147
3.5. GERENCIAMENTO DE SERVIÇO AUTOMATIZADO – BPMS ....................................................... 148
3.6 CONCLUSÃO .......................................................................................................................................... 151
DIAGRAMA 1 ............................................................................................................................................... 152 2.2 POOL ............................................................................................................................................ 152
2.2.1 Elementos do processo ......................................................................................................... 152
2.2.1.1 Event..................................................................................................................... 153
2.2.1.2 Levantar Requisitos .............................................................................................. 153
2.2.1.3 Atribuir valor as tarefas ........................................................................................ 153
2.2.1.4 Analise .................................................................................................................. 153
2.2.1.5 Gerencia Projeto ................................................................................................... 153
2.2.1.6 Desenvolvimento .................................................................................................. 153
2.2.1.7 Definir backlog ..................................................................................................... 153
2.2.1.8 Desenvolver Tarefa .............................................................................................. 153
2.2.1.9 Validar Tarefa ...................................................................................................... 153
2.2.1.10 Gateway ................................................................................................................ 153
2.2.1.11 Entregar produto ................................................................................................... 154
2.2.1.12 Verificar aceitação do cliente ............................................................................... 154
2.2.1.13 Gateway ................................................................................................................ 154
2.2.1.14 Negociar mudança nos requisitos ......................................................................... 154
13
2.2.1.15 Event..................................................................................................................... 154
2.2.1.16 Event..................................................................................................................... 154
2.2.1.17 Event..................................................................................................................... 154
3 SERVICO ............................................................................................................................................. 160
3.1 ELEMENT.............................................................................................................................. 160
3.2 ABRIR CHAMADO ................................................................................................................. 161
3.3 ATENDER CHAMADO N1 ....................................................................................................... 161
3.4 CHECAR INCIDENTES ............................................................................................................ 162
3.5 ELEMENT.............................................................................................................................. 163
3.6 ATENDER CHAMADO N2 ....................................................................................................... 163
3.7 ELEMENT.............................................................................................................................. 164
3.8 ATENDER CHAMADO N3 ....................................................................................................... 164
3.9 ANALISAR MOTIVO DO PROBLEMA ........................................................................................ 165
3.10 ELEMENT.............................................................................................................................. 166
3.11 SOLICITAR MANUTENÇÃO DE EQUIPAMENTO ........................................................................ 166
3.12 REGISTRAR NA BASE DE INCIDENTES .................................................................................... 166
3.13 RECEBER SOLUÇÃO .............................................................................................................. 167
3.14 ELEMENT.............................................................................................................................. 167
3.15 ELEMENT.............................................................................................................................. 167
3.16 REABRIR ............................................................................................................................... 168
3.17 CHECAR CONFIGURAÇAO DE SOFTWARE ............................................................................... 168
3.18 N2 ........................................................................................................................................ 168
3.19 ANALISAR REINCIDENCIA DO PROBLEMA ............................................................................. 168
3.20 ELEMENT.............................................................................................................................. 168
14
3.21 N1 ........................................................................................................................................ 169
3.22 AGENDAR TREINAMENTO ..................................................................................................... 169
3.23 N1 ........................................................................................................................................ 170
3.24 REABRIR ............................................................................................................................... 170
3.25 N2 ........................................................................................................................................ 170
3.26 CLIENTE ............................................................................................................................... 170
3.27 NIVEL 1 ................................................................................................................................ 170
3.28 NIVEL 2 ................................................................................................................................ 170
3.29 NIVEL 3 ................................................................................................................................ 170
3.30 MILESTONE 1 ....................................................................................................................... 170
CAPÍTULO 4 ................................................................................................................................................. 171
GERENCIAMENTO DE SERVIÇOS: ABERTURA DE CHAMADO CABARET FOIM-FOIM ............... 171
4.1 INTRODUÇÃO .................................................................................................................................... 171
4.2 REQUISITOS DO SISTEMA SBS (SISTEMA BAR E SEXO) .......................................................... 172
4.2.1[RF01] EFETUAR LOGON ................................................................................................................ 172 4.2.2 [RF02] EFETUAR LOGOFF .......................................................................................................... 172 4.2.3 [RF03] INSERIR PACOTES DE SERVIÇOS .................................................................................... 172 4.2.4 [RF04] REMOVER PACOTES DE SERVIÇOS ................................................................................. 173 4.2.5 [RF05] ATUALIZAR PACOTES DE SERVIÇOS .............................................................................. 173 4.2.6 [RF06] LISTAR PACOTES DE SERVIÇOS ..................................................................................... 173 4.2.7 REQUISITOS NÃO FUNCIONAIS ................................................................................................... 173 4.2.7.1 REQUISITOS DE PROCESSO .................................................................................................... 174
4.2.7.2 [RNF01] Utilizar SCRUM como Metodologia de Desenvolvimento ...... 174 4.2.7.3 [NFR02] - DESENVOLVIMENTO EM JAVA .............................................................................. 174 4.2.7.4 [NFR03] – UTILIZAR BANCO DE DADOS MYSQL .................................................................. 174 4.2.8. REQUISITOS EXTERNOS ..................................................................................................................... 175 4.2.8.1 [NRF04] - TEMPO DE DESENVOLVIMENTO ...................................................................................... 175 4.2.8.2 [RNF05] - CUSTO DE DESENVOLVIMENTO ...................................................................................... 175 4.2.9. REQUISITOS DE PRODUTO .................................................................................................................. 175 4.2.9.1 [RNF06] – PERMISSÃO .................................................................................................................... 175 4.2.9.2 [RNF07] – BACKUP ......................................................................................................................... 176 4.2.9.3 [RNF08] - MENSAGENS DE RETORNO ............................................................................................. 176 4.2.9.4 [RNF09] - MENUS BEM ESTRUTURADOS ......................................................................................... 176
4.3 NÍVEL DE SERVIÇO .......................................................................................................................... 181
4.3.1 ACORDO GERAL................................................................................................................................ 181
4.3.2 METAS E OBJETIVOS ....................................................................................................................... 181
15
4.3.3 RESPONSÁVEIS ................................................................................................................................. 182
4.3.4 AMBIENTE DE SERVIÇO.................................................................................................................. 182
4.3.5 REVISÃO PERIÓDICA ....................................................................................................................... 184
4.3.6 CONTRATO DE SERVIÇO ................................................................................................................ 184 4.3.6.1 ESCOPO DO SERVIÇO ....................................................................................................................... 184 4.3.6.2 RESPONSABILIDADES DO CLIENTE ................................................................................................... 185 4.3.6.3 RESPONSABILIDADES DO PROVEDOR DE SERVIÇOS,......................................................................... 186 4.3.6.4 SERVIÇOS PRESSUPOSTOS ................................................................................................................ 186
4.3.7 GERENCIAMENTO DO SERVIÇO.................................................................................................... 186 4.3.7.1 DISPONIBILIDADE DO SERVIÇO ......................................................................................................... 186 4.3.7.2 MEDIÇÃO DOS SERVIÇOS .................................................................................................................. 187 4.3.7.3 RELATÓRIO EM NÍVEL DE SERVIÇO .................................................................................................... 187 4.3.7.4 PEDIDOS DE SERVIÇOS ..................................................................................................................... 188 4.3.7.5 MANUTENÇÃO DOS SERVIÇOS ........................................................................................................... 188
4.3.8 MODELAGEM DO SERVIÇO ........................................................................................................... 189
4.5 GERENCIAMENTO DE SERVIÇO AUTOMATIZADO – BPMS .................................................... 193
APÊNDICE A – MODELAGEM DE PROCESSO ....................................................................................... 196
DIAGRAMA 1 ............................................................................................................................................... 196
3.31 CABARET FOIM FOIM ..................................................................................................................... 101
3.31.1 Elementos do processo ................................................................................. 101
3.31.1.1 Event ............................................................................................... 101
3.31.1.2 Levantar requisitos .......................................................................... 101
3.31.1.3 Elaborar documentação ................................................................... 101
3.31.1.4 Elaborar backlog ............................................................................. 101
3.31.1.5 Desenvolver o software .................................................................. 101
3.31.1.6 Gateway ........................................................................................... 102
3.31.1.7 Questionar dúvida ........................................................................... 102
3.31.1.8 Gateway ........................................................................................... 102
3.31.1.9 Testar software ................................................................................ 102
3.31.1.10 Gateway ......................................................................................... 102
3.31.1.11 Instalar software ............................................................................. 103
3.31.1.12 Event .............................................................................................. 103
16
3.31.1.13 Analise ........................................................................................... 103
3.31.1.14 Desenvolvimento ........................................................................... 103
3.31.1.15 Homologação ................................................................................. 103
3.31.1.16 Produção ........................................................................................ 103
CAPÍTULO 5 ................................................................................................................................................. 104
GERENCIAMENTO DE SERVIÇOS: SISTEMA BIBLIOTECÁRIO ......................................................... 104
5.1. INTRODUÇÃO ....................................................................................................................................... 104
5.2. REQUISITOS DO SISTEMA (SISTEMA BIBLIOTECÁRIO) ............................................................. 104 5.2.1 MOTIVAÇÃO ....................................................................................................................................... 105 5.2.2 O PROBLEMA IDENTIFICADO .............................................................................................................. 105 5.2.3 SOBRE A ORGANIZAÇÃO ..................................................................................................................... 105 5.2.4 PROPOSTAS PARA SISTEMA BIBLIOTECÁRIO ....................................................................................... 105
5.2.5 CONVENÇÕES PARA IDENTIFICAÇÃO DOS REQUISITOS ........................................................ 105
5.2.6 CONVENÇÕES PARA IDENTIFICAÇÃO DOS CASOS DE USO ................................................... 105 5.2.7 ESTRUTURA DOS CASOS DE USO .......................................................................................................... 105 5.2.8 PRIORIDADES DOS CASOS DE USO ....................................................................................................... 106 5.2.9 DESCRIÇÃO DOS ATORES .................................................................................................................... 106
5.3 REQUISITOS ORGANIZACIONAIS ..................................................................................................... 106
5.4. REQUISITOS FUNCIONAIS ................................................................................................................. 106 5.4.1 [RF01] EFETUAR LOGON .................................................................................................................... 107 5.4.2 [RF02] EFETUAR LOGOFF ................................................................................................................... 107 5.4.3 [RF03] INSERIR USUÁRIO ................................................................................................................... 107 5.4.4 [RF04] REMOVER USUÁRIO ............................................................................................................... 107 5.4.5 [RF05] ATUALIZAR USUÁRIO ............................................................................................................. 108 5.4.6[RF06] CONSULTAR USUÁRIOS ........................................................................................................... 108 5.4.7 [RF07] INSERIR LIVRO ....................................................................................................................... 108 5.4.8 [RF08] REMOVER LIVROS .................................................................................................................. 108 5.4.9 [RF09] ATUALIZAR LIVROS ................................................................................................................ 109 5.4.10 [RF10] CONSULTAR LIVROS ............................................................................................................. 109 5.4.11 [RF11] INSERIR DVDS ..................................................................................................................... 109 5.4.12 [RF12] REMOVER DVDS ................................................................................................................. 109 5.4.13 [RF13] ATUALIZAR USUÁRIO ........................................................................................................... 110 5.4.14 [RF14] CONSULTAR DVDS .............................................................................................................. 110 5.5 REQUISITOS NÃO FUNCIONAIS ............................................................................................................... 110 5.5.1 REQUISITOS DE PROCESSO .................................................................................................................. 110
5.5.1.1 [RNF01] Utilizar SCRUM como Metodologia de Desenvolvimento .................... 110 5.5.1.2 [NFR02] - DESENVOLVIMENTO EM JAVA ........................................................................................ 111 5.5.1.3 [NFR03] – UTILIZAR BANCO DE DADOS MYSQL ............................................................................. 111 5.5.2 REQUISITOS DE EXTERNOS ................................................................................................................. 111 5.5.2.1 [NRF04] - TEMPO DE DESENVOLVIMENTO ...................................................................................... 111 5.5.2.2 [RNF05] - CUSTO DE DESENVOLVIMENTO ...................................................................................... 112 5.5.3 REQUISITOS DE PRODUTO ................................................................................................................... 112 5.5.3.1 [RNF06] - PERMISSÃO ..................................................................................................................... 112 5.5.3.2 [RNF07] - BACKUP ......................................................................................................................... 112
17
5.5.3.3 [RNF08] - MENSAGENS DE RETORNO ............................................................................................. 112 5.5.3.4 [RNF09] - MENUS BEM ESTRUTURADOS ......................................................................................... 113
5.6 GERÊNCIA DE CONFIGURAÇÃO ....................................................................................................... 113 OBJETIVOS .................................................................................................................................................. 113
Organização do Documento ....................................................................................... 113
PAPEIS E RESPONSABILIDADES ............................................................................................................. 114
PLANO DE CONFIGURAÇÃO .................................................................................................................... 114 TIPOS DE CONFIGURAÇÃO ........................................................................................................................... 114 CONTROLE DE CONFIGURAÇÃO ................................................................................................................... 115
Estrutura do Repositório de Gerência de Configuração ............................................. 116 POLÍTICA DE SEGURANÇA ............................................................................................................................ 117
MÉTODOS DE IDENTIFICAÇÃO ............................................................................................................... 119 DOCUMENTOS ............................................................................................................................................. 119 CONFIGURAÇÃO BASE ................................................................................................................................. 120 DOCUMENTOS DE ANÁLISE DE SOFTWARE .................................................................................................. 120 DOCUMENTOS DE PROJETO DE SOFTWARE .................................................................................................. 120
CONTROLE DE MUDANÇAS ..................................................................................................................... 121
AMBIENTE, FERRAMENTAS E INFRA-ESTRUTURA ........................................................................... 125 PLANO DE SOFTWARE .................................................................................................................................. 125
COMISSÃO DE CONTROLE DE MUDANÇAS ......................................................................................... 126
Passo a passo: processo de gerenciamento de configurações: Estabelecer
sistema de configuração .......................................................................................... 128
Manter sistema de configuração ....................................................................... 128
identificar ites de configuraçãocom base nos critérios esabelecidos ................ 128
Criar a baseline com base nos itens de configuração que necessitam de um
controle formal. ...................................................................................................... 128
Registrar a situação atual dos itens de configuração ........................................ 128
Registrar a situação atual das baselines ............................................................ 128
Controlar as modificações dos itens de confiuração ......................................... 128
controlar o armazenameno dos itens de configuração e baselines .................... 128
Controlar o manuseio dos itens de configuração e baselines ........................... 128
Controlar a liberação dos itens de configuração e baselines ............................ 128
Realizar auditoria de cofiguração das baselines ............................................... 128
18
Realizar auditoria dos itens de configuração .................................................... 128
Comunicar as informações relacionadas aos itens de configuração às pastes
interessadas ............................................................................................................. 128
5.7 NÍVEL DE SERVIÇO .............................................................................................................................. 129
5.7.1 ACORDO GERAL ................................................................................................................................ 130
5.7.2 METAS E OBJETIVOS ....................................................................................................................... 130
5.7.3 RESPONSÁVEIS .................................................................................................................................. 130
5.7.4AMBIENTE DE SERVIÇO ................................................................................................................... 131
5.7.5 REVISÃO PERIÓDICA ........................................................................................................................ 133
5.7.6 CONTRATO DE SERVIÇO ................................................................................................................. 133 5.7.6.1 ESCOPO DO SERVIÇO ........................................................................................................................ 133 5.7.6.2 RESPONSABILIDADES DO CLIENTE ..................................................................................................... 134 5.7.6.3 RESPONSABILIDADES DO PROVEDOR DE SERVIÇOS ........................................................................... 134 5.7.6.4SERVIÇOS PRESSUPOSTOS .................................................................................................................. 135
5.7.7_GERENCIAMENTO DO SERVIÇO ................................................................................................... 135 5.7.7.1 DISPONIBILIDADE DO SERVIÇO ......................................................................................................... 136 5.7.7.2 MEDIÇÃO DOS SERVIÇOS .................................................................................................................. 136 5.7.7.3 RELATÓRIO EM NÍVEL DE SERVIÇO ................................................................................................... 136 A. PEDIDOS DE SERVIÇOS ....................................................................................................................... 137 B. MANUTENÇÃO DOS SERVIÇOS ............................................................................................................. 137
5.7.8_MODELO DE PROCESSO PARA INDISPONIBILIDADE NO SISTEMA: ..................................... 137
5.7.9_CUSTOS DOS SERVIÇOS .................................................................................................................. 138
5.8 GERENCIAMENTO DE SERVIÇO AUTOMATIZADO – BPMS ........................................................ 138
5.9 CONCLUSÃO .......................................................................................................................................... 141
19
Capítulo
1
Gerenciamento de Serviços: Integração do Banco de
Dados entre empresas de Diagnósticos na Cidade de
Caruaru
Gilberto João de Lima Junior, Jucyelle Cavalcante da Silva
Abstract
In the course of this document show to implement the integration of a database through
XML between companies hospital Diagnostics area of the city of Caruaru -PE , where the
bank data 1 through X company X system will generate an XML file where the database 2 ,
Y company , will , through the Y system , to integrate the data.
Resumo
Ao decorrer desde documento mostraremos como implementar a integração de um banco
de dados através de XML entre empresas da área de Diagnósticos Hospitalares da Cidade
de Caruaru-PE, onde o banco de dados 1 através do sistema X da empresa X, irá gerar um
arquivo XML onde o banco de dados 2, da empresa Y, irá, através do sistema Y, fazer a
integração dos dados.
20
1. Introdução
O objetivo desde documento é implementar a integração de um banco de dados
através de XML na empresa Centro de Diagnósticos X e da empresa Y, onde o banco de
dados 1 através do sistema X da empresa X, irá gerar um arquivo XML onde o banco de
dados 2, da empresa Y, irá, através do sistema Y, fazer a integração dos dados.
1.1. Motivação
Houve a necessidade desta integração devido à demora na geração dos dados da
Empresa X, que eram realizadas manualmente através de guias físicas, onde pessoas do
setor do faturamento, que eram as responsáveis pelo envio, escreviam os dados em um
doc.txt e enviavam de forma manual através de um e-mail institucional para a empresa
parceira Y.
1.1.2. Os Problemas Identificados
Os problemas identificados durante os envios destes dados eram os seguintes:
Demora na criação do arquivo de envio (doc.txt)
Erros na digitação do arquivo, onde as linhas com erro eram glosadas
“rejeitadas” pela empresa parceira Y.
Atraso no envio do arquivo, que sempre passa da data determinada pela Y,
ocasionando não pagamento devido ao atraso.
1.1.3. Sobre a Organização
As principais atividades exercidas pela empresa X é a terceirização dos serviços de
exames e diagnósticos por imagens solicitados pela Y, em suma, segmento voltado
à área clínica.
Realização de exames e diagnósticos por imagem incluem os seguintes exames:
RAIO-X
PET-CT
TOMOGRAFIA COMPUTADORIZADA
RESSONÂNCIA MAGNÉTICA
MAMOGRAFIA
RADIOLOGIA ORTODONTICA
DENSINTOMETRIA ÓSSEA
21
1.1.4. Propostas para integração do banco
As propostas são as seguintes:
Aumentar a velocidade de geração do arquivo.
Diminuir ou zerar a quantidade de erros existentes no arquivo durante a geração.
Garantir a integridade e segurança dos dados durante o envio, permitindo que o
layout seja apenas legível para o banco de dados que o vai receber.
1.1.5. Convenções para Identificação dos Requisitos
Por convenção, os requisitos são indicados e referenciados por um indicador no
formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não
funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os
nomes dos casos de uso relacionados.
1.1.6. Convenções para Identificação dos Casos de Uso
Por convenção, os casos de uso são indicados e referenciados por um indicador no
formato [UCxx], onde xx se refere ao número do caso de uso.
1.1.7. Estrutura dos casos de uso
Cada caso de uso terá o seguinte formato:
Atores: Os modelos de usuário que utilizarão o caso de uso;
Prioridade: Prioridade de implementação deste caso de uso;
Entradas: Variáveis que serão passadas ao sistema;
Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser
executado;
Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso
seja concluído, podendo incluir fluxos de eventos secundários e/ou
alternativos;
Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de uso for
executado;
Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser
finalizado.
1.1.8. Prioridades dos casos de uso
Os casos de uso são classificados como:
Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse
tipo de caso de uso deve ser implementado impreterivelmente, caso contrário, o
projeto perderá sua utilidade.
Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado.
Contudo, essa utilização se dá de forma não satisfatória pelo cliente.
22
Desejável: Esse tipo de caso de uso poderá ser implementado em versões
posteriores do sistema, visto que, mesmo sem a sua implementação, o sistema
atende as suas funcionalidades básicas.
1.1.9. Descrição dos Atores
Os atores são aqueles que interagem de alguma forma com o sistema. Eles são
bancos e instituições financeiras.
1.2. Requisitos Organizacionais
Os requisitos organizacionais devem satisfazer os objetivos da organização e definir
porque o sistema é necessário.
Esses requisitos são:
Facilitar a geração do arquivo de contas da Y;
Melhorar o a integridade e segurança do arquivo gerado;
Evitar erros durante geração manual.
1.2.1. Requisitos do Sistema
Neste capítulo são definidas as funções que o sistema deve realizar. Os requisitos
estão agrupados de acordo com suas características.
1.2.2. [RF01] Efetuar logon
Identificação: [RF01] Efetuar logon
Casos de Uso relacionados: [UC 01]
Descrição:
Permite que um usuário tenha acesso a informações
pertencentes ao software. Para isso, o usuário deve informar
login e senha. Não deve haver outra maneira de entrar no
sistema diferente desta.
Prioridade: Essencial Importante Desejável
23
1.2.3. [RF02] Efetuar logoff
Identificação: [RF02] Efetuar logoff
Casos de Uso relacionados: [UC 02]
Descrição: Permite que o usuário saia do sistema.
Prioridade: Essencial Importante Desejável
1.2.4. [RF03] Criar XML
Identificação: [RF03] Criar XML
Casos de Uso relacionados: [UC 03]
Descrição: O Usuário deve gerar o XML através do sistema no módulo
faturamento.
Prioridade: Essencial Importante Desejável
1.2.5. [RF05] Verificar erros antes da criação do XML
Identificação: [RF05] Verificar erros antes da criação do XML
Casos de Uso relacionados: [UC 05]
Descrição:
O sistema deve verificar antes de gerar o XML se há campos
em branco antes do envio para evitar erros, se houver erro o
mesmo deve apontar a linha com falha para a mesma possa ser
corrigida e novamente gerada pelo faturamento através do
sistema.
Prioridade: Essencial Importante Desejável
24
1.2.6. Requisitos Não Funcionais
Descreveremos a seguir, os requisitos que envolvem restrições e aspectos de
qualidade do sistema de controle de propostas de cartão, SisProposta. Os requisitos não
funcionais serão classificados em: requisitos de processo, requisitos externos e requisitos de
produto.
1.2.7. Requisitos de Processo
1.2.8. [NFR01] – Interagir com o SQLServer
Identificação [NFR01] – Interagir com o SQLServer
Casos de Uso
relacionados
Todos.
Descrição O sistema deve ter o layout de criação do arquivo
XML com interoperabilidade total entre as duas
instancias simultaneamente, obedecendo os campos
necessários para a integração.
Prioridade Essencial Importante
Desejável
1.2.9. Requisitos de Externos
1.2.10. [NRF02] - Conexão
Identificação [NRF02] - Conexão
Casos de Uso
relacionados
Todos.
Descrição A Y deve liberar uma porta de comunicação externa
para realização da conexão e efetivar a integração
“Insert”.
Prioridade Essencial Importante
Desejável
25
1.2.11. Requisitos de Produto
1.2.12. [RNF03] - Permissão
Identificação [NRF03] - Permissão
Casos de Uso
relacionados
Todos.
Descrição O sistema deve ter acesso de escrita na tabela “fatura”
na instância da Y.
Prioridade Essencial Importante
Desejável
Anexo A – Status das propostas e Controle Atual
Ao executar a aplicação, a mesma deve se conectar ao banco de dados e fazer o
select das informações necessárias, com uma trigger validar se existem campos em branco e
caso haja algum, deve retornar um erro dizendo a linha e a coluna que está faltando o
conteúdo, em seguida importa-las na extensão .XML e enviar para o banco de dados da Y
realizando um insert.
Anexo B – Descrição dos Casos de Uso
[UC01] Efetuar logon
Identificador: [UC 01]
Descrição: Autentica o usuário no sistema.
Atores: Faturista e Y
Prioridade: Essencial
Pré-condições: Não se aplica.
Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito.
Fluxo de Eventos Principal
1. Estando na tela inicial do sistema, o ator deve preencher os campos “login” e
“senha”;
2. O ator então clica no botão “OK”.
26
Fluxo Secundário 1
1. O ator fornece um login não cadastrado no sistema;
2. A mensagem “Usuário inexistente” é exibida.
Fluxo Secundário 2
1. O ator fornece um login e uma senha não correspondentes;
2. A mensagem “Senha incorreta” é exibida.
Requisitos Não Funcionais Específicos -
[UC02] Efetuar logoff
Identificador: [UC 02]
Descrição: Finaliza o acesso ao sistema.
Atores: Supervisor e Vendedores
Prioridade: Essencial
Pré-condições: O ator deve estar logado no sistema no momento da execução dessa
operação.
Pós-condições: O ator deixa de ter acesso às funcionalidades do sistema. O sistema
retorna à tela inicial.
Fluxo de Eventos Principal
1. O ator clica no botão “Sair”;
2. O sistema finaliza todas as operações que estão em execução devido às requisições
feitas por esse ator.
Requisitos Não Funcionais Específicos -
[UC03] Inserir número da fatura a ser gerada
Identificador: [UC 03]
Descrição: Insere um projeto no sistema.
Ator: Administrador do sistema.
27
Prioridade: Essencial
Pré-condições: O ator deve estar logado no sistema. Não aparecer nenhuma fatura
que já tenha sido enviada.
Pós-condições: Haverá um novo projeto cadastrado no sistema.
Fluxo de Eventos Principal
1. O ator seleciona no menu “FATURA” a opção “GERAR;
2. O sistema exibe o formulário de criação de um novo XML;
3. O ator informa os dados da fatura a ser gerada;
4. O ator clica no botão “OK”;
5. O sistema cadastra as informações na base e retorna para o formulário de
cadastro apresentando os campos limpos.
[UC04] Remover de XML
Identificador: [UC 04]
Descrição: Remove um XML do sistema e todos os registros relativos a ele.
Ator: Administrador do sistema.
Prioridade: Essencial
Pré-condições: O XML que se deseja remover não deve estar competência atual no
sistema.
Pós-condições: O registro do XML e todos os outros registros relativos não se
encontrarão mais no sistema.
Fluxo de Eventos Principal
28
1. Incluir o fluxo de eventos do caso de uso “[UC04] Listar XML”;
2. O ator seleciona o ícone de remoção de uma das entradas presentes na lista de Projeto;
3. O sistema exibe uma tela contendo um formulário com as informações do respectivo
XML e o botão “Excluir”;
4. O ator seleciona o botão “Excluir”;
5. O sistema exibe uma mensagem informando que o XML e outros registros
relacionados a ele serão removidos do sistema e pede a confirmação do usuário;
6. O ator confirma a exclusão;
7. O sistema remove os devidos registros e retorna para a tela de listar projetos.
Fluxo Secundário 1
1. No passo quatro do fluxo principal, o ator seleciona o botão “Cancelar”;
2. O sistema retorna para a tela de listar XML.
Fluxo Secundário 2
1. No passo seis do fluxo principal, o ator não confirma a exclusão;
2. O sistema retorna para a tela de listar de XML.
Requisitos Não Funcionais Específicos -
[UC05] Atualizar XML
Identificador: [UC 05]
Descrição: Atualiza as informações do XML.
Ator: Administrador do sistema.
Prioridade: Importante
Pré-condições: O XML a ser alterado deve estar presente no sistema.
Pós-condições: Os dados do XML informado na alteração serão persistidos no sistema.
Fluxo de Eventos Principal
29
1. Incluir o fluxo de eventos do caso de uso “[UC05] XML”;
2. O ator seleciona o ícone de alteração de uma das entradas presentes na lista de
XML’s;
3. O sistema exibe uma tela contendo um formulário com as informações do respectivo
XML e o botão “Alterar”;
4. O ator altera as informações desejadas;
5. O ator seleciona o botão “Alterar”;
6. O sistema persiste os novos dados do XML e volta para a tela de projetos.
Fluxo Secundário 1
1. No passo cinco do fluxo principal, o ator seleciona o botão “Cancelar”;
2. O sistema retorna para a tela de listar projetos.
Fluxo Secundário 2
1. No passo quatro do fluxo principal, o ator altera os dados do XML deixando-os iguais
ao de outra já cadastrada;
2. O sistema exibe uma mensagem avisando que já existe um projeto cadastrado com
esses dados e permanece na mesma tela com os campos preenchidos.
Requisitos Não Funcionais Específicos -
1.3. Gerência de Configuração
Introdução
Este documento descreve o Plano de Gerência de Configuração para o projeto de
integração do Banco de dados das empresas Clinica de diagnósticos X e o Hospital Y
Caruaru.
Objetivos
O presente documento tem por objetivo apresentar a organização, nomenclatura e
regras de versionamento para a gerencia de configuração do projeto de desenvolvimento do
sistema de integração.
Este plano é destinado a todos os integrantes da equipe responsável pelo o
desenvolvimento do sistema.
30
Papeis e Responsabilidades
Papel Responsabilidade
Gerente de Desenvolvimento (GD) Juntamente com a CCM (Comissão de Controle de
Mudanças) receber, analisar e aprovar os PFM
(Pedido Formal de Mu).
Líder de Projeto (LP) Planejar as atividades de GC (Gerência de
Configuração) juntamente com o RC (Responsável
pela Configuração), designar executante, autorizar
a criação das configurações bases conforme
descrito na seção Plano de Configuração.
Responsável pelo versionamento (RV) Criar, manter e alterar versão dos scripts de coleta
e envio de dados nos seus respectivos bancos.
a) Plano de Configuração
b) Verficar qual será a alteração a ser realizada.
c) Inserir no script qual tabela será excluída ou inserida.
d) Criar regra de rollback em caso de falha
e) Implementar em banco secundário para teste
f) Caso realizado com sucesso, implementar em produção.
Política de Segurança
A política de segurança definida para as pastas do repositório serão definidas
conforme tabela a seguir:
Branches SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração (RC) L, S, E, X
Outros Membros da Equipe L, S Tabela 1 - Permissões diretório Branches SVN
31
Tags SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração (RC) L, S, E, X
Outros Membros da Equipe L, S Tabela 2 - Permissões diretório Tags SVN
Trunk SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração (RC) L, S, E, X
Outros Membros da Equipe L, S Tabela 3 - Permissões diretório Trunk SVN
Wiki SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas Todos os Membros da Equipe L, S, E, X Tabela 4 - Permissões diretório Wiki SVN
Legenda: L – Ler
S – Salvar
E – Editar
X – Excluir
32
Métodos de Identificação
Documentos
Todos os documentos disponibilizados no repositório devem ser identificados
baseados na seguinte nomenclatura:
<ID_ARTEFATO> - <NOME_ARTEFATO>
Onde:
<ID_ARTEFATO> é a sigla de identificação do artefato conforme Tabela 19.
<NOME_ARTEFATO> é nome de identificação do artefato conforme Tabela
19.
ID_ARTEFATO NOME_ARTEFATO
APD Ativação de Projeto de Desenvolvimento
EOR Especificação de Objetivos e Requisitos
LPS Levantamento Preliminar do Software
PCP Plano de Comunicação do Projeto
PDS Plano de Desenvolvimento de Software
PGC Plano de Gerência de Configuração
PGQ Plano de Gerência da Qualidade
PGR Plano de Gerência de Riscos
RAC Relatório de Avaliação do Cliente
RAP Relatório de Acompanhamento do Projeto
PFM Pedido Formal de Modificação
SAI Solicitação de Análise de Impacto
RTF Relatório de RTF (Revisão Técnica Formal)
DAS Documento de Análise de Software
DPS Documento de Projeto de Software Tabela 5 - Identificadores e Nomes dos Artefatos
33
Controle de Mudanças
São definidos dois processos de controle de mudanças:
Procedimento Formal: este processo deve ser implementado quando a
mudança proposta afeta a última versão configuração já aprovada e estabelecida
o qual o item faça parte.
34
Pedido Formal de Mudança: O solicitante preenche o Pedido Formal de
Mudança conforme Pedido Formal de Mudança – PFM
PFM N°__________
1. Nome Solicitante:_________________________________________Data: ___/___/___
2. Descrição Detalhada: ________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
3. Comissão de Controle de Mudança:
Líder de Projeto:____________________________________________________________________
Equipe Técnica:_____________________________________________________________________
Equipe de Qualidade:________________________________________________________________
4. Resultado Triagem:
( ) Relevante Com Impacto
( ) Relevante Sem Impacto
( ) Irrelevante
5. Observações:_______________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade
Anexo 1, e envia para a Comissão de Controle de Mudança. Em cada PFM só
deve ter apenas uma mudança á ser avaliada.
35
Realizar Triagem de Mudança: A CCM com apoio da Equipe Técnica e da
Equipe de Qualidade realiza a triagem definindo a relevância e possível
impacto da mudança. O resultado da triagem pode gerar uma das seguintes
decisões: Relevante Com Previsão de Impacto Significativo, Relevante Sem
Previsão de Impacto Significativo e Mudança Irrelevante - Rejeitada.
Solicitação de Análise Detalhada de Impacto: As mudanças que foram
classificadas como Relevante com previsão de impacto significativo deve gerar
a Solicitação de Análise Detalhada de Impacto conforme modelo no Solicitação de Análise de Impacto – SAI
SAI N°_________
1. Nome Solicitante:_________________________________________________________________________Data: ___/___/_____ PFM Nº:_______
2. Responsáveis:_____________________________________________________________________________________________________________
3. Data de Inicio: ___/___/_____ Data de Término: ___/___/_____
4. Resultado Análise de Análise:
Item de Configuração Descrição da Alteração
Estimativa de Implementação Aprovação
ID Seção Esforço Tempo Custo
1 – Aprovada
2 – Reprovada – Tempo Excedido
3 – Reprovada – Custo Excedido
4 – Reprovada – Esforço Excedido
5 - Outros
5. Observações:__________________________________________________________________________________________________________________________
________________________________________________________________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade Cliente
Anexo 2.
Realizar Análise de Impacto: Estudo e análise de quais itens de configuração
a mudança impactará.
Relatório de Análise de Impacto: Relatório contendo a lista de itens de
configuração e o qual impacto sofrido pelo mesmo com a implementação da
mudança. Bem como a estimativa de esforço, de tempo e custo.
Negociar e Aprovar Mudanças: O CCM juntamente com o cliente negocia e
aprova se a mudança pode ser implementada. O resultado deste processo pode
gerar as seguintes decisões: Mudança Aprovada e Mudança Reprovada.
Mudança Aprovada: Relatório contendo a lista das alterações aprovadas que
serão implementadas.
Implementar Mudança: A CCM envia a mudança aprovada para o LP, que
providenciará a implementação da mudança.
36
Mudança Implementada: O LP envia para o RC a mudança implementada
solicitando que gere uma nova versão da configuração.
Gerar e Aprovar Configuração Base: Gera uma nova versão com as mudança
totalmente implementada.
Reportar Solicitante: A CCM envia ao solicitante se mudança foi reprovada
ou considerada irrelevante.
Modelagem
Modelagem de processo referenciado no apêndice B.
37
1.4. Nível de Serviço
Esse catálogo tem como finalidade definir serviços de TI oferecidos pela nossa
empresa de consultoria para a Clínica de Diagnósticos X, onde estaremos propondo
soluções em governança em ti para que possa minimizar problemas relacionados a falta de
controle dos serviços oferecidos.
Serviços:
Envio dos Arquivos XML – Após fechamento da competência mensal do faturamento,
será realizada pelo faturamento o envio do XML através do sistema de integração.
Código Unidade Organizacional
001 Suporte ao Usuário / Administração de Sistemas /
Descrição Características
Sistemas Disponibilidade, validação e envio dos dados nas rotinas de envio
dos XMLs “job’s”.
Requisitos de Execução Requisitos da Equipe
Verificar fechamento da competência
mensal antes do envio, validar erros
após geração do XML, após
validação fazer envio via sistema.
Todos os usuários envolvidos na operação do envio do
XML, devem ter total conhecimento na manipulação do
sistema através de treinamento.
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1. Disponibilidade do
software
50% em até
30 Min.
75% em 45
Min..
100% em até
55 Min..
Mensal
Janela: 1h x 1d =
1h/mês
Indisponibilidade:
719/mês
Disponibilidade:
98,9%/mês
Disponibilidade da base
de dados no período
específico.
*SLA – Dados fornecidos pela empresa que desenvolveu o software
38
Verificação de Erros de XML – Após gerar o arquivo XML o analista ficará responsável
pela verificação do arquivo gerado, com o intuito de evitar erros no arquivo gerado.
Código Unidade Organizacional
002 Analista de faturamento
Descrição Características
Verificação de Arquivo
Comparar o arquivo gerado com o arquivo de origem no
banco afim de visualizar se existem divergências através de
um checksum.
Requisitos de Atendimento Requisitos da Equipe
As divergências encontradas com os
arquivos gerados deverão ser
encaminhas pelo analista a equipe de
sistema responsável para análise.
Saber trabalhar com banco SQL Server 2008 R2 e ter conhecimentos
básicos de internet.
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1. Disponibilidade do
banco
50% em até
30 Min.
75% em 45
Min..
100% em até
55 Min..
Mensal
Janela: 1h x 1d =
1h/mês
Indisponibilidade:
719/mês
Disponibilidade:
98,9%/mês
Disponibilidade da base
de dados no período
específico.
*SLA – de acordo com informações disponibilizadas pelo fornecedor de hospedagem da
aplicação e que oferece o link de internet.
39
40
Módulos:
Login: Este módulo é responsável pela autenticação do usuário no sistema.
41
42
Tela de Menu
Criar XML: Responsável pela geração do arquivo a ser enviado.
EnviarXML: Responsável pelo envio do arquivo gerado.
Apagar XML: Responsável pela exclusão do arquivo gerado em caso de erro.
Logout: Sair do Sistema.
Pesquisa: Pesquisar XML’s enviados.
DATA: Pesquisa por data.
Fatura da competência: Pesquisar faturas inclusas na competência a ser enviada.
1.5. Gerenciamento de Serviço Automatizado – BPMS
Módulos:
Figura A mostra os campos que o usuário deve inserir no processo de abertura do chamado
FIGURA A
43
Figura B mostra a visão inicial da fila NIVEL 1 no momento de preencher se existe
chamados existentes em aberto
FIGURA B
Figura C mostra a visão de atendimento da fila NIVEL 1 se o chamado foi resolvido ou não.
FIGURA C
44
Figura D mostra a visão inicial da fila NIVEL 2 no momento de preencher se existe
chamados existentes em aberto
FIGURA D
Figura E mostra a visão de atendimento da fila NIVEL 2 se o chamado foi resolvido ou não.
FIGURA E
45
Figura F mostra a visão inicial da fila NIVEL 3 no momento de preencher se existe
chamados existentes em aberto
FIGURA F
Figura G mostra a visão de atendimento da fila NIVEL 3 se o chamado foi resolvido ou
não.
FIGURA G
46
Figura H mostra a visão de atendimento quando o chamado depende de serviços de
terceiros para ser resolvido.
FIGURA H
Figura I mostra a visão do usuário para responder se o chamado foi solucionado ou não.
FIGURA I
47
Figura J mostra a visão do usuário para o feedback de qualificação do chamado.
FIGURA J
A figura K mostra o encerramento do chamado por completo
FIGURA K
48
1.6 Conclusão
Mostraremos como implementar a integração de um banco de dados através de XML entre
empresas da área de Diagnósticos Hospitalares da Cidade de Caruaru-PE, onde o banco de
dados 1 através do sistema X da empresa X, irá gerar um arquivo XML onde o banco de
dados 2, da empresa Y, irá, através do sistema Y, fazer a integração dos dados.
A facilidade de quem irá operar a ferramenta será incomparável com a forma antiga, a
garantia de segurança e integridade dos dados serão preservadas de forma totalmente
segura.
O link que irá trabalhar realizando essa transferência será uma rede em anel, que irá garantir
a entrega do pacote, com rapidez se passar por nenhuma ISP, será PTP.
Em suma, o que ocorrerá, será a velocidade mais eficiente de criação do arquivo e do envio,
maximizando a eficiência na entrega e na confiabilidade dos dados.
Antes os usuários levariam 5 dias para fazer esse processo, hoje, com o novo recurso do
software, é realizado em 2 horas, elevando a produtividade do setor e principalmente da
empresa.
O processo de Versionamento do sistema é feito através da necessidade uma nova função,
onde a empresa responsável é acionada e implementa a nova função e é validada pelos
usuários.
49
Apêndice A - Prototipagem de Tela
A figura 1 contempla os requisitos funcionais 01.
50
FIGURA 1
A figura 2 contempla os requisitos funcionais 02 e 03.
51
FIGURA 2
52
Apêndice B - Modelagem do Processo
1. DIAGRAMA
53
1 . 1 A V A L I A Ç Ã O
1.1.1 ELEMENTOS DO PROCESSO
1.1.1.1 Event
1.1.1.2 Verificar necessidades do cliente
1.1.1.3 Analisar Requisitos
1.1.1.4 Gateway
54
Descrição
Se o requisito for válido passa para a etapa de validação, se acaso não volta para verificação das necessidades do cliente.
Portões
NÃO
SIM
1.1.1.5 Validar Requisitos
1.1.1.6 Organizar Backlog
1.1.1.7 Priorizar Backlog
1.1.1.8 Executar Sprint
1.1.1.9 Testar Sprint
1.1.1.10 Gateway
55
Descrição
Se o Sprint for Aprovado vai para o suporte executar a implementação, se acaso não for aprovado volta para o desenvolvimento executar a sprint
Portões
Reprovado
Aprovado
1.1.1.11 Implementar Sistema no Cliente
1.1.1.12 Event
1.1.1.13 Analista
1.1.1.14 Gestão
1.1.1.15 Desenvolvimento
1.1.1.16 Tester
1.1.1.17 Suporte
56
22 DD II AA GG RR AA MM 11
57
2 . 1 G E R E N C I A D E C O N F I G U R A Ç Ã O
2.1.1 PROCESS ELEMENTS
2.1.1.1 IDENTIFICAR TIPO DE CONFIGURAÇÃO
2.1.1.2 VERIFICAR CRITÉRIOS À SEREM CONFIGURADOS
2.1.1.3 ESTABELECER CRITÉRIOS PARA CONFIGURAÇÃO
2.1.1.4 CONCEDER ACESSO DE ARMAZENAMENTO DAS CONFIGURAÇÕES E
MANUSEIO À QUEM SE FIZER NECESÁRIO
2.1.1.5 AS MODIFICAÇÕES DE ITENS SERÃO CONTROLADAS
2.1.1.6 CONTROLAR A LIBERAÇÃO DOS ITENS DE CONFIGURAÇÃO POR QUEM
FOR AUTORIZADO.
2.1.1.7 AUDITORIA DOS ITENS DOS ITENS DE CONFIGURAÇÕES E ASSEGURAR
INTEGRIDADE DAS MESMAS.
2.1.1.8 AS INFORMAÇÕES DE CONFIGURAÇÃO SERÃO ENTREGUES AS PARTES
QUE SE FIZEREM DE DIREITO.
2.1.1.9 IDENTIFICAÇÃO
58
2.1.1.10 ARMAZENAMENTO E ITENS DE CONFIGURAÇÃO
2.1.1.11 AUDITORIA
Anexo C – Glossário
• Banco de dados SQL-SERVER 2008 R2: O programa SQL-SERVER é um
sistema de gerenciamento de banco de dados relacionais baseado em comandos SQL
(Structured Query Language - Linguagem Estruturada para Pesquisas) que vem ganhando
grande popularidade, sendo atualmente um dos bancos de dados mais populares.
• Login: Trata-se de uma sequência de caracteres utilizada para identificar um usuário
de forma única.
• Log on: Termo utilizado para demonstrar a ação de um usuário quando entra no
sistema dom login e senha.
• Log off: Termo utilizado para demonstrar a ação de um usuário quando este sai do
sistema.
59
Capítulo
2
Gerenciamento de Serviços: Controle de equipamentos
Jackson Daniel Almeida and Lívio Scílas Jerônimo
Abstract
This project was born from to need to control the devices, parts of devices, cell phone lines
and asset informatics acquired by enterprise and managed by I.T. department. Was evident
the difficult that the I.T. manager had to manage, to keep and to control this resources.
With the developer and implantation of the system of control, the I.T. manager can to be an
effective e precise control of these resources and has passed to deploy periodic reports to
board of directors with accurate information about the need for investment and durability
of devices. The focus of this work was in the development and optimization, following the
directives of the BPMN, using the Bizagi Studio like the tool of the modeling of the
planning processes, implantation and monitoring.
Resumo
Este projeto de sistema nasceu da necessidade de controlar os equipamentos, peças dos
equipamentos, linhas de celular e ativos de informática adquiridos pela empresa e
mantidos pelo setor de T.I. Era evidente a dificuldade que o gestor de T.I. tinha para
administrar, manter e também controlar estes recursos. Com o desenvolvimento e
implantação do sistema de controle, o gestor de T.I. pôde ter um controle eficaz e precisos
destes recursos e passou a entregar relatórios periódicos à diretoria com informações
sobre necessidade de investimentos e durabilidade dos equipamentos. O foco deste
trabalho foi no desenvolvimento e otimização seguindo as diretrizes da BPMN usando o
Bizagi Studio como ferramenta de modelagem dos processos de planejamento, implantação
e monitoramento.
60
2.1. Introdução
O processo de controle de equipamentos, peças dos equipamentos e linhas de celular era
feito praticamente de forma manual, sem padrões, sem relatórios e sem histórico de
alterações. A empresa analisada é a “Empresa X”. O foco da melhoria do processo é em
organizar o controle das peças e equipamentos e linhas de celular através de um software
para cadastros destes itens, com controles que incluem data de compra e histórico, entre
outras informações.
2.2. Requisitos do Sistema - Processo de controle de equipamentos
2.2.1. Introdução
Este documento visa descrever uma dificuldade de administração que foi
identificada tal como especificar os requisitos e a solução encontrada para esta dificuldade.
Tal problema foi identificado durante a visita realizada para estudo da viabilidade da
solução. Esta solução proverá um sistema de informação que será construído sobre as
informações coletadas.
2.2.2. Motivação
É crescente e constante a aquisição de equipamentos e peças para o setor de T.I. e
também de aparelhos eletrônicos para a empresa; da mesma maneira está crescente a
aquisição de linhas telefônicas celulares para os colaboradores. Controlar, de forma eficaz e
precisa, a localização dos equipamentos e peças, o controle de uso das peças, tal como
garantias e data de compra; controlar com quem está cada linha de celular e também
detalhes de cada linha está sendo um grande desafio para o gestor destes recursos.
Este projeto propõe desenvolver uma ferramenta para auxiliar o gerenciamento dos
itens acima citados por seus encarregados.
2.2.3. O Problema Identificado
Os ativos do setor de TI, tais como servidores, computadores, impressoras; as peças,
tais como memória e disco rígido; e também aparelhos eletrônicos, como celulares, não têm
61
um controle de data compra, de onde estão instalados ou por quem está sendo usado, dando
margem para extravio de equipamentos ou aparelhos, perda de controle de tempo de
garantia e dificuldade em identificar, junto à diretoria, o custo de manutenção que um
determinado equipamento está tendo.
Diante deste cenário, identificamos que o gestor dos recursos acima mencionados,
precisa de uma ferramenta para cadastrar estes recursos, de forma que ele possa controlá-los
de forma centralizada, sendo capaz de dar respostas em tempo hábil à diretoria sobre
localização de equipamentos, data de compra, histórico de manutenção, entre outras
informações pertinentes ao objeto cadastrado.
2.2.4. Sobre o departamento de T.I.
Uma das atividades do departamento de T.I. é gerir os equipamentos, peças e
aparelhos que estão sob sua responsabilidade.
2.2.5. Convenções para Identificação dos Requisitos
Por convenção, os requisitos são indicados e referenciados por um indicador no formato
[RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde
xx se refere ao número do requisito. Os requisitos também possuirão os nomes dos casos de
uso relacionados.
2.2.6. Convenções para Identificação dos Casos de Uso
Por convenção, os casos de uso são indicados e referenciados por um indicador no formato
[UCxx], onde xx se refere ao número do caso de uso.
2.2.7. Estrutura dos casos de uso
Cada caso de uso terá o seguinte formato:
Atores: Os modelos de usuário que utilizarão o caso de uso;
Prioridade: Prioridade de implementação deste caso de uso;
Entradas: Variáveis que serão passadas ao sistema;
Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser
executado;
62
Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso
seja concluído, podendo incluir fluxos de eventos secundários e/ou
alternativos;
Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de uso for
executado;
Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser
finalizado.
2.2.8. Prioridades dos casos de uso
Os casos de uso são classificados como:
Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse
tipo de caso de uso deve ser implementado impreterivelmente, caso contrário, o
projeto perderá sua utilidade.
Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado.
Contudo, essa utilização se dá de forma não satisfatória pelo cliente.
Desejável: Esse tipo de caso de uso poderá ser implementado em versões
posteriores do sistema, visto que, mesmo sem a sua implementação, o sistema
atende as suas funcionalidades básicas.
2.2.9. Descrição dos Atores
Os atores são aqueles que interagem de alguma forma com o sistema. Eles são bancos e
instituições financeiras.
2.3. Requisitos Organizacionais
Os requisitos organizacionais devem satisfazer os objetivos da organização e definir
porque o sistema é necessário. Esses requisitos são:
Centralizar a controle de ativos de T.I., peças, equipamentos, aparelhos eletrônicos e
linhas de celulares.
Fornecer à diretoria da empresa informações em tempo hábil acerca dos
equipamentos que estão sob a gestão do setor de T.I.
Melhorar o controle de manutenção de equipamentos, informando, em seu cadastro,
um histórico de ocorrências.
63
2.4. Requisitos Funcionais
Neste capítulo são definidas as funções que o sistema deve realizar. Os requisitos estão
agrupados de acordo com suas características.
2.4.1. [RF01] Efetuar logon
Identificação: [RF01] Efetuar logon
Casos de Uso relacionados: [UC 01]
Descrição:
Permite que um usuário tenha acesso a informações
pertencentes ao software. Para isso, o usuário deve informar
login, senha e estar ativo no sistema. Não deve haver outra
maneira de entrar no sistema diferente desta.
Prioridade: Essencial Importante Desejável
2.4.2. [RF02] Efetuar logoff
Identificação: [RF02] Efetuar logoff
Casos de Uso relacionados: [UC 02]
Descrição: Permite que o usuário encerre sua sessão no sistema.
Prioridade: Essencial Importante Desejável
2.4.3. [RF03] Inserir Usuário
Identificação: [RF03] Inserir usuário
Casos de Uso relacionados: [UC 03]
Descrição:
Os usuários com perfil administrador e analista do sistema
inserem um novo usuário no banco de dados do sistema. Um
usuário tem os dados: Nome, e-mail, Senha, Empresa ao qual é
funcionário e situação (Ativo ou Inativo).
Prioridade: Essencial Importante Desejável
64
2.4.4. [RF04] Remover Usuário
Identificação: [RF04] Remover Usuário
Casos de Uso relacionados: [UC 04]
Descrição:
O usuário com perfil administrador do sistema remove um
Usuário no banco de dados do sistema. Ao realizar essa
operação o sistema deve também remover todas as solicitações
do Usuário.
Um pedido de confirmação deve ser requerido ao
administrador, juntamente com uma mensagem informando
qual Usuário excluído.
Prioridade: Essencial Importante Desejável
2.4.5. [RF05] Atualizar Usuário
Identificação: [RF05] Atualizar Usuário
Casos de Uso relacionados: [UC 05]
Descrição: Os usuários com perfil administrador e analista do sistema
atualizam os dados de um Usuário
Prioridade: Essencial Importante Desejável
2.4.6. [RF06] Listar Usuários
Identificação: [RF06] Listar Usuários
Casos de Uso
relacionados:
[UC 06]
Descrição: Lista os Usuários do sistema.
Prioridade: Essencial Importante Desejável
65
2.4.7. [RF07] Alterar Senha
Identificação: [RF07] Alterar Senha
Casos de Uso relacionados: [UC 03]
Descrição:
Os usuários com status ativo do sistema alteram sua própria
senha no sistema através da confirmação de sua senha atual e a
inserção da nova senha.
Prioridade: Essencial Importante Desejável
2.4.8. [RF08] Inserir Empresa
Identificação: [RF08] Inserir Empresa
Casos de Uso relacionados: [UC 04]
Descrição:
Os usuários com perfil administrador e analista do sistema
inserem uma nova Empresa no banco de dados do sistema.
Uma Empresa tem os dados: Nome Fantasia, Razão Social,
Telefone, CNPJ, ETC.
Prioridade: Essencial Importante Desejável
2.4.9. [RF09] Remover Empresa
Identificação: [RF09] Remover Empresa
Casos de Uso relacionados: [UC 05]
Descrição: O usuário com perfil administrador do sistema remove uma
Empresa no banco de dados do sistema. A exclusão não deve
66
ser permitida caso a Empresa possua vínculos com usuários ou
equipamentos.
Um pedido de confirmação deve ser requerido ao
administrador, juntamente com uma mensagem informando
qual a Empresa excluída.
Prioridade: Essencial Importante Desejável
2.4.10. [RF10] Atualizar Empresa
Identificação: [RF10] Atualizar Empresa
Casos de Uso relacionados: [UC 06]
Descrição: Os usuários com perfil administrador e analista do sistema
atualizam os dados de uma Empresa.
Prioridade: Essencial Importante Desejável
2.4.11. [RF11] Listar Empresas
Identificação: [RF11] Listar Empresas
Casos de Uso relacionados: [UC 06]
Descrição: Lista as Empresas do sistema.
Prioridade: Essencial Importante Desejável
2.4.12. [RF12] Inserir Perfil
Identificação: [RF12] Inserir Perfil
Casos de Uso relacionados: [UC 06]
Descrição: Os usuários com perfil administrador e analista do sistema
67
inserem um novo Perfil no banco de dados do sistema. Um
Perfil define os níveis de acesso de cada usuário às funções
do sistema (Inserir, Remover, Atualizar, Listar).
Prioridade: Essencial Importante Desejável
2.4.13. [RF13] Remover Perfil
Identificação: [RF13] Remover Perfil
Casos de Uso relacionados: [UC 06]
Descrição:
O usuário com perfil administrador do sistema remove um
Perfil no banco de dados do sistema. Ao realizar essa
operação, os usuários cadastrados com esse perfil ficaram
sem nenhum acesso.
Um pedido de confirmação deve ser requerido ao
administrador, juntamente com uma mensagem informando
qual o Perfil excluído.
Prioridade: Essencial Importante Desejável
2.4.14. [RF14] Atualizar Perfil
Identificação: [RF14] Atualizar Perfil
Casos de Uso relacionados: [UC 06]
Descrição: Os usuários com perfil administrador e analista do sistema
atualizam as permissões de um Perfil
Prioridade: Essencial Importante Desejável
68
2.4.15. [RF15] Listar Perfis
Identificação: [RF15] Listar Perfis
Casos de Uso relacionados: [UC 06]
Descrição: Lista os Perfis do sistema.
Prioridade: Essencial Importante Desejável
2.4.16. [RF16] Inserir Equipamento
Identificação: [RF16] Inserir Equipamento
Casos de Uso relacionados: [UC 06]
Descrição:
Os usuários com perfil administrador e analista do sistema
inserem um novo Equipamento no banco de dados do
sistema. Um Equipamento possui os dados: Descrição,
Fabricante, Modelo, N° Série, Data de compra, Valor de
compra, Tipo, Status (Disponível, Em Uso, Defeito, Enviado
para assistência), ETC.
Prioridade: Essencial Importante Desejável
2.4.17. [RF17] Remover Equipamento
Identificação: [RF17] Remover Equipamento
Casos de Uso relacionados: [UC 06]
Descrição: O administrador do sistema remove um Equipamento no
banco de dados do sistema. Ao realizar essa operação o
69
sistema deve também remover todas as solicitações do
Equipamento.
Um pedido de confirmação deve ser requerido ao
administrador, juntamente com uma mensagem informando
qual o Equipamento excluído.
Prioridade: Essencial Importante Desejável
2.4.18. [RF18] Atualizar Equipamento
Identificação: [RF18] Atualizar Equipamento
Casos de Uso relacionados: [UC 06]
Descrição: Os usuários com perfil administrador e analista do sistema
atualizam os dados de um Equipamento.
Prioridade: Essencial Importante Desejável
2.4.19. [RF19] Listar Equipamentos
Identificação: [RF19] Listar Equipamento
Casos de Uso relacionados: [UC 06]
Descrição: Lista os Equipamentos do sistema.
Prioridade: Essencial Importante Desejável
70
2.4.20. [RF20] Solicitar Equipamento
Identificação: [RF20] Solicitar Equipamento
Casos de Uso relacionados: [UC 06]
Descrição:
Um usuário com perfil que permita solicitar equipamento faz
a solicitação de um equipamento no sistema. A solicitação
deve possuir os dados: usuário que solicitou (previamente
cadastrado no sistema) data de solicitação, descrição de uso,
ETC.
A solicitação precisa de um usuário responsável que será
associado como “solicitante”.
Ao realizar a solicitação, o status do equipamento deve ser
alterado para “Em uso” (Automaticamente).
Prioridade: Essencial Importante Desejável
2.4.21. [RF21] Devolver Equipamento
Identificação: [RF21] Devolver Equipamento
Casos de Uso relacionados: [UC 06]
Descrição:
Um usuário com perfil que permita devolver equipamento faz
a devolução de um equipamento no sistema. A devolução
deve possuir os dados: Data de devolução, Descrição do
estado do equipamento, ETC.
Ao realizar a devolução, o status do equipamento deve ser
alterado para “Disponível” (Automaticamente).
Prioridade: Essencial Importante Desejável
2.4.22. [RF22] Enviar à Assistência
Identificação: [RF22] Enviar à Assistência
71
Casos de Uso relacionados: [UC 06]
Descrição:
Um usuário com perfil que permita relatar o envio de um
equipamento à assistência faz o registro do envio no sistema.
O envio para a assistência deve possuir os dados: Data de
envio, Descrição de problema, dados da assistência técnica,
valor prévio, previsão de retorno, ETC.
Prioridade: Essencial Importante Desejável
2.4.23. [RF23] Retornar de Assistência
Identificação: [RF23] Retornar de assistência
Casos de Uso relacionados: [UC 06]
Descrição:
Um usuário com perfil que permita relatar o retorno de um
equipamento da assistência faz o registro do retorno no
sistema. O retorno do equipamento deve possuir os dados:
Data de retorno, descrição de solução, valor cobrado, ETC.
Prioridade: Essencial Importante Desejável
2.4.24. [RF24] Relatório de Equipamento
Identificação: [RF24] Relatório de Equipamento
Casos de Uso relacionados: [UC 06]
Descrição:
Um usuário com perfil que permita emitir relatório de
equipamento emite um relatório com informações e o
histórico de todas as solicitações, devoluções, idas à
assistência e retornos da assistência do equipamento no
sistema.
Prioridade: Essencial Importante Desejável
72
2.5. Requisitos Não Funcionais
Descreveremos a seguir, os requisitos que envolvem restrições e aspectos de
qualidade do sistema de controle de propostas de cartão, SisProposta. Os requisitos não
funcionais serão classificados em: requisitos de processo, requisitos externos e requisitos de
produto.
2.5.1. Requisitos de Processo
2.5.1.1. [RNF01] Utilizar SCRUM como Metodologia de
Desenvolvimento
Identificação [NFR01] – Desenvolvimento em SCRUM
Casos de Uso
relacionados
Todos.
Descrição O SCRUM será a metodologia empregada, pois
permite agilidade e participação ativa dos
stakeholders. Além disso, como o sistema será
gerenciado pela empresa desenvolvedora, não será
necessária a geração de uma documentação formal
extensa.
Prioridade Essencial Importante
Desejável
2.5.1.2. [NFR02] - Desenvolvimento em Java
Identificação [NFR02] – Desenvolvimento em PHP
Casos de Uso
relacionados
Todos.
Descrição O sistema deve ser desenvolvido utilizando a
linguagem PHP compatível com o servidor Apache
Tomcat 7.0.
Prioridade Essencial Importante
Desejável
2.5.1.3. [NFR03] – Utilizar Banco de Dados MySql
Identificação [NFR03] - Utilizar Banco de Dados MySql
Casos de Uso
relacionados
Todos.
Descrição A empresa dispõe de um serviço de banco de dados em
MySql, contratado e não utilizado. Portanto, a
73
aplicação deverá fazer desse serviço ocioso para
persistência dos dados.
Prioridade Essencial Importante
Desejável
2.5.2. Requisitos de Externos
2.5.2.1. [NRF04] - Tempo de Desenvolvimento
Identificação [NRF04] - Tempo de Desenvolvimento
Casos de Uso
relacionados
Todos.
Descrição O tempo para desenvolvimento do sistema não deve
ultrapassar o prazo previsto no documento de
viabilidade, visto a urgência da solução descrita no
mesmo documento. Dessa forma, o tempo de
desenvolvimento total não pode ser superior a 2 meses.
Prioridade Essencial Importante
Desejável
2.5.2.2. [RNF05] - Custo de Desenvolvimento
Identificação [NRF05] - Custo de Desenvolvimento
Casos de Uso
relacionados
Todos.
Descrição O custo de desenvolvimento não deve ultrapassar o
valor estimado no documento de viabilidade. Então,
para o trabalho de 2 meses temos que não se deve
ultrapassar o valor de R$ 5.998,60.
Prioridade Essencial Importante
Desejável
2.5.3. Requisitos de Produto
2.5.3.1. [RNF06] - Permissão
Identificação [NRF06] - Permissão
Casos de Uso
relacionados
Todos.
74
Descrição Cada usuário só poderá realizar ações que foram
permitidas a ele na hora do seu cadastro.
Prioridade Essencial Importante
Desejável
2.5.3.2. [RNF07] - Backup
Identificação [NRF07] - Backup
Casos de Uso
relacionados
Todos.
Descrição O sistema deverá disparar Backups agendados a fim de
aumentar a segurança em caso de perda de dados pela
empresa contratada para o serviço de hospedagem do
banco.
Prioridade Essencial Importante
Desejável
2.5.3.3. [RNF08] - Mensagens de Retorno
Identificação [NRF08] – Mensagens de Retorno
Casos de Uso
relacionados
Todos.
Descrição O sistema deverá exibir uma mensagem na tela para
toda ação do usuário, seja ela bem sucedida ou não,
bem como uma descrição do motivo quando for
necessário.
Prioridade Essencial Importante
Desejável
2.5.3.4. [RNF09] - Menus bem Estruturados
Identificação [NRF09] – Menus bem Estruturados
Casos de Uso
relacionados
Todos.
Descrição Os menus devem ser bem estruturados de modo a
permitir uma navegação simples e intuitiva,
proporcionando uma interface simples, melhorando a
usabilidade.
Prioridade Essencial Importante
Desejável
Figura 1 Modelagem de Requisitos Funcionais (Casos de Uso)
75
2.6. Conclusão
Através do documento de requisitos, foi possível entender, através de uma breve
descrição, o problema a ser resolvido com o sistema SGE.
Em seguida foram apresentados todos os requisitos funcionais do sistema, isto é,
todos os serviços que o SGE deve oferecer aos seus usuários, segundo a definição do
cliente.
Seguindo os requisitos funcionais, foram apresentados os requisitos não-funcionais,
que irão definir restrições de como o sistema irá funcionar baseado em seus requisitos
funcionais.
Também foi abordada a modelagem organizacional do sistema usando a notação i*,
em que foram incluídos os modelos de dependência estratégica (SD) e o modelo estratégico
de razão (SR) com os atores.
Dando continuidade à modelagem de requisitos funcionais, através do diagrama de
casos de uso, foram descritos os casos de uso do sistema, incluindo seus fluxos de eventos e
dependências entre si.
Finalmente, foi feita a modelagem dos requisitos não-funcionais utilizando a
plataforma NFR, mostrando os refinamentos deles, explicitando operacionalizações e
interdependências entre eles.
Referências
[Disciplina] Disciplina de Especificação de Requisitos e Validação de Sistemas.
Disponível em: <https://sites.google.com/a/cin.ufpe.br/if716/>. Acesso em: 05 mai. 11.
Site Atigonal, Artigos Gratuitos: <http://www.artigonal.com/administracao-artigos/como-
se-tornar-correspondente-bancario-2381049.html>
[Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering : Processes
and Techniques , John Wiley & Sons, 1998.
Relatório da Equipe
Nesta última seção, segue a porcentagem de esforço de cada membro da equipe. As
atividades realizadas por cada um estão descritas no Histórico de Revisões deste
documento.
Nome Esforço da equipe (%) Assinatura
Jackson Daniel 50%
Lívio Scílas 50%
Tabela 6Porcentagem de esforço dos membros da equipe
76
2.7. Anexo A – Realização de cadastros e manutenção de registros
Ao realizar um cadastro o analista ou administrador deverá preencher todos os
campos dos cadastros com as informações solicitadas.
O analista ou administrador do sistema deverá, ainda, realizar a manutenção dos
registros, mantendo os cadastros atualizados, realizando as alterações pertinentes aos
registros e informando as ocorrências de cada peça, equipamento ou linha telefônica no
campo Histórico.
Apenas o administrador do sistema poderá apagar algum registro, cadastrar ou
apagar usuário, cadastrar ou apagar empresa e cadastrar ou apagar perfil de usuário.
2.8. Anexo B – Descrição dos Casos de Uso
[UC01] Cadastrar um equipamento
Identificador: [UC 01] Cadastrar um equipamento
Descrição: Cadastrar um equipamento
Atores: Administrador, analista
Prioridade: Essencial
Pré-condições: Não se aplica.
Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito.
Fluxo de Eventos Principal
1. Após preencher os campos referentes ao cadastro do equipamento, o ator deve clicar
em “Salvar” para adicionar o cadastro ao banco de dados.
2. Volta para a tela dos registros, como segue na imagem 1.
Fluxo Secundário 1
1. O ator não preenche todos os campos pre-requeridos no cadastro do equipamento e
clica em “Salvar”.
2. É exibida uma mensagem de erro informando que os campos obrigatórios não foram
preenchidos e informa os campos que não foram preenchidos.
3. Os campos que são de preenchimento obrigatório e não foram preenchidos ficam em
evidência, conforme na imagem 2.
Fluxo Secundário 2
77
1. O ator, no campo referente a data, informa letras e pressiona a tecla TAB ou clica
em outro campo.
2. O sistema automaticamente preenche o campo com a data atual.
Requisitos Não Funcionais Específicos -
[UC02] Excluir o cadastro de um equipamento
Identificador: [UC 02] Excluir o cadastro de um equipamento
Descrição: Excluir um cadastro de equipamento
Atores: Administrador
Prioridade: Essencial
Pré-condições: Não se aplica.
Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito.
Fluxo de Eventos Principal
3. Estando na tela de cadastros, o ator deve clicar em “Excluir” referente ao registro.
4. O ator clica no botão “Remover”, conforme imagem 3.
5. Volta para a tela dos registros, conforme imagem 4.
Fluxo Secundário 1
4. Estando na tela do registro, o ator deve clicar em Excluir.
5. O ator clica no botão “Voltar”, conforme imagem 5.
6. Volta para a tela do registro, conforme imagem 6.
Fluxo Secundário 2
3. Estando na tela do registro, o ator deve clicar em Excluir.
4. O ator clica no botão “Fechar” ( X ), conforme imagem 7.
5. Volta para a tela do registro, conforme imagem 8.
Requisitos Não Funcionais Específicos -
2.9. Anexo C – Glossário
• Banco de dados MySQL: O programa 'MySQL' é um sistema de gerenciamento de
banco de dados relacionais baseado em comandos SQL (Structured Query Language -
78
Linguagem Estruturada para Pesquisas) que vem ganhando grande popularidade, sendo
atualmente um dos bancos de dados mais populares, com mais de 4 milhões de instalações.
• Login: Trata-se de uma sequência de caracteres utilizada para identificar um usuário
de forma única.
• Log on: Termo utilizado para demonstrar a ação de um usuário quando entra no
sistema dom login e senha.
• Log off: Termo utilizado para demonstrar a ação de um usuário quando este sai do
sistema.
2.10. Apêndice – Imagens
Imagem 1
Imagem 2
Imagem 3
79
Imagem 4
Imagem 5
80
Imagem 6
Imagem 7
Imagem 8
81
Imagem 9
Modelagem do processo SCRUM que descrevem os passos de coleta dos requisitos até o
desenvolvimento de cada Sprint. Os detalhamentos do processo estão no apêndice, item
2.7.1 – Scrum.
82
2.1. Gerência de Configuração
2.1.1. Introdução
Este documento descreve o Plano de Gerência de Configuração para o projeto de
desenvolvimento do SGE – Sistema de Gestão de Estoque.
2.1.2. Objetivos
O presente documento tem por objetivo apresentar a organização, nomenclatura e
regras de versionamento para a gerencia de configuração do projeto de desenvolvimento do
Sistema de Gestão de Estoque.
Este plano é destinado a todos os integrantes da equipe responsável pelo o
desenvolvimento do sistema.
2.1.3. Organização do Documento
As seções subsequentes deste documento estão assim organizadas:
Seção 2 é descrito os papeis e responsabilidades da gerência de configuração;
Seção 3 é apresenta o plano de configuração onde é definido a estrutura do
armazenamento, as configurações bases do projeto, o controle de
configuração e as políticas de segurança e acesso aos itens de configuração;
Seção 4 define como este plano será evoluído;
Seção 5 define os métodos de identificação;
Seção 6 apresenta a infraestrutura de software e hardware utilizados no projeto.
Seção 7 apresenta as assinaturas e data da aprovação deste documento.
Seção 8 apresenta o material bibliográfico utilizado para a confecção deste
plano.
Seção 9 apresenta os modelos de anexos dos documentos necessário para a
gerência de configuração.
2.1.4. Papeis e Responsabilidades
Papel Responsabilidade
Gerente de Desenvolvimento (GD) Juntamente com a CCM (Comissão de Controle de
Mudanças) receber, analisar e aprovar os PFM
(Pedido Formal de Mu).
Líder de Projeto (LP) Planejar as atividades de GC (Gerência de
Configuração) juntamente com o RC (Responsável
pela Configuração), designar executante, autorizar
a criação das configurações bases conforme
83
descrito na seção Plano de Configuração.
Responsável pela Configuração (RC) Criar e manter infraestrutura corporativa
(servidores) de GC; Implementar as políticas de
Controle de Acesso ao ambiente de GC, realizar os
backups dos repositório de configuração dos
projetos
2.1.5. Plano de Configuração
A estrutura de pastas utilizadas para o controle de versionamento é descrita como:
Trunk – pasta que contêm a estrutura definida no item. Sua finalidade é receber
todos os artefatos. A equipe armazena nesta pasta todas as versões de trabalho dos
documentos ou códigos.
Branches – pasta que armazena os documentos de uma versão que está sofrendo
uma mudança diferente da linha normal de desenvolvimento.
Tags – pasta que armazena as configurações bases do projeto. Estes itens de
configuração representam versões-base para entrega e não sofrerão mais mudanças.
Wiki – pasta para armazenas páginas de informação do projeto.
Tipos de Configuração
Os tipos de configurações definidas para este projeto são:
a) Configuração base de APD: é gerada quando a Ativação de Projeto de
Software e o Cronograma do Projeto forem aprovados formalmente pelo
Gerente de Desenvolvimento.
b) Configuração base de LPS: é gerada quando o Levantamento Preliminar de
Software for aprovado pelo Gerente de Desenvolvimento.
c) Configuração base de EOR: é gerada quando a Especificação de Objetivos e
Requisitos for aprovada formalmente pelo Gerente de Desenvolvimento.
d) Configuração base de PDS: é gerada quando o Plano de Desenvolvimento de
Software e seus planos correlatos for aprovado formalmente pelo Gerente de
Desenvolvimento.
O conteúdo das configurações bases podem listados na tabela abaixo:
ID Nome Itens de Configuração que compõem a
configuração base
Configuração APD Configuração de APD APD - Ativação de Projeto de Desenvolvimento
Cronograma do Projeto
84
Configuração LPS Configuração de LPS LPS – Levantamento Preliminar de Software
Configuração EOR Configuração de EOR EOR – Especificação de Objetivos e Requisitos
Configuração PDS Configuração de PDS
PDS – Plano de Desenvolvimento de Software
PGR – Plano de Gerência de Riscos
PGQ – Plano de Gerência de Qualidade
PCP – Plano de Comunicação do Projeto
PGQ – Plano de Gerência de Configuração
Configuração
CICLO1
Configuração do 1º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Configuração
CICLO2
Configuração do 2º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Configuração
CICLO3
Configuração do 3º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Configuração
CICLO4
Configuração do 4º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Tabela 7 - Itens de configuração que compõe as configurações bases
2.1.6. Controle de Configuração
Para o armazenamento dos artefatos de projeto a equipe utiliza um repositório
denominado SVN hospedado no GitHub através do endereço
https://github.com/jacksondan/SGE.git
O controle de versionamento dos itens de configuração ocorrerá através da própria
ferramenta ou por plugins no Eclipse e Netbean. As baselines ou configuração base quando
aprovadas receberá uma versão manual definido de acordo com o item 0 deste documento.
As atualizações nos itens de configuração no repositório ocorrem através da execução
do comando SVN Commit/SVN Submeter da ferramenta ou executar o Commit através
do plugin nos editores sempre que o autor julgar conveniente a criação de uma nova versão
do item. Caso o elemento da equipe necessita trabalhar deverá executar o comando SVN
Update/SVN Atualizar para obter a versão mais recente do item.
As versões aprovadas para fazer parte de uma baseline deverão ser bloqueadas através
do comando Get Lock/Obter bloqueio. O desbloqueio ocorrerá através do comando
Realease Lock/Liberar bloqueio somente após aprovação da mudança submetida ao
processo formal de mudanças definido no item 0 deste documento. Somente o Responsável
Pela Configuração que pode realizar o desbloqueio e uma nova versão de trabalho deve ser
gerada.
85
2.1.7. Estrutura do Repositório de Gerência de Configuração
A seguir será apresenta a estrutura definida para armazenamento dos artefatos do
projeto no repositório.
SVN
+-branches
| +-CFCvX.X
| +-Acompanhamento e Controle
| +-Construção
| | +-Análise
| | +-Implementação
| | +-Projeto
| | +-Revisões Técnicas
| | +-Testes
| +-Documentos não Padronizados
| +-Planejamento e Elaboração
| | +-Concepção
| | +-Objetivos e Requisitos
| | +-Planejamento Inicial
| | +-Planejamento do Desenvolvimento
| | +-Revisões Técnicas
+-tags
| +-<ID > - <VERSAO > - <DD-MM-AAAA>
| +-CFC
+-trunk
| +-CFC
| +-Acompanhamento e Controle
| +-Construção
| | +-Análise
| | +-Implementação
| | +-Projeto
| | +-Revisões Técnicas
86
| | +-Testes
| +-Documentos não Padronizados
| +-Planejamento e Elaboração
| | +-Concepção
| | +-Objetivos e Requisitos
| | +-Planejamento Inicial
| | +-Planejamento do Desenvolvimento
| | +-Revisões Técnicas
+-wiki
2.1.8. Política de Segurança
As políticas de segurança definida para as pastas do repositório serão definidas
conforme tabela a seguir:
Branches SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração (RC) L, S, E, X
Outros Membros da Equipe L, S
Tabela 8 - Permissões diretório Branches SVN
Tags SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração (RC) L, S, E, X
Outros Membros da Equipe L, S
Tabela 9 - Permissões diretório Tags SVN
87
Trunk SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração (RC) L, S, E, X
Outros Membros da Equipe L, S
Tabela 10 - Permissões diretório Trunk SVN
Wiki SVN – GitHub
Nome/Localização da Pasta Membro da Equipe Permissão
Todas Todos os Membros da Equipe L, S, E, X
Tabela 11 - Permissões diretório Wiki SVN
Legenda: L – Ler
S – Salvar
E – Editar
X – Excluir
2.1.9. Métodos de Identificação
Documentos
Todos os documentos disponibilizados no repositório devem ser identificados
baseados na seguinte nomenclatura:
<ID_ARTEFATO> - <NOME_ARTEFATO>
Onde:
88
<ID_ARTEFATO> é a sigla de identificação do artefato conforme Tabela 19.
<NOME_ARTEFATO> é nome de identificação do artefato conforme Tabela
19.
ID_ARTEFATO NOME_ARTEFATO
APD Ativação de Projeto de Desenvolvimento
EOR Especificação de Objetivos e Requisitos
LPS Levantamento Preliminar do Software
PCP Plano de Comunicação do Projeto
PDS Plano de Desenvolvimento de Software
PGC Plano de Gerência de Configuração
PGQ Plano de Gerência da Qualidade
PGR Plano de Gerência de Riscos
RAC Relatório de Avaliação do Cliente
RAP Relatório de Acompanhamento do Projeto
PFM Pedido Formal de Modificação
SAI Solicitação de Análise de Impacto
RTF Relatório de RTF (Revisão Técnica Formal)
DAS Documento de Análise de Software
DPS Documento de Projeto de Software
Tabela 12 - Identificadores e Nomes dos Artefatos
2.1.10. Configuração Base
As configurações bases definidas ao longo do projeto deverão ser utilizadas a
seguinte regra para a nomenclatura:
<ID_CONFIGURACAO> - <VERSAO_MANUAL> - < DD-MM-AAAA >
Onde:
89
< ID_CONFIGURACAO > é a identificação da configuração conforme Tabela
14.
<DD-MM -AAAA > é a data de criação da configuração base.
<VERSAO_MANUAL> é o número da versão realizada conforme o padrão
X.0. Em que X é um número decimal que representa a versão aprovada e liberada da
configuração base e é incrementado a cada liberação da configuração.
Documentos de Análise de Software
Para cada caso de uso do sistema será definida um Documento de Análise de
Software que será nomeado conforme regra a seguir:
MAS – <ID_CASO_USO> - <NOME_CASO_USO>
Onde:
MAS é a identificação do documento conforme já estabelecido na Tabela 14.
<ID_CASO_USO> é a identificação do caso de uso conforme definido no EOR
– Especificação de Objetivos e Requisitos.
< NOME_CASO_USO > é o nome caso de uso conforme definido no EOR –
Especificação de Objetivos e Requisitos.
2.1.11. Documentos de Projeto de Software
Para cada caso de uso do sistema será definida um Documento de Projeto de
Software que será nomeado conforme regra a seguir:
MPS – <ID_CASO_USO> - <NOME_CASO_USO>
Onde:
MPS é a identificação do documento conforme já estabelecido na Tabela 14.
<ID_CASO_USO> é a identificação do caso de uso conforme definido no EOR
– Especificação de Objetivos e Requisitos.
< NOME_CASO_USO > é o nome caso de uso conforme definido no EOR –
Especificação de Objetivos e Requisitos.
2.1.12. Controle de Mudanças
São definidos dois processos de controle de mudanças:
a) Procedimento Formal: este processo deve ser implementado quando a mudança
proposta afeta a última versão configuração já aprovada e estabelecida o qual o
item faça parte. A Erro! Fonte de referência não encontrada. ilustra o
processo formal de Modificação.
90
Figura 1 - Processo Formal de Modificação de Itens de Configuração
91
1. Pedido Formal de Mudança: O solicitante preenche o Pedido Formal de
Mudança conforme Pedido Formal de Mudança – PFM
PFM N°__________
1. Nome Solicitante:_________________________________________Data: ___/___/___
2. Descrição Detalhada: ________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
3. Comissão de Controle de Mudança:
Líder de Projeto:____________________________________________________________________
Equipe Técnica:_____________________________________________________________________
Equipe de Qualidade:________________________________________________________________
4. Resultado Triagem:
( ) Relevante Com Impacto
( ) Relevante Sem Impacto
( ) Irrelevante
5. Observações:_______________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade
2. Anexo 1, e envia para a Comissão de Controle de Mudança. Em cada PFM
só deve ter apenas uma mudança á ser avaliada.
92
3. Realizar Triagem de Mudança: A CCM com apoio da Equipe Técnica e
da Equipe de Qualidade realiza a triagem definindo a relevância e
possível impacto da mudança. O resultado da triagem pode gerar uma
das seguintes decisões: Relevante Com Previsão de Impacto
Significativo, Relevante Sem Previsão de Impacto Significativo e
Mudança Irrelevante - Rejeitada.
4. Solicitação de Análise Detalhada de Impacto: As mudanças que foram
classificadas como relevante com previsão de impacto significativo deve
gerar a Solicitação de Análise Detalhada de Impacto conforme modelo
no Solicitação de Análise de Impacto – SAI
SAI N°_________
1. Nome Solicitante:_________________________________________________________________________Data: ___/___/_____ PFM Nº:_______
2. Responsáveis:_____________________________________________________________________________________________________________
3. Data de Inicio: ___/___/_____ Data de Término: ___/___/_____
4. Resultado Análise de Análise:
Item de Configuração Descrição da Alteração
Estimativa de Implementação Aprovação
ID Seção Esforço Tempo Custo
1 – Aprovada
2 – Reprovada – Tempo Excedido
3 – Reprovada – Custo Excedido
4 – Reprovada – Esforço Excedido
5 - Outros
5. Observações:__________________________________________________________________________________________________________________________
________________________________________________________________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade Cliente
Anexo 2.
5. Realizar Análise de Impacto: Estudo e análise de quais itens de
configuração a mudança impactará.
6. Relatório de Análise de Impacto: Relatório contendo a lista de itens de
configuração e o qual impacto sofrido pelo mesmo com a implementação
da mudança. Bem como a estimativa de esforço, de tempo e custo.
7. Negociar e Aprovar Mudanças: O CCM juntamente com o cliente
negocia e aprova se a mudança pode ser implementada. O resultado deste
processo pode gerar as seguintes decisões: Mudança Aprovada e
Mudança Reprovada.
8. Mudança Aprovada: Relatório contendo a lista das alterações aprovadas
que serão implementadas.
9. Implementar Mudança: A CCM envia a mudança aprovada para o LP,
que providenciará a implementação da mudança.
93
10. Mudança Implementada: O LP envia para o RC a mudança
implementada solicitando que gere uma nova versão da configuração.
11. Gerar e Aprovar Configuração Base: Gera uma nova versão com as
mudanças totalmente implementadas.
12. Reportar Solicitante: A CCM envia ao solicitante se mudança foi
reprovada ou considerada irrelevante.
b) Procedimento Informal: O processo informal deve ser implementado nos casos
em que a(s) mudança(s) proposta(s) não afetarem os itens de configuração a
última versão da configuração base no qual
2.1.13. Ambiente, Ferramentas e Infraestrutura
Plano de Software
Software Propósito Ambiente Release/Versão
SVN GitHub Controle de Repositório Desenvolvimento
MS-Office Documentos do Word Todos 2010 ou 2013
Git Desktop Acesso ao repositório Desenvolvimento 1.6.12
MS-Project Edição do cronograma Desenvolvimento 2007
PHP Kit básico para o
desenvolvimento em PHP
Desenvolvimento 7.0
Richfaces Suporta AJAX. Desenvolvimento 3.3.0
Hibernate Framework de
persistência.
Desenvolvimento 3.2.6
iReport IDE para design de
relatórios.
Desenvolvimento 3.5.2
JasperReports Biblioteca responsável em
gerar relatórios em PDF.
Desenvolvimento 3.5.2
Eclipse July IDE de desenvolvimento. Desenvolvimento 07/2016
NetBeans IDE de desenvolvimento. 8.1
Enterprise
Architect
Modelagem de diagramas
de dados.
Desenvolvimento 6.5
Power
Designer
Modelagem de diagramas
de dados.
Desenvolvimento 12.5
94
HeidiSQL Gerenciador de banco de
dados MySQL.
Desenvolvimento 6.0
Subclipse Plugin SVN para o eclipse Desenvolvimento 1.6.17
Tabela 13 - Plano de Software
2.1.14. Comissão de Controle de Mudanças
A Comissão de Controle de Mudanças (CCM) será formada pelo Líder de Projeto,
integrantes da Equipe de Qualidade e integrantes da Equipe Técnica. E deve ser designada
pelo LP para cada PFM.
2.1.15. Aprovação Formal
Caruaru, __/__/__
De acordo,
Gerente de Desenvolvimento Líder de Projeto
95
2.1.16. Anexos
Pedido Formal de Mudança – PFM
96
Pedido Formal de Mudança – PFM
PFM N°__________
1. Nome Solicitante:_________________________________________Data: ___/___/___
2. Descrição Detalhada: ________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
3. Comissão de Controle de Mudança:
Líder de Projeto:____________________________________________________________________
Equipe Técnica:_____________________________________________________________________
Equipe de Qualidade:________________________________________________________________
4. Resultado Triagem:
( ) Relevante Com Impacto
( ) Relevante Sem Impacto
( ) Irrelevante
5. Observações:_______________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade
Anexo 1 - Pedido Formal de Mudança
97
Solicitação de Análise de Impacto
Solicitação de Análise de Impacto – SAI
SAI N°_________
1. Nome Solicitante:_________________________________________________________________________Data: ___/___/_____ PFM Nº:_______
2. Responsáveis:_____________________________________________________________________________________________________________
3. Data de Inicio: ___/___/_____ Data de Término: ___/___/_____
4. Resultado Análise de Análise:
Item de Configuração Descrição da Alteração
Estimativa de Implementação Aprovação
ID Seção Esforço Tempo Custo
1 – Aprovada
2 – Reprovada – Tempo Excedido
3 – Reprovada – Custo Excedido
4 – Reprovada – Esforço Excedido
5 - Outros
5. Observações:__________________________________________________________________________________________________________________________
________________________________________________________________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade Cliente
Anexo 2 - Solicitação de Análise de Impacto
98
Figura 2
Modelagem do processo gerenciamento. Os detalhamentos do processo estão no apêndice,
item 2.7.2 – Gerenciamento.
99
2.4. Nível de Serviço
2.4.1. Acordo Geral
Este contrato representa um acordo de nível de serviço ("SLA "ou" Contrato") entre a E-
commerce Development Ltda e o grupo “Empresa X” para o fornecimento de serviços
de TI necessárias para apoiar e sustentar “Empresa X”.
O presente acordo permanece válido até ser substituído por uma versão revisada com
acordo mutuamente aprovado pelos interessados. As mudanças são registradas na seção
“Alterações do presente acordo” e são efetivadas após a confirmação mútua das partes
interessadas.
O presente Acordo define os parâmetros de todos os serviços abrangidos, como eles são
mutuamente compreendidos pelos principais intervenientes. O presente acordo não
invalida atuais processos e procedimentos a menos que explicitamente indicado neste
documento.
2.4.2. Metas e Objetivos
O objetivo deste acordo é o de assegurar que as partes estão em condições de efetuar a
negociação, que a E-commerce Development Ltda está em condições de prestar serviço
de apoio consistente de TI e de entrega ao cliente(s) pelo prestador do serviço(s).
O objetivo deste acordo é a obtenção de mútuo acordo entre a prestação de serviços de
TI entre Provedor e Cliente.
Os objetivos deste acordo são os seguintes:
• Prestar serviço de referência, especificando claramente suas responsabilidades e
papéis;
• Apresentar uma clara, concisa e mensurável descrição da prestação de serviços ao
cliente;
• Listar condições da prestação de serviço efetivo de apoio e entrega.
100
2.4.3. Responsáveis
Os seguintes Provedores e o Cliente serão usados como base do acordo e representam
os principais intervenientes associados a este SLA:
Provedor de Serviço de TI: E-commerce Development Ltda
Cliente: “Empresa X”
A seguir, as partes interessadas são responsáveis pela implantação e suporte contínuo do
presente acordo:
Stakeholder Nome Contato
2.4.4. Ambiente de Serviço
As informações a seguir fornecem detalhes sobre os usuários, ferramentas, aplicações e
/ ou outros componentes apoiados por este SLA:
Número de usuários: 5
Número de usuários simultâneos: 10
Número de usuários registrados:5
Descrição do usuário-base Usuários interno da empresa
Âmbito de aplicações SGE vs 1.0, Módulo de requisição
Infraestrutura de Serviços: Gerenciamento e manutenção dos servidores da
aplicação.
101
Dependências do SLA: Depende do SLA da empresa GVT que prove internet
102
2.4.5. Revisão Periódica
Este acordo é válido a partir da data efetiva delineada neste documento e é válido até à data
da rescisão. Este acordo deverá ser revisto pelo menos uma vez por ano fiscal, no entanto,
em vez de uma revisão durante o período especificado, o atual acordo permanecerá em
vigor.
O Gerente de Negócios é responsável por facilitar a revisões regulares do presente
documento. O conteúdo deste documento pode ser alterado conforme necessário, desde que
o mútuo acordo é obtido a partir do primeiro comunicado a todos os interessados e as partes
afetadas. O proprietário do documento vai incorporar todas as revisões ulteriores e de obter
acordos mútuos / as aprovações necessárias.
Gerente de Negócios: Lívio Jerônimo
Periodicidade da revisão: Anual
Data prevista para revisão: 09/07/2017
Este acordo será enviado para os seguintes locais e vai ser acessível a todas as partes
interessadas:
Local do Documento:www.sge.com.br/documentos
2.4.6. Contrato de Serviço
Os seguintes parâmetros detalhados nesta seção do contrato de serviço são da
responsabilidade do prestador do serviço, no apoio contínuo do presente acordo.
2.4.6.1. Escopo do Serviço
Os seguintes serviços são abrangidos pelo presente acordo; pleno descrições,
caderno de encargos e os custos são delineadas nos “Custos dos serviços”.
Referência Módulo Descrição do Serviço
Req_01 Cad O serviço oferecido deve permitir os seguintes cadastros:
103
- Inserir Usuário
- Inserir Empresa
- Inserir Perfil
- Inserir Equipamento
Req_02 Fun O serviço oferecido deve permitir que usuários efetuem a
requisição de equipamentos de Tecnologia da Informação
Req_03 Fun O serviço oferecido deve disponibilizar ao cliente um
histórico de todas as movimentações feitas para cada
equipamento, provendo um acompanhamento detalhado.
Req_04 Est O serviço oferecido deve oferecer controle de estoque de
equipamentos
Req_05 Ger O serviço deve disponibilizar relatórios gerenciais de todas as
requisições dos equipamentos, além de suas históricos de
incidentes e idas a assistência.
2.4.6.2. Responsabilidades do Cliente
As responsabilidades e / ou requisitos dos clientes em apoio do presente acordo
incluem:
• A adesão relacionada com políticas, processos e procedimentos descritos nos
Apêndices;
• Adequação incidentes e / ou solicitar priorização como descrito anteriormente e / ou
em cooperação com o prestador de serviços;
• Opções de programação de todos os serviços relacionados com os pedidos e outros
serviços especiais com o prestador de serviços;
• Adequação da utilização de apoio conforme descrito no Apêndice A: Políticas
relacionadas, Processos e Procedimentos;
• Pagamento de todos os serviços relacionados com a instalação e / ou de configuração
despesas anteriores à prestação do serviço;
• Revisão todas as horas autenticadas pelo fornecedor de serviços para adequação;
• Razoável disponibilidade do cliente representante (s) na resolução de um incidente ou
serviço relacionado pedido.
2.4.6.3. Responsabilidades do Provedor de Serviços
104
Service Provider responsabilidades e / ou requisitos em apoio do presente acordo
incluem:
• Reuniões devidamente associadas a resposta a incidentes relacionados com serviços;
• Geração de relatórios trimestrais sobre os níveis de serviço para o cliente;
• Formação exigida pessoal em serviço com instrumentos de apoio adequados;
• Registrar todas as horas providas de recursos associados a serviços e prestados para a
revisão pelo Cliente;
• Devida notificação ao Cliente das manutenções programadas;
• Facilitação de apoio ao serviço de todas as atividades que envolvam incidente,
problema, mudança, liberação de configuração e gerenciamento.
2.4.6.4. Serviços Pressupostos
Pressupostos relacionados com o âmbito de serviços e / ou componentes incluem:
Os serviços são prestados a clientes externos de TI e são comunicados aos gerentes de
negócios;
Atendimento ao usuário básico permanecerá dentro de 5% dos efetivos níveis atuais;
Financiamento para maiores atualizações serão fornecidas pelo Cliente e tratado como
um projeto fora do âmbito de aplicação do presente acordo;
Mudanças de serviços serão documentadas e comunicadas a todos os interessados.
2.4.7. Gerenciamento do Serviço
Eficaz de apoio no âmbito de serviços é um resultado consistente de manutenção de níveis
de serviço. As seções a seguir fornecem informações relevantes sobre a disponibilidade,
acompanhamento, avaliação e comunicação dos serviços no âmbito de componentes e afins.
2.4.7.1. Disponibilidade do Serviço
As coberturas específicas para os serviços abrangidos pelo presente acordo são os
seguintes:
24 horas por dia, 365 dias por ano, com as seguintes exceções:
105
Desenvolvimento do Ambiente
Disponibilidade do Cliente Domingos a partir das 14h
Manutenção Domingos a partir das 14h
Monitoração automática dos
serviços
24 horas por dia, 365 dias por ano
2.4.8. Medição dos Serviços
As seguintes medições serão criadas e mantidas pelo prestador do serviço a garantir a
melhor prestação de serviço ao cliente:
Medição Definição Alvo
Aplicação X
Disponibilidade
Percentagem de tempo que
alguma Application está
disponível fora da janela de
manutenção.
95.5%
Tempo de
resposta do
cliente
Tempo de resposta para uma
amostra de operações
executadas em menos de 10
segundos.
92,5% das operações
especificadas em 30 segundos ou
menos.
2.4.9. Relatório em nível de Serviço
O fornecedor de serviços irá oferecer ao Cliente com os seguintes relatórios sobre a
periodicidade indicada:
Nome do relatório Intervalo A quem se destina Responsável
Relatório de
disponibilidade de
aplicação
Quinzenal Gerente de Negócio Gerente de Negócio
Tempos de
respostas ao cliente
Quinzenal Gerente de Negócio Gerente de Negócio
Relatório de Semanal Gerente de Negócio Gerente de Negócio
106
incidentes
2.4.10. Pedidos de Serviços
Em apoio aos serviços descritos no presente acordo, o prestador de serviços irá responder
aos incidentes relacionados ao serviço e / ou pedidos apresentados pelo Cliente, dentro dos
seguintes prazos estabelecidos:
Um (1) hora (durante o horário comercial) para questões classificadas como críticas;
Dois (2) horas (durante o horário comercial) para questões classificadas como alta
prioridade;
Quatro (4) horas (durante o horário comercial) para questões classificadas como
prioridade média;
Oito (8) horas (durante o horário comercial) para questões classificados como baixa
prioridade;
Vinte e quatro (24) horas (durante o horário comercial) para uma solicitação de serviço
geral.
2.4.11. Manutenção dos Serviços
Todos os serviços e / ou componentes relacionados com regularidade exigem
manutenção programada ("Janela de Manutenção"), a fim de satisfazer níveis de
serviço estabelecidos. Estas atividades vão tornar sistemas e / ou aplicações
indisponíveis para a interação entre os utilizadores normais para os seguintes locais
e datas:
Data/Horário: domingos entre 14h e 20h
2.4.12. Custos dos Serviços
Para a disponibilização dos serviços descritos na seção 6.1 – Escopo do serviço, o
custo será de R$ 1.500,00 mensais.
Solicitações de alterações e novas funcionalidades terão orçamento oferecido ao
cliente gratuitamente para então sua avaliação e possível aprovação.
107
Para o pagamento do referido valor, o cliente receberá uma fatura a vencer no dia 10
de cada mês.
O não pagamento desta fatura em até 30 dias implicará em juros e multa, e após o
30º dia os serviços oferecidos serão cancelados.
SERVIÇOS:
Monitoramento – o monitoramento é de fundamental importância para garantir maior
disponibilidade do serviço oferecido.
Código Unidade Organizacional
001 Monitoramento de disponibilidade
Descrição Características
Monitoramento Monitorar disponibilidade do sistema
Requisitos de Atendimento Requisitos da Equipe
O monitoramento será feito
periodicamente, de acordo com
periodicidade abaixo
informada.
Conhecimento de ferramentas de monitoramento
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1.
Disponibilidade
do sistema
50% em
até 4
horas.
25% em
até 6
horas.
25% em
até 8
horas.
Diária
A cada 4 horas
Janela: 24h x 30d
= 720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
108
*SLA – Dados fornecidos pela empresa que desenvolveu o software
Garantia de disponibilidade – o monitoramento é de fundamental importância para
garantir maior disponibilidade do serviço oferecido.
Código Unidade Organizacional
002 Garantias de disponibilidade
Descrição Características
Disponibilidade Especificar os requisitos para disponibilidade do sistema
Requisitos de Atendimento Requisitos da Equipe
O monitoramento será feito
periodicamente, de acordo com
periodicidade abaixo
informada.
Conhecimento de ferramentas de monitoramento
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1.
Disponibilidade
do sistema
50% em
até 4
horas.
25% em
até 6
horas.
25% em
até 8
horas.
Diária
A cada 4 horas
Janela: 24h x 30d
= 720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Internet Explorer 10
ou superior
Google Chrome
Link 1 MB Full
*SLA – Dados fornecidos pela empresa que desenvolveu o software
Garantia de funcionabilidade – cumprir os pré-requisitos são fundamentais para garantir a
funcionabiliadde do sistema.
Código Unidade Organizacional
003 Garantias de funcionabilidade
Descrição Características
Disponibilidade Cumprir pré-requisitos para funcionabilidade
Requisitos de Atendimento Requisitos da Equipe
109
Atender os pré-requisitos para
a funcionamento do sistema
Conhecimento dos pré-requisitos
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1. pré-requisitos 50% em
até 4
horas.
25% em
até 6
horas.
25% em
até 8
horas.
Diária
A cada 4 horas
Janela: 24h x 30d
= 720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Internet Explorer 10
ou superior
Google Crhome
Link 1 MB full
Correções de erros – correções de erros do sistema
Código Unidade Organizacional
004 Correções de erros
Descrição Características
Correção Corrigir os erros do sistema
Requisitos de Atendimento Requisitos da Equipe
Abrir solicitação de correção,
informando o processo ao qual
acarreta o erro e qual deveria
ser o resultado correto
Conhecimento no desenvolvimento do sistema
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1. correção de
erro
50% em
até 4
horas.
25% em
até 6
horas.
25% em
até 8
horas.
Sob demanda Janela: 24h x 30d
= 720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Link 1 MB full para
validação do
funcionamento
Aplicação de melhorias – aplicar melhorias visando a evolução do sistema.
Código Unidade Organizacional
110
005 Aplicar melhorias
Descrição Características
Melhorias Aplicar melhorias para permitir a evolução do sistema
Requisitos de Atendimento Requisitos da Equipe
Abrir solicitação de melhoria,
informando os benefícios que a
empresa vai ter com as
melhorias aplicadas e também
os impactos causados nas
regras de negócio da empresa
Conhecimento no desenvolvimento do sistema
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1. Aplicação de
melhorias
50% em
até 4
horas.
25% em
até 6
horas.
25% em
até 8
horas.
Sob demanda Janela: 24h x 30d
= 720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Verificação de
viabilidade técnica
Verificação de
viabilidade
financeira
Verificação da aplicação SEG – aplicar melhorias visando a evolução do sistema.
Código Unidade Organizacional
005 Verificar aplicação
Descrição Características
Verificar aplicação Verificação da aplicação após o informe de parada do
sistema
Requisitos de Atendimento Requisitos da Equipe
Conhecimentos na estrutura e
no funcionamento do sistema
Conhecimento no desenvolvimento do sistema
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
Verificar
aplicação
50% em
até 4
A cada 4 horas Janela: 24h x 30d
= 720h/mês
Disponibilidade do
servidor do sistema
111
horas.
25% em
até 6
horas.
25% em
até 8
horas.
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Verificação da aplicação SEG – verificar a aplicação.
Código Unidade Organizacional
006 Verificar aplicação
Descrição Características
Verificar aplicação
Verificação da aplicação após o informe de parada do
sistema
Requisitos de Atendimento Requisitos da Equipe
Conhecimentos na estrutura e
no funcionamento do sistema
Conhecimento no desenvolvimento do sistema
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
Verificar
aplicação
50% em
até 4
horas.
25% em
até 6
horas.
25% em
até 8
horas.
A cada 4 horas Janela: 24h x 30d
= 720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Disponibilidade do
servidor do sistema
Figura 1
112
Modelagem do processo gerenciamento. Os detalhamentos do processo estão no apêndice,
item 2.7.3 – Monitoramento.
113
2.5. Gerenciamento de Serviço Automatizado – BPMS
Módulos:
A figura A mostra os campos que o usuário deve inserir no processo de abertura do
chamado
FIGURA A
Figura B mostra a visão inicial da fila NIVEL 1 no momento de preencher se existe
chamados existentes em aberto
FIGURA B
114
Figura C mostra a visão de atendimento da fila NIVEL 1 se o chamado foi resolvido
ou não.
FIGURA C
Figura D mostra a visão inicial da fila NIVEL 2 no momento de preencher se existe
chamados existentes em aberto
FIGURA D
115
A figura E mostra a visão de atendimento da fila NÍVEL 2 se o chamado foi
resolvido ou não.
FIGURA E
Figura F mostra a visão inicial da fila NÍVEL 3 no momento de preencher se existe
chamados existentes em aberto
FIGURA F
116
Figura G mostra a visão de atendimento da fila NÍVEL 3 se o chamado foi resolvido
ou não.
FIGURA G
Figura H mostra a visão de atendimento quando o chamado depende de serviços de
terceiros para ser resolvido.
FIGURA H
117
Figura I mostra a visão do usuário para responder se o chamado foi solucionado ou
não.
FIGURA I
Figura J mostra a visão do usuário para o feedback de qualificação do chamado.
FIGURA J
118
A figura K mostra o encerramento do chamado por completo
FIGURA K
119
2.6. Conclusão
Este trabalho proporcionou uma solução para um problema existente no setor de TI
da Empresa X. O processo de melhoria se deu após a coleta de dados através de técnicas
com a etnografia, entrevista de campo, modelagem do processo atual e o desenho das
melhorias propostas no processo utilizando BPMN com a ferramenta Bizagi Modeler.
Através da modelagem BPMN, conseguimos localizar os pontos de falha e gargalos
nos processos e com o desenho dos processos, concretizamos a demonstração de uma
solução para o problema existente de uma maneira de fácil compreensão.
120
2.7. Apêndice
2.7.1. Scrum
Version: 1.0
Authors: Jackson Daniel e Lívio Scílas
2 . 2 S C R U M
2.2.1 PROCESS ELEMENTS
2.2.1.1 None
Description
Esta modelagem retreta todos os processos de desenvolvimento de software utilizando a
metodologia ágil Scrum. Nela está descrito os processos macros, desde a requisição de uma
solução por parte do cliente até a entrega das Sprints ao cliente.
2.2.1.2 Solicitar solução
Description
O cliente solicita a análise de uma problemática à empresa de Desenvolvimento
2.2.1.3 Identificar Problemática
Description
O representando do cliente, o Product Owner, leva a problemática do cliente para ser
analisado pela equipe do projeto.
2.2.1.4 Coletar Requisitos
Description
É feito a coleta de informações utilizando táticas como Entrevistas, Etnografia, etc.
121
2.2.1.5 Documentar Requisitos
Description
A equipe do projeto elabora o documento de requisitos que detalha todas as funcionalidades
do sistema. Também é detalhado os requisitos não funcionais, definindo a parte técnica
necessária para o software.
2.2.1.6 Analisar Proposta
Description
O cliente recebe o documento de requisitos e realiza a anaálise para verificar se o que está
sendo proposto atende às suas necessitades
2.2.1.7 Decisão de aprovação ao reprovação
Description
Este gateway indica os caminhos a serem seguitos caso o cliente aprove ou reprove a
solução proposta no documento de requisitos
Gates
Solução reprovada
Solução Aprovada
2.2.1.8 Revisar problemática
Description
O Product Owner realiza a revisão do documento para reajustado de acordo com as
necessidades apontadas pelo cliente
2.2.1.9 Compor Product Backlog
Description
A equipe do projeto começa a compor o Product Backlog, que possui doas as histórias de
que serão desenvolvidas em cada Sprint
2.2.1.10 Priorizar Histórias (Definir Sprint Backlog)
Description
122
O Scrum Master e os Desenvolvedores começam a pontuar as histórias. Nesta etapa o
Scrum Master define as histórias que irão compor cada sprint.
2.2.1.11 Desenvolver Sprint
Description
O processo de desenvolvimento é realizado para cada Sprint.
Nele está descrito o tempo de desenvolvimento da Sprint em semanas, reuniões diárias,
teste, revisões, ect
2.2.1.12 Avaliar Sprint
Description
O Product Owner realiza a validação da Sprint pronta para verificar se atende às requisições
do cliente
2.2.1.13 Inclusive Gateway
Gates
História(s) Reprovada(s)
História(s) Aprovada(s)
2.2.1.14 Enviar Sprint
Description
O Product Owner faz a entrega da Sprint prota para o cliente
Implementation
WebService
2.2.1.15 Receber Sprint
Description
O cliente recebe a Sprint funcional e pronta para o uso.
Implementation
WebService
123
2.2.1.16 Sprint Retrospective
Description
Após cada Sprint, o Product Owner se reune com a Scrum Master e a equipe de
desenvolvimento para fazer a retrospectiva da Sprint, visando pontos positivos e negativos
do desenvolvimento
2.2.1.17 Exclusive Gateway
Gates
Desenvolver nova Sprint
Finalizar Entregas
2.2.1.18 None
Description
Finalização do processo de desenvolvimento das Sprints
2.2.1.19 Parallel Gateway
Description
Convergência para receber as histórias reprovadas e a continuação do processo. Continuar
para reclacificação da nova Sprint.
2.2.1.20 Cliente
2.2.1.21 Product OWNER
2.2.1.22 Equipe de Desenvolvimento + Scrum Master
124
2.7.2. Gerência de configuração
Version: 1.0
Authors: Jackson Daniel e Lívio Scílas
2.1 GERÊNCIA DE CONFIGURAÇÃO
2.1.1 PROCESS ELEMENTS
2.1.1.1 Definir as diretrizes do gerenciamento
Description É feita reunião para definir as diretrizes do gernciamento das confgiurações.
2.1.1.2 Estabelecer e manter um sistema de gerenciamento de configuração
Description Nesta etapa é estabelecido um sistema de gerenciamento de configuração.
2.1.1.3 Estabelecer os critérios dos itens de configuração
Description Estabelece os critérios para os itens de configuração
125
2.1.1.4 Identificar os itens de configuração
Description Neste processo devem ser identificados os itens de configuração.
2.1.1.5 Criar uma Baseline dos itens de configuração sujeitos a controle
Description Neste processo é criada uma base line dos itens de confiuração que serão controlados através de versionamento.
2.1.1.6 Criar registros das baselines dos itens de configuração
Description Nesta estapa são criados os registros das base lines dos itens de configuração.
2.1.1.7 Disponibilizar os registros das baselines de configuração
2.1.1.8 Criar controle de alterções dos itens de configurção
2.1.1.9 Armazenar as alterações feitas nos itens de configuração e baselines
Description As alterações feitas nos itens de configuração da baseline serão armazenados atraves do servidor de SVN,
2.1.1.10 Realizar auditoria das configurações
Description É realizada uma auditoria durante as
2.1.1.11 Entregar os intens de configurção aos envolvidos no projeto.
Description
126
Os itens de configuração, juntamente com a baseline e as alterações são entregues aos interessados..
2.1.1.12 None
2.1.1.13 L1
Description Link de envio de processo
2.1.1.14 l2
Description Link de envio de processo
2.1.1.15 None
Description Finalizar processo de Gerenciamento de Configuração
2.1.1.16 L1
Description Link que recebe o processo
2.1.1.17 l2
Description Link que recebe o processo
127
2.1.1.18 PLANEJAMENTO
2.1.1.19 EXECUÇÃO
2.1.1.20 ENTREGA
2.7.3. Monitoramento
Version: 1.0
Authors: Jackson Daniel e Lívio Scílas
2.1 SLA SGE
2.1.1 PROCESS ELEMENTS
2.1.1.1 None
Description Descrição dos processo do serviço de monitoramento constante. Cada processo descreve os passo para verificação de monitoramento que
está pré-visto no catálogo
2.1.1.2 Verificar Disponibilidade do Sistema
Description É iniciado um ciclo de verificação de disponibilidade do serviço
2.1.1.3 Exclusive Gateway
Gates
128
Indisponível
Disponível
2.1.1.4 Verificar Provedor de Hospedagem da Aplicação
Description Os técnicos do monitoramento entram em contato com o provedor de hospedagem para constatar a disponibilidade do serviço.
2.1.1.5 Exclusive Gateway
Gates
Disponível
Indisponível
2.1.1.6 Verificar Aplicação SGE
Description Verificar disponibiidade da aplicação
2.1.1.7 Exclusive Gateway
Gates
Disponível
Indispinível
2.1.1.8 Prestar Suporte à Aplicação
Description É necessário realizar os reparos na aplicação
2.1.1.9 1
Description O processo retorna para o passo de verificação
129
2.1.1.10 None
Description Finalização de monitoramento
2.1.1.11 Contactar Provedor de Hospedagem
Description Entrar em contato com o provedor de hospedagem para solicitar solução
2.1.1.12 Tempo de Solução
Description Tempo pré-visto para que a terceirizada solucione o problema
Timer Date
2016-07-30T00:00:00
2.1.1.13 Receber resposta de provedor
Description O provedor realiza os repatos necessários para o funcionamento do sistema
2.1.1.14 1
Description O processo retorna para o passo de verificação
2.1.1.15 None
Description O processo de monitoramento é finalizado
130
2.1.1.16 1
Description Link de retorno ao passo de verificação
2.1.1.17 Monitoramento de
131
Capítulo
3
Gerenciamento de Serviços: Processo e-commerce
Andréa Rodrigues de Vasconcelos e Eder Ricardo de Melo Ferreira.
Abstract
This article describes the management environment used for creating a process model used
in an e- commerce company, which will deal with the requirements documents,
configuration management processes, service contract and system modeling using the
Bizagi tool.
Resumo
Este artigo descreve o ambiente de gerenciamento utilizado para criação de um modelo de
processo utilizado em uma empresa de e-commerce, onde irá tratar dos documentos de
requisitos, processos de gerência de configuração, contrato de serviço e modelagem do
sistema utilizando a ferramenta Bizagi.
132
3.1. Introdução
O objetivo desde documento é descrever o problema que foi identificado e
especificar os requisitos para a solução encontrada durante a fase de estudo de viabilidade
realizada previamente. Essa solução tem como centro um sistema de informação que deve
ser construído a partir das informações capturadas pela utilização de algumas técnicas
descritas adiante.
O nosso objeto de estudo é um e-commerce, onde facilitará o acesso dos clientes aos
produtos, provendo maior conforto do usuário ao poder realizar suas compras sem precisar
se locomover de sua residência. Também irá trazer benefícios para o vendedor, que poderá
oferecer suas mercadorias para mais pessoas em menos tempo.
3.2. Requisitos do Sistema (Processo X)
Neste tópico são definidas as funções que o sistema deve realizar. Os requisitos
estão agrupados de acordo com suas características.
3.2.1 Requisitos funcionais
3.2.1.1. [RF01] Efetuar Logon
Identificação: [RF01] Efetuar logon
Casos de Uso
relacionados: [UC 01]
Descrição: Permite que um usuário tenha acesso a informações pertencentes ao software.
Para isso, o usuário deve informar login e senha. Não deve haver outra maneira
de entrar no sistema diferente desta.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.2. [RF02] Efetuar Logoff
Identificação: [RF02] Efetuar logoff
Casos de Uso relacionados: [UC 02]
Descrição: Permite que o usuário saia do sistema.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.3. [RF03] Cadastrar perfil do Cliente
Identificação: [RF03] Cadastrar perfil de Cliente
133
Casos de Uso
relacionados: [UC 03]
Descrição: O cliente terá acesso a plataforma e poderá cadastrar suas informações pessoais
no sistema para poder realizar compras no site da empresa. O perfil tem os
dados: email, cpf, endereco, senha e nome.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.4. [RF04] Consultar Produtos
Identificação: [RF04] Consultar Produtos
Casos de Uso
relacionados: [UC 04]
Descrição: Os cliente podem consultar os produtos de seus interesses e conferir
preços e condições.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.5. [RF05] Adicionar produtos à lista de compras
Identificação: [RF05] Adicionar produtos à lista de compras
Casos de Uso
relacionados: [UC 05]
Descrição: O cliente, devidamente logado, pode incluir os produtos de seu interesse à
lista de compras para que posteriormente possa ser adquirido.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.6. [RF06] Remover produtos da lista de compras
Identificação: [RF06] Remover produto da lista de compras
Casos de Uso
relacionados: [UC 06]
Descrição: Em caso de desistência o cliente, devidamente logado, pode remover o
produto indesejado da sua lista de compras.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.7. [RF07] Finalizar compra
134
Identificação: [RF07] Finalizar compra
Casos de Uso
relacionados: [UC 06]
Descrição: O cliente, devidamente logado, irá confirmar os produtos, endereço de entrega
e forma de pagamento para que seja finalizada a transação e os produtos
possam ser enviados ao destinatário.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.8. [RF08] Cadastrar produto
Identificação: [RF08] Cadastrar Produto
Casos de Uso
relacionados: [UC 06]
Descrição: O Usuário, devidamente autenticado na plataforma administrativa, poderá
cadastrar um novo produto. O Cadastro do produto terá: nome, preço,
departamento, quantidade em estoque, tributação, código de barras.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.9. [RF09] Alterar produto
Identificação: [RF09] Alterar Produto
Casos de Uso
relacionados: [UC 06]
Descrição: O Usuário, devidamente autenticado na plataforma administrativa, poderá
alterar as informações cadastrais do produto.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
3.2.1.10. [RF10] Inativar produto
Identificação: [RF010] Inativar Produto
Casos de Uso
relacionados: [UC 06]
Descrição: O Usuário, devidamente autenticado na plataforma administrativa, poderá
inativar determinado produto.
Prioridade: ☑ Essencial ◻ Importante ◻ Desejável
135
3.2.1.11. [RF11] Consultar pedidos
Identificação: [RF011] Consultar pedidos
Casos de Uso
relacionados: [UC 06]
Descrição: O cliente, devidamente logado, poderá consultar o histórico de seus
pedidos.
Prioridade: ◻ Essencial ☑ Importante ◻ Desejável
3.2.1.12 [RF12] Cancelar pedido
Identificação: [RF012] Cancelar pedido
Casos de Uso
relacionados: [UC 06]
Descrição: Em caso de desistência o cliente, devidamente logado e dentro das
condições da empresa, poderá cancelar o seu pedido.
Prioridade: ◻ Essencial ☑ Importante ◻ Desejável
3.2.2. Requisitos não funcionais
Descreveremos a seguir, os requisitos que envolvem restrições e aspectos de qualidade do
sistema de vendas online. Os requisitos não funcionais serão classificados em: requisitos de
processo, requisitos externos e requisitos de produto.
3.2.2.1 Requisitos de processo
3.2.2.1.1. [RNF01] Utilizar SCRUM como Metodologia de Desenvolvimento
Identificação [NFR01] – Desenvolvimento em SCRUM
Casos de Uso
relacionados Todos.
Descrição O SCRUM será a metodologia empregada, pois permite agilidade e participação
ativa dos stakeholders. Além disso, como o sistema será gerenciado pela
empresa desenvolvedora, não será necessária a geração de uma documentação
formal extensa.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.1.2. [NFR02] - Desenvolvimento em Java
Identificação [NFR02] – Desenvolvimento em JSP
Casos de Uso Todos.
136
relacionados
Descrição O sistema deve ser desenvolvido utilizando a linguagem Java WEB
compatível com o servidor Apache Tomcat 7.0.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.1.3. [NFR03] – Utilizar Banco de Dados MySql
Identificação [NFR03] - Utilizar Banco de Dados MySql
Casos de Uso
relacionados Todos.
Descrição A empresa dispõe de um serviço de banco de dados em MySql, contratado e
não utilizado. Portanto, a aplicação deverá fazer desse serviço ocioso para
persistência dos dados.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.2. Requisitos de Externos
3.2.2.2.1. [NRF04] - Tempo de Desenvolvimento
Identificação [NRF04] - Tempo de Desenvolvimento
Casos de Uso
relacionados Todos.
Descrição O tempo para desenvolvimento do sistema não deve ultrapassar o prazo previsto
no documento de viabilidade, visto a urgência da solução descrita no mesmo
documento. Dessa forma, o tempo de desenvolvimento total não pode ser
superior a 4 meses.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.2.2. [RNF05] - Custo de Desenvolvimento
Identificação [NRF05] - Custo de Desenvolvimento
Casos de Uso
relacionados Todos.
Descrição O custo de desenvolvimento não deve ultrapassar o valor estimado no
documento de viabilidade. Então, para o trabalho de 4 meses temos que não se
deve ultrapassar o valor de R$ 12.000,00.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.3. Requisitos de Produto
3.2.2.3.1. [RNF06] – Permissão
Identificação [NRF06] - Permissão
Casos de Uso
relacionados Todos.
Descrição Cada usuário só poderá realizar ações que foram permitidas a ele na hora
do seu cadastro.
137
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.3.2. [RNF07] – Backup
Identificação [NRF07] - Backup
Casos de Uso
relacionados Todos.
Descrição O sistema deverá disparar Backups agendados a fim de aumentar a segurança
em caso de perda de dados pela empresa contratada para o serviço de
hospedagem do banco.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.3.3. [RNF08] - Mensagens de Retorno
Identificação [NRF08] – Mensagens de Retorno
Casos de Uso
relacionados Todos.
Descrição O sistema deverá exibir uma mensagem na tela para toda ação do usuário, seja
ela bem sucedida ou não, bem como uma descrição do motivo quando for
necessário.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2.3.4. [RNF09] - Menus bem estruturados
Identificação [NRF09] – Menus bem Estruturados
Casos de Uso
relacionados Todos.
Descrição Os menus devem ser bem estruturados de modo a permitir uma navegação
simples e intuitiva, proporcionando uma interface simples, melhorando a
usabilidade.
Prioridade ☑ Essencial ◻ Importante ◻ Desejável
3.2.2. Processo de modelagem de engenharia de requisitos
138
Figura 1 – modelagem de egenharia de requisitos
Fase inicial do projeto onde será escuta o cliente e documentado os requisitos para
desenvolvimento do sistema mostrada na figura 1.
3.2.3. Protótipo de telas
Utilizando o Mocqups foi possível construir um modelo possível para a utilização e
disponibilidade de recursos que foram estabelecidos com base nos requisitos do sistema.
139
Figura 2 – Tela inicial de login e cadastro de cliente
A figura 2 exemplifica os RF01 e RF03, onde serão realizados os cadastros de clientes e a opção de
logar no site.
Figura 3 – Usuário logado no sistema
A figura 3 mostra o direcionamento realizado após o login do usuário, que irá ter acesso a tela
inicial do site, podendo iniciar suas compras.
140
Figura 4 – consulta de produtos
O cliente irá ter a opção de realizar as consultas aos produtos desejados conforme é mostrado na
figura 4. Especificação que consta no RF04.
141
Figura 5 – Tela de carrinho
O cliente após escolher seus produtos, poderá visualizar suas opções no carrinho de compras
conforme mostra a figura 5. O RF05 será utilizado desta forma.
Figura 6 – Confirmar compra
Figura 6 mostra o RF07, com as opções de realizar a finalização da compra.
Figura 7 – Tela de pedidos
142
A tela de pedidos é possível controlar todas as compras realizadas no site, onde o RF11 é atendido.
Figura 8 – Tela administrativa
A tela administrativa irá dá acesso para todas as opções voltadas para os administradores do site,
que poderão cadastrar produtos, alterar preços e outras configurações conformes RFs.
3.3. Gerência de Configuração
A intenção do gerenciamento de configuração é estabelecer e manter a integridade dos
produtos do projeto durante seu ciclo de vida. As principais atividades envolvem identificar a
configuração de software, manter sua integridade durante o projeto e controlar sistematicamente as
mudanças. Esse plano contém todas as informações referentes ao sistema de gerencia de
configuração para o projeto E-commerce.
3.3.1 Controle de configuração
3.3.1.1. Procedimentos de mudança
Toda e qualquer modificação nos itens de configuração deve ser aberta uma CR conforme
descrito na seção 1.3.1.1.1.
3.3.1.1.1. Criando Solicitação de Mudança
As solicitações de mudanças devem ser criadas através de abertura de chamado pelo
administrador. Os seguintes dados devem ser informados:
CAMPO VALOR
143
VERSAO Selecionar a versão apropriada
Grupo Selecionar o grupo de artefatos a ser modificado
Plataforma Todas
OS Todos
Prioridade Selecionar a prioridade para correção do bug. Quanto menor, mais prioritário.
Caso não tenha prioridade, deixar o valor default.
TIPO Escolha o tipo da bronca:
DEFECT: relato de um defeito a ser mudado
ENHANCEMENT: melhoria do artefato já existente
FEATURE: criação de novo artefato
TASK: uma tarefa, normalmente não requer mudança de um item do
Subversion
PATCH: selecione esse tipo para contribuições externas na forma de patches.
Assigned To Responsavel
CC Lista de destinatários
URL URL para alguma página contendo informação adicional que possa auxiliar para
resolução da CR.
Summary Breve descrição do problema
Detailed
Description
Descrição detalhada do problema.
3.3.2. Auditoria de Configuração
As auditorias de configuração devem ser feitas para cada ciclo do processo de
desenvolvimento de forma a garantir que o processo de gerencia de configuração vem sendo
aplicado corretamente. Os artefatos gerados baseados no template devem ser armazenados no
repositório do projeto e devem ser acompanhados pelos gerentes de qualidade e pelos gerentes de
Projeto.
3.3.3. Plano de Contingência
Uma vez por semana será feito um backup da versão mais recente dos artefatos que se
encontram no CVS na máquina de dois membros da fábrica desenvolvimento do projeto.
3.3.4. Ferramentas FERRAMENTA DESCRIÇÃO Eclipse IDE a ser utilizada para o desenvolvimento da aplicação.
GanttProject Gerencia de Projeto
Whatsapp Ferramenta de comunicação
MySQL 5. SGBD a ser utilizado
Subeclipse Plugin do eclipse para gerencia de configuração (SVN)
Tomcat 7 Sevidor de aplicação
TortoiseSVN 1.7 Ferramenta para gerencia de Configuração.
144
3.3.5. Processo de gerência de configuração
Figura 9 - Modelagem do processo de configuração
Com base nos itens de configuração estabelecidos previamente, o processo de gerência de
configuração irá assegurar a integridade de todos os produtos de trabalho, mantendo-os disponíveis.
3.4. Nível de Serviço O objetivo deste acordo é o de assegurar que as partes estão em condições de efetuar a
negociação, que a E-commerce Serviços de Software Ltda está em condições de prestar
serviço de apoio consistente de TI e de entrega ao cliente (s) pelo prestador do serviço (s).
O objetivo deste acordo é a obtenção de mútuo acordo entre a prestação de serviços de
TI entre Provedor e Cliente.
Os objetivos deste acordo são os seguintes:
Prestar serviço de referência, especificando claramente suas responsabilidades e
papéis;
Apresentar uma clara, concisa e mensurável descrição da prestação de serviços ao
cliente;
Listar condições da prestação de serviço efetivo de apoio e entrega.
145
3.4.1. Ambiente de Serviço
As informações a seguir fornecem detalhes sobre os usuários, ferramentas, aplicações e
/ ou outros componentes apoiadas por este SLA:
Número de usuários: Ilimitado
Número de usuários simultâneos: Ilimitado
Número de usuários registrados: Ilimitado
Descrição do
usuário-base
Administradores do site da empresa, clientes.
Âmbito de
aplicações
Versão 1.0, web e mobile.
Infraestrutura de
Serviços:
Servidor web, firewall.
Dependências do
SLA:
Acordos Nível Operacional (OLAS), sustentando Contratos (UCS),
paralelamente SLA dependências.
3.4.2. Contrato de serviço Os seguintes parâmetros detalhados nesta seção do contrato de serviço são da
responsabilidade do prestador do serviço, no apoio contínuo do presente acordo.
3.4.2.1. Escopo de serviço Os seguintes serviços são abrangidos pelo presente acordo; pleno descrições,
caderno de encargos e os custos são delineadas nos “Custos dos serviços”.
Referência Módulo Descrição do Serviço
RF01 Usu O serviço oferecido deve solicitar as seguintes informações:
- Nome de usuário;
- Senha;
RF02 Usu O serviço oferecido deve permitir que usuários deixem o sistema
com segurança.
RF03 Usu O serviço oferecido deve disponibilizar ao cliente a possibilidade
de realizar o cadastro de seus dados no site.
RF04 Ven O serviço deve oferecer a opção ao cliente de verificar a
disponibilidade dos produtos desejados.
RF05 Ven O serviço oferecido deve oferecer ao cliente a possibilidade de
escolher os produtos e continuar comprando outros produtos.
RF06 Ven O serviço deve disponibilizar relatórios gerenciais de todas as
negociações
RF07 Ven O cliente, devidamente logado, irá confirmar os produtos,
endereço de entrega e forma de pagamento para que seja finalizada
146
a transação e os produtos possam ser enviados ao destinatário.
RF08 Pro O Usuário, devidamente autenticado na plataforma administrativa,
poderá cadastrar um novo produto. O Cadastro do produto terá:
nome, preço, departamento, quantidade em estoque, tributação,
código de barras.
RF09 Pro O Usuário, devidamente autenticado na plataforma administrativa,
poderá alterar as informações cadastrais do produto.
RF010 Pro O Usuário, devidamente autenticado na plataforma administrativa,
poderá inativar determinado produto.
RF011 Ped O cliente, devidamente logado, poderá consultar o histórico de
seus pedidos.
RF012 Ped Em caso de desistência o cliente, devidamente logado e dentro das
condições da empresa, poderá cancelar o seu pedido.
3.4.3. Gerenciamento do serviço Eficaz de apoio no âmbito de serviços é um resultado consistente de manutenção de
níveis de serviço. As seções a seguir fornecem informações relevantes sobre a
disponibilidade, acompanhamento, avaliação e comunicação dos serviços no âmbito de
componentes e afins.
3.4.3.1. Disponibilidade do serviço As coberturas específicas para o serviços abrangidos pelo presente acordo são os
seguintes:
24 horas por dia, 365 dia por ano, com as seguintes exceções:
Desenvolvimento do Ambiente
Disponibilidade do Cliente Domingos a partir das 14h
Manutenção Domingos a partir das 14h
Monitoração automática dos serviços 24 horas por dia, 365 dia por ano
3.4.3.2 Medição dos Serviços
As seguintes medições serão criadas e mantidas pelo prestador do serviço a garantir a
melhor prestação de serviço ao cliente:
Medição Definição Alvo
Aplicação X
Disponibilidade
Percentagem de tempo que alguma
Application está disponível fora da
janela de manutenção.
95.5%
147
Tempo de resposta
do cliente
Tempo de resposta para uma amostra
de operações executadas em menos
de 10 segundos.
92,5% das operações
especificadas em 30
segundos ou menos.
3.4.3.3. Relatório em nível de Serviço
O fornecedor de serviços irá oferecer ao Cliente com os seguintes relatórios sobre
a periodicidade indicada:
Nome do relatório Intervalo
A quem se
destina
Responsável
Relatório de disponibilidade de
aplicação
Quinzenal Gerente de
Negócio
Gerente de
Negócio
Tempos de respostas ao cliente Quinzenal Gerente de
Negócio
Gerente de
Negócio
Relatório de incidentes Semanal Gerente de
Negócio
Gerente de
Negócio
3.4.3.4. Pedidos de Serviços
Em apoio aos serviços descritos no presente acordo, o prestador de serviços irá
responder aos incidentes relacionados ao serviço e / ou pedidos apresentados pelo Cliente,
dentro dos seguintes prazos estabelecidos:
Um (1) hora (durante o horário comercial) para questões classificadas como críticas;
Dois (2) horas (durante o horário comercial) para questões classificadas como alta
prioridade;
Quatro (4) horas (durante o horário comercial) para questões classificadas como
prioridade média;
Oito (8) horas (durante o horário comercial) para questões classificados como baixa
prioridade;
Vinte e quatro (24) horas (durante o horário comercial) para uma solicitação de
serviço geral.
3.4.3.5. Manutenção dos Serviços Todos os serviços e / ou componentes relacionados com regularidade exigem
manutenção programada ( "Janela de Manutenção"), a fim de satisfazer níveis de serviço
148
estabelecidos. Estas atividades vão tornar sistemas e / ou aplicações indisponíveis para a
interação entre os utilizadores normais para os seguintes locais e datas:
Data/Horário: domingos entre 14h e 20h
3.5. Gerenciamento de Serviço Automatizado – BPMS
Figura 10 – Abertura de chamado
Tela inicial onde o usuário do sistema irá abrir um chamado relatando seu problema
mostrada na figura 10.
149
Figura 11 – tela de atendimento nível 1
Na figura 11 é possível verificar a tela onde o suporte irá dá início ao atendimento do chamado.
Figura 12 – Atendimento nível 2
Tela de atendimento do chamado nível 2, mostrado na figura 12.
150
Figura 13 – Atendimento nível 3
Figura 13 mostra o atendimento nível 3 do chamado, onde terá que ser resolvido pelo suporte para
que possa ser finalizado e avaliado pelo usuário que abriu.
151
Figura 14 – Fechamento e avaliação do chamado
Na figura 14 será onde o chamado irá ser encerrado e avaliado, para que seja formalmente
resolvido o problema.
3.6 Conclusão
A partir da construção de um guia baseado no framework Cobit, utilizando do uso de
documentações voltadas para requisitos e gerenciamento de configuração, foi possível realizar a
modelagem de um sistema e-commerce.
Foi realizado a estruturação do ciclo dos processos, analisando taticamente cada um deles,
assim, o gerenciamento da TI terá os seus desempenhos aprofundados a partir do momento que se
estabelecer todos os riscos para que sejam devidamente tratados e corrigidos.
152
Apêncide A - Modelagem do processo de análise e desenvolvimento do software
Diagrama 1
Versão: 1.0
Autor: 152A09079
2 . 2 P O O L
2.2.1 ELEMENTOS DO PROCESSO
8/2/2016 153
2.2.1.1 Event
Descrição
Inicio
2.2.1.2 Levantar Requisitos
Descrição
Fase inicial do projeto onde será escuta o cliente e documentado os requisitos para desenvolvimento do sistema.
2.2.1.3 Atribuir valor as tarefas
2.2.1.4 Analise
2.2.1.5 Gerencia Projeto
2.2.1.6 Desenvolvimento
2.2.1.7 Definir backlog
Descrição
Definir a lista de tarefas que o time se compromete a entregar no final da sprint.
2.2.1.8 Desenvolver Tarefa
Descrição
Os programadores receberam as tarefas para desenvolvimento.
2.2.1.9 Validar Tarefa
Descrição
A equipe de testes ficará responsavel por testar e validar as tarefas conformes forem sendo entregues.
2.2.1.10 Gateway
Descrição
Será feito o teste e validação da tarefa para verificar a adequação do item ao que foi documentado. Caso nao atenda os requisitos voltará
ao setor de desenvolvimento.
Portões
Entregar produto
8/2/2016 154
Portão
2.2.1.11 Entregar produto
Descrição
Realização da instalação e treinamento do sistema aos usuarios.
2.2.1.12 Verificar aceitação do cliente
Descrição
Será feito o acompanhamento com o cliente para verificar se o produto que foi entregue se adequará devidamente as suas necessidades e
conforme documentado.
2.2.1.13 Gateway
Descrição
Em Caso de recusa do cliente será direcionado para equipe de analise.
Portões
Negociar mudança nos requisitos
Portão
2.2.1.14 Negociar mudança nos requisitos
Descrição
Negociação com o cliente para mudança do documento de requisitos, renegociaçao de prazos e preços.
2.2.1.15 Event
Descrição
Apos negociação será direcionado para gerencia definir valores e volta da tarefa ao product backlog
2.2.1.16 Event
Descrição
Finalização
2.2.1.17 Event
Descrição
Tarefa volta para que seja atribuído valores
8/2/2016 155
Apêndice B – Modelagem do processo de configuração
Índice
NOVO MODELO BIZAGI MODELER
1 DIAGRAMA 1 1.1 PROCESSO 1
1.1.1 Elementos do processo
1.1.1.1 Event
1.1.1.2 Estabelecer um Sistema de Gerencia de Configuração
1.1.1.3 Identificar os itens de configuração
1.1.1.4 Colocar os itens de configuração sob baseline
1.1.1.5 Registrar a situação dos itens de configuração ao longo do tempo e disponibilidade
1.1.1.6 Controlar as modificações dos itens de configuração
1.1.1.7 Armazenar os Itens de Configuração
1.1.1.8 Manusear os Itens de Configuração
1.1.1.9 Liberar os itens de configuração
1.1.1.10 Auditar os Itens de Configurações
1.1.1.11 Comunicar as informações às partes interessadas
1.1.1.12 Gerenciamento
1.1.1.13 Planejamento
1.1.1.14 Operacional
8/2/2016 156
DIAGRAMA 1
Versão: 1.0
PROCESSO 1
1. ELEMENTOS DO PROCESSO
1. Event
2. Estabelecer um Sistema de Gerencia de COnfiguração
Descrição Um Sistema de Gerência de Configuração é estabelecido e mantido
3. Identificar os itens de configuração
Descrição Os itens de configuração são identificados com base em critérios estabelecidos
4. Colocar os itens de configuração sob baseline
8/2/2016 157
Descrição Os itens de configuração sujeitos a um controle formal são colocados sob baseline
5. Registrar a situação dos itens de configuração ao longo do tempo e disponibilidade
Descrição A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada
6. Controlar as modificações dos itens de configuração
Descrição Modificações em itens de configuração são controladas
7. Armazenar os Itens de Configuração
8. Manusear os Itens de COnfiguração
9. Liberar os itens de configuração
10. Auditar os Itens de Configurações
Descrição Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros,
completos e consistentes
11. Comunicar as informações às partes interessadas
Descrição As informações de itens de configuração são comunicadas às partes interessadas
12. Gerenciamento
13. Planejamento
14. Operacional
8/2/2016 158
Apêndice C - Modelagem do processo de Service desk do Sistema e-commerce
Table of Contents
1 SERVICO ............................................................................................................................................ 160
1.1 ELEMENT ............................................................................................................................... 160
1.2 ABRIR CHAMADO ................................................................................................................... 161
1.3 ATENDER CHAMADO N1 ........................................................................................................ 161
1.4 CHECAR INCIDENTES ............................................................................................................. 162
1.5 ELEMENT ............................................................................................................................... 163
1.6 ATENDER CHAMADO N2 ........................................................................................................ 163
1.7 ELEMENT ............................................................................................................................... 164
1.8 ATENDER CHAMADO N3 ........................................................................................................ 164
1.9 ANALISAR MOTIVO DO PROBLEMA ......................................................................................... 165
1.10 ELEMENT ......................................................................................................................... 166
1.11 SOLICITAR MANUTENÇÃO DE EQUIPAMENTO .................................................................... 166
1.12 REGISTRAR NA BASE DE INCIDENTES ................................................................................ 166
1.13 RECEBER SOLUÇÃO .......................................................................................................... 167
1.14 ELEMENT ......................................................................................................................... 167
1.15 ELEMENT ......................................................................................................................... 167
1.16 REABRIR .......................................................................................................................... 168
1.17 CHECAR CONFIGURAÇAO DE SOFTWARE .......................................................................... 168
1.18 N2 .................................................................................................................................... 168
1.19 ANALISAR REINCIDENCIA DO PROBLEMA ......................................................................... 168
1.20 ELEMENT ......................................................................................................................... 168
1.21 N1 .................................................................................................................................... 169
8/2/2016 159
1.22 AGENDAR TREINAMENTO ................................................................................................. 169
1.23 N1 .................................................................................................................................... 170
1.24 REABRIR .......................................................................................................................... 170
1.25 N2 .................................................................................................................................... 170
1.26 CLIENTE ........................................................................................................................... 170
1.27 NIVEL 1 ............................................................................................................................ 170
1.28 NIVEL 2 ............................................................................................................................ 170
1.29 NIVEL 3 ............................................................................................................................ 170
1.30 MILESTONE 1 ................................................................................................................... 170
33 SS EE RRVV II CC OO
Order
1
Access type
Process
Use parent case number
True
Enable notifications
True
Enable alarms
True
State
Active
Version
1.0
3 . 1 E L E M E N T
8/2/2016 161
3 . 2 A B R I R C H A M A D O
Duration
1/0/0 (d/h/m)
Timer event duration
0/0/0 (d/h/m)
Reassign
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
3 . 3 A T E N D E R C H A M A D O N 1
Description
O técnico de Nivel 1 realiza o primeiro atendimento ao problema do cliente.
Duration
1/0/0 (d/h/m)
Timer event duration
0/0/0 (d/h/m)
Reassign
8/2/2016 162
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
3 . 4 C H E C A R I N C I D E N T E S
Description
Checar em fonte externa se o problema relatado ja foi resolvido em outra ocasião.
Duration
0/0/0 (d/h/m)
Timer event duration
0/0/0 (d/h/m)
Reassign
False
Allow to release
False
Priority
0
Notify
8/2/2016 163
False
Is singleton
False
Mobile access
True
3 . 5 E L E M E N T
Gates
Gate
Condition type
Default
Gate
3 . 6 A T E N D E R C H A M A D O N 2
Description
Caso o técnico de Nivel 1 não resolva o problema o técnico de Nivel 2 receberá o chamado
Duration
2/0/0 (d/h/m)
Timer event duration
0/0/0 (d/h/m)
Reassign
False
Allow to release
False
8/2/2016 164
Priority
0
Notify
False
Is singleton
False
Mobile access
True
3 . 7 E L E M E N T
Gates
Gate
Condition type
Default
Gate
3 . 8 A T E N D E R C H A M A D O N 3
Description
Caso o técnico de Nivel 2 não resolva o problema o técnico de Nivel 3 receberá o chamado
Duration
3/0/0 (d/h/m)
Timer event duration
0/0/0 (d/h/m)
Reassign
8/2/2016 165
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
3 . 9 A N A L I S A R M O T I V O D O P R O B L E M A
Reassign
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
8/2/2016 166
3 . 1 0 E L E M E N T
Gates
Gate
Condition type
Default
Gate
3 . 1 1 S O L I C I T A R M A N U T E N Ç Ã O D E
E Q U I P A M E N T O
3 . 1 2 R E G I S T R A R N A B A S E D E I N C I D E N T E S
Reassign
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
8/2/2016 167
3 . 1 3 R E C E B E R S O L U Ç Ã O
Reassign
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
3 . 1 4 E L E M E N T
Gates
Gate
Gate
Condition type
Default
3 . 1 5 E L E M E N T
8/2/2016 168
3 . 1 6 R E A B R I R
3 . 1 7 C H E C A R C O N F I G U R A Ç A O D E
S O F T W A R E
3 . 1 8 N 2
3 . 1 9 A N A L I S A R R E I N C I D E N C I A D O
P R O B L E M A
Reassign
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
3 . 2 0 E L E M E N T
Gates
8/2/2016 169
Gate
Gate
Condition type
Default
3 . 2 1 N 1
3 . 2 2 A G E N D A R T R E I N A M E N T O
Duration
1/0/0 (d/h/m)
Timer event duration
0/0/0 (d/h/m)
Reassign
False
Allow to release
False
Priority
0
Notify
False
Is singleton
False
Mobile access
True
8/2/2016 170
3 . 2 3 N 1
3 . 2 4 R E A B R I R
3 . 2 5 N 2
3 . 2 6 C L I E N T E
3 . 2 7 N I V E L 1
3 . 2 8 N I V E L 2
3 . 2 9 N I V E L 3
3 . 3 0 M I L E S T O N E 1
Type
Case Creation
8/2/2016 171
Capítulo
4
Gerenciamento de Serviços: Abertura de Chamado Cabaret
Foim-Foim
Cleudimar Galindo, Fábio Arimatéia e Raphael Lorena
Abstract
This section destined to show the management of BPMN and BPMS processes used to develop
the SBS system (Bar System and sex), which applies to show home and adult entertainment. As
well as clarify all the so-called opening process established by the developer company and
approved by the business establishment in accordance with the best practices in ITIL V.3
freamworks and COBIT 4.1
Resumo
Este capítulo destinasse a demonstrar o gerenciamento dos processos BPMN e BPMS utilizados
para o desenvolvimento do sistema SBS (Sistema de Bar e Sexo), que se aplica a casa de show e
entretenimento adulto. Bem como, esclarecer todo o processo de abertura de chamado
estabelecido pela empresa desenvolvedora e aprovada pelo estabelecimento empresarial de
acordo com as melhores práticas nos freamworks ITIL V.3 e COBIT 4.1
4.1 Introdução
O nosso objeto de estudo é um cabaré, onde tem como finalidade melhorar o nível de
serviço, organizar as informações e diminuir o retrabalho. Tendo em vista o grande número de
tarefas a ser realizadas pelas colaboradoras, o projeto vem com o objetivo de ajudar as mesmas
no gerenciamento das informações.
Grande parte das empresas sejam elas de pequeno, médio ou grande porte, ainda se
utilizam de planilhas de cálculo para o seu controle, organização e planejamento de negócio. O
cabaré semanalmente recebe inúmeros clientes para os quais prestam serviços, planilhas
8/2/2016 172
contendo informações do comissionamento a receber, em pagamento aos serviços
disponibilizados pela instituição e suas colaboradoras. Controlar todas as propostas contidas
nessas planilhas é um grande desafio, e esse projeto propõe desenvolver uma ferramenta para
auxiliar o gerenciamento dessas pelos seus encarregados.
4.2 Requisitos do Sistema SBS (Sistema Bar e Sexo)
São definidas as funções que o sistema deve realizar. Os requisitos estão agrupados de
acordo com suas características.
4.2.1 [RF01] Efetuar logon
Identificação: [RF01] Efetuar logon
Casos de Uso relacionados: [UC 01]
Descrição:
Permite que um usuário tenha acesso a informações
pertencentes ao software. Para isso, o usuário deve informar
login e senha. Não deve haver outra maneira de entrar no
sistema diferente desta.
Prioridade: Essencial Importante Desejável
4.2.2 [RF02] Efetuar logoff
Identificação: [RF02] Efetuar logoff
Casos de Uso relacionados: [UC 02]
Descrição: Permite que o usuário saia do sistema.
Prioridade: Essencial Importante Desejável
4.2.3 [RF03] Inserir Pacotes de Serviços
Identificação: [RF03] inserir pacotes de serviços
Casos de Uso relacionados: [UC 03]
Descrição:
O administrador do sistema insere novos pacotes de serviços no
banco de dados do sistema. Um pacote tem os dados: Nome do
pacote, cabaré, Comissão paga pelo cabaré para cada serviço
realizado, Previsão do total de clientes que o pacote pode
atender, período de vigência do pacote.
Prioridade: Essencial Importante Desejável
8/2/2016 173
4.2.4 [RF04] Remover Pacotes de Serviços
Identificação: [RF04] Remover Pacote de Serviços
Casos de Uso relacionados: [UC 04]
Descrição:
O administrador do sistema remove um pacote de serviços no
banco de dados do sistema. Ao realizar essa operação o sistema
deve também remover todos os clientes desse pacote.
Um pedido de confirmação deve ser requerido ao
administrador, juntamente com uma mensagem informando
que o projeto e os clientes associados serão excluídos.
Prioridade: Essencial Importante Desejável
4.2.5 [RF05] Atualizar Pacotes de Serviços
Identificação: [RF05] Atualizar Pacotes de Serviços
Casos de Uso relacionados: [UC 05]
Descrição: O administrador do sistema atualiza os dados de um Pacotes de
Serviços
Prioridade: Essencial Importante Desejável
4.2.6 [RF06] Listar Pacotes de Serviços
Identificação: [RF06] Listar Pacotes de Serviços
Casos de Uso
relacionados: [UC 06]
Descrição: Lista Pacotes de Serviços no cabaré e período de vigência
do Pacotes de Serviços.
Prioridade: Essencial Importante Desejável
4.2.7 Requisitos Não Funcionais
Descreveremos a seguir, os requisitos que envolvem restrições e aspectos de qualidade do
sistema de propostas de pacotes de serviços, SBS (Sistema de Bar e Sexo). Os requisitos não
8/2/2016 174
funcionais serão classificados em: requisitos de processo, requisitos externos e requisitos de
serviços.
4.2.7.1 Requisitos de Processo
4.2.7.2 [RNF01] Utilizar SCRUM como Metodologia de Desenvolvimento
Identificação [NFR01] – Desenvolvimento em SCRUM
Casos de Uso
relacionados
Todos.
Descrição O SCRUM será a metodologia empregada, pois
permite agilidade. Além disso, como o sistema será
gerenciado pela empresa desenvolvedora, não será
necessária a geração de uma documentação formal
extensa.
Prioridade Essencial Importante
Desejável
4.2.7.3 [NFR02] - Desenvolvimento em Java
Identificação [NFR02] – Desenvolvimento em Java
Casos de Uso
relacionados
Todos.
Descrição O sistema deve ser desenvolvido utilizando a
linguagem Java compatível com o servidor Apache
Tomcat 7.0.
Prioridade Essencial Importante
Desejável
4.2.7.4 [NFR03] – Utilizar Banco de Dados MySql
Identificação [NFR03] - Utilizar Banco de Dados MySql
Casos de Uso
relacionados
Todos.
Descrição A empresa dispõe de um serviço de banco de dados em
MySql, contratado e não utilizado. Portanto, a
aplicação deverá fazer desse serviço ocioso para
persistência dos dados.
Prioridade Essencial Importante
Desejável
8/2/2016 175
4.2.8. Requisitos Externos
4.2.8.1 [NRF04] - Tempo de Desenvolvimento
Identificação [NRF04] - Tempo de Desenvolvimento
Casos de Uso
relacionados
Todos.
Descrição O tempo para desenvolvimento do sistema não deve
ultrapassar o prazo previsto no documento de
viabilidade, visto a urgência da solução descrita no
mesmo documento. Dessa forma, o tempo de
desenvolvimento total não pode ser superior a 2 meses.
Prioridade Essencial Importante
Desejável
4.2.8.2 [RNF05] - Custo de Desenvolvimento
Identificação [NRF05] - Custo de Desenvolvimento
Casos de Uso
relacionados
Todos.
Descrição O custo de desenvolvimento não deve ultrapassar o
valor estimado no documento de viabilidade. Então,
para o trabalho de 2 meses temos que não se deve
ultrapassar o valor de R$ 5.998,60.
Prioridade Essencial Importante
Desejável
4.2.9. Requisitos de Produto
4.2.9.1 [RNF06] – Permissão
Identificação [NRF06] - Permissão
Casos de Uso
relacionados
Todos.
Descrição Cada usuário só poderá realizar ações que foram
8/2/2016 176
permitidas a ele na hora do seu cadastro.
Prioridade Essencial Importante
Desejável
4.2.9.2 [RNF07] – Backup
Identificação [NRF07] - Backup
Casos de Uso
relacionados
Todos.
Descrição O sistema deverá disparar Backups agendados a fim de
aumentar a segurança em caso de perda de dados pela
empresa contratada para o serviço de hospedagem do
banco.
Prioridade Essencial Importante
Desejável
4.2.9.3 [RNF08] - Mensagens de Retorno
Identificação [NRF08] – Mensagens de Retorno
Casos de Uso
relacionados
Todos.
Descrição O sistema deverá exibir uma mensagem na tela para
toda ação do usuário, seja ela bem sucedida ou não,
bem como uma descrição do motivo quando for
necessário.
Prioridade Essencial Importante
Desejável
4.2.9.4 [RNF09] - Menus bem estruturados
Identificação [NRF09] – Menus bem Estruturados
Casos de Uso
relacionados
Todos.
Descrição Os menus devem ser bem estruturados de modo a
permitir uma navegação simples e intuitiva,
proporcionando uma interface simples, melhorando a
usabilidade.
8/2/2016 177
Prioridade Essencial Importante
Desejável
Imagem do Processo de Abertura de Chamado
Figura demonstra modelagem do processo de abertura de chamado.
Figura 1 – Processo Abertura de Chamado no Bizagi
8/2/2016 178
Figura da tela de login do sistema.
Figura demonstra a tela de login para acesso ao sistema SBS
Está referenciada a RF01
Figura 2 – Login
Tela de Logoff
Está referenciada a RF02. O Logoff foi inserido em todas as telas depois do login, para
que o admnistrador saia o momento que desejar.
8/2/2016 179
Figura 3 - Logoff
Tela de Cadastro de Serviço
Está referenciada a RF03, figura demostra a tela de cadastro pacotes de serviços do sistema SBS.
Figura 4 – Cadastro de Serviço
Tela de Remover Pacote
8/2/2016 180
Está referenciada a RF04, figura demonstra a tela para remover pacotes de serviços do
sistema SBS.
Figura 5 – Remover Pacote
Tela de Atualizar Pacote
Está referenciada a RF05, figura demonstra a tela para atualizar pacotes de serviços do
sistema SBS.
Figura 6 – Atualizar Pacote
8/2/2016 181
Tela de Listar Pacotes
Está referenciada a RF06, figura demonstra a tela para listar pacotes de serviços do
sistema SBS.
Figura 7 – Listar Pacotes
4.3 Nível de Serviço
4.3.1 Acordo Geral
Este contrato representa um acordo de nível de serviço (" SLA "ou" Contrato ") entre a
RFC Software Ltda e o grupo Foim Foim Prazeres & LTDA para o fornecimento de serviços
de TI necessárias para apoiar e sustentar [Cliente].
O presente acordo permanece válido até ser substituído por uma versão revisada com
acordo mutuamente aprovado pelos interessados. As mudanças são registradas na seção
“Alterações do presente acordo” e são efetivadas após a confirmação mútua das partes
interessadas.
O presente Acordo define os parâmetros de todos os serviços abrangidos, como eles são
mutuamente compreendidos pelos principais intervenientes. O presente acordo não invalida
atuais processos e procedimentos a menos que explicitamente indicado neste documento.
4.3.2 Metas e Objetivos
O objetivo deste acordo é o de assegurar que as partes estão em condições de efetuar a
negociação, que RFC Software Ltda está em condições de prestar serviço de apoio consistente
de TI e de entrega ao cliente (s) pelo prestador do serviço (s).
8/2/2016 182
O objetivo deste acordo é a obtenção de mútuo acordo entre a prestação de serviços de TI
entre Provedor e Cliente.
Os objetivos deste acordo são os seguintes:
• Prestar serviço de referência, especificando claramente suas responsabilidades e papéis;
• Apresentar uma clara, concisa e mensurável descrição da prestação de serviços ao
cliente;
• Listar condições da prestação de serviço efetivo de apoio e entrega.
4.3.3 Responsáveis
Os seguintes Provedores e o Cliente serão usados como base do acordo e representam os
principais intervenientes associados a este SLA:
Provedor de Serviço de TI: RFC Software Ltda
Cliente: Foim Foim Prazeres & LTDA
A seguir, as partes interessadas são responsáveis pela implantação e suporte contínuo do
presente acordo:
Stakeholder Nome Contato
Gerente TI Raphael Lorena
Gerente TI Fabio Arimateia
Diretora da Foim Foim Rita Alves
Gerente de Produção Nicole Silva
4.3.4 Ambiente de Serviço
As informações a seguir fornecem detalhes sobre os usuários, ferramentas, aplicações e /
ou outros componentes apoiadas por este SLA:
Número de usuários: 15
Número de usuários simultâneos: 15
8/2/2016 183
Número de usuários registrados: 100
Descrição do usuário-base usuário interno
Âmbito de aplicações Versão 1, módulos de agendamento, Salão de festas,
Financeiro, Contabil/Fiscal, BI, Relatórios
Infraestrutura de Serviços: Rede cabeada de 100 Mbps e Wifi para o módulo de
Salão de Festa com segurança.
Dependências do SLA: Dependência do SLA da rede Interna e do WIFI
8/2/2016 184
4.3.5 Revisão Periódica
Este acordo é válido a partir da data efetiva delineada neste documento e é válido até à
data da rescisão. Este acordo deverá ser revisto pelo menos uma vez por ano fiscal, no entanto,
em vez de uma revisão durante o período especificado, o atual acordo permanecerá em vigor.
O Gerente de Negócios é responsável por facilitar a revisões regulares do presente
documento. O conteúdo deste documento pode ser alterada conforme necessário, desde que o
mútuo acordo é obtido a partir do primeiro comunicado a todos os interessados e as partes
afetadas. O proprietário do documento vai incorporar todas as revisões ulteriores e de obter
acordos mútuos / as aprovações necessárias.
Gerente de Negócios: Raphael Lorena
Periodicidade da revisão: 1 ano
Data prevista para revisão: 09/07/2017
Este acordo será enviado para os seguintes locais e vai ser acessível a todas as partes
interessadas:
Local do Documento: File Server da empresa Foim Foim Prazeres & Ltda.
4.3.6 Contrato de Serviço
Os seguintes parâmetros detalhados nesta seção do contrato de serviço são da
responsabilidade do prestador do serviço, no apoio contínuo do presente acordo.
4.3.6.1 Escopo do Serviço
Os seguintes serviços são abrangidos pelo presente acordo; pleno descrições, caderno de
encargos e os custos são delineadas nos “Custos dos serviços”.
Referência Módulo Descrição do Serviço
[RF01] Log Permite que um usuário tenha acesso a informações
pertencentes ao software. Para isso, o usuário deve informar
login e senha. Não deve haver outra maneira de entrar no
8/2/2016 185
sistema diferente desta.
[RF02] Log Permite que o usuário saia do sistema.
[RF03] Cad O administrador do sistema insere novos pacotes de serviços
no banco de dados do sistema. Um pacote tem os dados:
Nome do pacote, cabaré, Comissão paga pelo cabaré para
cada serviço realizado, Previsão do total de clientes que o
pacote pode atender, período de vigência do pacote.
[RF04] Cad O administrador do sistema remove um pacote de serviços no
banco de dados do sistema. Ao realizar essa operação o
sistema deve também remover todos os clientes desse pacote.
Um pedido de confirmação deve ser requerido ao
administrador, juntamente com uma mensagem informando
que o projeto e os clientes associados serão excluídos.
[RF05] Cad O administrador do sistema atualiza os dados de um Pacotes
de Serviços
[RF06] Cad Lista Pacotes de Serviços no cabaré e período de vigência do
Pacotes de Serviços.
4.3.6.2 Responsabilidades do Cliente
As responsabilidades e / ou requisitos dos clientes em apoio do presente acordo incluem:
• A adesão relacionadas com políticas, processos e procedimentos descritos nos Apêndices;
• Adequação incidentes e / ou solicitar priorização como descrito anteriormente e / ou em
cooperação com o prestador de serviços;
• Opções de programação de todos os serviços relacionados com os pedidos e outros serviços
especiais com o prestador de serviços;
• Adequação da utilização de apoio conforme descrito no Apêndice A: Políticas relacionadas,
Processos e Procedimentos;
• Pagamento de todos os serviços relacionados com a instalação e / ou de configuração
despesas anteriores à prestação do serviço;
• Revisão todas as horas autenticadas pelo fornecedor de serviços para adequação;
• Razoável disponibilidade do cliente representante (s) na resolução de um incidente ou
serviço relacionado pedido.
8/2/2016 186
4.3.6.3 Responsabilidades do Provedor de Serviços,
Service Provider responsabilidades e / ou requisitos em apoio do presente acordo
incluem:
• Reuniões devidamente associadas a resposta a incidentes relacionados com serviços;
• Geração de relatórios trimestrais sobre os níveis de serviço para o cliente;
• Formação exigida pessoal em serviço com instrumentos de apoio adequados;
• Registrar todas as horas providas de recursos associados a serviços e prestados para a
revisão pelo Cliente;
• Devida notificação ao Cliente das manutenções programadas;
• Facilitação de apoio ao serviço de todas as atividades que envolvam incidente, problema,
mudança, liberação de configuração e gerenciamento.
4.3.6.4 Serviços Pressupostos
Pressupostos relacionados com o âmbito de serviços e / ou componentes incluem:
Os serviços são prestados a clientes externos de TI e são comunicados aos gerentes de
negócios;
Atendimento ao usuário básico permanecerá dentro de 5% dos efetivos níveis atuais;
Financiamento para maiores atualizações serão fornecidas pelo Cliente e tratado como um
projeto fora do âmbito de aplicação do presente acordo;
Mudanças de serviços serão documentadas e comunicadas a todos os interessados.
4.3.7 Gerenciamento do Serviço
Eficaz de apoio no âmbito de serviços é um resultado consistente de manutenção de níveis de
serviço. As seções a seguir fornecem informações relevantes sobre a disponibilidade,
acompanhamento, avaliação e comunicação dos serviços no âmbito de componentes e afins.
4.3.7.1 Disponibilidade do Serviço
As coberturas específicas para os serviços abrangidos pelo presente acordo são os
seguintes:
8/2/2016 187
24 horas por dia, 365 dias por ano, com as seguintes exceções:
Desenvolvimento do Ambiente
Disponibilidade do Cliente Domingos a partir das 14h
Manutenção Domingos a partir das 14h
Monitoração automático dos
serviços
24 horas por dia, 365 dias por ano
4.3.7.2 Medição dos Serviços
As seguintes medições serão criadas e mantidas pelo prestador do serviço a garantir a melhor
prestação de serviço ao cliente:
Medição Definição Alvo
Aplicação X
Disponibilidade
Percentagem de tempo que
alguma Application está
disponível fora da janela de
manutenção.
95.5%
Tempo de
resposta do
cliente
Tempo de resposta para uma
amostra de operações
executadas em menos de 10
segundos.
92,5% das operações
especificadas em 30 segundos ou
menos.
4.3.7.3 Relatório em nível de Serviço
O fornecedor de serviços irá oferecer ao Cliente com os seguintes relatórios sobre a periodicidade
indicada:
Nome do relatório Intervalo A quem se destina Responsável
Relatório de Quinzenal Gerente de Negócio Gerente de Negócio
8/2/2016 188
disponibilidade de
aplicação
Tempos de
respostas ao cliente
Quinzenal Gerente de Negócio Gerente de Negócio
Relatório de
incidentes
Semanal Gerente de Negócio Gerente de Negócio
4.3.7.4 Pedidos de Serviços
Em apoio aos serviços descritos no presente acordo, o prestador de serviços irá responder aos
incidentes relacionados ao serviço e / ou pedidos apresentados pelo Cliente, dentro dos seguintes
prazos estabelecidos:
Um (1) hora (durante o horário comercial) para questões classificadas como críticas;
Dois (2) horas (durante o horário comercial) para questões classificadas como alta
prioridade;
Quatro (4) horas (durante o horário comercial) para questões classificadas como prioridade
média;
Oito (8) horas (durante o horário comercial) para questões classificados como baixa
prioridade;
Vinte e quatro (24) horas (durante o horário comercial) para uma solicitação de serviço
geral.
4.3.7.5 Manutenção dos Serviços
Todos os serviços e / ou componentes relacionados com regularidade exigem
manutenção programada (“Janela de Manutenção"), a fim de satisfazer níveis de serviço
estabelecidos. Estas atividades vão tornar sistemas e / ou aplicações indisponíveis para a
interação entre os utilizadores normais para os seguintes locais e datas:
Data/Horário: terça entre 08h e 12h
4.3.8 Modelagem do serviço
Figura 8 – Modelagem de serviço
8/2/2016 190
4.4 Catálogo de Serviços
Esse catálogo tem como finalidade definir serviços de TI oferecidos pela nossa empresa
de consultoria para o Foim Foim Prazeres & LTDA, onde estaremos propondo soluções em
governança em ti para que possa minimizar problemas relacionados a falta de controle dos
serviços oferecidos.
Serviços:
Service Desk – a implantação de um Service Desk será fundamental para a casa dos prazeres
com a finalidade de concentrar todas ligações em um só lugar, onde terá um base dados com as
informações necessárias para que o funcionário possa solucionar de maneira rápida e eficaz
problemas conhecidos ou indicar o profissional indicado para realização de uma determinada
tarefa.
Código Unidade Organizacional
001 Suporte ao Usuário / Administração de Sistemas
Descrição Características
Service Desk
Disponibilidade de serviço de apoio a usuários para suporte e
resolução de problemas técnicos.
Requisitos de Atendimento Requisitos da Equipe
Todas as solicitações referente
a problemas (equipamentos e
manutenção, incidentes e
requisições),deverão ser
encaminhadas para o Service
Desk para que a realização do
serviço seja cadastrada e que
rapidamente possa solucionar o
problema, observando as
necessidades do cliente bem
como a legislação vigente,
dentro do horário do
expediente.
Suporte ao usuário com conhecimentos nos serviços
prestados no local do cliente
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1. Disponibilidade do
software
50% em até
4 horas.
25% em até
6 horas.
25% em até
8 horas. Mensal
Janela: 24h x 30d =
720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Disponibilidade da base
de dados.
Até 80 chamados
simultâneos
8/2/2016 191
Software SBS – Será desenvolvido um software para a Foim Foim Prazeres & LTDA
para que todas informações referente ao cabaré esteja contido nesse software com a finalidade
de utilizar a web para expandir vendas e controle interno financeiro e organizacional do cabaré
bem como disponibilizar preços, reservas de quartos e todos o serviços de portfólio que o
cabaré oferece para que o cliente sinta-se satisfeito ao que se diz respeito as informações do
empreendimento, evitando com isso inúmeros transtornos para o cabaré e aumentando a receita,
pois uma grande maioria dos clientes são jovens e utilizam a web para decidir quais serviços
iram ser utilizados.
Código Unidade Organizacional
002 Desenvolvimento de software
Descrição Características
Software SVS
Disponibilidade do serviço do portal com desempenho e
segurança.
Requisitos de Atendimento Requisitos da Equipe
Qualquer solicitação de atendimento
referente ao software deve ser
encaminhada ao setor de
desenvolvimento para que o mesmo
possa checar o problema e
disponibilizar a solução o mais
rápido possível.
Desenvolvedor com conhecimento em Java com SQL Server e forte
conhecimento em regras de negocio.
Item de Controle SLA* Periodicidade Disponibilidade Condicionante
1. Disponibilidade do
Software
50% em até
4 horas.
25% em até
6 horas.
25% em até
8 horas. Mensal
Janela: 24h x 30d =
720h/mês
Indisponibilidade:
36h/mês
Disponibilidade:
95%/mês
Disponibilidade
infraestrutura de rede e
Hardware
Disponibilidade do
servidor do banco de
dados
*SLA – de acordo com informações disponibilizadas pelo fornecedor de infraestrutura de rede /
hardware e servidor de banco de dados.
8/2/2016 192
Figura 9 –Tela de Login
Funcionalidades:
Reservas de quartos.
Orçamentos.
Visualização de todos os tipos de quartos.
Reservas para eventos.
Propagandas e ofertas.
Entre outras funcionalidades.
CRM: Devido a preocupação com a insatisfação dos clientes é de extrema importância
a implantação de um CRM, para que possamos identificar o que os clientes não estão
gostando e o que eles gostam do cabaré, tratando cada cliente de maneira individual
para que da próxima vez que voltar ao cabaré já sabemos o seu gosto e agilizar o seu
atendimento de forma a satisfazê-lo e melhorando o nosso serviço.
Login :
8/2/2016 193
4.5 Gerenciamento de Serviço Automatizado – BPMS
Figura 10 – Tela inicial abertura de chamado
8/2/2016 194
Figura 11 – Resolução de chamado nível 1
Figura 12 – Tela de resolução final do chamado
Figura 13 – SLA da resolução abertura de chamado
4.6 Conclusão
Conclui-se que a utilização da metodologia do BPM permite que, através de uma
execução e de um controle mais eficaz, processos possam ser melhorados em qualquer área.
8/2/2016 195
Percebesse que a utilização de processos de gerenciamento é de extrema importância na
modelagem gerencial destinado a demonstrar a aplicabilidade das boas práticas na TIC
(Tecnologia da Informação e Comunicação) como as de BPMN, BMPNS, freamworks ITIL V.3
e COBIT 4.1.
8/2/2016 196
Apêndice A – Modelagem de processo
Diagrama 1
8/2/2016 101
Versão: 1.0
Autor: 151b09013
3 . 3 1 C A B A R E T F O I M F O I M
3.31.1 ELEMENTOS DO PROCESSO
3.31.1.1 Event
Descrição
Início do desenvolvimento
3.31.1.2 Levantar requisitos
Descrição
Levantamento de requisito junto ao cliente, demonstrando suas necessitades para o software
3.31.1.3 Elaborar documentação
Descrição
Construção da documentação da elaboração de requisito
3.31.1.4 Elaborar backlog
Descrição
Elaboração da necessidades do software
3.31.1.5 Desenvolver o software
Descrição
Atividade de desenvolvimento junto com a equipe técnica
8/2/2016 102
3.31.1.6 Gateway
Descrição
Verifica se o software está correto
Portões
Se concluido ir para teste
Questionar dúvida
3.31.1.7 Questionar dúvida
Descrição
Atividade para sanar dúvidas durante o desenvolvimento e teste do software
3.31.1.8 Gateway
Descrição
Verifica se a dúvida foi solucionada
Portões
Dúvida solucionada
Dúvida não solucionada, volta ao requisito
3.31.1.9 Testar software
Descrição
Atividade para testar o software desenvolvido pela equipe técnica observando se os requisitos funcionais e não funcionais estão de
acordo com a documentação
3.31.1.10 Gateway
Descrição
Verifica se o software foi aprovado no teste
Portões
Falha no software
8/2/2016 103
Software aprovado
3.31.1.11 Instalar software
Descrição
Instalar o software no ambiente de produção do cliente.
3.31.1.12 Event
Descrição
Fim do processo de desenvolvimento
3.31.1.13 Analise
3.31.1.14 Desenvolvimento
3.31.1.15 Homologação
3.31.1.16 Produção
8/2/2016 104
Capítulo
5
Gerenciamento de Serviços: Sistema bibliotecário
Caio Henrique Monteiro B. de Moraes, Luciano
Paulino da Silva Filho
Abstract
This meta-article describes the problem identified in a public library Caruaru and
specifies the requirements for the solution found at the stage of feasibility study carried
out previously. This solution is centered around an information system to be built from
the information captured by the use of certain techniques described below.
Resumo
Este meta-artigo descreve o problema identificado em uma biblioteca pública de
Caruaru e especifica os requisitos para a solução encontrada durante a fase de estudo de
viabilidade realizada previamente. Essa solução tem como centro um sistema de
informação que deve ser construído a partir das informações capturadas pela utilização
de algumas técnicas descritas adiante.
5.1. Introdução
O nosso objeto de estudo é uma Biblioteca Pública, onde tem como finalidade
maior organizar as informações e diminuir o retrabalho dos funcionários. Tendo em
vista o grande número de tarefas, e a realização de cadastros manuais dos colaboradores.
5.2. Requisitos do Sistema (Sistema Bibliotecário)
O objetivo desde documento é descrever o problema que foi identificado e
especificar os requisitos para a solução encontrada durante a fase de estudo de
viabilidade realizada previamente. Essa solução tem como centro um sistema de
informação que deve ser construído a partir das informações capturadas pela utilização
de algumas técnicas descritas adiante.
8/2/2016 105
5.2.1 Motivação
Otimizar a performance dos funcionários da biblioteca, implementando um
sistema para cadastro de usuários e livros didáticos
5.2.2 O Problema Identificado
O tempo que os funcionários perdiam para cadastrar manualmente em planilhas
os usuários daquela biblioteca pública e o descontrole de livros emprestados eram muito
grande. O que trazia uma morosidade muito grande ao processo.
5.2.3 Sobre a Organização
Esse documento baseia-se em uma biblioteca pública localizada na Avenida
Agamenon Magalhaes, que disponibiliza livros e dvd’s para consulta ou empréstimo,
atendendo todas as faixas etárias,
A biblioteca tem como objetivo realizar os seguintes serviços:
Empréstimos de Livros;
Empréstimos de dvds de vídeos aulas;
Consulta de livros;
Consulta de dvds;
5.2.4 Propostas para Sistema Bibliotecário
O sistema de gestão bibliotecário, tem como objetivo facilitar o dia a dia dos
colaboradores e dos usuários, com a automatização dos processos da biblioteca.
5.2.5 Convenções para Identificação dos Requisitos
Por convenção, os requisitos são indicados e referenciados por um indicador no
formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não
funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os
nomes dos casos de uso relacionados.
5.2.6 Convenções para Identificação dos Casos de Uso
Por convenção, os casos de uso são indicados e referenciados por um indicador
no formato [UCxx], onde xx se refere ao número do caso de uso.
5.2.7 Estrutura dos casos de uso
Cada caso de uso terá o seguinte formato:
Atores: Os modelos de usuário que utilizarão o caso de uso;
Prioridade: Prioridade de implementação deste caso de uso;
8/2/2016 106
Entradas: Variáveis que serão passadas ao sistema;
Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso
ser executado;
Fluxo de eventos: O passo a passo das ações realizadas para que o caso de
uso seja concluído, podendo incluir fluxos de eventos secundários e/ou
alternativos;
Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de uso
for executado;
Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso
ser finalizado.
5.2.8 Prioridades dos casos de uso
Os casos de uso são classificados como:
Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse
tipo de caso de uso deve ser implementado impreterivelmente, caso
contrário, o projeto perderá sua utilidade.
Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado.
Contudo, essa utilização se dá de forma não satisfatória pelo cliente.
Desejável: Esse tipo de caso de uso poderá ser implementado em versões
posteriores do sistema, visto que, mesmo sem a sua implementação, o
sistema atende as suas funcionalidades básicas.
5.2.9 Descrição dos Atores
Os atores são aqueles que interagem de alguma forma com o sistema. Eles são
bancos e instituições financeiras.
5.3 Requisitos Organizacionais
Os requisitos organizacionais devem satisfazer os objetivos da organização e
definir porque o sistema é necessário. Esses requisitos são:
Facilitar comunicação bancos e instituições financeiras – tornar a comunicação
entre as partes mais ágil e tranqüila;
Fornecer informações sobre as correspondências bancárias – tornar transparentes
informações do processo envolvido;
Obter maior controle das parcelas dos clientes em relação à inadimplência.
5.4. Requisitos Funcionais
Neste capítulo são definidas as funções que o sistema deve realizar. Os requisitos
estão agrupados de acordo com suas características.
8/2/2016 107
5.4.1 [RF01] Efetuar logon
Identificação: [RF01] Efetuar logon
Casos de Uso relacionados: [UC 01]
Descrição:
Permite que um usuário tenha acesso a informações
pertencentes ao software. Para isso, o usuário deve informar
login e senha. Não deve haver outra maneira de entrar no
sistema diferente desta.
Prioridade: Essencial Importante Desejável
5.4.2 [RF02] Efetuar logoff
Identificação: [RF02] Efetuar logoff
Casos de Uso relacionados: [UC 02]
Descrição: Permite que o usuário saia do sistema.
Prioridade: Essencial Importante Desejável
5.4.3 [RF03] Inserir Usuário
Identificação: [RF03] Inserir Usuário
Casos de Uso relacionados: [UC 03]
Descrição: Os colaboradores da biblioteca, irão cadastrar os usuários para
poderem realizar empréstimos de livros didáticos ou dvds.
Prioridade: Essencial Importante Desejável
5.4.4 [RF04] Remover Usuário
Identificação: [RF04] Remover Usuário
Casos de Uso relacionados: [UC 04]
Descrição: Os colaboradores terão a opção de excluir os usuários do
sistema por algum motivo indesejável.
8/2/2016 108
Prioridade: Essencial Importante Desejável
5.4.5 [RF05] Atualizar Usuário
Identificação: [RF05] Atualizar Usuário
Casos de Uso relacionados: [UC 05]
Descrição: Os colaboradores têm autorização para alterar os dados
cadastrais dos usuários.
Prioridade: Essencial Importante Desejável
5.4.6[RF06] Consultar Usuários
Identificação: [RF06] Consultar Usuários
Casos de Uso
relacionados:
[UC 06]
Descrição: Os colaboradores têm a opção de consultar os usuários, sempre
que for necessário.
Prioridade: Essencial Importante Desejável
5.4.7 [RF07] Inserir Livro
Identificação: [RF07] Inserir Usuário
Casos de Uso relacionados: [UC 07]
Descrição: Os colaboradores da biblioteca, irão cadastrar os livros
disponíveis na biblioteca
Prioridade: Essencial Importante Desejável
5.4.8 [RF08] Remover Livros
Identificação: [RF08] Remover Livros
Casos de Uso relacionados: [UC 08]
8/2/2016 109
Descrição: Os colaboradores terão a opção de excluir os livros do sistema
por algum motivo indesejável.
Prioridade: Essencial Importante Desejável
5.4.9 [RF09] Atualizar Livros
Identificação: [RF09] Atualizar Livros
Casos de Uso relacionados: [UC 09]
Descrição: Os colaboradores têm autorização para alterar os dados
cadastrais dos livros.
Prioridade: Essencial Importante Desejável
5.4.10 [RF10] Consultar Livros
Identificação: [RF10] Consultar Livros
Casos de Uso
relacionados:
[UC 10]
Descrição: Os colaboradores têm a opção de consultar os Livros, sempre
que for necessário.
Prioridade: Essencial Importante Desejável
5.4.11 [RF11] Inserir DVDs
Identificação: [RF11] Inserir DVDs
Casos de Uso relacionados: [UC 11]
Descrição: Os colaboradores da biblioteca, irão cadastrar os DVDs
disponíveis para empréstimos aos usuários.
Prioridade: Essencial Importante Desejável
5.4.12 [RF12] Remover DVDs
Identificação: [RF12] Remover Usuário
8/2/2016 110
Casos de Uso relacionados: [UC 12]
Descrição: Os colaboradores terão a opção de excluir os DVDs
cadastrados no sistema
Prioridade: Essencial Importante Desejável
5.4.13 [RF13] Atualizar Usuário
Identificação: [RF13] Atualizar Usuário
Casos de Uso relacionados: [UC 13]
Descrição: Os colaboradores têm autorização para alterar os dados
cadastrais dos DVDs.
Prioridade: Essencial Importante Desejável
5.4.14 [RF14] Consultar DVDs
Identificação: [RF14] Consultar Usuários
Casos de Uso
relacionados:
[UC 14]
Descrição: Os colaboradores têm a opção de consultar os DVDs cadastrados
no sistema, sempre que for necessário.
Prioridade: Essencial Importante Desejável
5.5 Requisitos Não Funcionais
Descreveremos a seguir, os requisitos que envolvem restrições e aspectos
de qualidade do Sistema Bibliotecário. Os requisitos não funcionais serão classificados
em: requisitos de processo, requisitos externos e requisitos de produto.
5.5.1 Requisitos de Processo
5.5.1.1 [RNF01] Utilizar SCRUM como Metodologia de Desenvolvimento
Identificação [NFR01] – Desenvolvimento em SCRUM
8/2/2016 111
Casos de Uso
relacionados
Todos.
Descrição O SCRUM será a metodologia empregada, pois
permite agilidade e participação ativa dos
stakeholders. Além disso, como o sistema será
gerenciado pela empresa desenvolvedora, não será
necessária a geração de uma documentação formal
extensa.
Prioridade Essencial Importante
Desejável
5.5.1.2 [NFR02] - Desenvolvimento em Java
Identificação [NFR02] – Desenvolvimento em Java
Casos de Uso
relacionados
Todos.
Descrição O sistema deve ser desenvolvido utilizando a
linguagem Java compatível com o servidor Apache
Tomcat 7.0.
Prioridade Essencial Importante
Desejável
5.5.1.3 [NFR03] – Utilizar Banco de Dados MySql
Identificação [NFR03] - Utilizar Banco de Dados MySql
Casos de Uso
relacionados
Todos.
Descrição A empresa dispõe de um serviço de banco de dados em
MySql, contratado e não utilizado. Portanto, a
aplicação deverá fazer desse serviço ocioso para
persistência dos dados.
Prioridade Essencial Importante
Desejável
5.5.2 Requisitos de Externos
5.5.2.1 [NRF04] - Tempo de Desenvolvimento
Identificação [NRF04] - Tempo de Desenvolvimento
Casos de Uso
relacionados
Todos.
Descrição O tempo para desenvolvimento do sistema não deve
ultrapassar o prazo previsto no documento de
viabilidade, visto a urgência da solução descrita no
8/2/2016 112
mesmo documento. Dessa forma, o tempo de
desenvolvimento total não pode ser superior a 2 meses.
Prioridade Essencial Importante
Desejável
5.5.2.2 [RNF05] - Custo de Desenvolvimento
Identificação [NRF05] - Custo de Desenvolvimento
Casos de Uso
relacionados
Todos.
Descrição O custo de desenvolvimento não deve ultrapassar o
valor estimado no documento de viabilidade. Então,
para o trabalho de 2 meses temos que não se deve
ultrapassar o valor de R$ 5.998,60.
Prioridade Essencial Importante
Desejável
5.5.3 Requisitos de Produto
5.5.3.1 [RNF06] - Permissão
Identificação [NRF06] - Permissão
Casos de Uso
relacionados
Todos.
Descrição Cada usuário só poderá realizar ações que foram
permitidas a ele na hora do seu cadastro.
Prioridade Essencial Importante
Desejável
5.5.3.2 [RNF07] - Backup
Identificação [NRF07] - Backup
Casos de Uso
relacionados
Todos.
Descrição O sistema deverá disparar Backups agendados a fim de
aumentar a segurança em caso de perda de dados pela
empresa contratada para o serviço de hospedagem do
banco.
Prioridade Essencial Importante
Desejável
5.5.3.3 [RNF08] - Mensagens de Retorno
Identificação [NRF08] – Mensagens de Retorno
Casos de Uso
relacionados
Todos.
Descrição O sistema deverá exibir uma mensagem na tela para
8/2/2016 113
toda ação do usuário, seja ela bem sucedida ou não,
bem como uma descrição do motivo quando for
necessário.
Prioridade Essencial Importante
Desejável
5.5.3.4 [RNF09] - Menus bem Estruturados
Identificação [NRF09] – Menus bem Estruturados
Casos de Uso
relacionados
Todos.
Descrição Os menus devem ser bem estruturados de modo a
permitir uma navegação simples e intuitiva,
proporcionando uma interface simples, melhorando a
usabilidade.
Prioridade Essencial Importante
Desejável
Figura 1 Modelagem de Requisitos Funcionais (Casos de Uso)
5.6 Gerência de Configuração
Este documento descreve o Plano de Gerência de Configuração para o projeto de
desenvolvimento do Sistema Bibliotecário.
Objetivos
O presente documento tem por objetivo apresentar a organização, nomenclatura
e regras de versionamento para a gerencia de configuração do projeto de
desenvolvimento do Sistema Bibliotecário.
Este plano é destinado a todos os integrantes da equipe responsável pelo o
desenvolvimento do sistema.
Organização do Documento
As seções subsequentes deste documento estão assim organizadas: Seção 2, é
descrito os papeis e responsabilidades da gerência de configuração; Seção 3 é apresenta
o plano de configuração onde é definido a estrutura do armazenamento, as
configurações bases do projeto, o controle de configuração e as políticas de segurança e
acesso aos itens de configuração; Seção 4 define como este plano será evoluído; Seção 5
define os métodos de identificação;Seção 6 apresenta a infra-estrutura de software e
hardware utilizados no projeto.Seção 7 apresenta as assinaturas e data da aprovação
deste documento.Seção 8 apresenta o material bibliográfico utilizado para a confecção
deste plano.
8/2/2016 114
Seção 9 apresenta os modelos de anexos dos documentos necessário para a
gerência de configuração.
Papeis e Responsabilidades
Papel Responsabilidade
Gerente de Desenvolvimento (GD) Receber, analisar e aprovar os PFMs.
Líder de Projeto (LP) Planejar as atividades de GC juntamente com o
Responsável pela Configuração, designar
executante, finalizar SM, autorizar a criação das
configurações bases conforme descritas na seção
Plano de Configuração.
Responsável pela Configuração (RC) Criar e manter infra-estrutura corporativa
(servidores) de GC; Implementar as políticas de
Controle de Acesso ao ambiente de GC, Realizar
os backups dos repositório de configuração dos
projetos
Plano de Configuração
A estrutura de pastas utilizadas para o controle de versionamento é descrita
como:
Trunk – pasta que contêm a estrutura definida no item. Sua finalidade é receber
todos os artefatos. A equipe armazena nesta pasta todas as versões de trabalho dos
documentos ou códigos.
Branches – pasta que armazena os documentos de uma versão que está
sofrendo uma mudança diferente da linha nomal de desenvolvimento.
Tags – pasta que armazena as configurações bases do projeto. Estes itens de
configuração representam versões-base para entrega e não sofrerão mais mudanças.
Wiki – pasta para armazenas páginas de informação do projeto.
Tipos de Configuração
Os tipos de configurações definidas para este projeto são:
8/2/2016 115
e) Configuração base de APD: é gerada quando a Ativação de Projeto de
Software e o Cronograma do Projeto for aprovado formalmente pelo
Gerente de Desenvolvimento.
f) Configuração base de LPS: é gerada quando o Levantamento Preliminar
de Software for aprovado pelo Gerente de Desenvolvimento.
g) Configuração base de EOR: é gerada quando o Especificação de
Objetivos e Requisitos for aprovada formalmente pelo Gerente de
Desenvolvimento.
h) Configuração base de PDS: é gerada quando o Plano de
Desenvolvimento de Software e seus planos correlatos for aprovado
formalmente pelo Gerente de Desenvolvimento.
O conteúdo das configurações bases podem listados na tabela abaixo:
ID Nome Itens de Configuração que compõem a
configuração base
Configuração
APD Configuração de APD
APD - Ativação de Projeto de Desenvolvimento
Cronograma do Projeto
Configuração LPS Configuração de LPS LPS – Levantamento Preliminar de Software
Configuração
EOR Configuração de EOR EOR – Especificação de Objetivos e Requisitos
Configuração PDS Configuração de PDS
PDS – Plano de Desenvolvimento de Software
PGR – Plano de Gerência de Riscos
PGQ – Plano de Gerência de Qualidade
PCP – Plano de Comunicação do Projeto
PGQ – Plano de Gerência de Configuração
Configuração
CICLO1
Configuração do 1º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Configuração
CICLO2
Configuração do 2º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Configuração
CICLO3
Configuração do 3º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Configuração
CICLO4
Configuração do 4º
Ciclo
MAS – Documento de Análise de Software
MPS – Documento de Projeto de Software
Tabela 14 - Itens de configuração que compõe as configurações bases
Controle de Configuração
Para o armazenamento dos artefatos de projeto a equipe utiliza um repositório
denominado SVN hospedado no Google Code.
8/2/2016 116
O controle de versionamento dos itens de configuração ocorrerá através da própria
ferramenta. As baselines ou configuração base quando aprovadas receberá uma versão
manual definido de acordo com o item 0 deste documento.
As atualizações nos itens de configuração no repositório ocorre através da execução
do comando SVN Commit/SVN Submeter da ferramenta sempre que o autor julgar
conveniente a criação de um nova versão do item. Caso o elemento da equipe necessita
trabalhar deverá executar o comando SVN Update/SVN Atualizar para obter a versão
mais recente do item.
As versões aprovadas para fazer parte de uma baseline deverão ser bloqueadas
através do comando Get Lock/Obter bloqueio. O desbloqueio ocorrerá através do
comando Realease Lock/Liberar bloqueio somente após aprovação da mudança
submetida ao processo formal de mudanças definido no item 0 deste documento.
Somente o Responsável Pela Configuração que pode realizar o desbloqueio e uma nova
versão de trabalho deve ser gerada.
Estrutura do Repositório de Gerência de Configuração
A seguir será apresenta a estrutura definida para armazenamento dos artefatos do
projeto no repositório.
SVN
+-branches
| +-SBTCvX.X
| +-Acompanhamento e Controle
| +-Construção
| | +-Análise
| | +-Implementação
| | +-Projeto
| | +-Revisões Técnicas
| | +-Testes
| +-Documentos não Padronizados
| +-Planejamento e Elaboração
| | +-Concepção
| | +-Objetivos e Requisitos
| | +-Planejamento Inicial
| | +-Planejamento do Desenvolvimento
| | +-Revisões Técnicas
+-tags
8/2/2016 117
| +-<ID > - <VERSAO > - <DD-MM-AAAA>
| +-STBC
+-trunk
| +-SBTC
| +-Acompanhamento e Controle
| +-Construção
| | +-Análise
| | +-Implementação
| | +-Projeto
| | +-Revisões Técnicas
| | +-Testes
| +-Documentos não Padronizados
| +-Planejamento e Elaboração
| | +-Concepção
| | +-Objetivos e Requisitos
| | +-Planejamento Inicial
| | +-Planejamento do Desenvolvimento
| | +-Revisões Técnicas
+-wiki
Política de Segurança
A política de segurança definida para as pastas do repositório serão definidas
conforme tabela a seguir:
Branches SVN – Google Code
Nome/Localização da
Pasta
Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração
(RC)
L, S, E, X
Outros Membros da Equipe L, S Tabela 15 - Permissões diretório Branches SVN
8/2/2016 118
Tags SVN – Google Code
Nome/Localização da
Pasta
Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração
(RC)
L, S, E, X
Outros Membros da Equipe L, S Tabela 16 - Permissões diretório Tags SVN
Trunk SVN – Google Code
Nome/Localização da
Pasta
Membro da Equipe Permissão
Todas
Gerente de Desenvolvimento (GD) L, S, E, X
Líder de Projeto (LP) L, S, E, X
Responsável pela Configuração
(RC)
L, S, E, X
Outros Membros da Equipe L, S Tabela 17 - Permissões diretório Trunk SVN
Wiki SVN – Google Code
Nome/Localização da Pasta Membro da Equipe Permissão
Todas Todos os Membros da Equipe L, S, E, X Tabela 18 - Permissões diretório Wiki SVN
Legenda: L – Ler
S – Salvar
E – Editar
X – Excluir
8/2/2016 119
Métodos de Identificação
Documentos
Todos os documentos disponibilizados no repositório devem ser identificados
baseados na seguinte nomenclatura:
<ID_ARTEFATO> - <NOME_ARTEFATO>
Onde:
<ID_ARTEFATO> é a sigla de identificação do artefato conforme Tabela
19.
<NOME_ARTEFATO> é nome de identificação do artefato conforme
Tabela 19.
ID_ARTEFATO NOME_ARTEFATO
APD Ativação de Projeto de Desenvolvimento
SBTC Sistema Bibliotecário
EOR Especificação de Objetivos e Requisitos
LPS Levantamento Preliminar do Software
PCP Plano de Comunicação do Projeto
PDS Plano de Desenvolvimento de Software
PGC Plano de Gerência de Configuração
PGQ Plano de Gerência da Qualidade
PGR Plano de Gerência de Riscos
RAC Relatório de Avaliação do Cliente
RAP Relatório de Acompanhamento do Projeto
PFM Pedido Formal de Modificação
SAI Solicitação de Análise de Impacto
RTF Relatório de RTF (Revisão Técnica Formal)
DAS Documento de Análise de Software
DPS Documento de Projeto de Software Tabela 19 - Identificadores e Nomes dos Artefatos
8/2/2016 120
Configuração Base
As configurações bases definidas ao longo do projeto deverá ser utilizada a
seguinte regra para a nomenclatura:
<ID_CONFIGURACAO> - <VERSAO_MANUAL> - < DD-MM-AAAA >
Onde:
< ID_CONFIGURACAO > é a identificação da configuração conforme
Tabela 14.
<DD-MM -AAAA > é a data de criação da configuração base.
<VERSAO_MANUAL> é o número da versão realizada conforme o
padrão X.0. Em que X é um número decimal que representa a versão aprovada e
liberada da configuração base e é incrementado a cada liberação da configuração.
Documentos de Análise de Software
Para cada caso de uso do sistema será definida um Documento de Análise de
Software que será nomeado conforme regra a seguir:
MAS – <ID_CASO_USO> - <NOME_CASO_USO>
Onde:
MAS é a identificação do documento conforme já estabelecido na Tabela
14.
<ID_CASO_USO> é a identificação do caso de uso conforme definido no
EOR – Especificação de Objetivos e Requisitos.
< NOME_CASO_USO > é o nome caso de uso conforme definido no EOR
– Especificação de Objetivos e Requisitos.
Documentos de Projeto de Software
Para cada caso de uso do sistema será definida um Documento de Projeto de
Software que será nomeado conforme regra a seguir:
MPS – <ID_CASO_USO> - <NOME_CASO_USO>
Onde:
8/2/2016 121
MPS é a identificação do documento conforme já estabelecido na Tabela
14.
<ID_CASO_USO> é a identificação do caso de uso conforme definido no
EOR – Especificação de Objetivos e Requisitos.
< NOME_CASO_USO > é o nome caso de uso conforme definido no EOR
– Especificação de Objetivos e Requisitos.
Controle de Mudanças
São definidos dois processos de controle de mudanças:
c) Procedimento Formal: este processo deve ser implementado quando a
mudança proposta afeta a última versão configuração já aprovada e
estabelecida o qual o item faça parte. A Erro! Fonte de referência não
encontrada. ilustra o processo formal de Modificação.
8/2/2016 122
Realizar Triagem
da Mudança
Inicio
Pedido
Formal de
Mudança
Resultado
Triagem
Mudança Relevante
(Com Previsão de Impacto Significativo)
Solicitação
de Análise
de Impacto
Realizar Análise de
Impacto
Relatório
de Análise
de Impacto
Negociar e Aprovar
Mudança
Mudança
Aprovada
Implementar
MudançaMudança Irrelevante - Rejeitada
Gerar e Aprovar
Configuração BaseFim
Reportar
Solicitante
Mudança Relevante
(Sem Previsão de Impacto Significativo)
Resultado
Aprovação
Mudança Aprovada
Mudança
Implementada
Mudança Reprovada
Figura 2 - Processo Formal de Modificação de Itens de Configuração
8/2/2016 123
13. Pedido Formal de Mudança: O solicitante preenche o Pedido
Formal de Mudança conforme Pedido Formal de Mudança – PFM
PFM N°__________
1. Nome Solicitante:_________________________________________Data: ___/___/___
2. Descrição Detalhada: ________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
3. Comissão de Controle de Mudança:
Líder de Projeto:____________________________________________________________________
Equipe Técnica:_____________________________________________________________________
Equipe de Qualidade:________________________________________________________________
4. Resultado Triagem:
( ) Relevante Com Impacto
( ) Relevante Sem Impacto
( ) Irrelevante
5. Observações:_______________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade
14. Anexo 1, e envia para a Comissão de Controle de Mudança. Em cada
PFM só deve ter apenas uma mudança á ser avaliada.
15. Realizar Triagem de Mudança: A CCM com apoio da Equipe
Técnica e da Equipe de Qualidade realiza a triagem definindo a
8/2/2016 124
relevância e possível impacto da mudança. O resultado da triagem
pode gerar uma das seguintes decisões: Relevante Com Previsão de
Impacto Significativo, Relevante Sem Previsão de Impacto
Significativo e Mudança Irrelevante - Rejeitada.
16. Solicitação de Análise Detalhada de Impacto: As mudanças que
foram classificadas como Relevante com previsão de impacto
significativo deve gerar a Solicitação de Análise Detalhada de
Impacto conforme modelo no Solicitação de Análise de Impacto – SAI
SAI N°_________
1. Nome Solicitante:_________________________________________________________________________Data: ___/___/_____ PFM Nº:_______
2. Responsáveis:_____________________________________________________________________________________________________________
3. Data de Inicio: ___/___/_____ Data de Término: ___/___/_____
4. Resultado Análise de Análise:
Item de Configuração Descrição da Alteração
Estimativa de Implementação Aprovação
ID Seção Esforço Tempo Custo
1 – Aprovada
2 – Reprovada – Tempo Excedido
3 – Reprovada – Custo Excedido
4 – Reprovada – Esforço Excedido
5 - Outros
5. Observações:__________________________________________________________________________________________________________________________
________________________________________________________________________________________________________________________________________
6. Aprovação Formal
Goiânia, ____/____/______
De acordo,
Gerente de Desenvolvimento Líder de Projeto Responsável Eq. Técnica Responsável Eq. Qualidade Cliente
Anexo 2.
17. Realizar Análise de Impacto: Estudo e análise de quais itens de
configuração a mudança impactará.
18. Relatório de Análise de Impacto: Relatório contendo a lista de itens
de configuração e o qual impacto sofrido pelo mesmo com a
implementação da mudança. Bem como a estimativa de esforço, de
tempo e custo.
19. Negociar e Aprovar Mudanças: O CCM juntamente com o cliente
negocia e aprova se a mudança pode ser implementada. O resultado
deste processo pode gerar as seguintes decisões: Mudança Aprovada e
Mudança Reprovada.
20. Mudança Aprovada: Relatório contendo a lista das alterações
aprovadas que serão implementadas.
21. Implementar Mudança: A CCM envia a mudança aprovada para o
LP, que providenciará a implementação da mudança.
22. Mudança Implementada: O LP envia para o RC a mudança
implementada solicitando que gere uma nova versão da configuração.
23. Gerar e Aprovar Configuração Base: Gera uma nova versão com as
mudança totalmente implementada.
8/2/2016 125
24. Reportar Solicitante: A CCM envia ao solicitante se mudança foi
reprovada ou considerada irrelevante.
d) Procedimento Informal: O processo informal deve ser implementado nos
casos em que a(s) mudança(s) proposta(s) não afetarem os itens de
configuração a ultima versão da configuração base no qual
Ambiente, Ferramentas e Infra-estrutura
Plano de Software
Software Propósito Ambiente Release/Versão
SVN Controle de Repositório Desenvolvimento
MS-Office Documentos do Word Todos 2003 ou 2007
TortoiseSVN Acesso ao repositório Desenvolvimento 1.6.12
MS-Project Edição do cronograma Desenvolvimento 2007
Java JDK Kit básico para o
desenvolvimento em Java
Desenvolvimento 01/06/11
JSF Framework MVC para o
desenvolvimento de
aplicações Web..
Desenvolvimento 1.2
Richfaces Biblioteca de
componentes para o
framework JSF. Suporta
AJAX.
Desenvolvimento 3.3.0
Hibernate Framework de
persistência.
Desenvolvimento 3.2.6
iReport IDE para design de
relatórios.
Desenvolvimento 3.5.2
JasperReports Biblioteca responsável
em gerar relatórios em
PDF.
Desenvolvimento 3.5.2
Eclipse
Helios
IDE de desenvolvimento. Desenvolvimento 3.6.2
Enterprise
Architect
Modelagem de diagramas
de dados.
Desenvolvimento 6.5
Power
Designer
Modelagem de diagramas
de dados.
Desenvolvimento 12.5
HeidiSQL Gerenciador de banco de Desenvolvimento 6.0
8/2/2016 126
dados MySQL.
Subclipse Plugin SVN para o
eclipse
Desenvolvimento 1.6.17
Tabela 20 - Plano de Software
Comissão de Controle de Mudanças
A Comissão de Controle de Mudanças (CCM) será formada pelo Líder de Projeto,
integrantes da Equipe de Qualidade e integrantes da Equipe Técnica. E deve ser
designada pelo LP para cada PFM.
8/2/2016 127
8/2/2016 128
Passo a passo: processo de gerenciamento de configurações:
Estabelecer sistema de configuração
Manter sistema de configuração
identificar ites de configuraçãocom base nos critérios esabelecidos
Criar a baseline com base nos itens de configuração que necessitam de um controle formal.
Registrar a situação atual dos itens de configuração
Registrar a situação atual das baselines
Controlar as modificações dos itens de confiuração
controlar o armazenameno dos itens de configuração e baselines
Controlar o manuseio dos itens de configuração e baselines
Controlar a liberação dos itens de configuração e baselines
Realizar auditoria de cofiguração das baselines
Realizar auditoria dos itens de configuração
Comunicar as informações relacionadas aos itens de configuração às pastes interessadas
8/2/2016 129
5.7 Nível de Serviço
Contrato de Serviço (SLA)
para
Biblioteca municipal de Caruaru
por
Luciano Corporation Ltda.
09/07/2016
Proprietário do documento: Luciano Corporation Ltda.
Gerente de Negociação: Luciano Filho
Versões
Versão Data Revisão Autor
1.0 09/07/2016 Luciano Filho e
Caio
Aprovação
(Ao assinar abaixo, o cliente concorda com todos os termos e as condições definidas no
presente acordo.)
Cliente Assinatura Data
8/2/2016 130
5.7.1 Acordo Geral
Este contrato representa um acordo de nível de serviço (" SLA "ou" Contrato ")
entre a E-commerce Serviços de Software Ltda e o grupo [Cliente] para o
fornecimento de serviços de TI necessárias para apoiar e sustentar [Cliente].
O presente acordo permanece válido até ser substituído por uma versão revisada
com acordo mutuamente aprovado pelos interessados. As mudanças são registradas
na seção “Alterações do presente acordo” e são efetivadas após a confirmação mútua
das partes interessadas.
O presente Acordo define os parâmetros de todos os serviços abrangidos, como eles
são mutuamente compreendidos pelos principais intervenientes. O presente acordo
não invalida atuais processos e procedimentos a menos que explicitamente indicado
neste documento.
5.7.2 Metas e Objetivos
O objetivo deste acordo é o de assegurar que as partes estão em condições de
efetuar a negociação, que a E-commerce Serviços de Software Ltda está em
condições de prestar serviço de apoio consistente de TI e de entrega ao cliente (s)
pelo prestador do serviço (s).
O objetivo deste acordo é a obtenção de mútuo acordo entre a prestação de serviços
de TI entre Provedor e Cliente.
Os objetivos deste acordo são os seguintes:
• Prestar serviço de referência, especificando claramente suas responsabilidades e
papéis;
• Apresentar uma clara, concisa e mensurável descrição da prestação de serviços
ao cliente;
• Listar condições da prestação de serviço efetivo de apoio e entrega.
5.7.3 Responsáveis
Os seguintes Provedores e o Cliente serão usados como base do acordo e
representam os principais intervenientes associados a este SLA:
8/2/2016 131
Provedor de Serviço de TI: Luciano Corporation Ltda.
Cliente: Biblioteca Municipal de Caruaru
A seguir, as partes interessadas são responsáveis pela implantação e suporte
contínuo do presente acordo:
Stakeholder Nome Contato
Bibliotecário José 978563214
Bibliotecário Maria 978562536
Bibliotecário Manuela 977863234
Bibliotecário Paulo 977867894
5.7.4Ambiente de Serviço
As informações a seguir fornecem detalhes sobre os usuários, ferramentas,
aplicações e / ou outros componentes apoiadas por este SLA:
Número de usuários: 4
Número de usuários simultâneos: 4
Número de usuários registrados: 100
Descrição do usuário-base [Descrição do usuário-base] Bibliotecários da
biblioteca municipal de Caruaru.
Âmbito de aplicações [Âmbito de aplicações] Versão 1.0, aplicação desktop
Infraestrutura de Serviços: [Infraestrutura de Serviços] Intranet entre as máquinas
que utilizarão o sistema e a máquina que armazenará os
dados. Banco de dados Oracle em uma máquina
específica.
8/2/2016 132
Dependências do SLA: [Dependências do SLA] SLA da empresa fornecedora
de eletricidade.
8/2/2016 133
5.7.5 Revisão Periódica
Este acordo é válido a partir da data efetiva delineada neste documento e é válido até à
data da rescisão. Este acordo deverá ser revisto pelo menos uma vez por ano fiscal, no
entanto, em vez de uma revisão durante o período especificado, o atual acordo
permanecerá em vigor.
O Gerente de Negócios é responsável por facilitar a revisões regulares do presente
documento. O conteúdo deste documento pode ser alterada conforme necessário, desde
que o mútuo acordo é obtido a partir do primeiro comunicado a todos os interessados e
as partes afetadas. O proprietário do documento vai incorporar todas as revisões
ulteriores e de obter acordos mútuos / as aprovações necessárias.
Gerente de Negócios: Luciano Filho
Periodicidade_da_revisão:_Trimestral
Data prevista para revisão: 09/10/2016
Este acordo será enviado para os seguintes locais e vai ser acessível a todas as partes
interessadas:
Local do Documento: Prefeitura Municipal de Caruaru
5.7.6 Contrato de Serviço
Os seguintes parâmetros detalhados nesta seção do contrato de serviço são da
responsabilidade do prestador do serviço, no apoio contínuo do presente acordo.
5.7.6.1 Escopo do Serviço
Os seguintes serviços são abrangidos pelo presente acordo; pleno descrições,
caderno de encargos e os custos são delineadas nos “Custos dos serviços”.
Referência Módulo Descrição do Serviço
Req_01 Cad O serviço oferecido deve permitir os seguintes cadastros:
- Cadastro de usuários
- Cadastro de Livros
8/2/2016 134
- Cadastro de Dvds
Req_02 Alt O serviço oferecido deve permitir as seguintes alterações::
- Alteração de usuários
- Alteração de Livros
- Alteração de Dvds
Req_03 Excl O serviço oferecido deve permitir as seguintes exclusões::
- Alteração de usuários
- Alteração de Livros
- Alteração de Dvds acompanhamento de sua compra, estando
ela em qualquer situação
Req_03 Cons O serviço oferecido deve permitir as seguintes consultas::
- Consulta de usuários
- Consulta de Livros
- Consulta de Dvds
5.7.6.2 Responsabilidades do Cliente
As responsabilidades e / ou requisitos dos clientes em apoio do presente acordo
incluem:
• A adesão relacionadas com políticas, processos e procedimentos descritos nos
Apêndices;
• Adequação incidentes e / ou solicitar priorização como descrito anteriormente e /
ou em cooperação com o prestador de serviços;
• Opções de programação de todos os serviços relacionados com os pedidos e outros
serviços especiais com o prestador de serviços;
• Adequação da utilização de apoio conforme descrito no Apêndice A: Políticas
relacionadas, Processos e Procedimentos;
• Pagamento de todos os serviços relacionados com a instalação e / ou de
configuração despesas anteriores à prestação do serviço;
• Revisão todas as horas autenticadas pelo fornecedor de serviços para adequação;
• Razoável disponibilidade do cliente representante (s) na resolução de um incidente
ou serviço relacionado pedido.
5.7.6.3 Responsabilidades do Provedor de Serviços
8/2/2016 135
Service Provider responsabilidades e / ou requisitos em apoio do presente
acordo incluem:
• Reuniões devidamente associadas a resposta a incidentes relacionados com
serviços;
• Geração de relatórios trimestrais sobre os níveis de serviço para o cliente;
• Formação exigida pessoal em serviço com instrumentos de apoio adequados;
• Registrar todas as horas providas de recursos associados a serviços e prestados para
a revisão pelo Cliente;
• Devida notificação ao Cliente das manutenções programadas;
• Facilitação de apoio ao serviço de todas as atividades que envolvam incidente,
problema, mudança, liberação de configuração e gerenciamento.
5.7.6.4Serviços Pressupostos
Pressupostos relacionados com o âmbito de serviços e / ou componentes
incluem:
Os serviços são prestados a clientes externos de TI e são comunicados aos gerentes
de negócios;
Atendimento ao usuário básico permanecerá dentro de 5% dos efetivos níveis
atuais;
Financiamento para maiores atualizações serão fornecidas pelo Cliente e tratado
como um projeto fora do âmbito de aplicação do presente acordo;
Mudanças de serviços serão documentadas e comunicadas a todos os interessados.
5.7.7_Gerenciamento do Serviço
Eficaz de apoio no âmbito de serviços é um resultado consistente de manutenção de
níveis de serviço. As seções a seguir fornecem informações relevantes sobre a
disponibilidade, acompanhamento, avaliação e comunicação dos serviços no âmbito de
componentes e afins.
8/2/2016 136
5.7.7.1 Disponibilidade do Serviço
As coberturas específicas para os serviços abrangidos pelo presente acordo são
os seguintes:
De segunda a sexta, 5 horas por dia, de 8h às 13h.
5.7.7.2 Medição dos Serviços
As seguintes medições serão criadas e mantidas pelo prestador do serviço a garantir
a melhor prestação de serviço ao cliente:
Medição Definição Alvo
Aplicação X
Disponibilidade
Percentagem de tempo que
alguma aplicação está
disponível fora da janela de
manutenção.
98%
Tempo de
resposta do
cliente
Tempo de resposta para
suporte, caso ocorra algum
problema com o sistema
durante o período de
funcionamento acordado.
1 hora
5.7.7.3 Relatório em nível de Serviço
O fornecedor de serviços irá oferecer ao Cliente com os seguintes relatórios sobre a
periodicidade indicada:
Nome do
relatório Intervalo A quem se destina
Responsável
Relatório de
disponibilidade de
aplicação
Mensal Coordenador
bibliotecário
Luciano Filho
Tempos de
respostas ao
cliente
Quinzenal Coordenador
bibliotecário
Luciano Filho
8/2/2016 137
Relatório de
incidentes
Semanal Coordenador
bibliotecário
Luciano Filho
a. Pedidos de Serviços
Em apoio aos serviços descritos no presente acordo, o prestador de serviços irá responder aos incidentes
relacionados ao serviço e / ou pedidos apresentados pelo Cliente, dentro dos seguintes prazos
estabelecidos:
30 minutos (durante o horário comercial) para questões classificadas como críticas;
1 hora (durante o horário comercial) para questões classificadas como alta
prioridade;
2 horas (durante o horário comercial) para questões classificadas como prioridade
média;
3 horas (durante o horário comercial) para questões classificados como baixa
prioridade;
Vinte e quatro (24) horas (durante o horário comercial) para uma solicitação de
serviço geral.
b. Manutenção dos Serviços
Todos os serviços e / ou componentes relacionados com regularidade exigem
manutenção programada ( "Janela de Manutenção"), a fim de satisfazer níveis
de serviço estabelecidos. Estas atividades vão tornar sistemas e / ou aplicações
indisponíveis para a interação entre os utilizadores normais para os seguintes
locais e datas:
Data/Horário: Segundas feiras de 14h às 16h.
5.7.8_Modelo de processo para indisponibilidade no sistema:
8/2/2016 138
5.7.9_Custos dos Serviços
Para a disponibilização dos serviços descritos na seção 6.1 – Escopo do serviço, o custo
será de R$ 2000,00 mensais.
Solicitações de alterações e novas funcionalidades terão orçamento oferecido ao cliente
gratuitamente para então sua avaliação e possível aprovação.
Para o pagamento do referido valor, o cliente receberá uma fatura a vencer no dia 10 de
cada mês.
O não pagamento desta fatura em até 30 dias implicará em juros e multa, e após o 30º
dia os serviços oferecidos serão cancelados.
5.8 Gerenciamento de Serviço Automatizado – BPMS
Neste tópico será demonstrado o nosso sistema de Service Desk para atendimento de
chamados do cliente, com a implantação da gestão de serviços.
Caixa de entrada dos chamados.
8/2/2016 139
Dados do processo de abertura de chamado, com sua data de criação e vencimento.
Tela de validação de chamado pelo cliente. Após ação realizada pelo suporte.
8/2/2016 140
Tela de chamados atendidos dentro do prazo, respeitando o SLA.
8/2/2016 141
Modelo de dados utilizado para a criação do fluxo de atendimento de chamados.
5.9 Conclusão
O mapeamento do processo foi realizado com a utilização do BPMN, o que contribuiu para a
representação de processos de negócios de modo a apresentar fluxos modelados a partir de um
padrão universal e de fácil compreensão e replicação por quem os utiliza.
Aliada a ferramentas específicas para modelagem de processos de negócio, modelo de
gerenciamento de configuração, levantamento de requisitos, a BPMN ganha ainda mais força e
eficiência, desestimulando o uso de fluxos genéricos, descrições textuais ou padrões proprietários
para representação de fluxos de processos de negócio, e fortalecendo a linguagem única para a
modelagem e gestão de processos de negócio, contribuindo para o ganho de produtividade e clareza
na distribuição de informações.
Apresentando assim, um melhor ganho para o gerenciamento de serviço de TI, com as boas práticas
da Governança de TI.