Instruções aos Autores de Contribuições para o SIBGRAPIromulocesar.com.br/wp-content/uploads/2016/08/Livro_Governança_BPM... · gerÊncia de configuraÇÃo ..... 29 introduÇÃo

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.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.1 None ................................................................................................ 127

2.1.1.2 Verificar Disponibilidade do Sistema ............................................. 127


2.1.1.4 Verificar Provedor de Hospedagem da Aplicação .......................... 128


2.1.1.6 Verificar Aplicação SGE ................................................................. 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.7 ELEMENT.............................................................................................................................. 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


Descrição: Permite que o usuário saia do sistema.


1.2.4. [RF03] Criar XML

Identificação: [RF03] Criar XML


Descrição: O Usuário deve gerar o XML através do sistema no módulo

faturamento.


1.2.5. [RF05] Verificar erros antes da criação do XML

Identificação: [RF05] Verificar erros antes da criação do XML


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.


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


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.


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


Descrição: Finaliza o acesso ao sistema.

Atores: Supervisor e Vendedores


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.


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.


[UC03] Inserir número da fatura a ser gerada


Descrição: Insere um projeto no sistema.

Ator: Administrador do sistema.

27


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.


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


Descrição: Remove um XML do sistema e todos os registros relativos a ele.



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.


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.


[UC05] Atualizar XML


Descrição: Atualiza as informações do XML.


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.


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.


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


Todas




Outros Membros da Equipe L, S Tabela 2 - Permissões diretório Tags SVN

Trunk SVN – GitHub


Todas




Outros Membros da Equipe L, S Tabela 3 - Permissões diretório Trunk SVN

Wiki SVN – GitHub


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:__________________________________________________________________________________________________________________________

________________________________________________________________________________________________________________________________________


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.


002 Analista de faturamento


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.



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


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


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


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





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



tipo de caso de uso deve ser implementado impreterivelmente, caso contrário, o

projeto perderá sua utilidade.




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



Descrição:



login, senha e estar ativo no sistema. Não deve haver outra

maneira de entrar no sistema diferente desta.


2.4.2. [RF02] Efetuar logoff



Descrição: Permite que o usuário encerre sua sessão no sistema.


2.4.3. [RF03] Inserir Usuário

Identificação: [RF03] Inserir usuário


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


64

2.4.4. [RF04] Remover Usuário

Identificação: [RF04] Remover Usuário


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.


2.4.5. [RF05] Atualizar Usuário

Identificação: [RF05] Atualizar Usuário


Descrição: Os usuários com perfil administrador e analista do sistema

atualizam os dados de um Usuário


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.


65

2.4.7. [RF07] Alterar Senha

Identificação: [RF07] Alterar Senha


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.


2.4.8. [RF08] Inserir Empresa

Identificação: [RF08] Inserir Empresa


Descrição:


inserem uma nova Empresa no banco de dados do sistema.

Uma Empresa tem os dados: Nome Fantasia, Razão Social,

Telefone, CNPJ, ETC.


2.4.9. [RF09] Remover Empresa

Identificação: [RF09] Remover Empresa


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.



qual a Empresa excluída.


2.4.10. [RF10] Atualizar Empresa

Identificação: [RF10] Atualizar Empresa



atualizam os dados de uma Empresa.


2.4.11. [RF11] Listar Empresas

Identificação: [RF11] Listar Empresas


Descrição: Lista as Empresas do sistema.


2.4.12. [RF12] Inserir Perfil

Identificação: [RF12] Inserir Perfil



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


2.4.13. [RF13] Remover Perfil

Identificação: [RF13] Remover Perfil


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.



qual o Perfil excluído.


2.4.14. [RF14] Atualizar Perfil

Identificação: [RF14] Atualizar Perfil



atualizam as permissões de um Perfil


68

2.4.15. [RF15] Listar Perfis

Identificação: [RF15] Listar Perfis


Descrição: Lista os Perfis do sistema.


2.4.16. [RF16] Inserir Equipamento

Identificação: [RF16] Inserir Equipamento


Descrição:


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.


2.4.17. [RF17] Remover Equipamento

Identificação: [RF17] Remover Equipamento


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.



qual o Equipamento excluído.


2.4.18. [RF18] Atualizar Equipamento

Identificação: [RF18] Atualizar Equipamento



atualizam os dados de um Equipamento.


2.4.19. [RF19] Listar Equipamentos

Identificação: [RF19] Listar Equipamento


Descrição: Lista os Equipamentos do sistema.


70

2.4.20. [RF20] Solicitar Equipamento

Identificação: [RF20] Solicitar Equipamento


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


2.4.21. [RF21] Devolver Equipamento

Identificação: [RF21] Devolver Equipamento


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


2.4.22. [RF22] Enviar à Assistência

Identificação: [RF22] Enviar à Assistência

71


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.


2.4.23. [RF23] Retornar de Assistência

Identificação: [RF23] Retornar de assistência


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.


2.4.24. [RF24] Relatório de Equipamento

Identificação: [RF24] Relatório de Equipamento


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.


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


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.


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.


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.


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.


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.


Desejável


2.5.3.1. [RNF06] - 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.


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.


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.


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.


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

https://sites.google.com/a/cin.ufpe.br/if716/

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





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.


[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





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.


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.1. Introdução


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.



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


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


Ciclo



Configuração

CICLO3


Ciclo



Configuração

CICLO4


Ciclo



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


+-tags

| +-<ID > - <VERSAO > - <DD-MM-AAAA>

| +-CFC

+-trunk

| +-CFC


| +-Construção

| | +-Análise


| | +-Projeto


86

| | +-Testes



| | +-Concepção





+-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


Branches SVN – GitHub


Todas




Outros Membros da Equipe L, S

Tabela 8 - Permissões diretório Branches SVN

Tags SVN – GitHub


Todas





Tabela 9 - Permissões diretório Tags SVN

87

Trunk SVN – GitHub


Todas





Tabela 10 - Permissões diretório Trunk SVN

Wiki SVN – GitHub


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




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.
















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


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


< 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


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°__________



__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________


Líder de Projeto:____________________________________________________________________

Equipe Técnica:_____________________________________________________________________





( ) Irrelevante

5. Observações:_______________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


Goiânia, ____/____/______

De acordo,


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°_________


2. Responsáveis:_____________________________________________________________________________________________________________






1 – Aprovada




5 - Outros

5. Observações:__________________________________________________________________________________________________________________________

________________________________________________________________________________________________________________________________________


Goiânia, ____/____/______

De acordo,


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.


JasperReports Biblioteca responsável em

gerar relatórios em PDF.


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


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°__________



__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________


Líder de Projeto:____________________________________________________________________

Equipe Técnica:_____________________________________________________________________





( ) Irrelevante

5. Observações:_______________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


Goiânia, ____/____/______

De acordo,


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°_________


2. Responsáveis:_____________________________________________________________________________________________________________






1 – Aprovada




5 - Outros

5. Observações:__________________________________________________________________________________________________________________________

________________________________________________________________________________________________________________________________________


Goiânia, ____/____/______

De acordo,


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


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.


001 Monitoramento de disponibilidade


Monitoramento Monitorar disponibilidade do sistema


O monitoramento será feito

periodicamente, de acordo com

periodicidade abaixo

informada.

Conhecimento de ferramentas de monitoramento


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


Garantia de disponibilidade – o monitoramento é de fundamental importância para

garantir maior disponibilidade do serviço oferecido.


002 Garantias de disponibilidade


Disponibilidade Especificar os requisitos para disponibilidade do sistema


O monitoramento será feito

periodicamente, de acordo com

periodicidade abaixo

informada.

Conhecimento de ferramentas de monitoramento


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


Garantia de funcionabilidade – cumprir os pré-requisitos são fundamentais para garantir a

funcionabiliadde do sistema.


003 Garantias de funcionabilidade


Disponibilidade Cumprir pré-requisitos para funcionabilidade


109

Atender os pré-requisitos para

a funcionamento do sistema

Conhecimento dos pré-requisitos


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


004 Correções de erros


Correção Corrigir os erros do sistema


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


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.


110

005 Aplicar melhorias


Melhorias Aplicar melhorias para permitir a evolução do sistema


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



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.


005 Verificar aplicação


Verificar aplicação Verificação da aplicação após o informe de parada do

sistema


Conhecimentos na estrutura e

no funcionamento do sistema



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.


006 Verificar aplicação


Verificar aplicação

Verificação da aplicação após o informe de parada do

sistema


Conhecimentos na estrutura e

no funcionamento do sistema



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


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


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


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


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


2.1 GERÊNCIA DE CONFIGURAÇÃO


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


2.1 SLA SGE


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


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.


Gates

Disponível

Indisponível

2.1.1.6 Verificar Aplicação SGE

Description Verificar disponibiidade da aplicação


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


3.2.1 Requisitos funcionais

3.2.1.1. [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





3.2.1.3. [RF03] Cadastrar perfil do Cliente

Identificação: [RF03] Cadastrar perfil de Cliente

133

Casos de Uso


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.


3.2.1.4. [RF04] Consultar Produtos

Identificação: [RF04] Consultar Produtos

Casos de Uso


Descrição: Os cliente podem consultar os produtos de seus interesses e conferir

preços e condições.


3.2.1.5. [RF05] Adicionar produtos à lista de compras

Identificação: [RF05] Adicionar produtos à lista de compras

Casos de Uso


Descrição: O cliente, devidamente logado, pode incluir os produtos de seu interesse à

lista de compras para que posteriormente possa ser adquirido.


3.2.1.6. [RF06] Remover produtos da lista de compras

Identificação: [RF06] Remover produto da lista de compras

Casos de Uso


Descrição: Em caso de desistência o cliente, devidamente logado, pode remover o

produto indesejado da sua lista de compras.


3.2.1.7. [RF07] Finalizar compra

134

Identificação: [RF07] Finalizar compra

Casos de Uso


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.


3.2.1.8. [RF08] Cadastrar produto

Identificação: [RF08] Cadastrar Produto

Casos de Uso


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.


3.2.1.9. [RF09] Alterar produto

Identificação: [RF09] Alterar Produto

Casos de Uso



alterar as informações cadastrais do produto.


3.2.1.10. [RF10] Inativar produto

Identificação: [RF010] Inativar Produto

Casos de Uso



inativar determinado produto.


135

3.2.1.11. [RF11] Consultar pedidos

Identificação: [RF011] Consultar pedidos

Casos de Uso


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


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


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.


3.2.2.1.3. [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



3.2.2.2. Requisitos de Externos

3.2.2.2.1. [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.


3.2.2.2.2. [RNF05] - 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.


3.2.2.3. Requisitos de Produto

3.2.2.3.1. [RNF06] – 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


3.2.2.3.2. [RNF07] – 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.


3.2.2.3.3. [RNF08] - 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.


3.2.2.3.4. [RNF09] - 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.


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.


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.


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


3.4.2.1. Escopo de serviço Os seguintes serviços são abrangidos pelo presente acordo; pleno descrições,



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.


poderá alterar as informações cadastrais do produto.


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:




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:


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.


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:



prioridade;

Quatro (4) horas (durante o horário comercial) para questões classificadas como

prioridade média;


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


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


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

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.gjdgxs

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.30j0zll

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.1fob9te

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.3znysh7

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.2et92p0

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.tyjcwt

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.3dy6vkm

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.1t3h5sf

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.4d34og8

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.2s8eyo1

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.17dp8vu

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.3rdcrjn

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.26in1rg

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.lnxbz9

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.35nkun2

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.1ksv4uv

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.44sinio

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.2jxsxqh

https://docs.google.com/document/d/1C8steXa4V1u7MfUdOlLv-aQSZF_JI-Fz0_DSpua3twk/edit#heading=h.z337ya



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.7 ELEMENT ............................................................................................................................... 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)


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)


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


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)


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


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)


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)


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



Descrição:






4.2.2 [RF02] Efetuar logoff





4.2.3 [RF03] Inserir Pacotes de Serviços

Identificação: [RF03] inserir pacotes de serviços


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.


8/2/2016 173

4.2.4 [RF04] Remover Pacotes de Serviços

Identificação: [RF04] Remover Pacote de Serviços


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.



que o projeto e os clientes associados serão excluídos.


4.2.5 [RF05] Atualizar Pacotes de Serviços

Identificação: [RF05] Atualizar Pacotes de Serviços


Descrição: O administrador do sistema atualiza os dados de um Pacotes de

Serviços


4.2.6 [RF06] Listar Pacotes de Serviços

Identificação: [RF06] Listar Pacotes de Serviços

Casos de Uso


Descrição: Lista Pacotes de Serviços no cabaré e período de vigência

do Pacotes de Serviços.


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


serviços.

4.2.7.1 Requisitos de Processo

4.2.7.2 [RNF01] Utilizar SCRUM como Metodologia de Desenvolvimento


Casos de Uso

relacionados

Todos.


permite agilidade. Além disso, como o sistema será



extensa.


Desejável

4.2.7.3 [NFR02] - Desenvolvimento em Java

Identificação [NFR02] – Desenvolvimento em Java

Casos de Uso

relacionados

Todos.


linguagem Java compatível com o servidor Apache

Tomcat 7.0.


Desejável

4.2.7.4 [NFR03] – Utilizar Banco de Dados MySql


Casos de Uso

relacionados

Todos.






Desejável

8/2/2016 175

4.2.8. Requisitos Externos

4.2.8.1 [NRF04] - Tempo de Desenvolvimento


Casos de Uso

relacionados

Todos.







Desejável

4.2.8.2 [RNF05] - Custo de Desenvolvimento


Casos de Uso

relacionados

Todos.






Desejável


4.2.9.1 [RNF06] – Permissão


Casos de Uso

relacionados

Todos.


8/2/2016 176



Desejável

4.2.9.2 [RNF07] – Backup


Casos de Uso

relacionados

Todos.




banco.


Desejável

4.2.9.3 [RNF08] - Mensagens de Retorno


Casos de Uso

relacionados

Todos.




necessário.


Desejável

4.2.9.4 [RNF09] - Menus bem estruturados


Casos de Uso

relacionados

Todos.




usabilidade.

8/2/2016 177


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.


• 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;


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:


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:



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.


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



interessadas:

Local do Documento: File Server da empresa Foim Foim Prazeres & Ltda.

4.3.6 Contrato de Serviço



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


[RF01] Log Permite que um usuário tenha acesso a informações



8/2/2016 185


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



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;


• 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;



• Registrar todas as horas providas de recursos associados a serviços e prestados para a

revisão pelo Cliente;


• 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;


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:




Monitoração automático dos

serviços

24 horas por dia, 365 dias por ano


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:


Aplicação X

Disponibilidade


alguma Application está


manutenção.

95.5%

Tempo de

resposta do

cliente

Tempo de resposta para uma

amostra de operações

executadas em menos de 10

segundos.


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


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:



prioridade;

Quatro (4) horas (durante o horário comercial) para questões classificadas como prioridade

média;


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


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.


001 Suporte ao Usuário / Administração de Sistemas


Service Desk

Disponibilidade de serviço de apoio a usuários para suporte e

resolução de problemas técnicos.


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



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


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.


002 Desenvolvimento de software


Software SVS

Disponibilidade do serviço do portal com desempenho e

segurança.


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.



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




8/2/2016 106


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



tipo de caso de uso deve ser implementado impreterivelmente, caso

contrário, o projeto perderá sua utilidade.




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


8/2/2016 107

5.4.1 [RF01] Efetuar logon



Descrição:






5.4.2 [RF02] Efetuar logoff





5.4.3 [RF03] Inserir Usuário

Identificação: [RF03] Inserir Usuário


Descrição: Os colaboradores da biblioteca, irão cadastrar os usuários para

poderem realizar empréstimos de livros didáticos ou dvds.


5.4.4 [RF04] Remover Usuário



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


5.4.5 [RF05] Atualizar Usuário



Descrição: Os colaboradores têm autorização para alterar os dados

cadastrais dos usuários.


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.


5.4.7 [RF07] Inserir Livro

Identificação: [RF07] Inserir Usuário


Descrição: Os colaboradores da biblioteca, irão cadastrar os livros

disponíveis na biblioteca


5.4.8 [RF08] Remover Livros

Identificação: [RF08] Remover Livros


8/2/2016 109

Descrição: Os colaboradores terão a opção de excluir os livros do sistema

por algum motivo indesejável.


5.4.9 [RF09] Atualizar Livros

Identificação: [RF09] Atualizar Livros



cadastrais dos livros.


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.


5.4.11 [RF11] Inserir DVDs

Identificação: [RF11] Inserir DVDs


Descrição: Os colaboradores da biblioteca, irão cadastrar os DVDs

disponíveis para empréstimos aos usuários.


5.4.12 [RF12] Remover DVDs


8/2/2016 110


Descrição: Os colaboradores terão a opção de excluir os DVDs

cadastrados no sistema


5.4.13 [RF13] Atualizar Usuário




cadastrais dos DVDs.


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.


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


8/2/2016 111

Casos de Uso

relacionados

Todos.


permite agilidade e participação ativa dos

stakeholders. Além disso, como o sistema será



extensa.


Desejável

5.5.1.2 [NFR02] - Desenvolvimento em Java

Identificação [NFR02] – Desenvolvimento em Java

Casos de Uso

relacionados

Todos.


linguagem Java compatível com o servidor Apache

Tomcat 7.0.


Desejável

5.5.1.3 [NFR03] – Utilizar Banco de Dados MySql


Casos de Uso

relacionados

Todos.






Desejável

5.5.2 Requisitos de Externos

5.5.2.1 [NRF04] - Tempo de Desenvolvimento


Casos de Uso

relacionados

Todos.




8/2/2016 112




Desejável

5.5.2.2 [RNF05] - Custo de Desenvolvimento


Casos de Uso

relacionados

Todos.






Desejável

5.5.3 Requisitos de Produto

5.5.3.1 [RNF06] - Permissão


Casos de Uso

relacionados

Todos.




Desejável

5.5.3.2 [RNF07] - Backup


Casos de Uso

relacionados

Todos.




banco.


Desejável

5.5.3.3 [RNF08] - Mensagens de Retorno


Casos de Uso

relacionados

Todos.


8/2/2016 113



necessário.


Desejável

5.5.3.4 [RNF09] - Menus bem Estruturados


Casos de Uso

relacionados

Todos.




usabilidade.


Desejável

Figura 1 Modelagem de Requisitos Funcionais (Casos de Uso)

5.6 Gerência de Configuração


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.



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


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


Ciclo



Configuração

CICLO2


Ciclo



Configuração

CICLO3


Ciclo



Configuração

CICLO4


Ciclo



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


| +-Construção

| | +-Análise


| | +-Projeto


| | +-Testes



| | +-Concepção





+-tags

8/2/2016 117

| +-<ID > - <VERSAO > - <DD-MM-AAAA>

| +-STBC

+-trunk

| +-SBTC


| +-Construção

| | +-Análise


| | +-Projeto


| | +-Testes



| | +-Concepção





+-wiki

Política de Segurança

A política de segurança definida para as pastas do repositório serão definidas


Branches SVN – Google Code

Nome/Localização da

Pasta

Membro da Equipe Permissão

Todas



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


Pasta


Todas




(RC)

L, S, E, X

Outros Membros da Equipe L, S Tabela 16 - Permissões diretório Tags SVN

Trunk SVN – Google Code


Pasta


Todas




(RC)

L, S, E, X

Outros Membros da Equipe L, S Tabela 17 - Permissões diretório Trunk SVN

Wiki SVN – Google Code


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




Onde:

<ID_ARTEFATO> é a sigla de identificação do artefato conforme Tabela

19.

<NOME_ARTEFATO> é nome de identificação do artefato conforme

Tabela 19.



SBTC Sistema Bibliotecário














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


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


Documentos de Projeto de Software

Para cada caso de uso do sistema será definida um Documento de Projeto de


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


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°__________



__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________


Líder de Projeto:____________________________________________________________________

Equipe Técnica:_____________________________________________________________________





( ) Irrelevante

5. Observações:_______________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


Goiânia, ____/____/______

De acordo,


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°_________


2. Responsáveis:_____________________________________________________________________________________________________________






1 – Aprovada




5 - Outros

5. Observações:__________________________________________________________________________________________________________________________

________________________________________________________________________________________________________________________________________


Goiânia, ____/____/______

De acordo,


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.


Hibernate Framework de

persistência.


iReport IDE para design de

relatórios.


JasperReports Biblioteca responsável

em gerar relatórios em

PDF.


Eclipse

Helios

IDE de desenvolvimento. Desenvolvimento 3.6.2

Enterprise

Architect


de dados.

Desenvolvimento 6.5

Power

Designer


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


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.


• 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;


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:


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


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



interessadas:

Local do Documento: Prefeitura Municipal de Caruaru

5.7.6 Contrato de Serviço



5.7.6.1 Escopo do Serviço

Os seguintes serviços são abrangidos pelo presente acordo; pleno descrições,



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;


• 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;



• Registrar todas as horas providas de recursos associados a serviços e prestados para

a revisão pelo Cliente;


• 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;


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.


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:


Aplicação X

Disponibilidade


alguma aplicação está


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


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.

Documents

Instruções aos Autores de Contribuições para o SIBGRAPIromulocesar.com.br/wp-content/uploads/2016/08/Livro_Governança_BPM... · gerÊncia de configuraÇÃo ..... 29 introduÇÃo