Академический Документы
Профессиональный Документы
Культура Документы
Verso 1.7
Niteri, Setembro 2013
ndice
1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.1.5
2.1.1.2
Analisar o PDI vigente na UFF para identificar oportunidades para
solues de TI ......................................................................................... 21
2.1.1.3
2.1.1.4
2.1.1.5
Escolher alternativas de solues de TI alinhadas s reas
estratgicas do PDI vigente. ...................................................................... 21
2.1.1.6
Priorizar as alternativas de solues de TI escolhidas para cada
rea estratgica do PDI vigente. ................................................................ 21
2.1.1.7
PDI.
2.1.1.8
2.1.1.9
2.1.1.10
Elaborao de planejamento estratgico da STI contemplando as
demandas de todos os projetos escolhidos. ................................................. 22
2.1.1.11
2.1.1.12
2.1.1.13
2.1.1.14
2.1.1.15
2.1.1.16
2.1.1.17
3.1.1.2
3.1.1.3
3.1.1.4
3.1.1.5
3.1.1.6
3.1.1.7
3.1.1.8
3.1.1.9
3.1.1.10
3.1.1.11
3.1.1.12
3.1.1.13
3.1.1.14
3.1.1.15
3.1.1.16
17/9/2013
3.1.1.17
4
4.1.1.2
Comunicao ........................................................................ 30
5.1.1.2
5.1.1.3
5.1.1.4
5.1.1.5
5.1.1.6
Entrega ................................................................................ 33
5.1.1.7
5.1.1.8
5.1.1.9
5.1.1.10
5.1.1.11
5.1.1.12
5.1.1.13
5.1.1.14
5.1.1.15
5.1.1.16
17/9/2013
6.1.1.1
Incio do Planejamento........................................................... 38
6.1.1.2
6.1.1.3
6.1.1.4
6.1.1.5
6.1.1.6
6.1.1.7
6.1.1.8
6.1.1.9
6.1.1.10
Avis-lo ............................................................................ 40
6.1.1.11
7.1.1.2
7.1.1.3
7.1.1.4
7.1.1.5
8.1.1.2
8.1.1.3
8.1.1.4
8.1.1.5
17/9/2013
8.1.1.6
8.1.1.7
8.1.1.8
8.1.1.9
8.1.1.10
8.1.1.11
8.1.1.12
8.1.1.13
8.1.1.14
8.1.1.15
Plano do Projeto ................................................................. 51
8.2 CRIAR TABELA DE RISCOS ............................................................................ 53
8.2.1
Elementos do processo ................................................................... 53
8.2.1.1
8.2.1.2
8.2.1.3
9.1.1.2
9.1.1.3
9.1.1.4
9.1.1.5
9.1.1.6
9.1.1.7
Atualizar cronograma............................................................. 57
9.1.1.8
9.1.1.9
17/9/2013
10
EXECUO DO SPRINT .......................................................................... 59
10.1
PROCESSO PRINCIPAL ............................................................................. 60
10.1.1 Elementos do processo ................................................................... 60
10.1.1.1
Elemento .......................................................................... 60
10.1.1.2
10.1.1.3
10.1.1.4
10.1.1.5
10.1.1.6
10.1.1.7
10.1.1.8
10.1.1.9
Controlar Qualidade............................................................ 62
10.1.1.10
11
CDS-04-CONTROLE DA QUALIDADE ....................................................... 64
11.1
CDS-04-CONTROLE DA QUALIDADE ........................................................... 65
11.1.1 Elementos do processo ................................................................... 65
11.1.1.1
11.1.1.2
11.1.1.3
11.1.1.4
11.1.1.5
11.1.1.6
11.1.1.7
11.1.1.8
12
CONTROLE DO SPRINT .......................................................................... 67
12.1
PROCESSO PRINCIPAL ............................................................................. 68
12.1.1 Elementos do processo ................................................................... 68
12.1.1.1
17/9/2013
12.1.1.2
12.1.1.3
13
COLOCAR SISTEMA OU FUNCIONALIDADE EM PRODUO .................... 69
13.1
PROCESSO PRINCIPAL ............................................................................. 70
13.1.1 Elementos do processo ................................................................... 70
13.1.1.1
13.1.1.2
13.1.1.3
13.1.1.4
13.1.1.5
13.1.1.6
13.1.1.7
14
CDS-06-ACOMPANHAMENTO DE PROJETO ............................................. 71
14.1
CDS-06-ACOMPANHAMENTO DE PROJETO..................................................... 72
14.1.1 Elementos do processo ................................................................... 72
14.1.1.1
14.1.1.2
Preparar RA ...................................................................... 72
14.1.1.3
14.1.1.4
projetos
14.1.1.5
14.1.1.6
14.1.1.7
14.1.1.8
14.1.1.9
14.1.1.10
14.1.1.11
14.1.1.12
17/9/2013
14.1.1.13
14.1.1.14
14.1.1.15
14.1.1.16
14.1.1.17
15
ENCERRAMENTO DO PROJETO ............................................................... 76
15.1
ENCERRAMENTO DO PROJETO .................................................................... 77
15.1.1 Elementos do processo ................................................................... 77
15.1.1.1
15.1.1.2
15.1.1.3
15.1.1.4
15.1.1.5
15.1.1.6
16
CDS-02-SCRUM ...................................................................................... 78
16.1
CDS-02-SCRUM .................................................................................. 79
16.1.1 Elementos do processo ................................................................... 79
16.1.1.1
16.1.1.2
16.1.1.3
16.1.1.4
Review .............................................................................. 79
16.1.1.5
Retrospectiva .................................................................... 79
17
CDS-03-REVISO TRIMESTRAL ............................................................. 80
17.1
CDS-03-REVISO TRIMESTRAL................................................................. 81
17.1.1 Elementos do processo ................................................................... 81
17.1.1.1
17.1.1.2
17.1.1.3
17/9/2013
17.1.1.4
17.1.1.5
17.1.1.6
17.1.1.7
17.1.1.8
17.1.1.9
17.1.1.10
18
AVALIAO DE CADA PROJETO ............................................................. 83
18.1
PROCESSO PRINCIPAL ............................................................................. 84
18.1.1 Elementos do processo ................................................................... 84
18.1.1.1
18.1.1.2
18.1.1.3
18.1.1.4
18.1.1.5
18.1.1.6
19
CDS-05-QUALIFICAO DE DEMANDA ................................................... 85
19.1
CDS-05-QUALIFICAO DE DEMANDA ........................................................ 86
19.1.1 Elementos do processo ................................................................... 86
19.1.1.1
19.1.1.2
19.1.1.3
19.1.1.4
19.1.1.5
19.1.1.6
19.1.1.7
19.1.1.8
17/9/2013
19.1.1.9
19.1.1.10
19.1.1.11
19.1.1.12
19.1.1.13
19.1.1.14
20
COORDENAO TCNICA ....................................................................... 89
20.1
MAIN PROCESS .................................................................................... 90
20.1.1 Elementos do processo ................................................................... 90
20.1.1.1
20.1.1.2
20.1.1.3
Telefonia ........................................................................... 90
21
CTE-01 - GERENCIAMENTO DE SERVIOS DA CTE .................................. 91
21.1
CTE - 01 - GERENCIAMENTO DE SERVIOS DA CTE ......................................... 92
21.1.1 Elementos do processo ................................................................... 92
21.1.1.1
21.1.1.2
Projetar servio.................................................................. 92
21.1.1.3
Implantao ...................................................................... 92
21.1.1.4
Operao .......................................................................... 92
21.1.1.5
22
CTE - 02 - ATENDIMENTO TCNICO - CLASSE DE SERVIOS .................. 93
22.1
MAIN PROCESS .................................................................................... 94
22.1.1 Elementos do processo ................................................................... 94
22.1.1.1
Servios de Operao ......................................................... 94
22.2
CTE -02- ATENDIMENTO TCNICO - CLASSE DE SERVIOS ................................. 95
22.2.1 Elementos do processo ................................................................... 95
22.2.1.1
22.2.1.2
Manuteno,
configurao
e
instalao
de
recursos
computacionais ........................................................................................ 95
22.2.1.3
17/9/2013
10
22.2.1.4
22.2.1.5
23
CTE - 03- MANUTENO, CONFIGURAO E INSTALAO DE RECURSOS
COMPUTACIONAIS ......................................................................................... 96
23.1
CTE-03 -MANUTENO, CONFIGURAO E INSTALAO DE RECURSOS COMPUTACIONAIS
97
23.1.1 Elementos do processo ................................................................... 97
23.1.1.1
23.1.1.2
23.1.1.3
23.1.1.4
23.1.1.5
23.1.1.6
23.1.1.7
24
CTE-04 -OFICINA DE REPARO ................................................................ 98
24.1
MAIN PROCESS .................................................................................... 99
24.1.1 Elementos do processo ................................................................... 99
24.1.1.1
24.1.1.2
24.1.1.3
25
CTE- 05 -TELEFONIA - CLASSE DE SERVIOS ...................................... 100
25.1
MAIN PROCESS .................................................................................. 101
25.1.1 Elementos do processo ................................................................. 101
25.1.1.1
25.1.1.2
25.1.1.3
Treinamento a usurios e tcnicos ..................................... 101
25.2
CTE- 05 -TELEFONIA - CLASSE DE SERVIOS .............................................. 102
25.2.1 Elementos do processo ................................................................. 102
25.2.1.1
25.2.1.2
25.2.1.3
17/9/2013
11
25.2.1.4
25.2.1.5
26
CTE- 06 -ATIVAO DE RAMAL ........................................................... 103
26.1
CTE- 06 -ATIVAO DE RAMAL .............................................................. 104
26.1.1 Elementos do processo ................................................................. 104
26.1.1.1
26.1.1.2
26.1.1.3
26.1.1.4
26.1.1.5
26.1.1.6
26.1.1.7
27
CTE- 07 - REMANEJAMENTO DE RAMAL ............................................... 105
27.1
CTE- 07 - REMANEJAMENTO DE RAMAL ...................................................... 106
27.1.1 Elementos do processo ................................................................. 106
27.1.1.1
27.1.1.2
27.1.1.3
27.1.1.4
27.1.1.5
27.1.1.6
27.1.1.7
28
CTE- 08 - CONFIGURAO DE RAMAL .................................................. 107
28.1
CTE- 08 - CONFIGURAO DE RAMAL ....................................................... 108
28.1.1 Elementos do processo ................................................................. 108
28.1.1.1
28.1.1.2
28.1.1.3
17/9/2013
12
28.1.1.4
28.1.1.5
28.1.1.6
28.1.1.7
29
CTE- 09 -DISPONIBILIZAO DE SENHAS ........................................... 109
29.1
CTE- 09 -DISPONIBILIZAO DE SENHAS .................................................. 110
29.1.1 Elementos do processo ................................................................. 110
29.1.1.1
29.1.1.2
29.1.1.3
29.1.1.4
29.1.1.5
29.1.1.6
30
CTE- 10 - TREINAMENTO NO SISTEMA DE MONITORIA ....................... 111
30.1
CTE- 10 - TREINAMENTO NO SISTEMA DE MONITORIA .................................... 112
30.1.1 Elementos do processo ................................................................. 112
30.1.1.1
30.1.1.2
30.1.1.3
30.1.1.4
30.1.1.5
31
CET-11-ATENDIMENTO TCNICO-ATUAL ............................................. 113
31.1
CET-11-ATENDIMENTO TCNICO ............................................................. 114
31.1.1 Elementos do processo ................................................................. 114
31.1.1.1
31.1.1.2
31.1.1.3
31.1.1.4
17/9/2013
13
31.1.1.5
31.1.1.6
31.1.1.7
31.1.1.8
31.1.1.9
31.1.1.10
32
RHB-01-PROCESSO SELETIVO DE BOLSISTAS ..................................... 115
32.1
ENTRADA - PROCESSO SELETIVO .............................................................. 116
32.1.1 Elementos do processo ................................................................. 116
32.1.1.1
32.1.1.2
32.1.1.3
32.1.1.4
32.1.1.5
32.1.1.6
32.1.1.7
32.1.1.8
32.1.1.9
32.1.1.10
32.1.1.11
Identificar vagas .............................................................. 118
32.2
INDICAO DE MEMBRO......................................................................... 119
32.2.1 Elementos do processo ................................................................. 119
32.2.1.1
33
RHB-02-AVALIAAO DE DESEMPENHO DE BOLSISTAS ........................ 120
33.1
RHB-02-AV. DE DESEMPENHO GERAL ....................................................... 121
33.1.1 Elementos do processo ................................................................. 121
33.1.1.1
33.1.1.2
17/9/2013
14
33.1.1.3
33.1.1.4
33.1.1.5
33.1.1.6
33.1.1.7
33.1.1.8
33.1.1.9
33.1.1.10
33.1.1.11
33.1.1.12
33.1.1.13
33.1.1.14
33.1.1.15
33.1.1.16
33.1.1.17
33.1.1.18
33.1.1.19
33.1.1.20
34
RHB-03-AVALIAAO DE DESEMPENHO DE NOVOS BOLSISTAS ............ 124
34.1
RHB-03-AV. DE DESEMPENHO GERAL ....................................................... 125
34.1.1 Elementos do processo ................................................................. 125
34.1.1.1
34.1.1.2
34.1.1.3
34.1.1.4
17/9/2013
15
34.1.1.5
34.1.1.6
34.1.1.7
34.1.1.8
34.1.1.9
34.1.1.10
34.1.1.11
34.1.1.12
34.1.1.13
34.1.1.14
34.1.1.15
34.1.1.16
34.1.1.17
34.1.1.18
34.1.1.19
34.1.1.20
34.1.1.21
Complementar relatrio de
34.1.1.22
34.1.1.23
34.1.1.24
A. D. .................................... 127
35
CENTRAL DE ATENDIMENTO ................................................................ 128
35.1
CENTRAL DE ATENDIMENTO .................................................................... 129
35.1.1 Elementos do processo ................................................................. 129
35.1.1.1
35.1.1.2
35.1.1.3
17/9/2013
16
36
35.1.1.4
35.1.1.5
35.1.1.6
35.1.1.7
35.1.1.8
35.1.1.9
35.1.1.10
17/9/2013
17
1 P O R TA L D E P R O C E S S O S
Verso: 1.0
Autor: Bruno Olmpio
17/9/2013
18
1.1
PROCESSO PRINCIPAL
Coordenao de Governana de TI
Processo
Governana de TI - Processo principal
1.1.1.2
Coordenao Tcnica
Descrio
Processo
Coordenao Tcnica - Main Process
1.1.1.3
1.1.1.4
Descrio
Processos relativos Coordenao de Desenvolvimento de Sistemas da STI.
Processo
Coordenao de Desenvolvimento de Sistemas - Processo principal
1.1.1.5
Central de Atendimento
Processo
Central de Atendimento - Central de Atendimento
17/9/2013
19
2 GTI-01-ELABORAO DE PDTIC
Verso: 1.0
Autor: web
17/9/2013
20
2.1.1.2
2.1.1.3
2.1.1.4
2.1.1.5
2.1.1.6
2.1.1.7
2.1.1.8
2.1.1.9
17/9/2013
21
2.1.1.10
Elaborao de planejamento estratgico da STI
contemplando as demandas de todos os projetos escolhidos.
2.1.1.11
2.1.1.12
2.1.1.13
2.1.1.14
2.1.1.15
2.1.1.16
2.1.1.17
Anlise das crticas e sugestes do COTI e da Comisso do
PDI.
17/9/2013
22
3 GTI-02-GESTO DE DEMANDAS E
MUDANAS
Verso: 1.0
Autor: Escritrio de Gerenciamento de Projetos - STI - UFF
17/9/2013
23
Identificar demanda
Descrio
Uma demanda pode chegar STI oriunda de:
* pr-reitorias;
* superintendncias;
* outras unidades gestoras;
* reitoria.
3.1.1.2
Descrio
Esta anlise visa verificar o alinhamento entre a demanda e o Plano de Desenvolvimento de
Tecnologia da Informao e Comunicao (PDTIC) vigente. Esta atividade garante que a STI
investir seus esforos no desenvolvimento de solues que atendam s necessidades da
Universidade, mantendo-se coerente com a Poltica de Governana de TI da UFF.
3.1.1.3
Descrio
A aprovao da direo da STI visa obter o compromisso dos gestores, que atravs dela iniciam
um novo projeto.
17/9/2013
24
3.1.1.4
Projeto de Infraestrutura
3.1.1.5
3.1.1.6
Descrio
A STI emite um parecer indicando a aquisio de uma soluo j existente no mercado e sugere a
observao do Guia de Boas de Contratao de Solues de TI, da Secretaria de Logstica e
Tecnologia da Informao do Ministrio do Planejamento, Oramento e Gesto.
Arquivo anexo
Guia de Boas Praticas em Contratacao de Solucoes de TI V 1.0.pdf
3.1.1.7
Descrio
Uma anlise tcnica realizada objetivando detectar o impacto, criticidade e urgncia da demanda
por manuteno corretiva.
* Impacto: o quanto este problema impacta na operao da soluo?
* Criticidade: perguntas-chave: 1) A soluo est exposta? 2) A segurana dos dados foi
comprometida? 3) A operao da soluo foi interrompida (saiu do ar)? Com base nestas
respostas, define-se o quo crtica a demanda.
* Urgncia: perguntas-chave: a soluo est em perodo de pico de acessos? Algum prazo do
cliente est prestes a ser quebrado?
3.1.1.8
Descrio
Situaes comuns de nvel 3:
* Falhas diversas na infraestrutura de produo;
* Falhas nas rotinas de backup dos dados;
* Falhas crticas (brechas de segurana, erros de processamento dos dados) de sistemas em
produo;
17/9/2013
25
* Cliente (opcional)
3.1.1.9
Executar / solucionar
Descrio
Equipe responsvel documenta a atividade na ferramenta de gesto de informao e soluciona o
problema.
Solicitao de mudanas
http://sistemas.uff.br/redmine
3.1.1.10
Comunicar os interessados
Descrio
Aps solucionar o problema, a equipe responsvel comunica aos interessados, conforme o Acordo
de Nveis de Servio preestabelecido.
Implementao
Servio Web
3.1.1.11
Descrio
A equipe responsvel utiliza a base de conhecimento para documentar o problema e sua soluo.
3.1.1.12
Descrio
Situaes comuns de nvel 2;
* Dificuldades de uso dos sistemas;
* Erros de sada de dados;
3.1.1.13
Descrio
Situaes comuns de nvel 1:
* Erros ocasionados por falhas de uso;
17/9/2013
26
3.1.1.14
Descrio
Todas as demandas e solicitaes identificadas devem ser classificadas em uma das trs categorias:
* Novas solues: quando necessrio desenvolver ou adquirir uma nova soluo, geralmente um sistema;
* Manuteno evolutiva: quando se pretende acrescentar novas funcionalidades a uma soluo j em produo;
* Manuteno corretiva: quando necessrio corrigir algum erro de uma soluo em produo.
Portes
Novas solues
Manuteno corretiva
Manuteno evolutiva
3.1.1.15
Aquisio ou desenvolvimento?
Descrio
Para atender s demandas por novas solues, a STI pode desenvolver internamente uma
soluo ou emitir um parecer recomendando a aquisio de uma soluo de outro fornecedor do
mercado.
3.1.1.16
Descrio
De acordo com a anlise realizada, o Nvel de Servio determinado.
Portes
Porto
17/9/2013
27
Porto
Porto
3.1.1.17
CDS-01-Desenvolvimento de Sistemas
Descrio
Este diagrama descreve o processo de desenvolvimento de sistemas/solues da STI.
Processo
CDS-01-Projetos de Desenvolvimento de Sistemas - CDS-01-Projetos de Desenvolvimento de
Sistemas
17/9/2013
28
4 C O O R D E N A O D E D E S E N V O LV I M E N T O
DE SISTEMAS
Verso: 1.0
Autor: Escritrio de Projetos - CDS
Descrio
A CDS a responsvel pela gesto de sistemas utilizados pela Universidade. Dois grupos de
atividades so de responsabilidade da CDS: O desenvolvimento de novos sistemas e a
manuteno dos sistemas j existentes, para garantir a continuidade da prestao dos mais
diversos servios oferecidos pela UFF.
17/9/2013
29
4.1
PROCESSO PRINCIPAL
4.1.1.2
Comunicao
17/9/2013
30
5 CDS-01-PROJETOS DE
D E S E N V O LV I M E N T O D E S I S T E M A S
Verso: 1.1
Autor: Escritrio de Gerenciamento de Projetos - STI - UFF
Descrio
Este diagrama descreve o processo de desenvolvimento de sistemas/solues da STI.
17/9/2013
31
5.1 CDS-01-PROJETOS DE
DESENVOLVIMENTO DE SISTEMAS
Descrio
Este processo descreve a produo de um projeto de software da STI
Descrio
A Coordenao Desenvolvimento de Sistemas inicia um projeto quando seu incio receber
autorizao da direo da STI.
5.1.1.2
Iniciao do Projeto
Descrio
Neste processo sero identificadas as partes interessadas, objetivo e limitaes do projeto.
Ao trmino deste processo, o projeto efetivamente ser iniciado.
O marco do incio do projeto a assinatura do termo de abertura.
Executantes
PO, PMO
Processo
Iniciao de Projeto - Processo principal
5.1.1.3
Planejamento de Sprint
Descrio
O Sprint um ciclo de desenvolvimento de 15 dias. Ele possui um escopo definido e um objetivo estabelecido no seu
planejamento, ao final dele existe uma reunio de entrega e aprovao, e uma reunio de melhoria contnua.
No processo "Planejamento de Sprint", o sprint ser planejado, identificando quais requisitos devem ser entregues ao final
dele. Neste processo os requisitos sero desenvolvidos e esmiuados em tarefas, com suas respectivas estimativas. Alm
disso, define-se o objetivo do Sprint e toda a equipe compromete-se a trabalhar em prol dele.
O Planejamento de Sprint dividido em duas reunies: planejamento I e planejamento II. No primeiro planejamento, o
cliente deve identificar, dentro os itens do Product Backlog, quais tem mais prioridade e devem ser desenvolvidos no
prximo Sprint. O segundo planejamento uma reunio tcnica, no qual a equipe ir criar tarefas para que os requisitos
escolhidos possam ser entregues.
Executantes
Lder do Projeto, PO, Equipe
Processo
Planejamento de Sprint - Processo principal
17/9/2013
32
5.1.1.4
Execuo do Sprint
Descrio
Durante este processo a equipe efetivamente desenvolve o que foi definido no Planejamento do Sprint, ou seja, implementa
cada funcionalidade para agregar valor ao produto do projeto e entregar uma parte dele ao cliente ao final de cada Sprint.
Executantes
Lder do Projeto, Equipe
Processo
Execuo do Sprint - Processo principal
5.1.1.5
Encerramento do Projeto
Descrio
Uma vez que o que foi planejado seja plenamente implementado e entregue pela equipe ao cliente,
o processo de finalizao tem por finalidade averiguar se o produto do projeto atende ao escopo e
qualidade definidos e tomar medidas necessrias para possveis adequaes que ainda sejam
necessrias. A principal sada deste processo o Termo de Entrega do Projeto.
Executantes
PMO, PO, Lder do Projeto
Processo
Encerramento do Projeto - Encerramento do projeto
5.1.1.6
Entrega
Descrio
A entrega o momento onde recebe o produto final do projeto como sendo o que efetivamente foi
solicitado e planejado. O Termo de Entrega do Projeto assinado e o projeto termina. A partir
disto, apenas a manuteno corretiva realizada. Novas funcionalidades no so mais
desenvolvidas e aguardam a iniciao de um novo projeto caso sejam necessrias.
5.1.1.7
Descrio
O projeto considerado pronto quando uma das condies satisfeita:
- O objetivo identificado no termo de abertura foi alcanado;
- O Product Backlog foi entregue;
Portes
Sim
No
17/9/2013
33
5.1.1.8
Controle do Sprint
Descrio
o processo de, entrega e homologao dos requisitos desenvolvidos ao cliente e melhoria
contnua dos processos e equipe.
Os objetivos deste processo so controlar a qualidade e conformidade do que foi desenvolvido, e
melhorar o processo de desenvolvimento e a capacidade tcnica da equipe.
Executantes
Lder do Projeto, Equipe
Processo
Controle do Sprint - Processo principal
5.1.1.9
Termo de Abertura
Descrio
O template do Termo de Abertura pode ser encontrado atravs do endereo abaixo.
Utilize sempre a verso mais recente do documento.
URL
https://sistemas.uff.br/redmine/documents/127
5.1.1.10
Plano do Projeto
Descrio
O template do plano de projeto est acessvel atravs do endereo abaixo.
Utilize sempre a verso mais recente do documento.
URL
https://sistemas.uff.br/redmine/documents/48
5.1.1.11
Relatrio de Acompanhamento
Descrio
O template do Relatrio de Acompanhamento pode ser encontrado atravs do endereo abaixo.
Utilize sempre a verso mais recente do documento.
URL
https://sistemas.uff.br/redmine/documents/107
17/9/2013
34
5.1.1.12
Descrio
Documento extrado diretamente do Redmine do projeto, atravs do relatrio "SCRUM: Sprint
Planning/Review".
5.1.1.13
Descrio
O modelo do Termo de Encerramento de Projeto pode ser encontrado no endereo abaixo.
Utilize sempre a verso mais recente do documento.
URL
https://sistemas.uff.br/redmine/documents/128
5.1.1.14
Descrio
Documento extrado diretamente do Redmine do projeto, atravs do relatrio "SCRUM: Sprint
Planning/Review".
5.1.1.15
Planejamento Geral
Descrio
Neste processo, feito um planejamento inicial do projeto, no qual os requisitos so analisados de forma geral e superficial.
O foco deste processo entender mais sobre o projeto com a finalidade de estimar o tamanho, custo, cronograma, equipe,
Product Owner e Gerente do Projeto, e os recursos disponveis para a sua execuo. O entendimento dos requisitos deve
ser suficiente apenas para estimar um cronograma bsico e os definir de forma a evitar ambiguidades e futuros
desentendimentos.
Executantes
PO, Lder do Projeto, PMO
Processo
Planejamento Geral - Planejamento Geral
5.1.1.16
Acompanhamento de Projeto
Descrio
o processo de acompanhamento dos resultados do trabalho da equipe.
17/9/2013
35
O resultado do Sprint de cada projeto coletado e divulgado para que todos tenham uma viso
geral do andamento dos projetos.
Executantes
PMO, Lder do Projeto
Processo
CDS-06-Acompanhamento de Projeto - CDS-06-Acompanhamento de Projeto
17/9/2013
36
6 INICIAO DE PROJETO
Verso: 1.0
Autor: Thiago Wigg
17/9/2013
37
6.1
PROCESSO PRINCIPAL
Incio do Planejamento
Descrio
O incio do planejamento se d aps o processo CDS-05 - Qualificao de Demanda ocorrer e esta demanda for aprovada.
6.1.1.2
Identificar justificativa
Descrio
O motivo pelo qual o projeto deve ser feito identificado e registrado. Pode conter uma justificativa
de o cliente ou o patrocinador requisitar o projeto, alm de sua necessidade para a universidade.
Podem ser includos tambm problemas de arquitetura de projetos antigos e tudo que justifique a
abertura de um novo projeto (oportunidade).
6.1.1.3
Descrio
Todas as pessoas que possam estar envolvidas direta e indiretamente no produto final e no projeto
so identificadas e registradas. Isso inclui clientes, patrocinadores, usurios, equipe de projeto,
pessoas que usaro dos dados do produto produzido, entre outros.
As partes interessadas so necessrias ao planejamento do produto que deve ser desenvolvido
fornecendo os pontos de vista de utilizao ou de quem ser afetado pelo sistema. Para garantir
qualidade e usabilidade a identificao das partes interessadas fundamental.
6.1.1.4
Identificar objetivos
Descrio
Os objetivos que o projeto pretende alcanar devem ser identificados e registrados. Estes objetivos devem ser contrastados
nos Pontos de Controle e Marcos do projeto para avaliar seu andamento e continuidade.
6.1.1.5
Descrio
O responsvel por definir a prioridade de desenvolvimento e homologar as entregas do produto deve ser identificado e
registrado. O Product Owner designado pelo cliente, ele junto ao time tem compromisso com o produto que est sendo
desenvolvido e seu sucesso tambm depende dele. Este papel deve ser desempenhado por algum com autonomia para
responder pelos requisitos do sistema, sejam funcionais ou no funcionais.
O seu contato com a equipe ocorre em dois momentos: no Planejamento de Sprint I e na Reviso do Sprint. No
planejamento ele deve definir, dentre o que ainda resta para ser desenvolvido, o que possui maior importncia e ser
abordado no prximo Sprint. Na reviso, sero apresentados os requisitos desenvolvidos, em uma demonstrao no
ambiente de homologao. Nesta reunio o P.O. tem o papel de validar o que foi desenvolvido e aceitar ou no. No caso de
no aceitar, modificaes devem ser indicadas para que sejam realizadas num prximo Sprint. Estas duas reunies
17/9/2013
38
6.1.1.6
Descrio
Cabe ao PMO definir um membro da equipe capacitado para liderar o projeto.
6.1.1.7
Descrio
O modelo de termo e abertura utilizado pelo STI compreende os seguintes campos:
Justificativa: o motivo pelo qual o projeto deve ser feito. Pode ser acrescentado aqui a justificativa
de o cliente ou o patrocinador requisitar o projeto. Podem ser includos tambm problemas de
arquitetura de projetos antigos e tudo que justifique a abertura de um novo projeto (oportunidade).
Produto do Projeto: Descreve o resultado final do projeto, aquilo que ser entregue ao fim do
mesmo. Isto inclui o sistema em si, suas integraes com outros sistemas, melhorias, documentos,
entre outros.
17/9/2013
39
Riscos: eventos que impactam o sucesso do projeto, tanto positiva como negativamente.
Aprovado por: Nome e assinatura do responsvel do PMO por este projeto e do gerente do projeto.
6.1.1.8
Descrio
Aps a criao do Termo de Abertura, existem duas maneiras de se validar a proposta (Termo de Abertura), a fim de
concretizar a iniciao do projeto:
1) Coletar assinaturas do Cliente e de um representante do Escritrio de Projetos; ou
2) Receber confirmao por e-mail.
6.1.1.9
Descrio
Com o Termo assinado e validado, o Escritrio de Projetos se responsabiliza pela criao (abertura) do projeto no Redmine
com todos os requisitos iniciais.
6.1.1.10
Avis-lo
Descrio
Avisar ao membro que atuar como gerente.
6.1.1.11
Termo de Abertura
Descrio
O arquivo do atual modelo de Termo de Abertura utilizado pelo STI que deve ser preenchido
durante este processo e assinado pelo cliente ao final do mesmo.
17/9/2013
40
7 ESPECIFICAR REQUISITOS
Verso: 1.0
Autor: Thiago Wigg
17/9/2013
41
7.1
PROCESSO PRINCIPAL
Especificar requisitos
Descrio
A especificao de requisitos feita usualmente em trs momentos: anlise de demandas, planejamento geral e Sprint
Planning.
Sprint Plannings:
durante as reunies de planejamento de cada sprint o Product Owner deve definir a ordem de desenvolvimento do produto.
Dado que a cada sprint um ou mais requisitos so entregues, comum o Product Owner apresentar outros requisitos que
no havia imaginado antes.
7.1.1.2
Classificar requisitos
Descrio
A partir da coleta de requisitos, obtemos uma listagem das funcionalidades que devem ser entregues - a isto damos o nome
de Product Backlog (PB). De posse do PB, precisamos agrupar os requisitos de acordo com suas caractersticas, de modo
que o PB fique mais organizado e fcil de entender e, ainda mais importante, para que possamos criar a EAP.
Imaginemos os seguintes requisitos:
"O estoquista deve poder cadastrar a materiais no estoque para registrar a entrada dos mesmos no patrimnio";
"O estoquista deve poder dar baixa em materiais no estoque para registrar a sada dos mesmos no patrimnio";
"O gerente deve poder gerar relatrio de entrada de materiais em estoque em um perodo de tempo sua escolha para
conhecer as alteraes de patrimnio";
"O gerente deve poder gerar relatrio de listagem de materiais em estoque por categoria, para controlar o abastecimento da
empresa";
"O gerente deve poder cadastrar fornecedores para manter uma base de consulta de fornecedores de materiais";
"O gerente deve poder visualizar fornecedores ordenados por data de incluso ou por ltima transao realizada, para obter
informaes sobre os fornecedores mais antigos ou mais frequentes".
Repare que os requisitos a e b referem-se a operaes com materiais. Assim, poderamos agrup-los numa categoria
chamada Materiais.
Do mesmo modo, os requisitos c e d tratam da gerao de relatrios. Logo, agrupar-se-iam na categoria Relatrios.
Analogamente, os requisitos e e f pertenceriam categoria Fornecedores.
IMPORTANTE: Cabe ressaltar que a classificao de requisitos em categorias no um procedimento nico e invarivel.
Existem diversas maneiras de classificar requisitos e nenhuma est absolutamente correta ou incorreta. Elas servem, de
17/9/2013
42
modos diferentes, ao mesmo objetivo: tornar a estrutura geral do sistema mais inteligvel e orientar o desenvolvimento
construo de valor, e no apenas criao de cdigo. Outra classificao para os requisitos anteriores poderia ser:
Os requisitos a e b referem-se ao ator estoquista;
Os requisitos c, d, e e f referem-se ao ator gerente;
Cada cliente traz demandas e prioridades distintas, s quais uma determinada classificao atende melhor que outra, ou
ainda uma terceira, diferente das duas anteriores. A categorizao pode depender da demanda, do cliente, do sistema, do
pblico-alvo, etc. Independente de como se ela d, o importante que ela reflita a realidade e seja coerente com o que foi
acordado com o cliente.
7.1.1.3
Priorizar requisitos
Descrio
Esta a atividade em que o P.O. estabelece uma pontuao de importncia de cada requisito, com o intuito de definir uma
ordem de implementaao.Com base nesta pontuao a equipe desenvolve as funcionalidades para o sistema. A pontuao
dada a cada requisito estabelece apenas a ordem de execuo, no uma relao numrica entre eles. Por exemplo: Se o
requisito A possui importncia 10 e o B possui importncia 30, no significa que B 3 vezes mais importante que A (dado
que 3x10=30), mas simplesmente que B mais importante que A.
Executantes
PO, Lder do Projeto, Equipe
7.1.1.4
Descrio
Para cadastrar categorias no Redmine voc deve ser o lder do seu projeto.
Basta clicar na em Configuraes >> Categorias das tarefas e em seguida clicar no boto Nova
categoria do lado esquerdo da tela.
Depois de clicar no boto Nova categoria , basta digitar o nome da categoria e criar. No
necessrio preencher o campo Atribudo para.
7.1.1.5
Descrio
Aps a criao das categorias de requisitos, cada um deles deve ser cadastrado e includo em uma categoria, sempre
seguindo a escrita padro de requisitos.
17/9/2013
43
8 PLANEJAMENTO GERAL
Verso: 1.0
Autor: Escritrio de Gerenciamento de Projetos - STI - UFF
17/9/2013
44
8.1
PLANEJAMENTO GERAL
Especificar requisitos
Descrio
Entradas:
- Relatrio de Anlise de Demandas;
- Termo de abertura.
Ferramentas:
- Reunio de especificao de requisitos
Sadas:
- Product Backlog, ordenado de acordo com a importncia definida pelo cliente e dependncias funcionais j conhecidas.
Descrio:
Um requisito deve ser escrito em linguagem de negcios e no tecnicamente, o que significa dizer, que deve conter um
valor que ser incorporado ao projeto ou ao produto. Alm disso, deve ser entregvel em no mximo um sprint. Desta forma,
a cada sprint o projeto gera valor para o cliente e este valor pode ser mensurado e avaliado pelo P.O.
Todos os requisitos devem priorizar uma redao padro, no seguinte esquema:
<Um ator> faz <alguma coisa> para <agregar algum valor>
Estes trs elementos: ATOR, AO e VALOR devem sempre que possvel compor a redao dos requisitos. O item a
abaixo contm alguns exemplos disto.
Um bom requisito precisa atender s seguintes diretrizes INVEST:
I = Independente : no depende de outra histria para ser concluda
N = Negocivel: a qualquer momento um requisito poder ser negociado pelo P.O.
V = Agrega Valor: obrigatoriamente precisa agregar valor ao negcio, quando for satisfeito.
E = Estimvel: precisa estar minimamente detalhada e entendida a ponto da equipe conseguir realizar uma estimativa de
esforo para sua concluso;
S = Pequena (Small): precisa possuir um tamanho mximo, onde o esforo para a concluso seja de at um Sprint;
T = Testvel: precisa dizer, claramente, qual a condio para sua aceitao pelo P.O.
A coleta de requisitos feita usualmente em dois momentos:
Reunio de levantamento de requisitos: realizada entre Product Owner (PO) e Equipe do Projeto aps a assinatura do termo
de abertura, esta reunio abre a fase de planejamento do projeto, e exclusivamente destinada coleta de requisitos. De
posse do Termo de Abertura, o PO expe mais detalhadamente suas necessidades especficas (o que chamamos histrias)
e a Equipe do Projeto identifica as demandas e, lapida a informao com o PO para gerar os requisitos do projeto e do
produto que devem ser contemplados na execuo. Por exemplo:
O product owner diz: preciso que o sistema controle a entrada e sada de materiais do estoque.
O gerente identifica: registrar entrada de materiais, registrar sada de materiais, gerar relatrios sobre a movimentao.
Lapidao da informao: Quem o funcionrio responsvel pelo controle de entrada e sada de materiais? o mesmo
para os dois? O que ele faz efetivamente? Que tipo de registro ele precisa gerar? Como os gestores devem consultar estes
registros?
Identificao de requisitos:
O estoquista deve poder cadastrar a materiais no estoque para registrar a entrada dos mesmos no patrimnio
O estoquista deve poder dar baixa em materiais no estoque para registrar a sada dos mesmos no patrimnio
O gerente deve poder gerar relatrio de entrada de materiais em estoque em um perodo de tempo sua escolha para
17/9/2013
45
Processo
Especificar Requisitos - Processo principal
8.1.1.2
Criar FBS
Descrio
Entradas:
- Product Baklog;
Ferramentas:
- Redmine, relatrio "FBS" da seo "Tarefas" do projeto;
Sadas:
- FBS;
- Plano de projeto, seo "Estrutura analtica do projeto"
Descrio:
O formato de estrutura analtica de projeto utilizado pelo STI est orientado a funcionalidades (FBS - Features Breakdown
Structure), uma vez que mais simples para o entendimento da equipe do projeto e do prprio P.O.(cliente).
A FBS deve ser gerada atravs do Redmine e para que ela esteja correta fundamental cadastrar com preciso os
requisitos. Uma vez que eles estejam corretamente cadastrados basta utilizar a consulta personalizada FBS na guia de
Tarefas do seu projeto. Ela agrupa os requisitos por categoria, gerando assim a FBS adequada.
8.1.1.3
Descrio
Entradas:
- Product Backlog
Ferramentas:
- Avaliao tcnica e das regras de negcio discutidas no processo de coleta de requisitos;
Sadas:
- Matriz de dependncias
- Plano de projeto, seo "Matriz de dependncias"
Descrio:
17/9/2013
46
A matriz de dependncias relaciona requisitos entre si de modo que se identifique que requisitos
dependem de outros para serem implementados.
8.1.1.4
Estimar Requisitos
Descrio
Entradas:
- Product Backlog;
Ferramentas:
- Planning Poker;
Sadas:
- Product Backlog estimado;
- Plano de projeto, Seo "Product Backlog"
Descrio:
A estimativa deve ser feita em pontos de histria e em alto nvel, sem muitos detalhes.
Apenas o necessrio para estimar o tamanho do projeto.
8.1.1.5
Definir equipe
Descrio
Entradas:
- Product Backlog estimado;
- Termo de abertura;
- Proposta de Projeto.
Ferramentas:
- Avaliao tcnico-gerencial
Sadas:
- Plano de projeto, seo "Recursos Humanos"
Descrio:
A estimativa de equipe define qual o nmero ideal e a capacidade das pessoas que trabalharo no projeto.
Somente so definidos dois papis na equipe:
Gerente - responsvel pela execuo do processo dentro da equipe, comunicao com o product owner, gerao e
atualizao das informaes do projeto no redmine e nos documentos definidos pelo processo. Atua tambm como Scrum
Master, zelando pela plena realizao do scrum conforme definido pelo processo e removendo os impedimentos que surjam
17/9/2013
47
ao longo do sprint.
Desenvolvedor - todos os demais membros fixos da equipe, independente das tarefas que desempenhem ou das habilidades
com que contribuam para a execuo do projeto. Conforme definido pelo Scrum, todos da equipe so igualmente
responsveis pelo desenvolvimento das solues s quais o projeto se destina.
8.1.1.6
Descrio
Entradas:
- Plano de projeto, seo "Recursos Humanos";
- Dados histricos;
- Proposta de Projeto.
Ferramentas:
- Avaliao tcnico-gerencial
- Estimativa baseada em dados histricos
Sadas:
- Estimativa inicial de velocidade do time;
- Plano de projeto, seo "Velocidade do time"
Descrio:
A estimativa do time feita levando em conta o nmero de pessoas do time e a capacidade tcnica dos membros, com base
em dados histricos ou em referncias tcnicas.
8.1.1.7
Estimar infraestrutura
Descrio
Entradas:
- Product Backlog estimado;
- Plano de projeto, seo "Recursos Humanos"
Ferramentas:
- Avaliao tcnico-gerencial;
Sadas:
- Plano de projeto, seo "Infraestrutura"
Descrio:
Com base no que precisa ser desenvolvido e na e equipe que participar deste desenvolvimento, realizada uma avaliao
tcnico-gerencial objetivando estimar infraestrutura necessria ao projeto. A partir desta avaliao sero identificadas
17/9/2013
48
necessidades como espao de trabalho, mquinas, ferramentas, tecnologias, mobilirio, espao de disco, capacidade de
processamento e memria dos servidores, sistema de controle de verses e tudo o mais que for preciso para garantir
equipe as condies de desenvolvimento do projeto.
8.1.1.8
Criar cronograma
Descrio
Entradas:
- Plano de projeto, seo "Product Backlog";
- Plano de projeto, seo "Velocidade do time";
- Plano de projeto, seo "Matriz de dependncias";
- Proposta de Projeto.
Ferramentas:
- Estimativa com fator de foco/produtividade;
- Diviso de tempo em sprints
Sadas:
- Cronograma baseado em sprints;
- Plano de projeto, seo "Cronograma".
Descrio:
Distribuir os itens do backlog em sprints, de acordo com a velocidade do time, respeitando a ordem de importncia dos
requisitos definida pelo cliente e possveis dependncias entre eles.
8.1.1.9
Estimar custo
Descrio
Entradas:
- Plano de projeto, seo "Recursos Humanos";
- Plano de projeto, seo "Cronograma";
- Plano de projeto, seo "Infraestrutura".
Ferramentas:
- Avaliao financeira
- Planilha de estimativas
Sadas:
- Planilha de estimativa de custos do projeto
Descrio:
17/9/2013
49
8.1.1.10
Determinar oramento
Descrio
Entradas:
- Estimativa de custo;
Ferramentas:
- Avaliao gerencial
Sadas:
- Oramento do projeto
Descrio:
Se o projeto for gerar receita, necessrio definir um preo com base no custo estimado.
8.1.1.11
Definir a qualidade
Descrio
Entradas:
- Termo de Abertura do Projeto
- Product Backlog Estimado
Ferramentas:
- Avaliao tcnico-gerencial
Sadas:
- Indicadores e metas de qualidade
Descrio
8.1.1.12
Planejar Comunicao
Descrio
17/9/2013
50
8.1.1.13
Descrio
Entradas:
- Termo de Abertura;
- Cronograma;
- Estimativa de equipe;
- Estimativa de custos;
- Estimativa de infraestrutura.
Ferramentas:
- Avaliao gerencial
Sadas:
- Tabela de riscos
Descrio:
Os riscos devem ser identificados e catalogados na tabela de riscos, contendo uma descrio, uma anlise qualitativa e um
planejamento de resposta a cada risco.
8.1.1.14
Descrio
Entradas:
- Termo de abertura;
- Template de plano de projeto;
Sadas:
- Plano de Projeto
Descrio:
Com base nas sadas de cada atividade deste processo, o plano de projeto apenas organizado
utilizando o template padro de plano de projeto, fornecido pelo Escritrio de Projetos.
8.1.1.15
Plano do Projeto
Descrio
17/9/2013
51
17/9/2013
52
8.2
Descrio
Entradas:
- Termo de Abertura;
- Cronograma;
- Estimativa de equipe;
- Estimativa de custos;
- Estimativa de infraestrutura.
Ferramentas:
- Avaliao gerencial
Sadas:
- Tabela de riscos
Descrio:
Os riscos devem ser identificados e catalogados na tabela de riscos, contendo uma descrio, uma anlise qualitativa e um
planejamento de resposta a cada risco.
Descrio
Analisar a probabilidade e o impacto de todos os riscos identificados, utilizando mtodos
qualitativos.
17/9/2013
53
8.2.1.2
Descrio
Desenvolver e manter um planejamento de resposta aos riscos. A resposta ao risco deve identificar
estratgias de risco e considerar os nveis de tolerncia definidos.
8.2.1.3
Identificar os riscos
Descrio
Identificar eventos com potencial impacto negativo nos objetivos ou nas operaes da organizao,
incluindo aspectos de negcios, regulamentao, aspectos jurdicos, tecnologia, parcerias
de negcio, recursos humanos e operacionais. Determinar a natureza do impacto e manter esta
informao.
17/9/2013
54
9 PLANEJAMENTO DE SPRINT
Verso: 1.0
Autor: STI
17/9/2013
55
9.1
PROCESSO PRINCIPAL
Atualizar requisitos no PB
Descrio
Na reunio de planejamento do sprint deve-se conhecer, tanto quanto possvel, os objetivos de
requisito, o valor de negcio, observaes importantes acerca da implementao e tudo o mais
que for necessrio para garantir que a equipe conseguir definir como implementar o requisito.
9.1.1.2
Atualizar importncias no PB
Descrio
O cliente deve priorizar os requisitos de acordo com o valor de cada um para o negcio. Esta
estimativa deve ser registrada nos requisitos no Redmine.
9.1.1.3
Atualizar estimativas no PB
Descrio
A equipe e o lder de projeto devem analisar as informaes existentes de um requisito e estim-lo
utilizando o planning poker.
9.1.1.4
Seleciona requisito do PB
9.1.1.5
Descrio
Entradas:
- Product Backlog
Ferramentas:
- Planning Poker
- Estimativa em pontos de complexidade
Sadas:
- Tarefas cadastradas e estimadas no Redmine.
Descrio:
a identificao das tarefas especficas necessrias para entregar os requisitos. Requisitos definem O QUE deve ser feito.
Tarefas dizem COMO fazer.
17/9/2013
56
Referncias
- [PMBOK:6.1 Definir Atividades]
- Ferramenta do PMBOK: Planejamento em ondas sucessivas
9.1.1.6
Estimar atividades
Descrio
Entradas:
* Lista de atividades de cada requisito que ser implantado no prximo sprint.
Ferramentas:
- Planning Poker
- Estimativa em pontos de complexidade
Sadas:
- Tarefas cadastradas e estimadas no Redmine.
Descrio:
a estimativa de quanto esforo ser necessrio para concluir cada atividade. Esta estimativa no
feita em tempo, mas em Pontos de Complexidade, que leva em conta o conhecimento
necessrio e o que se possui sobre a tecnologia e as regras para realizar a atividade, o tempo que
toma, a complexidade de execuo, entre outros.
Referncias:
9.1.1.7
Atualizar cronograma
Descrio
Aps a definio do Sprint Backlog, o cronograma do projeto deve ser atualizado.
9.1.1.8
Descrio
As informaes dos selecionados para o sprint e das tarefas estimadas, devem ser atualizadas no redmine, registrando o
Sprint backlog e o cronograma atualizado.
9.1.1.9
Descrio
17/9/2013
57
Dado que todos os requisitos e respectivas tarefas j foram atualizados no Redmine, deve-se
imprimi-los e anexar no quadro Scrum.
Este quadro ser ferramenta importante na execuo do sprint, especialmente nas reunies
dirias.
17/9/2013
58
10
EXECUO DO SPRINT
Verso: 1.0
Autor: Thiago Wigg
17/9/2013
59
10.1
PROCESSO PRINCIPAL
Elemento
Descrio
Neste processo, as ferramentas adequadas devem ser utilizadas para o desenvolvimento e
implementao dos requisitos acordados na reunio de planejamento. A equipe do projeto e
somente ela responsvel pela implementao dos requisitos. Caso surja algum impedimento
execuo desta tarefas, ele deve ser reportado na reunio diria ou o mais breve possvel ao lder
do projeto.
10.1.1.2
Buscar tarefa
Descrio
O desenvolvedor deve acessar o Redmine (https://sistemas.uff.br/redmine/) em busca de tarefas.
Devem ser realizadas as tarefas do requisito mais importante (prioritrio).
10.1.1.3
Descrio
Se o desenvolvedor no possuir o projeto na sua rea de trabalho, ele deve realizar "checkout".
Caso contrrio, ele deve atualizar o projeto, realizando um "update" do SVN.
REFERNCIA
- SVN Book, Captulo 7.
10.1.1.4
Descrio
Partindo da especificao do requisito e dos critrios de aceitao, deve-se desenhar a soluo, que envolve a arquitetura e
os testes.
17/9/2013
60
10.1.1.5
Implementar soluo
Descrio
Nesta atividade ser realizada a implementao da soluo para que a tarefa seja concluda e o
requisito possa ser entregue.
Caso o desenvolvedor precise de ajuda, por no saber como alcanar uma soluo, os seguintes
passos devem ser seguidos:
1. Buscar solues na base de conhecimento;
2. Buscar solues no google;
3. Perguntar aos outros desenvolvedores;
4. Avisar do impedimento ao Lder Tcnico, Scrum Master ou Gerente do Projeto;
5. Apresentar impedimento na reunio diria.
REFERNCIAS:
- (TODO: boas prticas JAVA)
- (TODO: boas prticas de Ruby on Rails)
10.1.1.6
Implementar testes
Descrio
Devem ser implementados os testes de aceitao e unitrios planejados anteriormente.
10.1.1.7
Descrio
A soluo suficiente quando:
- Os testes esto passando;
- A cobertura de testes segue o definido para o projeto;
- O padro de codificao foi seguido;
17/9/2013
61
10.1.1.8
Publicar soluo
Descrio
O QUE ?
- Atualizar a situao da tarefa no Redmine;
- Comitar as alteraes no projeto.
COMO FAZER?
Deve-se realizar um commit seguindo o padro STI (ver referncia, abaixo): mensagem + referncia ao ticket do Redmine.
O Commit com esta referncia j atualiza ou fecha o ticket no Redmine.
10.1.1.9
Controlar Qualidade
Descrio
Processo
CDS-04-Controle da Qualidade - CDS-04-Controle da Qualidade
10.1.1.10
Descrio
A reunio diria realizada no mesmo horrio em cada dia e seu objetivo acompanhar e
controlar o andamento do Sprint. Nesta reunio so identificados ou reportados os impedimentos
que no permitem a implementao dos requisitos ou atrapalham a produtividade da equipe de
desenvolvimento.
Esta reunio deve durar no mximo 15 minutos, independente do nmero de membros
participantes da mesma. Nela, cada membro do time de desenvolvimento deve responder a trs
perguntas:
1.
O que foi feito desde a ltima reunio de acompanhamento ou planejamento de sprint,
caso seja a primeira reunio;
2.
O que ser feito at a prxima reunio de acompanhamento ou trmino do sprint, caso
seja a ltima reunio;
3.
Esta reunio deve ser realizada em p ao lado do quadro SCRUM ou monitor com Redmine
(quando o time no estiver usando um quadro SCRUM ainda). As perguntas devem ser
17/9/2013
62
respondidas para o time e no para o lder do projeto apenas, afinal todo o time est comprometido
com os objetivos e requisitos definidos no incio do Sprint.
Durante a reunio diria, cada membro deve atualizar a situao das suas tarefas no quadro
SCRUM. E ao final dela, o lder do projeto deve atualizar no Redmine a situao das tarefas.
Todos os membros devem ajudar o lder do projeto a manter o Redmine atualizado, com as
situaes das suas tarefas.
17/9/2013
63
11
CDS-04-CONTROLE DA QUALIDADE
Verso: 1.0
Autor: Daniel
17/9/2013
64
11.1
CDS-04-CONTROLE DA
QUALIDADE
Realizar medies
Descrio
Extrair mtricas do projeto, como complexidade ciclomtica e linhas de cdigo.
Implementao
Servio Web
11.1.1.2
Verificar cdigo
Descrio
Executar verificaes de boas prticas no cdigo.
Java:
- PMD
- Checkstyle
Ruby on Rails:
- Rails Best Pratices
Implementao
Servio Web
11.1.1.3
Descrio
Esta tarefa executada pelo Jenkins.
Os testes automatizados so executados e seu resultado coletado.
Implementao
Servio Web
11.1.1.4
Descrio
Um e-mail para a equipe do projeto enviado sempre que:
17/9/2013
65
11.1.1.5
Descrio
Nesta tarefa, o resultados dos testes, das medies e da verificao de cdigo so publicados no
Sonar (https://sistemas.uff.br/sti/sonar/).
O Sonar o sistema de monitoramento da qualidade da CDS-STI.
Sonar CDS STI
https://sistemas.uff.br/sti/sonar/
Implementao
Servio Web
11.1.1.6
Disparar alarmes
Descrio
Quando os testes quebrarem, valores de mtricas forem ultrapassados e violaes ocorrerem, alarmes so disparados.
Esses alarmes so e-mails para a equipe do projeto e equipe de qualidade.
Implementao
Servio Web
11.1.1.7
Analisar qualidade
Descrio
Analisar os relatrios do Sonar e Jenkins para avaliar a qualidade do projeto.
11.1.1.8
Indicar no conformidades
Descrio
Se existirem no conformidades, deve-se criar tickets no Redmine indicando-as.
17/9/2013
66
12
CONTROLE DO SPRINT
Verso: 1.0
Autor: Thiago Wigg
17/9/2013
67
12.1
PROCESSO PRINCIPAL
Reviso do Sprint
Descrio
Reunio onde equipe e lder do projeto apresentam o que foi desenvolvido ao cliente j na forma
de funcionalidade dentro do sistema, em ambiente de homologao.
O objetivo permitir ao cliente verificar se o que foi planejado efetivamente foi feito e validar se as
entregas satisfazem s demandas.
Esta reunio deve gerar uma ata.
12.1.1.2
Retrospectiva do Sprint
Descrio
Reunio onde lder do projeto e equipe, tratam do sprint que acaba de terminar e identificam:
* O que foi bom e deve ser mantido;
* O que pode melhorar;
* Sugestes
A partir disto, todos se comprometem a esforarem-se para atender ao que foi proposto a partir do
prximo sprint.
12.1.1.3
Processo
Colocar Sistema ou Funcionalidade em produo - Processo principal
17/9/2013
68
13
COLOCAR SISTEM A OU
FUNCIONALIDADE EM PRODUO
Verso: 1.0
Autor: Thiago Wigg
17/9/2013
69
13.1
PROCESSO PRINCIPAL
13.1.1.2
13.1.1.3
13.1.1.4
13.1.1.5
Realizar deploy
13.1.1.6
13.1.1.7
17/9/2013
70
14
C D S - 0 6 - A C O M PA N H A M E N T O D E
PROJETO
Verso: 1.0
Autor: Daniel
17/9/2013
71
14.1
CDS-06-ACOMPANHAMENTO
DE PROJETO
Fim do Sprint
Descrio
Este processo executado a cada 15 dias (perodo de um sprint) ou quando terminar o sprint (no
final do ano, normalmente, temos um sprint de uma ou trs semanas).
Data do timer
2011-08-16T00:00:00
14.1.1.2
Preparar RA
Descrio
O gerente do projeto deve preencher o Relatrio de Acompanhamento, com base no template disponibilizado pelo PMO:
https://sistemas.uff.br/redmine/attachments/download/3144/Template_RA_Projeto.dot
Arquivo anexo
Template_RA_v3.5.doc
14.1.1.3
Envia ao PMO
Descrio
Importante: o RA deve ser enviado at o momento da Reunio de Acompanhamento. Cada gerente possui sua agenda
marcada com o PMO.
14.1.1.4
Gerar e enviar Resumo de Acompanhamento e Gantt dos
projetos
Descrio
O PMO relata o progresso dos projetos para o Diretor da CDS.
Link para download do
Resumo_Acomp-Projeto.dot
template:
https://sistemas.uff.br/redmine/attachments/download/3148/Template-DCDS-
O documento contm:
1. Informaes bsicas
1.1 Identificao do Sprint: Sprint (ex.: #2010.14); Data de incio; Data de trmino.
17/9/2013
72
2. Qualidade e Indicadores
2.1 Produtividade Atual x Anterior: uma comparao com produtividade do sprint anterior (ex.: no sprint referente foram
entregues 20 pontos de histria e no anterior 18, logo deve-se indicar uma seta verde).
2.2 Situao (Progresso): representa quanto do planejado para o sprint foi entregue, ou seja, Pontos de Histria Entregues /
Pontos de Histria Planejados (ex.: 20 pts planejados, 15 pts entregues -> 75%).
2.3 Observaes: espao para breves descries explicativas acerca dos indicadores de produtividade e progresso.
2.4 Qualidade: 100% dos testes passando? ; 80% de cobertura mnima de cdigo? (todo projeto da STI deve atender a essas
duas limitaes).
3. Progresso
3.1 Requisitos (concludos/total): feita a relao entre quantidade de requisitos concludos no sprint e a quantidade
planejada para o sprint (ex.: 4/6)
3.1.1 Progresso %: representa o valor percentual da informao anterior (ex.: 66,7%).
3.2 Pontos de Histria (concludos/total): feita a relao entre os pontos de histria concludos no sprint e a quantidade
planejada para o sprint (ex.: 15/20)
3.2.1 Progresso %: representa o valor percentual da informao anterior (ex.: 75%).
3.3 Sprint restantes: nmero de sprint que restam de trabalho para o projeto, segundo planejamento.
14.1.1.5
Divulgar notcias
Descrio
As notcias coletadas nas reunies de acompanhamento passam por uma triagem do PMO e so divulgadas apenas
internamente ou interna e externamente, pela equipe de mdia e supervisionadas pelo PMO.
17/9/2013
73
14.1.1.6
Descrio
Equipe de Comunicao envia e-mail interno com notcias dos projetos.
14.1.1.7
Relatrio de Acompanhamento
Descrio
Link para download do template:
https://sistemas.uff.br/redmine/attachments/download/3144/Template_RA_Projeto.dot
14.1.1.8
Descrio
A atividade de atualizao do Redmine com o review envolve um esforoo do gerente para conferir os status, estimativas e
possveis notas dos tickets, de modo a deix-los conforme a realidade do projeto e prontos para o review com o cliente.
obs.: requisitos que no foram concludos devem seguir no sprint, de modo a possibilitar um acompanhamento mais real
possvel por parte do PMO.
14.1.1.9
Descrio
Essa atividade consta da extrao dos relatrios salvos (consultar personalizadadas):
- Resumo de Revew -> "SCRUM: Sprint Review"
- Backlog: "Anexo 01 -> Product Backlog"
14.1.1.10
Descrio
A equipe do PMO deve atualizar o quadro de cronogramas e o Gantt de projetos, levando em considerao o progresso em
requisitos (requisitos entregues / requisitos totais).
Link do Gantt: https://sistemas.uff.br/redmine/projects/projetos/issues/gantt
14.1.1.11
Descrio
Com insumos gerados na Reunio de Avaliao do Acompanhamento, o PMO toma as medidas necessrias para remoo
dos impedimentos (que devem estar cadastrados no Redmine).
17/9/2013
74
14.1.1.12
Descrio
Aps (ou durante) o Sprint Planning com o cliente, o Redmine deve ser atualizado, principalmente no que concerne ao
cronograma. Ou seja, revisto o planejamento do projeto.
14.1.1.13
Descrio
14.1.1.14
Descrio
Essa reunio ocorre entre o gerente e a equipe do PMO, e tem por objetivo discutir a respeito das Reunies e dos Relatrios,
alm de analisar os impedimentos cadastrados no Redmine ("_PMO: Impedimentos dos Projetos").
14.1.1.15
Reunio de acompanhamento
Descrio
A Reunio de Acompanhamento realizada entre PMO e gerente do projeto, orientada pela discusso de cada item do
relatrio de acompanhamento. um ponto importante de checagem do cumprimento do processo e de identificao de
demandas que precisem do apoio direto do PMO na sua soluo.
14.1.1.16
Envio ao DCDS
Descrio
O PMO envia os Resumos de Acompanhamento para o DCDS toda quinta-feira de incio de sprint.
Eles devem ser enviados com os anexos, em formato PDF , em e-mail individual para o DCDS, com cpia para o gerente e o
PMO (pmo.sti@id.uff.br).
Deve ser enviado tambm, em outro e-mail individual, o Gantt em formato PDF, para o DCDS com cpia para o PMO
(pmo.sti@id.uff.br).
14.1.1.17
Descrio
Aps as aes para remoo de impedimentos serem tomadas, chega-se ao fim do acompanhamento do sprint.
17/9/2013
75
15
ENCERRAMENTO DO PROJETO
Verso: 1.0
Autor: Bruno Olmpio
17/9/2013
76
15.1
ENCERRAMENTO DO PROJETO
Descrio
A reunio de encerramento de projeto tem presena das partes interessadas (Escritrio de Projetos, Diretor da CDS, cliente,
PO, gerente do projeto, equipe do projeto e equipe de comunicao).
Este evento ocorre para que se formalize o trmino do projeto e seja assinado o Termo de Encerramento.
15.1.1.2
15.1.1.3
Descrio
O Escritrio de Projetos responsvel por marcar a reunio com os interessados (envolvidos).
15.1.1.4
15.1.1.5
Descrio
Deve-se fechar o projeto no Redmine.
15.1.1.6
Descrio
A operao do Redmine a rea de gesto da manuteno do cdigo e nela que devem ser registrados bugs, pequenas
melhorias e inconformidades.
Aps a soluo estar finalizada e em produo, deve-se criar uma rea interna "Operaes" do modo "Operao: <nome
da aplicao>".
Caso o projeto tenha sido foco apenas de refatoraes e/ou melhorias, ou seja, refino de uma soluo j existente, a nova
rea no deve ser criada.
17/9/2013
77
16
CDS-02-SCRUM
Verso: 1.0
Autor: Daniel
17/9/2013
78
16.1
CDS-02-SCRUM
Sprint Planning
16.1.1.2
Desenvolvimento dirio
16.1.1.3
Reunio diria
16.1.1.4
Review
16.1.1.5
Retrospectiva
17/9/2013
79
17
CDS-03-REVISO TRIMESTRAL
Verso: 1.0
Autor: Giovanna
17/9/2013
80
17.1
CDS-03-REVISO
TRIMESTRAL
17.1.1.2
17.1.1.3
Preencher RRT
Descrio
Etapas:
Preencher e avaliar as metas trimestrais
Anunciar o resultado alcanado
Completar o status da meta (alcanado, parcialmente alcanado, no alcanado ou no planejado)
Definir os indicadores de desempenho
Preencher os resultados colhidos
Preencher o estado atual
Sinalizar os impedimentos e seus motivos
Observaes e sugestes
17.1.1.4
Processo
Avaliao de cada projeto - Processo principal
Tipo de loop
Padro
17.1.1.5
Reinclu-las no planejamento
Descrio
Avaliar o grau de importncia das metas. Caso no sejam muito importantes, sero movidas para outro trimestre que no o
seguinte
17/9/2013
81
17.1.1.6
Descrio
Avaliar se as metas definidas para o trimestre seguinte ainda so coerentes, ou se precisam ser
removidas ou movidas para outro trimestre.
17.1.1.7
Rever indicadores
Descrio
Verificar se os indicadores definidos so coerentes com as metas e incluir novos indicadores que
se faam necessrios.
17.1.1.8
Descrio
O Escritrio de Projetos revisar todos os relatrios dos projetos e criar um relatrio geral do trimestre.
17.1.1.9
Descrio
Baseado nas revises realizadas pelos projetos, o Escritrio de Projetos disponibilizar o
planejamento anual revisado no trimestre em questo.
17.1.1.10
17/9/2013
82
18
AV A L I A O D E C A D A P R O J E T O
Verso: 1.0
Autor: Thiago Wigg
17/9/2013
83
18.1
PROCESSO PRINCIPAL
Apresentar projeto
18.1.1.2
Apresentar meta
18.1.1.3
Descrio
Estados possveis: completamente alcanado, parcialmente alcanado e BL
18.1.1.4
18.1.1.5
18.1.1.6
Avaliar a situao
17/9/2013
84
19
CDS-05-QUALIFICAO DE
DEMANDA
Verso: 1.0
Autor: Thiago Wigg
17/9/2013
85
19.1
CDS-05-QUALIFICAO DE
DEMANDA
Descrio
Solicitaes de programas/projetos
Descrio
Novas solicitaes oriundas de programas j existentes, sejam relativas extenso ou modificao de escopo de projetos em
execuo, sejam de ampliao dos objetivos do programa e gerao de novos projetos, devem ser comunicadas ao Escritrio
de Projetos, que o responsvel pela gesto dos programas e projetos da CDS.
19.1.1.2
Registrar Solicito
Descrio
Todas as solicitaes devero ser registradas na ferramenta oficial de comunicao (Redmine) na forma de tickets do tipo
"Demanda" informando sempre o solicitante (nome, setor, pr-reitoria ou superintendncia).
19.1.1.3
Novas solicitaes
Descrio
Novas solicitaes so aquelas que ainda no foram includas em nenhum dos programas ou projetos j existentes na CDS.
Elas so identificadas pelo diretor da CDS, em contato direto com os clientes, e devem ser registradas.
19.1.1.4
Registrar Solicitao
Descrio
Todas as solicitaes devero ser registradas na ferramenta oficial de comunicao (Redmine) na forma de tickets do tipo
"Demanda" informando sempre o solicitante (nome, setor, pr-reitoria ou superintendncia).
19.1.1.5
Descrio
Nesse ponto debate-se uma nova demanda, considerando elementos como: a existncia ou no de uma soluo prvia da
STI; a criticidade; e a urgncia. Aps isso, decide-se pelo arquivamento ou pela execuo da anlise da demanda.
Durante esta atividade, as solicitaes podem ser desmembradas em subitens (demandas) com a finalidade de melhor avalilas. Isto acontece porque dentro de uma solicitao pode haver demandas que sero atendidas e outras no.
17/9/2013
86
19.1.1.6
Analisar demanda
Descrio
Todas as demandas aceitas na avaliao inicial so atribudas equipe de Anlise, que dever efetuar uma anlise das
mesmas e emitir um parecer contendo uma descrio da demanda com os objetivos a que ela pretende atender e uma
estimativa de tamanho.
A reunio realizada entre Product Owner (PO) e Equipe de Anlise. Esta reunio exclusivamente destinada especificao
de requisitos. De posse do Relatrio de Anlise de Demandas, o PO expe mais detalhadamente suas necessidades
especficas (o que chamamos histrias) e a Equipe de Anlise especifica as demandas e, lapida a informao com o PO para
gerar os requisitos do projeto e do produto que devem ser contemplados na execuo. Por exemplo:
O product owner diz: preciso que o sistema controle a entrada e sada de materiais do estoque.
O analista identifica: registrar entrada de materiais, registrar sada de materiais, gerar relatrios sobre a movimentao.
Lapidao da informao: Quem o funcionrio responsvel pelo controle de entrada e sada de materiais? o mesmo para
os dois? O que ele faz efetivamente? Que tipo de registro ele precisa gerar? Como os gestores devem consultar estes
registros?
Identificao de requisitos:
O estoquista deve poder cadastrar a materiais no estoque para registrar a entrada dos mesmos no patrimnio
O estoquista deve poder dar baixa em materiais no estoque para registrar a sada dos mesmos no patrimnio
O gerente deve poder gerar relatrio de entrada de materiais em estoque em um perodo de tempo sua escolha para
conhecer as alteraes de patrimnio.
O parecer da anlise deve conter uma descrio dos objetivos do cliente com o sistema ou soluo solicitada e seus
respectivos requisitos.
Nesse momento no necessrio ter todas as informaes sobre o requisito, como prototipao, por exemplo, mas a
quantidade necessria de informaes para entend-los.
importante que todos os requisitos estejam agrupados por objetivo.
19.1.1.7
Descrio
Deve ser informado ao solicitante o parecer da CDS aps a avaliao da solicitao, informando quais objetivos e requisitos
foram identificados e registrados, e quais foram negados.
19.1.1.8
Descrio
Em reunio de avaliao das demandas analisadas pela equipe responsvel, o diretor da CDS, em conjunto com o gerente
do Escritrio de Projetos e o gerente de Anlise, delibera sobre a aprovao ou no da demanda, considerando seus
objetivos e o alinhamento destes aos da Universidade e da STI.
17/9/2013
87
Uma demanda pode ser parcialmente aprovada, ou seja, algumas necessidades podem ser atendidas e outras no.
19.1.1.9
Demanda aprovada?
Descrio
As demandas aprovadas passam a ser responsabilidade do Escritrio de Projetos. As rejeitadas, total ou parcialmente, so
registradas no meio oficial de comunicao (Redmine) e so descartadas.
Portes
Sim
No (total ou parcialmente)
19.1.1.10
Descrio
Uma vez que uma demanda analisada foi aprovada, o Escritrio de Projetos identifica a qual programa a demanda pertence
e a cadastra devidamente, atualizando o backlog do programa e a Estrutura Analtica do Programa (EAP) para que a
documentao reflita o novo escopo do programa.
Caso seja oriunda de uma nova solicitao, o escritrio de projetos decide pela abertura ou no de um programa que
contemple aqueles objetivos.
19.1.1.11
Descrio
O Escritrio de Projetos emite um parecer acerca das novas demandas, de acordo com sua capacidade produtiva,
disponibilidade de recursos e planejamento dos projetos em execuo, sobre se possvel ou no prever quando um novo
projeto que atenda ao todo ou em parte as novas demandas. So considerados sem estimativa possvel os casos em que no
seja razovel fornecer uma previso de prazo de incio ou quando esta previso superar em 12 meses a data do parecer.
19.1.1.12
Demanda aprovada/analisada
Descrio
Aprovada a demanda, pode-se iniciar o planejamento e dado sinal para a Iniciao do Projeto.
19.1.1.13
Descrio
19.1.1.14
Proposta de Projeto
17/9/2013
88
20
COORDENAO TCNICA
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
A CTE responsvel por planejar, divulgar, coordenar e supervisionar as atividades da Coordenao de acordo com as
diretrizes da Superintendncia.
17/9/2013
89
20.1
MAIN PROCESS
Descrio
Processo
CTE-01 - Gerenciamento de Servios da CTE - CTE - 01 - Gerenciamento de Servios da CTE
20.1.1.2
Atendimento Tcnico
Descrio
Processo
Atendimento Tcnico - Main Process
20.1.1.3
Telefonia
Descrio
Processo
Telefonia - Main Process
17/9/2013
90
21
CTE-01 - GERENCIAMENTO DE
SERVIOS DA CTE
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
91
21.1
CTE - 01 - GERENCIAMENTO
DE SERVIOS DA CTE
Definio estratgica
21.1.1.2
Projetar servio
21.1.1.3
Implantao
21.1.1.4
Operao
21.1.1.5
17/9/2013
92
22
C T E - 0 2 - AT E N D I M E N T O T C N I C O CLASSE DE SERVIOS
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
93
22.1
MAIN PROCESS
Servios de Operao
Descrio
17/9/2013
94
22.2
CTE -02- ATENDIMENTO
TCNICO - CLASSE DE SERVIOS
22.2.1.2
Manuteno, configurao e instalao de recursos
computacionais
22.2.1.3
Finalizar chamado
22.2.1.4
Oficina de reparos
Descrio
22.2.1.5
Laudo de equipamentos
17/9/2013
95
23
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
96
23.1
CTE-03 -MANUTENO,
CONFIGURAO E INSTALAO DE
RECURSOS COMPUTACIONAIS
Recepo de chamado
23.1.1.2
23.1.1.3
Atendimento do chamado
23.1.1.4
Reagendamento de visita
23.1.1.5
23.1.1.6
23.1.1.7
17/9/2013
97
24
C T E - 0 4 - O F I C I N A D E R E PA R O
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
98
24.1
MAIN PROCESS
Descrio
Limpeza, solda, outros
24.1.1.2
24.1.1.3
Reparos de complexidademdia
17/9/2013
99
25
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
100
25.1
MAIN PROCESS
Gesto
25.1.1.2
Servios de Operao
Descrio
Limpeza, solda, outros
25.1.1.3
17/9/2013
101
25.2
CTE- 05 -TELEFONIA CLASSE DE SERVIOS
25.2.1.2
Consultoria
25.2.1.3
Finalizar chamado
25.2.1.4
25.2.1.5
Treinamento
17/9/2013
102
26
C T E - 0 6 - AT I V A O D E R A M A L
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
103
26.1
CTERAMAL
06 -ATIVAO DE
Recebimento de chamado
26.1.1.2
Agendamento de atendimento
26.1.1.3
Instala telefone IP
26.1.1.4
26.1.1.5
26.1.1.6
26.1.1.7
17/9/2013
104
27
CTE- 07 - REMANEJAMENTO DE
RAMAL
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
105
27.1
CTE- 07 - REMANEJAMENTO
DE RAMAL
Recebimento de chamado
27.1.1.2
Agendamento de atendimento
27.1.1.3
27.1.1.4
27.1.1.5
27.1.1.6
27.1.1.7
Reagenda visita
17/9/2013
106
28
CTE- 08 - CONFIGURAO DE
RAMAL
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
107
28.1
CTE- 08 - CONFIGURAO DE
RAMAL
Recebimento de chamado
28.1.1.2
Configura ramal
28.1.1.3
Realiza testes
28.1.1.4
28.1.1.5
Configura grupo
28.1.1.6
Agenda visita
28.1.1.7
17/9/2013
108
29
CTE- 09 -DISPONIBILIZAO DE
SENHAS
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
109
29.1
CTE- 09 -DISPONIBILIZAO
DE SENHAS
Recebimento de chamado
29.1.1.2
29.1.1.3
Realiza testes
29.1.1.4
29.1.1.5
29.1.1.6
17/9/2013
110
30
CTE- 10 - TREINAMENTO NO
SISTEMA DE MONITORIA
Verso: 1.0
Autor: Coordenao Tcnica
Descrio
17/9/2013
111
30.1
CTE- 10 - TREINAMENTO NO
SISTEMA DE MONITORIA
Recebimento de chamado
30.1.1.2
30.1.1.3
30.1.1.4
Realizao do treinamento
30.1.1.5
17/9/2013
112
31
C E T - 1 1 - AT E N D I M E N T O T C N I C O AT U A L
Verso: 1.0
Autor: Bruno Olmpio
17/9/2013
113
31.1
CET-11-ATENDIMENTO
TCNICO
Verificar rea
31.1.1.2
31.1.1.3
31.1.1.4
31.1.1.5
Anlise da solicitao
Descrio
Anlise da solicitao e descrio, com data e hora, sobre procedimentos adotados para a soluo
do chamado.
31.1.1.6
31.1.1.7
31.1.1.8
31.1.1.9
Aguarda aquisio
31.1.1.10
17/9/2013
114
32
RHB-01-PROCESSO SELETIVO DE
B O L S I S TA S
Verso: 1.0
Autor: DanCastellani
17/9/2013
115
32.1
ENTRADA - PROCESSO
SELETIVO
Descrio
Este processo descreve as tarefas que ocorrem durante a entrada de um novo estagirio pelo
processo seletivo.
Avaliar indicao
Descrio
As indicaes devem ser avaliadas para verificar a seriedade e a validade da indicao.
Executantes
RHB
32.1.1.2
Entrevistar candidatos
Descrio
As entrevistas devem ser marcadas no NTI, na sala de reunio e devem durar cerca de 30 minutos.
Executantes
RHB
32.1.1.3
Descrio
A entrada dos candidatos deve ser realizada em uma reunio com o PMO, RH e Gerente dos
Projetos que possuem vagas, ou um membro experiente que pertena ao projeto.
Executantes
PMO, RHB, Lder do Projeto
32.1.1.4
Divulgar Resultado
Descrio
O resultado do processo Seletivo deve ser informado na lista geral.
Executantes
RHB
17/9/2013
116
32.1.1.5
Descrio
Os novos estagirios devem ser apresentados na lista geral e no ambiente de trabalho.
O Gerente do projeto, junto ao RH deve apresentar o novo estagirio aos membros do STI que trabalham no polo do projeto
em questo.
Executantes
Lder do Projeto, RHB
32.1.1.6
Treinar os estagirios
Descrio
Os novos estagirios devem ser alocados aos respectivos projetos.
32.1.1.7
Alocar os estagirios
Descrio
Os novos estagirios devem ser alocados entre os projetos que possuam vagas, se ainda no tiver sido feito.
Provavelmente esta alocao j foi efetuada durante a aprovao do candidato.
Mas ela pode mudar de acordo com o treinamento, por isso deve ser revista.
Executantes
RHB
32.1.1.8
Descrio
O RH deve entrar em contato com os candidatos informando sobre o resultado do processo
seletivo.
Caso o candidato tenha sido aprovado, ele deve ser convocado para iniciar o estgio.
Executantes
RHB
32.1.1.9
Descrio
As vagas disponveis devem ser divulgadas no site e na secretaria do curso de computao.
Executantes
RHB
17/9/2013
117
32.1.1.10
Descrio
As vagas identificadas devem ser divulgadas internamente objetivando indicaes dos membros
do STI.
Executantes
RHB
32.1.1.11
Identificar vagas
Descrio
O RH deve consultar o PMO para descobrir quais projetos possuem vagas e descobrir como so
as vagas.
Executantes
RHB
17/9/2013
118
32.2
INDICAO DE MEMBRO
Fazer indicao
Descrio
Qualquer membro pode fazer uma indicao.
As indicaes devem ser feitas atravs do formulrio no site do STI.
Executantes
Membro
17/9/2013
119
33
R H B - 0 2 - AV A L I A A O D E
D E S E M P E N H O D E B O L S I S TA S
Verso: 1.0
Autor: Carolina Rosa
17/9/2013
120
33.1
RHB-02-AV. DE DESEMPENHO
GERAL
Descrio
Pesquisa com gerncias e de acordo com a cultura da organizao os pontos de relevncia e
desejveis para serem avaliados
33.1.1.2
Descrio
Escolhe a escala utilizada para responder as perguntas realizadas. A escolha destas escalas direciona respostas
associando-as a uma caracterstica, o que facilitar o entendimento do respondente, um padro de respostas e mensurao
dos dados.
33.1.1.3
Descrio
Escolhe ferramenta para aplicao, (no caso o google forms) e monta perguntas e opes de respostas para gerncia de
acordo com parmetros e variveis levantadas. Cada resposta ter uma pontuao que ao fim, formar a pontuao geral
recebida, pontuao esta que refletir um conceito (mdia) geral sobre o desempenho do funcionrio.
No caso dos membros, elaborada tambm atravs da ferramenta google forms, uma solicitao de auto avaliao de
acordo com as variveis da avaliao de desempenho. A autoavaliao tambm dever conter um campo para que o
bolsista manifeste satisfaes e insatisfaes e para campo para sugestes. Link para formulrio:
33.1.1.4
Descrio
O plano de execuo, diz respeito ao modo como ela ser executada e suas fases, assim como a
tcnica utilizada para aplicao da avaliao de desempenho.
33.1.1.5
Descrio
A avaliao de desempenho deve ser divulgada para que a equipe entenda seus objetivos, utilidade e colabore com o
processo, atribuindo valor ao mesmo.
33.1.1.6
Descrio
17/9/2013
121
A definio de local essencial na medida em que o processo deve ser realizado com concentrao e sigilo. Os horrios
para realizao de AD e Auto avaliao devero ser marcados de forma coletiva, porm respondidos individualmente e em
ambiente de trabalho para que possam ser respondidos com o apoio do analista de RH e sem influncias externas.
33.1.1.7
33.1.1.8
A.D.
Descrio
Explicar papel da gerncia no processo, objetivos e como responder questionrio
33.1.1.9
33.1.1.10
33.1.1.11
Descrio
A autoavaliao essencial na medida em que no teremos dados unilaterais. Ela dever conter explicaes sobre como
responder e que pontos devero ser avaliados
33.1.1.12
Responder autoavaliao
Descrio
33.1.1.13
Descrio
A reviso dos dados coletados essencial para que algo indelicado ou que gere conflitos no seja passado adiante como
feedback. A autoavaliao dever ser um feedback construtivo para gerncias assim como a avaliao de desempenho
para os membros.
A anlise dos dois dados pelo RH gerar dados para gerncias de diferenas de viso gerencial e de membros, para que
possam entender e solucionar gaps dentro da equipe.
33.1.1.14
Enviar e-mail com autoavaliao e incoerncias para
gerncias
Descrio
17/9/2013
122
33.1.1.15
Descrio
O feedback ser o resultado obtido em avaliao, transformado em pontos a melhorar, pontos de destaque e uma frase
descrevendo de forma geral o desempenho visto em seu trabalho, junto a uma frase motivadora.
33.1.1.16
Descrio
A gerncia no dia da avaliao dever ser orientada a como proceder em caso de esclarecimentos
em relao a avaliao de desempenho. O RH estar disponvel para qualquer assessoria.
33.1.1.17
33.1.1.18
Acionar RH
Descrio
Tanto gerncias, como membros podero solicitar o RH para soluo de dvidas e conflitos.
33.1.1.19
Solucionar conflito
33.1.1.20
17/9/2013
123
34
R H B - 0 3 - AV A L I A A O D E
D E S E M P E N H O D E N O V O S B O L S I S TA S
Verso: 1.0
Autor: Carolina Rosa
17/9/2013
124
34.1
RHB-03-AV. DE DESEMPENHO
GERAL
34.1.1.2
34.1.1.3
34.1.1.4
Montar questionrios
34.1.1.5
Descrio
34.1.1.6
34.1.1.7
34.1.1.8
Descrio
Explicar objetivos e como responder a Avaliao de Desempenho
34.1.1.9
34.1.1.10
Aplicar questionrio
Responder questionrio
17/9/2013
125
34.1.1.11
34.1.1.12
34.1.1.13
Descrio
34.1.1.14
Descrio
Explicar objetivos e como responder a Avaliao de Desempenho
34.1.1.15
34.1.1.16
Realizar autoavaliao
Descrio
34.1.1.17
Dar feedback
34.1.1.18
Descrio
Membro opina sobre feedback e elabora plano de melhorias
34.1.1.19
Descrio
34.1.1.20
Descrio
RH mensura dados do feedback relacionando com dados de A.D.
17/9/2013
126
34.1.1.21
Complementar relatrio de
A. D.
34.1.1.22
Descrio
Retorna planos de melhorias e apontamentos relevantes para gerncias
34.1.1.23
Geral
34.1.1.24
Acionar PMO
17/9/2013
127
35
C E N T R A L D E AT E N D I M E N T O
Verso: 1.0
Autor: Bruno Olmpio
17/9/2013
128
35.1
CENTRAL DE ATENDIMENTO
Recebe solicitao
35.1.1.2
35.1.1.3
35.1.1.4
Resolve problema
35.1.1.5
Descrio
35.1.1.6
35.1.1.7
35.1.1.8
35.1.1.9
Atualiza o ticket
35.1.1.10
Resolve o problema
17/9/2013
129
36
RECURSOS
RHB (Funo)
O setor de Recursos Humanos de Bolsistas tem a funo de executar recrutamento e seleo de
bolsistas e controle da alocao de cada bolsista nos projetos
Lder do Projeto (Funo)
O lder a referncia de processo e metodologia da equipe. Cada equipe de desenvolvimento
precisa possuir um lder, e este o principal ponto de contato de cada equipe com o PMO. O lder
o responsvel por conduzir as reunies internas da equipe com o cliente, garantir que os
desenvolvedores possuam as condies necessrias para executar seu trabalho e remover
possveis impedimentos que surjam durante os sprints (ciclos de desenvolvimento).
Membro (Funo)
O Membro qualquer integrante do STI
PMO (Funo)
PMO a sigla em ingls para Escritrio de Gerenciamento de Projetos. Esta a equipe
responsvel pela definio e manuteno dos padres de processos e mtricas e pelo suporte ao
gerenciamento dos projetos. As principais funes do PMO so:
Gesto dos recursos compartilhados entre os projetos;
Orientao, aconselhamento, superviso e treinamento das equipes;
Coordenao da comunicao entre projetos
PO (Funo)
O Product Owner pessoa responsvel pela definio e gerenciamento das funcionalidades que
sero desenvolvidas e por garantir o valor do trabalho realizado pelo Time. Essa pessoa define em
que ordem os requisitos devem ser implementados e garante que todos saibam em que devem
trabalhar.
Ao final de cada Sprint, o product owner homologa as funcionalidades desenvolvidas pelo time.
Referncia: Scrum Guide, 02/2010
Equipe (Funo)
o grupo de desenvolvedores, que transformam os requisitos em incrementos de funcionalidades
a cada Sprint. As equipes devem ser multidisciplinares e auto-organizveis, na medida em que
devem definir como cada requisito deve ser implementado e possuir as habilidades necessrias ao
seu desenvolvimento.
17/9/2013
130