A Valiação de P Rocessos de S Oftware em Um Ambiente Da Administração Pública

C ENTRO F EDERAL DE E DUCAO T ECNOLGICA DE M INAS G ERAIS
D EPARTAMENTO DE C OMPUTAO
C URSO DE E NGENHARIA DE C OMPUTAO
AVALIAO DE P ROCESSOS DE S OFTWARE EM UM

AMBIENTE DA ADMINISTRAO PBLICA
H IGOR A UGUSTO M ADUREIRA P EREIRA
Orientadora: Prof.a Dr.a Kecia Aline Marques Ferreira

Centro Federal de Educao Tecnolgica de Minas Gerais CEFET-MG
B ELO H ORIZONTE
N OVEMBRO DE 2015
H IGOR A UGUSTO M ADUREIRA P EREIRA
AVALIAO DE P ROCESSOS DE S OFTWARE EM UM

AMBIENTE DA ADMINISTRAO PBLICA
Orientadora:
Kecia Aline Marques Ferreira

Centro Federal de Educao Tecnolgica
de Minas Gerais CEFET-MG
C ENTRO F EDERAL DE E DUCAO T ECNOLGICA DE M INAS G ERAIS

D EPARTAMENTO DE C OMPUTAO
C URSO DE E NGENHARIA DE C OMPUTAO
B ELO H ORIZONTE
N OVEMBRO DE 2015
Centro Federal de Educao Tecnolgica de Minas Gerais

Curso de Engenharia de Computao
Avaliao do Trabalho de Concluso de Curso
Aluno: Higor Augusto Madureira Pereira

Ttulo do Trabalho: Avaliao de Processos de Software em um ambiente da administrao pblica
Data da defesa: 25/11/2015
Horrio: 10:40
Local da defesa: Sala 401, Prdio 17 do CEFET-MG - Campus II
O presente Trabalho de Concluso de Curso foi avaliado pela seguinte banca:

Professora Kecia Aline Marques Ferreira Orientadora
Departamento de Computao
Professora Daniela Cristina Cascini Kupsch Membro da banca de avaliao
Professora Glvia Anglica Rodrigues Barbosa Membro da banca de avaliao
ii
Resumo
A qualidade do produto de software est diretamente ligada qualidade do processo
de desenvolvimento usado na sua produo. Neste trabalho foi realizada uma avaliao
do processo atual do Escritrio de Projetos (EP), que faz parte do CEFET-MG, com o
intuito de verificar seus pontos fracos, pontos fortes e oportunidades de melhorias. O
processo atual segue uma metodologia gil, baseada no Scrum, e a avaliao realizada
segue o modelo proposto pelo MPS.BR, sendo verificado o nvel de maturidade G.
Visando melhorar o processo atual, foi elaborado um plano de melhorias focando nos
pontos fracos e oportunidades de melhorias encontrados durante a avaliao. O plano
de melhorias proposto foi avaliado pela equipe do EP e possui o objetivo de adequar o
processo atual ao nvel de maturidade requerido.
Palavras-chave: MPS.BR; processos de software; mtodos geis; avaliao de processo;
MA-MPS.
iii
Lista de Figuras
Figura 1 Organograma da SGI . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figura 2 Abordagem conceitual para qualidade de acordo com a ISO/IEC 25010
(2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 3 Etapas principais do processo de criao do padro ISO/IEC 15504 .
Figura 4 As duas dimenses do modelo de avaliao de processos da ISO/IEC
15504 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 5 Componentes do modelo MPS . . . . . . . . . . . . . . . . . . . . . .
Figura 6 Fases e processos do SCAMPI . . . . . . . . . . . . . . . . . . . . . . .
Figura 7 Diagrama geral do processo . . . . . . . . . . . . . . . . . . . . . . . .
Figura 8 Planilha de indicadores . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 9 Plugin RedRisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 10 Plugin Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 11 Plugin Redmine Planning . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 12 Resultados da questo 1 . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
2
5
15
16
22
30
43
51
77
81
82
84
84
85
86
86
Lista de Tabelas
Tabela 1 Nveis de capacidade e atributos a serem atendidos conforme

ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabela 2 Nveis de capacidade e maturidade do CMMI . . . . . . . . . . .
Tabela 3 Nveis de maturidade do MR-MPS-SW . . . . . . . . . . . . . . .
Tabela 4 Mapeamento entre os nveis de maturidade do MR-MPS e CMMI
Tabela 5 Comparao entre MR-MPS e CMMI . . . . . . . . . . . . . . . .
Tabela 6 Atores do processo de desenvolvimento de software do EP . . .
a
. .
. .
. .
. .
. .
. .
18
20
28
34
34
42
Lista de Quadros
Quadro 1
Quadro 2
Quadro 3
Quadro 4
Quadro 5
Quadro 6
Quadro 7
Quadro 8
Quadro 9
Quadro 10
Quadro 11
Quadro 12
Quadro 13
Quadro 14
Quadro 15
Quadro 16
Quadro 17
Quadro 18
Quadro 19
Quadro 20
Quadro 21
Quadro 22
Quadro 23
Quadro 24
Quadro 25
Quadro 26
Quadro 27
Quadro 28
Quadro 29
Quadro 30
Quadro 31
Quadro 32
Quadro 33
Quadro 34
Quadro 35
Quadro 36
Modelo de qualidade da ISO 25010 . . . . . . . . . . . . . . . . . . .

Itens para descrio de uma tarefa . . . . . . . . . . . . . . . . . . .
Projetos executados no EP . . . . . . . . . . . . . . . . . . . . . . . .
Tabela com orientao de tempo e composio da equipe de avaliao
Equipe de avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Colaboradores no projeto . . . . . . . . . . . . . . . . . . . . . . . . .
Cronograma geral da avaliao . . . . . . . . . . . . . . . . . . . . .
Cronograma das atividades da avaliao . . . . . . . . . . . . . . . .
Evidncias GPR 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GPR 19 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias RAP 1 - Gerncia de Projetos . . . . . . . . . . . . . . . .
vi
6
32
47
48
48
49
49
49
53
54
54
55
55
56
57
57
58
59
59
60
60
61
61
62
62
63
63
64
64
65
65
66
66
66
67
67
Quadro 37
Quadro 38
Quadro 39
Quadro 40
Quadro 41
Quadro 42
Quadro 43
Quadro 44
Quadro 45
Quadro 46
Quadro 47
Quadro 48
Quadro 49
Quadro 50
Quadro 51
Quadro 52
Quadro 53
Quadro 54
Quadro 55
Evidncias RAP 10 - Gerncia de Projetos . . . . . . . . . . . . . . .

Evidncias GRE 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GRE 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GRE 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GRE 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias GRE 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evidncias RAP 1 - Gerncia de Requisitos . . . . . . . . . . . . . . .
Evidncias RAP 10 - Gerncia de Requisitos . . . . . . . . . . . . . .
Relao de pontos fortes, pontos fracos e oportunidades de melhorias
Modelo para descrio dos papis . . . . . . . . . . . . . . . . . . . .
Modelo para o mapa de perfis . . . . . . . . . . . . . . . . . . . . . .
vii
68
68
68
69
69
70
70
71
71
71
72
72
73
73
73
74
75
79
79
Lista de Abreviaturas e Siglas
AP
Atributos de Processos
BI
Business Intelligence
CEFET-MG
CMM
Capability Maturity Model
CMMI
Capability Maturity Model Integration
CMMI-DEV
CMMI para desenvolvimento
CMMI-ACQ
CMMI para aquisio
CMMI-SVC
CMMI para servios
DG
Diretoria Geral
DIS
Diviso de Sistemas
DITIC
Diviso de Infraestrutura de Tecnologia da Informao e Comunicao
EP
Escritrio de Projetos
ISO
International Organization for Standardization
MA-MPS
Mtodo de Avaliao MPS
MN-MPS
Modelo de Negcios MPS
MPS.BR
Melhoria de Processos do Software Brasileiro
MPS-RH
Modelo MPS Gesto de Pessoas
MR-MPS
Modelo de Referncia para Melhoria de Processo de Software
MR-MPS-SW
Modelo de Referncia MPS para Software
MR-MPS-SV
Modelo de Referncia MPS para Servios
PME
Pequenas e mdias empresas
RAP
Resultados esperados de Atributos de Processos
RUP
Rational Unified Process

viii
SBTIC
Subsecretaria de Tecnologia da Informao e Comunicao
SCAMPI
Standard CMMI Appraisal Method for Process Improvement
SEAU
Setor de Atendimento ao Usurio
SEI
Software Engineering Institute
SGI
Secretaria de Governana da Informao
SPICE
Software Process Improvement and Capability dEtermination
SQuaRE
Software Product Quality Requirements and Evaluation
ix
Sumrio
1 Introduo . . . . . . . . . . . . .
1.1 A SGI . . . . . . . . . . . . .
1.2 Problema . . . . . . . . . . .
1.3 Objetivos . . . . . . . . . . .
1.3.1 Objetivo Geral . . . .
1.3.2 Objetivos Especficos
1.4 Organizao do trabalho . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
3
3
3
2 Referencial terico . . . . . . . . . . . . .
2.1 Qualidade de software . . . . . . . .
2.2 Qualidade de processo . . . . . . . .
2.3 ISO 15504 . . . . . . . . . . . . . . . .
2.4 CMMI . . . . . . . . . . . . . . . . . .
2.4.1 Nveis de capacidade . . . . .
2.4.2 Nveis de maturidade . . . .
2.5 MPS.BR . . . . . . . . . . . . . . . . .
2.5.1 Arquitetura MPS.BR . . . . .
2.5.2 Nveis do MR-MPS-SW . . .
2.6 Mtodos de avaliao de processos .
2.6.1 SCAMPI . . . . . . . . . . . .
2.6.2 MA-MPS . . . . . . . . . . . .
2.6.3 Mtodo a ser aplicado no EP .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
10
15
19
20
20
21
21
22
29
29
31
33
3 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Prodabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Prodemge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
36
37
4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Reviso bibliogrfica . . . . . . . . . . . . . . . . . . . . . .
4.2 Definio do modelo e mtodo a ser utilizado . . . . . . . .
4.3 Levantamento do processo atual . . . . . . . . . . . . . . .
4.4 Definio do nvel de maturidade a ser avaliado . . . . . .
4.5 Avaliao da capacidade atual dos processos . . . . . . . .
4.6 Avaliao dos resultados e definio de plano de melhorias
4.7 Avaliao do plano de melhorias . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
39
39
39
39
39
39
40
40
5 Avaliao do Processo de Software no EP . . . . . . . . . . . . . . . . . . . . .
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.1
5.2
5.3
5.4
Processo de software do EP . . . . . . . . . . . . . . . . . .
5.1.1 Levantamento do processo atual . . . . . . . . . . .
5.1.2 Metodologia de desenvolvimento . . . . . . . . . . .
Planejamento da avaliao . . . . . . . . . . . . . . . . . . .
5.2.1 Definio do nvel a ser avaliado . . . . . . . . . . .
5.2.2 Seleo de projetos . . . . . . . . . . . . . . . . . . .
5.2.3 Definio da equipe de avaliao . . . . . . . . . . .
5.2.4 Cronograma geral . . . . . . . . . . . . . . . . . . . .
Avaliao inicial . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Treinamento da equipe . . . . . . . . . . . . . . . . .
5.3.2 Planilha de indicadores . . . . . . . . . . . . . . . . .
5.3.3 Verificao dos indicadores de implementao . . .
5.3.4 Pontos fortes, fracos e oportunidades de melhorias
Consideraes . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Plano de melhorias . . . . . . . . . . . . . . . . . . . . . .
6.1 Atividade 1: Gerenciamento de riscos . . . . . . . .
6.1.1 Ferramentas utilizadas . . . . . . . . . . . . .
6.1.2 Artefatos produzidos . . . . . . . . . . . . .
6.1.3 Resultados esperados atendidos . . . . . . .
6.1.4 Restries para implantao . . . . . . . . . .
6.2 Atividade 2: Anlise de complexidade das tarefas .
6.3 Atividade 3: Gerenciamento dos recursos humanos
6.4 Atividade 4: Anlise de viabilidade . . . . . . . . . .
6.5 Atividade 5: Melhorias no planejamento da sprint .
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
44
45
45
46
46
48
50
50
50
51
74
74
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
76
76
76
76
76
77
77
78
78
78
78
78
79
79
79
79
79
80
80
80
80
80
81
82
82
6.5.4 Restries para implantao . . . . . . . . . . . . . . . . . . . . . .

Avaliao do plano de melhorias . . . . . . . . . . . . . . . . . . . . . . .
82
82
7 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
88
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
6.6
xii
1 Introduo
Desenvolvimento de software um processo no qual o conhecimento, que

dever torna-se o software, coletado, reunido e incorporado ao software (PRESSMAN,
2011). Durante o desenvolvimento de software, so executadas diversas atividades
necessrias para a realizao do produto final. Essas atividades podem ser agrupadas em
processos que, de modo geral, definem os passos utilizados para o seu desenvolvimento
(ANACLETO, 2004).
Segundo Pressman (2011), processo de software uma metodologia para as
atividades que so necessrias para a construo de software de alta qualidade. Essa
qualidade determinada pela rea denominada de Qualidade de Software que, segundo
Wazlawick (2013), visa garantir bons produtos a partir de bons processos.
A qualidade do produto de software, ento, est fortemente ligada qualidade
do processo utilizado para sua produo. Alcanar um bom processo pode auxiliar
na produo de softwares cada vez melhores, produzidos em um menor tempo e com
um custo mais baixo. Visando uma maior produtividade e vantagens competitivas nos
mercados internos e externos, as organizaes tm se empenhado em busca da melhoria
de processo de software (ANACLETO, 2004).
A Norma ISO/IEC 15504 (2008) veio como complementao da ISO/IEC 12207
(2008) com o objetivo de orientar a realizao de avaliaes de processos nas empresas,
levantando seus pontos fortes e fracos e nveis de maturidade, culminando na elaborao de um plano de melhorias para os processos. Em conformidade com a ISO/IEC
15504 surgiram diversos modelos e mtodos de avaliao para melhoria de processo de
software, tais como, o MR-MPS (SOFTEX, 2012) e o CMMI (CMMI-INSTITUTE, 2014a).
1.1
A SGI
O Centro Federal de Educao Tecnolgica de Minas Gerais (CEFET-MG)

uma instituio pblica federal de ensino. A Secretaria de Governana da Informao
a unidade organizacional vinculada Diretoria Geral (DG) do CEFET-MG que
responsvel por elaborar, coordenar, avaliar e planejar as polticas dos recursos de
tecnologia da informao e do desenvolvimento de projetos, sistemas e tecnologias para
a gesto da informao institucional (CD-049, 2012). Fazem parte da SGI o Escritrio
de Projetos, a Subsecretaria de Tecnologia da Informao e Comunicao(SBTIC), a
Diviso de Sistemas (DIS), a Diviso de Infraestrutura de Tecnologia da Informao e
Comunicao (DITIC) e o Setor de Atendimento ao Usurio (SEAU). A Figura 1 define
o organograma da SGI de acordo com a resoluo do CEFET-MG CD-049.
Captulo 1. Introduo
Figura 1 Organograma da SGI
O Escritrio de Projetos, ao qual est vinculado o autor do presente trabalho

com o cargo de Tcnico em Tecnologia da Informao, a unidade organizacional
responsvel por elaborar e executar os projetos, sistemas e tecnologias de gesto da
informao que daro suporte as aes estratgicas definidas pela SGI (CD-049, 2012).
1.2
Problema
O EP, nos ltimos anos, tem vivenciado um aumento elevado em relao ao

nmero de demandas feitas pela comunidade. Isso ocorre devido ao crescimento da
instituio, em nmero de cursos e de funcionrios. O quadro de servidores do EP, por
exemplo, teve um aumento considervel nos ltimos dois anos, passando de quatro
servidores para doze, no incio desse ano.
Diante desse cenrio, surge a necessidade de implantao de melhorias do
processo de desenvolvimento de software da equipe, visto que ele no capaz de
satisfazer a demanda atual.
Neste trabalho, apresentado o estado da arte com os modelos e mtodos
existentes que seguem a ISO/IEC 15504, analisando suas especificidades a fim de
identificar o modelo e o mtodo que melhor se adaptam ao ambiente alvo do nosso
estudo de caso: o Escritrio de Projetos (EP) vinculado Secretaria de Governana da
Informao (SGI) CEFET-MG, responsvel pelo desenvolvimento e implantao de
sistemas de informao na instituio. Definido o modelo e o mtodo a serem utilizados,
Captulo 1. Introduo
foi realizada a anlise dos processos atuais e definido um plano de melhorias de

processo de desenvolvimento de software para o EP.
1.3
1.3.1
Objetivos
Objetivo Geral
O objetivo geral deste projeto avaliar os processos de software atuais do EP,

utilizando um mtodo conforme a norma ISO/IEC 15504, a fim de traar um plano de
melhorias para o processo de software aplicado no EP.
1.3.2
Objetivos Especficos
So objetivos especficos deste trabalho:
Realizar uma reviso bibliogrfica sobre os modelos e mtodos de avaliao de

processos de software que atendem a ISO/IEC 15504.
Definir o modelo e o mtodo a ser utilizado na conduo do trabalho, a partir das
anlises resultantes da reviso da literatura.
Fazer o levantamento do processo atual do EP.
Definir o nvel de maturidade a ser utilizado na avaliao do processo de software.
Avaliar a capacidade atual dos processos selecionados.
Analisar os resultados e definir plano de melhorias.
Avaliar o plano de melhorias proposto.
1.4
Organizao do trabalho
O restante deste documento est organizado da seguinte forma: o Captulo 2

descreve conceitos relacionados a qualidade de software, as normas e modelos de qualidade de processo de software; o Captulos 3 discute os principais trabalhos relacionados;
o Captulo 4 descreve a metodologia aplicada na conduo do trabalho; o Captulo 5
apresenta a avaliao realizada neste trabalho a respeito do processo atual aplicado no
EP; o Captulo 6 apresenta o plano de melhorias proposto para o processo de software
do EP, bem como sua avaliao; o Captulo 7 traz as concluses deste trabalho.
2 Referencial terico
Neste captulo, so apresentados os principais conceitos que so aplicados neste

trabalho: qualidade de software e qualidade de processo.
2.1
Qualidade de software
O uso de sistemas de software tem se tornado cada vez mais frequente e o

funcionamento correto desses sistemas crucial para o sucesso das empresas que os
empregam. Desenvolver produtos de software de qualidade , portanto, um requisito de extrema importncia. Ter uma especificao detalhada e realizar avaliaes
dos softwares a chave para o sucesso. Para alcanarmos o objetivo de produo de
softwares melhores, podemos definir algumas caractersticas de qualidade levando em
considerao seus objetivos (ISO/IEC 25000, 2014).
A ISO/IEC 25000: Software Engineering: Software Product Quality Requirements and
Evaluation (SQuaRE) foi criada para unir as normas ISO/IEC 9126 (Software Product
Quality) e ISO/IEC 14598 (Software Product Evaluation) que definiam tais caractersticas
de qualidade de forma complementar, mas, por possuir ciclos de vida independentes,
apresentavam algumas divergncias.
O modelo SQuaRE possui cinco divises:
a) ISO/IEC 2500n Diviso Gesto da Qualidade
b) ISO/IEC 2501n Diviso Modelo de Qualidade
c) ISO/IEC 2502n Diviso Medio da Qualidade
d) ISO/IEC 2503n Diviso Requisitos de Qualidade
e) ISO/IEC 2504n Diviso Avaliao da Qualidade
A diviso de modelo de qualidade, conforme indicado pela Figura 2, fornece
caractersticas de qualidade internas, externas e de uso. As qualidades internas auxiliam
a equipe de desenvolvimento a alcanar seus objetivos de forma eficiente. As qualidades
externas permitem que o usurio final do sistema alcance seus objetivos. Defende-se
que a qualidade do processo influencia a qualidade interna, que influencia a qualidade
externa, que, finalmente, influencia a qualidade de uso (WAZLAWICK, 2013).
A ISO/IEC 25010 define dois tipos de qualidade: qualidade de produto e qualidade de uso. Cada tipo de qualidade possui vrias caractersticas distribudas hierar-
Captulo 2. Referencial terico
Figura 2 Abordagem conceitual para qualidade de acordo com a ISO/IEC 25010 (2011)
Fonte: (WAZLAWICK, 2013)
quicamente, sendo oito caractersticas de maior nvel para qualidade de produto e cinco
para qualidade de uso.
O Quadro 1 mostra as caractersticas fundamentais definidas pela norma ISO/IEC
25010. Cada umas dessas caractersticas contribui para a produo de um software de
melhor qualidade. A seguir, explicamos, de acordo com a ISO 25010, cada uma dessas
caractersticas brevemente.
Caractersticas do produto:
1. Adequao funcional: o grau com que o produto ou sistema satisfaz as necessidades explcitas e implcitas quando usado sob condies especificadas. Possui
trs subcaractersticas:
a) Completude funcional : indica se a lista de funes fornecidas pelo software
cobre todas as tarefas especificadas e os objetivos do usurio.
b) Corretude funcional: avalia se os resultados fornecidos so corretos de acordo
com a necessidade de preciso.
c) Funcionalidade apropriada: indica o grau com que as funes facilitam o
cumprimento das tarefas e objetivos do sistema.
2. Confiabilidade: refere-se ao comportamento de um software ou sistema durante
a execuo de determinadas funes sob condies especificadas durante determinado perodo de tempo. Um software confivel aquele que se mantm
consistente com o esperado nessa condies (WAZLAWICK, 2013). Possui quatro
subcaractersticas:
a) Maturidade: indica o grau com que o produto ou sistema satisfaz as necessidade de confiabilidade sob condies normais.
Quadro 1 Modelo de qualidade da ISO 25010
Tipo
Caractersticas
do produto
Caractersticas
do uso
Fonte: adaptado de Wazlawick (2013)

Caractersticas
Subcaractersticas
Completude funcional
Corretude funcional (Acurcia)
Adequao funcional
Funcionalidade apropriada
Maturidade
Disponibilidade
Confiabilidade
Tolerncia a falhas
Recuperabilidade
Apropriao reconhecvel
Inteligibilidade
Operabilidade
Usabilidade
Proteo contra erro de usurio
Esttica de interface com usurio
Acessibilidade
Comportamento em relao ao tempo
Utilizao de recursos
Eficincia de desempenho
Capacidade
Confidencialidade
Integridade
No repdio
Segurana
Rastreabilidade de uso
Autenticidade
Coexistncia
Compatibilidade
Interoperabilidade
Modularidade
Reusabilidade
Capacidade de manuteno Analisabilidade
Modificabilidade
Testabilidade
Adaptabilidade
Instalabilidade
Portabilidade
Substituibilidade
Efetividade
Efetividade
Eficincia
Eficincia
Utilidade
Prazer
Satisfao
Conforto
Confiana
Mitigao de risco econmico
Mitigao de risco a sade e segurana
Uso sem riscos
Mitigao de risco ambiental
Completude de contexto
Cobertura de contexto
Flexibilidade
b) Disponibilidade: grau com que o produto ou sistema est disponvel e funcionando quando requisitado para uso.
c) Tolerncia a falhas: avalia se o produto ou sistema funciona como esperado
apesar da existncia de falhas de software ou hardware.
d) Recuperabilidade: grau com que o produto ou sistema capaz de recuperar
os seus dados aps uma falha.
2. Usabilidade: avalia o grau com que o produto ou sistema pode ser usado por
determinados usurios para concluir seus objetivos com efetividade, eficincia e
satisfao quando usados sob condies especificadas. Possui seis subcaractersticas:
a) Apropriao reconhecvel: indica o grau com que os usurios podem reconhecer se o produto ou sistema apropriado para suas necessidades.
b) Inteligibilidade: grau com que o produto ou sistema pode ser usado por
determinado usurio de forma que possa aprender a us-lo com efetividade,
eficincia, livre de riscos e com satisfao.
c) Operabilidade: indica o grau com que o produto ou sistema possui atributos
que o torna fcil de usar e controlar.
d) Proteo contra erro de usurio: avalia como o sistema protege os usurio de
cometerem erros.
e) Esttica de interface com usurio: indica o grau com que a interface do
usurio permite agradar e satisfazer a interao com o usurio.
f) Acessibilidade: avalia o grau com que o produto ou sistema pode ser usado
por usurios com caractersticas e capacidades das mais diversas.
3. Eficincia de Desempenho: est relacionada otimizao do uso de recursos, que
podem ser outros softwares, hardwares ou outros materiais como, por exemplo,
papis. Possui trs subcaractersticas:
a) Comportamento em relao ao tempo: leva em considerao o tempo de
resposta e processamento das funes do sistema.
b) Utilizao de recursos: relacionado utilizao dos recursos como espao
de armazenamento ou memria. comum ter que sacrificar a eficincia de
recursos para obter eficincia de tempo e vice-versa.
c) Capacidade: indica o grau com que os limites mximos do produto ou parmetros do sistema satisfazem os requisitos.
4. Segurana: est relacionada capacidade do produto ou sistema em proteger seus

dados e informaes de modo que outros usurios ou sistemas somente tenham
acesso de acordo com seu nvel de autorizao. Possui cinco subcaractersticas:
a) Confidencialidade: indica se o produto ou sistema garante que os dados
podem ser acessados apenas por usurios ou sistemas autorizados.
b) Integridade: indica se o produto ou sistema impede o uso no autorizado de
forma que possa modificar seus dados.
c) No repdio: indica o grau com que as aes e funes executadas no sistemas
podem ser provadas que foram realmente executadas, de tal forma que no
possam ser negadas futuramente.
d) Rastreabilidade de uso: indica o grau com que possvel rastrear as aes
realizadas por uma pessoa ou sistema para comprovar que foram realizadas
unicamente por essa pessoa ou sistema.
e) Autenticidade: indica se a identidade de uma pessoa ou recurso pode ser
provada aquela que se diz ser.
5. Compatibilidade indica o grau com que um produto ou sistema consegue trocar
informaes com outros produtos ou sistemas e executar suas funes enquanto
divide o mesmo ambiente e hardware. Possui duas subcaractersticas:
a) Coexistncia: indica o grau com que o produto ou sistema capaz de executar as suas funes de forma eficiente enquanto compartilha o ambiente e
recursos com outros produtos ou sistemas, sem impacto negativo nos demais
produtos.
b) Interoperabilidade: indica o grau com que dois ou mais produtos ou sistemas
podem interagir entre si, trocando informaes.
6. Capacidade de Manuteno: indica o grau com que o produto ou sistema pode
ser modificado com efetividade e eficincia pelos seus mantenedores. Essa modificaes podem ser correes, melhorias ou adaptaes. Possui cinco subcaractersticas:
a) Modularidade: indica o grau com que o produto ou sistema composto por
componentes, de tal forma que uma mudana em um componente tem o
mnimo de impacto nos outros.
b) Reusabilidade: indica o grau com que partes do sistema podem ser reutilizadas em outros sistemas.
c) Analisabilidade: indica o grau com que possvel avaliar o impacto de uma
mudana em um produto ou sistema, ou diagnosticar as causas de erros ou
falhas.
d) Modificabilidade: indica o grau de facilidade de um produto ou sistema ser

modificado sem introduzir defeitos ou prejudicar outros sistemas. Modularidade e analisabilidade colaboram para uma maior modificabilidade.
e) Testabilidade: indica o grau de facilidade de serem criados e executados
testes para um produto ou sistema.
7. Portabilidade indica o grau de facilidade de um produto ou sistema ser transferido
de um ambiente ou hardware para outro. Possui trs subcaractersticas:
a) Adaptabilidade: indica o grau de facilidade do produto ou sistema de se
adaptar no novo ambiente.
b) Instalabilidade: indica o grau de facilidade de um produto ou sistema ser
instalado ou desinstalado em um ambiente especfico.
c) Substituibilidade: indica o grau com que um produto ou sistema pode substituir outro com as mesmas funes no mesmo ambiente.
Caractersticas do uso:
1. Efetividade: avalia se possvel aos usurios alcanar seus objetivos de forma
correta e completa.
2. Eficincia: a relao entre os recursos gastos pelo usurio e o que o produto ou
sistema fornece.
3. Satisfao: avalia o grau com que as necessidades do usurio so satisfeitas quando
o produto ou sistema utilizado no seu ambiente final. Possui quatro subcaractersticas:
a) Utilidade: indica o grau com que o usurio satisfeito com a obteno percebida de metas pragmticas, incluindo os resultados e consequncias de
uso.
b) Prazer: indica o grau com que o usurio sente prazer ao utilizar o produto
ou sistema para alcanar seus objetivos.
c) Conforto: indica o grau com o usurio est satisfeito em relao ao seu
conforto fsico ao usar o produto ou sistema.
d) Confiana: indica o grau com que o usurio possui confiana que o produto
ou software ir se comportar da forma esperada.
4. Uso sem riscos: indica o grau de capacidade do produto ou software de minimizar
os riscos econmicos, de sade e ambiental. Possui trs subcaractersticas:
10
a) Mitigao de risco econmico: indica o grau com que o produto ou software

minimiza os riscos financeiros, incluindo danos propriedades e reputao
de pessoas.
b) Mitigao de risco sade e segurana: indica o grau com que o produto
ou software minimiza os riscos s pessoas em seu contexto de uso.
c) Mitigao de risco ambiental: indica o grau com que o produto ou software
minimiza os riscos propriedade ou ambiente em seu contexto de uso.
5. Cobertura de contexto: indica o grau com que o produto ou sistema pode ser
usado com efetividade, eficincia, satisfao e livre de riscos tanto no contexto de
uso especificado como em outros contextos. Possui duas subcaractersticas:
a) Completude de contexto: indica o grau com que o produto ou sistema pode
ser usado com efetividade, eficincia, satisfao e livre de riscos no contexto
especificado inicialmente.
b) Flexibilidade: indica o grau com que o produto ou sistema pode ser usado
com efetividade, eficincia, satisfao e livre de riscos em outros contextos
alm do especificado inicialmente.
2.2
Qualidade de processo
A qualidade do produto de software est ligada qualidade do processo que o

gera (WAZLAWICK, 2013). Portanto, investir na qualidade do processo tem se tornado
uma prtica cada vez mais comum.
Como guia para melhoria do processo de software, foi criada a ISO/IEC 90003
(2014), verso mais atual da ISO/IEC 9000-3 (1997), que um guia para aplicao
da (ISO/IEC 9001, 2008) no contexto de software. Nela so definidas padres para
gerenciamento e garantia da qualidade do processo de desenvolvimento, fornecimento,
aquisio, operao e manuteno de software.
A aplicao das normas da famlia 9000 pode ser dividida em gesto da qualidade e garantia da qualidade, sendo a primeira uma filosofia que deve ser empregada
em todos os setores da empresa e a segunda uma forma de assegurar ao cliente que a
empresa possui capacidade de atender aos requisitos de qualidade em seus processos e
produtos.
Umas das correes feitas na ISO 90003 foi adio de aspectos como melhoria
de processos de software, que era uma das limitaes da antiga norma ISO 9000-3. A
seguir, listaremos alguns requisitos e orientaes de acordo com a ISO 90003:
1. Requisitos e orientaes sistmicos
11
So divididos em duas partes:

a) Estabelecer um sistema de gerenciamento de qualidade para produtos de
software: identificar e descrever os processos da empresa que fazem parte do
sistema de qualidade (desenvolvimento, planejamento do desenvolvimento,
planejamento da qualidade, operao e manuteno), gerenciar, dar suporte,
monitorar, mensurar e melhorar a efetividade dos processos estabelecidos.
b) Documentar o sistema de qualidade orientado ao software: desenvolver
os documentos que implementam o sistema de qualidade, descrever os
processos de software e os modelos de ciclo de vida; preparar um manual dos
sistema para documentar os procedimentos, interao dos processos, escopo
do sistema de qualidade e justificar suas excluses e redues; controlar os
documentos de gerenciamento de qualidade, aprovando-os antes de distribulos, fornecendo verses corretas, prevenindo o uso de documentos obsoletos
e preservando a usabilidade dos documentos de qualidade.
2. Requisitos e orientaes de gerenciamento
So divididos em seis partes:
a) Suporte qualidade: promover a importncia da qualidade, promovendo
a necessidade de satisfazer aos requisitos do cliente e produto de software;
desenvolver, implementar e aperfeioar o sistema de gerenciamento da qualidade, dando suporte ao desenvolvimento da qualidade do sistema, criando
polticas de qualidade, definindo objetivos, provendo os recursos necessrios,
encorajando as pessoas a satisfazer os requisitos de qualidade do sistema e
realizando revises do sistema de gerenciamento da qualidade.
b) Foco no cliente: identificar, satisfazer e melhorar os requisitos do cliente.
importante certificar-se que a empresa ser capaz de realizar essas tarefas.
c) Estabelecer a poltica de qualidade: definir a poltica de qualidade, certificandose que ela atende aos propsitos da empresa, satisfaz os requisitos e facilita o
desenvolvimento dos objetivos da qualidade; revisar e publicar para toda a
empresa poltica definida.
d) Realizar o planejamento da qualidade: formular os objetivos da qualidade
para todas as reas e nveis da empresa; planejar o desenvolvimento do
sistema de gerenciamento da qualidade e aperfeioar a efetividade desse
sistema.
e) Controlar o sistema de qualidade: definir, documentar e comunicar as responsabilidades e autoridades; indicar um representante da gerncia que deve
supervisionar e dar suporte a manuteno do sistema de gerenciamento da
12
qualidade; suportar a comunicao interna, certificando-se que o processo de

comunicao est estabelecido e ocorre em toda empresa.
f) Realizar revises de gerenciamento: revisar o sistema de gerenciamento
da qualidade, planejar revises regulares, avaliar a efetividade, manter um
registro das revises; examinar as entradas para as revises de gerenciamento, resultados das auditorias, oportunidades de melhorias, feedback dos
clientes , conformidade dos dados do produto de software, informaes de
performance do processo, aes corretivas e preventivas e revises de gerenciamento da qualidade j feitas; gerar sadas das revises de gerenciamento
contendo aes para melhoria da efetividade do sistema de qualidade e o
prprio produto de software, alm de tratar as necessidades de recursos.
3. Requisitos e orientaes relacionados a recursos
So divididos em quatro partes:
a) Recursos de qualidade: identificar os recursos necessrios para suportar seu
sistema de qualidade, satisfazer os requisitos do cliente e os requisitos regulatrios; proporcionar recursos necessrios para dar suporte, implementar e
melhorar o sistema de qualidade.
b) Pessoal de qualidade: certificar que o pessoal possui a experincia, educao,
treinamento e habilidades corretas; dar suporte e definir os nveis aceitveis de competncia, identificar e avaliar as necessidades de treinamento e
conscientizao da empresa e manter um registro de competncias.
c) Infraestrutura de qualidade: identificar, fornecer e manter a infraestrutura
necessria para desenvolver o software, tais como hardware, software e
instalaes, alm de ferramentas necessrias para desenvolver, suportar,
proteger e controlar o software.
d) Ambiente de qualidade: identificar, implementar e gerenciar o ambiente de
trabalho necessrio.
4. Requisitos e orientaes para realizao de projetos
So divididos em seis partes:
a) Controle do planejamento da realizao de produtos de software: planejar os
processos de realizao de produtos de software, identificando os requisitos
e objetivos da qualidade do software, requisitos e necessidades da realizao
do produto, requisitos de gerenciamento de riscos e manuteno de registros;
desenvolver os processos de realizao do produto, contendo os documentos,
sistema de manuteno de registros e mtodos para controle da qualidade;
13
usar modelos de ciclo de vida para planejar o trabalho, deve-se selecionar

os modelos de ciclo de vida adequados para planejar as tarefas, atividades
e processos; planejar como ser aplicado o sistema de gerenciamento da
qualidade no desenvolvimento dos produtos de software e em cada projeto
de software.
b) Controle de processos de cliente: identificar e revisar os requisitos do produto de software do cliente; comunicar com seus clientes e desenvolver um
processo para controlar essa comunicao, programar revises durante o
desenvolvimento junto ao cliente para discutir dvidas, contratos, termos
aditivos e progresso.
c) Controle de projeto de software e desenvolvimento: deve-se planejar o design e o desenvolvimento do produto, definindo os estgios, procedimentos,
responsabilidades e autoridades necessrias; definir as entradas e gerar as
sadas do projeto e desenvolvimento do produto; realizar revises, verificaes, validaes e gerenciar as mudanas no design e no desenvolvimento
do software.
d) Controle da funo de compras: controlar o processo de compras de software, partes e componentes; documentar as compras realizadas e verificar os
produtos que foram comprados, verificando se atendem aos requisitos.
e) Gerenciamento da produo e fornecimento de servios: controlar e validar
a produo e o fornecimento de servios; identificar e acompanhar seus
produtos; proteger propriedades fornecidas pelos clientes; preservar seus
produtos e componentes.
f) Controle dos dispositivos de monitoramento: identificar as necessidades de
monitoramento e medio; selecionar os dispositivos capazes de suprir essa
necessidades; calibrar os dispositivos comparando-os com padres nacionais
e internacionais e gravar os resultados dessa calibrao; proteger os dispositivos de ajustes no autorizados e contra danos ou deteriorao; validar os
dispositivos antes de us-los e, por fim, us-los para garantir que seu produto
satisfaz os requisitos.
5. Requisitos e orientaes para aes corretivas
So divididos em cinco partes:
a) Executar processos corretivos: planejar e implementar os processos corretivos,
utilizando monitoramento, medio e processos analticos para demonstrar
conformidade e definir como sero utilizados esses processos para manter e
melhorar a qualidade do sistema de gerenciamento da qualidade.
14
b) Monitorar e medir a qualidade: monitorar e medir a satisfao do cliente; planejar e realizar auditorias internas regularmente e estabelecer um programa
de auditoria; monitorar e medir a qualidade dos processos e caractersticas
do produto.
c) Controlar a no conformidade dos produtos de software: estabelecer um
procedimento, identificar, controlar e verificar a no conformidade de produtos de software; controlar produtos de software no conformes aps entrega
ou uso; manter o registro de produtos de software que no apresentarem
conformidade.
d) Analisar as informaes da qualidade: definir necessidades de informao
de gerenciamento da qualidade; coletar dados do sistema de gerenciamento
da qualidade; fornecer informaes de gerenciamento da qualidade.
e) Realizar aes corretivas necessrias: manter o sistema de gerenciamento
da qualidade; corrigir as no conformidades atuais; prevenir potenciais no
conformidades.
2.3
15
ISO 15504
A norma ISO/IEC 15504 (2008) teve seu inicio em 1992 com a criao de um
grupo de estudos para investigar necessidades e requisitos para um padro internacional de avaliao de processo de software. Em 1993 foi estabelecido pela ISO/IEC o
projeto SPICE (Software Process Improvement and Capability dEtermination) que cerca de
dez anos depois se tornou a ISO/IEC 15504 (ROUT et al., 2007). Por isso, a norma ficou
conhecida como SPICE. A Figura 3 mostra as etapas desse processo de criao da norma.
Recentemente a norma foi revisada pela ISO/IEC 33001 (2015) que a reorganizou entre
a srie de normas da famlia 330xx.
Figura 3 Etapas principais do processo de criao do padro ISO/IEC 15504
Fonte: (SILVA, 2007)
A principal caracterstica do projeto SPICE foi o conceito de avaliao de processos de software a partir de uma comparao com um modelo de processo, que atende
os critrios para serem executados levando em considerao a qualidade, custo e metas
de cronograma (ROUT et al., 2007).
Uma avaliao de processo de software , portanto, uma investigao e uma
anlise de processos selecionados em uma unidade organizacional em comparao com
um modelo de referncia de avaliao. Um modelo de avaliao possui duas dimenses,
como mostra a Figura 4:
1. Dimenso de processos: o domnio de aplicao do modelo, ou seja, quais
16
processos sero avaliados.

2. Dimenso de capacidades: determina a capacidade de cada processo individualmente.
Figura 4 As duas dimenses do modelo de avaliao de processos da ISO/IEC 15504
Fonte: (SILVA, 2007)
A dimenso de processos varivel pois o SPICE permite a incluso de novos

modelos de processo, o que de fato o torna bastante flexvel. A seguir listaremos as
cinco principais categorias, que esto de acordo com a ISO/IEC 12207:
1. CUS: cliente/fornecedor, que incluem:
CUS.1: aquisio de software;
CUS.2: gerenciamento das necessidades do cliente;
CUS.3: fornecimento de software;
CUS.4: operao de software;
CUS.5: fornecimento de servio ao usurio.
2. ENG: processos de engenharia, que incluem:
ENG.1: desenvolvimento de requisitos do sistema e do projeto;
17
ENG.2: desenvolvimento dos requisitos do software;

ENG.3: desenvolvimento do projeto do software;
ENG.4: implementao do projeto do software;
ENG.5: integrao e teste do software;
ENG.6: integrao e teste do sistema;
ENG.7: manuteno do sistema e do software.
3. SUP: processos de suporte, que incluem:
SUP.1: desenvolvimento de documentao;
SUP.2: gerenciamento de configurao;
SUP.3: assegurar qualidade;
SUP.4: verificar o produto do trabalho;
SUP.5: validar o produto do trabalho;
SUP.6: revisar conjuntamente;
SUP.7: realizar auditorias;
SUP.8: resolver problemas.
4. MAN: processos de gerncia, que incluem:
MAN.1: gerenciamento do projeto;
MAN.2: gerenciamento da qualidade;
MAN.3: gerenciamento de riscos;
MAN.4: gerenciamento de subcontratados.
5. ORG: processos de organizao, que incluem:
ORG.1: engenharia de negcio;
ORG.2: definio dos processos;
ORG.3: melhoria dos processos;
ORG.4: fornecimento de recursos humanos capacitados;
ORG.5: fornecimento de infraestrutura de engenharia de software.
Cada um dos diversos processos listados, dentro das cinco categorias, podem ser
classificados de acordo com seis nveis de capacidade, conforme descrito na Tabela 1.
Para determinar em qual nvel de capacidade o processo se encontra, necessrio
avaliar tambm os atributos de processos (AP). Esses atributos so avaliados de acordo
com a seguinte escala:
18
Tabela 1 Nveis de capacidade e atributos a serem atendidos conforme a ISO/IEC

15504
Nvel
Classificao e
descrio sumria
do Processo
Incompleto:
processo no executado, falho
na obteno de resultados
Executado:
processo desempenhado informalmente,
sem planejamento e controle
Gerenciado:
processo planejado econtrolado
Estabelecido:
processo bem definido e processo
padro documentado
Previsvel:
processo mensurado,com predio e
medio quantitativas
Em Otimizao:
processo em melhoria contnua
Atributos de Processos (AP)

Nenhum Atributo de Processo
especificado
Atributo de execuo de processo
(AP 1.1)
AP do nvel 1 (AP 1.1) +
Atributo de gesto de execuo
(AP 2.1)
Atributo de gesto de artefatos
(AP 2.2)
AP do nvel 2 (AP 1.1, AP2.1,
AP 2.2) +
Atributo de definio de processo
(AP 3.1)
Atributo de recursos de processo
(AP 3.2)
AP do nvel 3 (AP 1.1, AP2.1,
AP 2.2, AP 3.1, AP 3.2) +
Atributo de medida (AP4.1)
Atributo de controle de processo
(AP 4.2)
AP do Nvel 3 (AP 1.1, AP2.1,
AP 2.2, AP 3.1, AP 3.2,AP 4.1,
AP 4.2) +
Atributo de mudana de processo
(AP 5.1)
Atributo de melhoria contnua
(AP 5.2)
1. N - No atendido (0% - 15%)

2. P - Parcialmente atendido (>15% - 50%)
3. L - Largamente atendido (>50% - 85%)
4. F - Totalmente atendido (>85% - 100%)
Para que determinado processo seja avaliado em um nvel N, necessrio que
ele atenda a todos os atributos do nvel anterior com escala F e que obtenha pelo menos
escala L nos atributos do nvel N.
19
A norma ISO/IEC 15504 fornece tambm um guia geral para a avaliao dos processos, embora um pouco superficial. Essa avaliao pode ter dois objetivos: determinar
a capacidade de um processo ou melhorar o processo existente.
As atividades que compem a avaliao so as seguintes:
1. iniciar a avaliao por parte do interessado;
2. selecionar o avaliador e sua equipe;
3. planejar a avaliao, selecionando os processos que sero avaliados de acordo
com o modelo e a demanda do interessado;
4. reunio de pr-avaliao;
5. coletar os dados;
6. validar os dados;
7. atribuir nvel de capacidade aos processos;
8. relatar os resultados da avaliao.
2.4
CMMI
O CMMI (Capability Maturity Model Integration) foi criado pelo SEI (Software
Engineering Institute), que faz parte da Carnegie Mellon University, como um sucessor
do CMM (Capability Maturity Model), com sua verso 1.1 sendo lanada em 2002 e verso
1.3 lanada em 2010, que a mais atual. Ele consiste em uma coleo de modelos e boas
prticas para ajudar as organizaes a melhorar seus processos. Esses modelos foram
desenvolvidos em conjunto com a indstria, o governo americano e o SEI.
O modelo CMMI possui dois tipos de representaes: por nvel de capacidade e
por nvel de maturidade. A representao por nvel de capacidade permite a organizao
focar seus esforos para melhoria em processos especficos, desde o nvel de capacidade
0 at o nivel 3. J a representao por nvel de maturidade permite a melhoria da
organizao como um todo, podendo alcanar desde o nvel 1 de maturidade at o nvel
5 (CMMI-INSTITUTE, 2014a). A Tabela 2 exemplifica os dois tipos de representaes
existentes no CMMI.
Atualmente o CMMI pode ser divido em trs vertentes:
1. CMMI-DEV: fornece um guia para aplicar as boas prticas do CMMI em organizaes que desenvolvem produtos e servios.
20
Tabela 2 Nveis de capacidade e maturidade do CMMI

Nvel
0
1
2
3
4
5
Capacidade
Incompleto
Realizado
Gerenciado
Definido
Maturidade
Inicial
Gerenciado
Definido
Quantitativamente gerenciado
Em otimizao
2. CMMI-ACQ: fornece um guia para aplicar as boas prticas do CMMI para aquisio de produtos e servios.
3. CMMI-SVC: fornece um guia para aplicar as boas prticas do CMMI em organizaes provedoras de servios.
Embora desenvolvido de forma independente da ISO/IEC 15504, o modelo
proposto pelo SEI possui compatibilidade com o SPICE.
2.4.1
Nveis de capacidade
Existem quatro nveis de capacidade no modelo CMMI.
1. Nvel 0 - Incompleto: significa que ou o processo no foi estabelecido ou que no

executado da forma adequada. Nesse nvel, um ou mais objetivos especficos da
rea do processo no so satisfeitos.
2. Nvel 1 - Realizado: o processo executado, mas no foi institucionalizado ainda.
3. Nvel 2 - Gerenciado: o processo realizado e foi institucionalizado, segue um
planejamento e uma poltica bem definida que permitem que o processo seja
seguido mesmo em perodos de estresse. Ele monitorado, revisado e controlado.
4. Nvel 3 - Definido: o processo alm de ser gerenciado gerado a partir de um
padro de processos da organizao.
2.4.2
Nveis de maturidade
Existem cinco nveis de maturidade no modelo CMMI.
1. Nvel 1 - Inicial: no existe um ambiente de suporte ao controle do processo. Est

focado nas capacidades individuais dos funcionrios e no no processo em s. Os
desenvolvedores tm a tendncia de deixar o processo de lado em momentos de
estresse.
21
2. Nvel 2 - Gerenciado: existe um planejamento e uma poltica para execuo e

controle dos processos.
3. Nvel 3 - Definido: o processo a ser seguido gerado a partir de um padro da
organizao.
4. Nvel 4 - Quantitativamente gerenciado: existem metas de qualidade quantitativas
definidas para o processo. O processo avaliado quantitativamente.
5. Nvel 5 - Em otimizao: o processo sofre mudanas constantemente baseadas nos
resultados quantitativos do nvel 4.
2.5
MPS.BR
O Modelo de Referncia para Melhoria de Processo de Software (MR-MPS)

tambm conhecido como MPS.BR, foi criado em 2003 sob a coordenao da Associao
para Promoo da Excelncia do Software Brasileiro (SOFTEX), com apoio do governo
(MCT1 e FINEP2 ), SEBRAE3 /PROIMPE4 e BID5 , da indstria de software brasileira e
de instituies de pesquisa. O objetivo principal da criao desse modelo foi incentivar
a melhoria de processos de software nas organizaes brasileiras, fornecendo um
modelo acessvel economicamente para as Pequenas e Mdias Empresas (PMEs). Ele
foi feito levando-se em considerao as boas prticas da Engenharia de Software e as
necessidades da indstria brasileira (KALINOWSKI et al., 2010).
O modelo proposto pelo MPS.BR, embora feito de forma independente, possui
total conformidade com as normas ISO/IEC 15504, ISO/IEC 12207 e o modelo CMMI.
Sua estrutura dividida em nveis de maturidade e capacidade.
Nessa seo, abordaremos a arquitetura do modelo MPS, descrevendo seus
componentes, nveis de maturidade e capacidade.
2.5.1
Arquitetura MPS.BR
Atualmente o modelo MPS, ilustrado na Figura 5, possui cinco componentes:

modelo de referncia MPS para Software (MR-MPS-SW), o modelo de referncia MPS
para Servios (MR-MPS-SV), o mtodo de avaliao MPS (MA-MPS), o modelo de
negcios MPS (MN-MPS) e o modelo MPS Gesto de Pessoas (MPS-RH). O MPS-RH
foi adicionado recentemente ao conjunto de componentes e est na sua verso beta
1
2
3
4
5
Ministrio da Cincia e Tecnologia

Financiadora de Estudos e Projetos
Servio Brasileiro de Apoio s Micro e Pequenas Empresas
Programa de Estmulo ao Uso de Tecnologia da Informao em Micro e Pequenas Empresas
Banco Interamericano de Desenvolvimento
22
publicada em Novembro de 2014. Cada um desses componentes possuem guias e

documentos que o descrevem (SOFTEX, 2014).
Figura 5 Componentes do modelo MPS
Fonte: (SOFTEX, 2014)
Neste trabalho, ser enfatizado o MR-MPS-SW, que contm os requisitos necessrios para que as organizaes alcancem a conformidade com o modelo, define
os nveis de maturidade , processos e atributos de processos e o mtodo de avaliao
MA-MPS que contm o processo, o mtodo de avaliao e os requisitos necessrios para
os avaliadores.
2.5.2
Nveis do MR-MPS-SW
O MR-MPS-SW descreve processos que possuem propsitos e resultados esperados, o que permite avaliar o grau de efetividade na execuo desses processos. A
capacidade de cada processo avaliada conforme o alcance de seus objetivos, sendo
relacionada ao atendimento aos atributos de processo associados a cada nvel de maturidade.
So definidos sete nveis de maturidade, que indicam a evoluo dos processos
em uma organizao. So eles os nveis: A (Em otimizao), B (Gerenciado quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F
(Gerenciado) e G (Parcialmente Gerenciado). Em cada um desses nveis, so atribudos
23
um perfil de processos que auxiliam as organizaes em quais processos devem colocar

seus esforos visando a melhoria.
De forma semelhante ao CMMI e SPICE, para que uma organizao possa ser
avaliada em determinado nvel, necessrio que ela satisfaa todos os critrios dos
nveis anteriores e os do nvel em que deseja ser avaliada.
Existem nove atributos de processos (AP) que so alcanados de acordo com os
resultados esperados de atributos de processos (RAP). Esses atributos so definidos
conforme a SOFTEX (2012):
1. AP 1.1 O processo executado: este atributo evidencia o quanto o processo atinge
o seu propsito.
Resultado esperado:
a) RAP 1: o processo atinge seus resultados definidos.
2. AP 2.1 O processo gerenciado: este atributo evidencia o quanto a execuo do
processo gerenciada.
Resultados esperados:
a) RAP 2: existe uma poltica organizacional estabelecida e mantida para o
processo.
b) RAP 3: a execuo do processo planejada.
c) RAP 4 (para o nvel G)6 : a execuo do processo monitorada e ajustes so
realizados.
d) RAP 4 (a partir do nvel F): medidas so planejadas e coletadas para monitorao da execuo do processo e ajustes so realizados.
e) RAP 5: as informaes e os recursos necessrios para a execuo do processo
so identificados e disponibilizados.
f) RAP 6 (at o nvel F) 7 : as responsabilidades e a autoridade para executar o
processo so definidas, atribudas e comunicadas.
g) RAP 6 (a partir do nvel E): os papis requeridos, responsabilidades e autoridade para execuo do processo definido so atribudos e comunicados.
h) RAP 7: as pessoas que executam o processo so competentes em termos de
formao, treinamento e experincia.
i) RAP 8: a comunicao entre as partes interessadas no processo planejada e
executada de forma a garantir o seu envolvimento.
6
7
O RAP 4 tem exigncias diferentes para o nvel G e para os nveis posteriores.

O RAP 6 tem exigncias diferentes para os Nveis G e F e para o nveis posteriores.
24
j) RAP 9 (at o nvel F)8 : os resultados do processo so revistos com a gerncia

de alto nvel para fornecer visibilidade sobre a sua situao na organizao.
k) RAP 9 (a partir do nvel E): mtodos adequados para monitorar a eficcia
e adequao do processo so determinados e os resultados do processo so
revistos com a gerncia de alto nvel para fornecer visibilidade sobre a sua
situao na organizao.
l) RAP 10 (para o nvel G)9 : o processo planejado para o projeto executado.
m) RAP 10 (a partir do nvel F): a aderncia dos processos executados s descries de processo, padres e procedimentos avaliada objetivamente e so
tratadas as no conformidades.
3. AP 2.2 Os produtos de trabalho do processo so gerenciados: este atributo evidencia o quanto os produtos de trabalho produzidos pelo processo so gerenciados
apropriadamente.
a) RAP 11: os requisitos dos produtos de trabalho do processo so identificados.
b) RAP 12: requisitos para documentao e controle dos produtos de trabalho
so estabelecidos.
c) RAP 13: os produtos de trabalho so colocados em nveis apropriados de
controle.
d) RAP 14: os produtos de trabalho so avaliados objetivamente com relao
aos padres, procedimentos e requisitos aplicveis e so tratadas as no
conformidades.
4. AP 3.1. O processo definido: este atributo evidencia o quanto um processo
padro mantido para apoiar a implementao do processo definido.
a) RAP 15: um processo padro descrito, incluindo diretrizes para sua adaptao.
b) RAP 16: a sequncia e interao do processo padro com outros processos
so determinadas.
c) RAP 17: os papis e competncias requeridos para executar o processo so
identificados como parte do processo padro.
d) RAP 18: a infra-estrutura e o ambiente de trabalho requeridos para executar
o processo so identificados como parte do processo padro.
8
9
O RAP 9 tem exigncias diferentes para os Nveis G e F e para os nveis posteriores.

O RAP 10 tem exigncias diferentes para o Nivel G e para os nveis posteriores.
25
5. AP 3.2 O processo est implementado: este atributo evidencia o quanto o processo padro efetivamente implementado como um processo definido para
atingir seus resultados.
a) RAP 19: um processo definido implementado baseado nas diretrizes para
seleo e/ou adaptao do processo padro.
b) RAP 20: a infra-estrutura e o ambiente de trabalho requeridos para executar
o processo definido so disponibilizados, gerenciados e mantidos.
c) RAP 21: dados apropriados so coletados e analisados, constituindo uma
base para o entendimento do comportamento do processo, para demonstrar
a adequao e a eficcia do processo, e avaliar onde pode ser feita a melhoria
contnua do processo.
6. AP 4.1 O processo medido: este atributo evidencia o quanto os resultados de
medio so usados para assegurar que a execuo do processo atinge os seus
objetivos de desempenho e apoia o alcance dos objetivos de negcio definidos.
a) RAP 22: as necessidades de informao dos usurios dos processos, requeridas para apoiar objetivos de negcio relevantes da organizao, so identificadas.
b) RAP 23: objetivos de medio organizacionais dos processos e/ou subprocessos so derivados das necessidades de informao dos usurios do processo.
c) RAP 24: objetivos quantitativos organizacionais de qualidade e de desempenho dos processos e/ou subprocessos so definidos para apoiar os objetivos
de negcio.
d) RAP 25: os processos e/ou subprocessos que sero objeto de anlise de
desempenho so selecionados a partir do conjunto de processos padro da
organizao e das necessidades de informao dos usurios dos processos.
e) RAP 26: medidas, bem como a frequncia de realizao de suas medies,
so identificadas e definidas de acordo com os objetivos de medio do
processo/subprocesso e os objetivos quantitativos de qualidade e de desempenho do processo.
f) RAP 27: resultados das medies so coletados, analisados, utilizando tcnicas estatsticas e outras tcnicas quantitativas apropriadas, e so comunicados
para monitorar o alcance dos objetivos quantitativos de qualidade e de desempenho do processo/subprocesso.
26
g) RAP 28: resultados de medio so utilizados para caracterizar o desempenho

do processo/subprocesso.
h) RAP 29: modelos de desempenho do processo so estabelecidos e mantidos.
7. AP 4.2 O processo controlado: este atributo evidencia o quanto o processo
controlado estatisticamente para produzir um processo estvel, capaz e previsvel
dentro de limites estabelecidos.
a) RAP 30: tcnicas de anlise e de controle para a gerncia quantitativa dos
processos/subprocessos so identificadas e aplicadas quando necessrio.
b) RAP 31: limites de controle de variao so estabelecidos para o desempenho
normal do processo.
c) RAP 32: dados de medio so analisados com relao a causas especiais de
variao.
d) RAP 33: aes corretivas e preventivas so realizadas para tratar causas
especiais, ou de outros tipos, de variao.
e) RAP 34: limites de controle so restabelecidos, quando necessrio, seguindo
as aes corretivas, de forma que os processos continuem estveis, capazes e
previsveis.
8. AP 5.1 O processo objeto de melhorias incrementais e inovaes: este atributo evidencia o quanto as mudanas no processo so identificadas a partir da
anlise de defeitos, problemas, causas comuns de variao do desempenho e
da investigao de enfoques inovadores para a definio e implementao do
processo.
a) RAP 35: objetivos de negcio da organizao so mantidos com base no
entendimento das estratgias de negcio e resultados de desempenho do
processo.
b) RAP 36: objetivos de melhoria do processo so definidos com base no entendimento do desempenho do processo, de forma a verificar que os objetivos
de negcio relevantes so atingveis.
c) RAP 37: dados que influenciam o desempenho do processo so identificados,
classificados e selecionados para anlise de causas.
d) RAP 38: dados selecionados so analisados para identificar causas raiz e
propor solues aceitveis para evitar ocorrncias futuras de resultados
similares ou incorporar melhores prticas no processo.
27
e) RAP 39: dados adequados so analisados para identificar causas comuns de

variao no desempenho do processo.
f) RAP 40: dados adequados so analisados para identificar oportunidades para
aplicar melhores prticas e inovaes com impacto no alcance dos objetivos
de negcio.
g) RAP 41: oportunidades de melhoria derivadas de novas tecnologias e conceitos de processo so identificadas, avaliadas e selecionadas com base no
impacto no alcance dos objetivos de negcio.
h) RAP 42: uma estratgia de implementao para as melhorias selecionadas
estabelecida para alcanar os objetivos de melhoria do processo e para
resolver problemas.
9. AP 5.2 O processo otimizado continuamente: este atributo evidencia o quanto
as mudanas na definio, gerncia e desempenho do processo tm impacto
efetivo para o alcance dos objetivos relevantes de melhoria do processo.
a) RAP 43: o impacto de todas as mudanas propostas avaliado com relao
aos objetivos do processo definido e do processo padro.
b) RAP 44: a implementao de todas as mudanas acordadas gerenciada para
assegurar que qualquer alterao no desempenho do processo seja entendida
e que sejam tomadas as aes pertinentes.
c) RAP 45: as aes implementadas para resoluo de problemas e melhoria
no processo so acompanhadas, com uso de tcnicas estatsticas e outras
tcnicas quantitativas, para verificar se as mudanas no processo corrigiram
o problema e melhoraram o seu desempenho.
d) RAP 46: dados da anlise de causas e de resoluo so armazenados para
uso em situaes similares.
A Tabela 3 mostra a relao entre os nveis de maturidade, os processos e os atributos de processos. O nvel G do modelo MPS.BR o nvel mais bsico a ser alcanado.
Ele inclui os processos de Gerncia de requisitos (GRE) e Gerncia de processos (GPR).
O nvel A o mais elevado nvel de maturidade a ser alcanado, embora, ele no possua
processos relacionados, seus atributos de processos (AP 5.1 e AP 5.2), garantem que o
processo otimizado. Nesse trabalho iremos propor uma avaliao conforme o nvel G.
O mtodo de avaliao ser abordado nos prximos captulos.
28
Tabela 3 Nveis de maturidade do MR-MPS-SW

Nvel
Processos
Gerncia de Projetos GPR (evoluo)

Gerncia de Riscos GRI
Desenvolvimento para Reutilizao DRU
Gerncia de Decises GDE
Verificao VER
Validao VAL
Projeto e Construo do Produto PCP
Integrao do Produto ITP
Desenvolvimento de Requisitos DRE
Gerncia de Projetos GPR (evoluo)
Gerncia de Reutilizao GRU
Gerncia de Recursos Humanos GRH
Definio do Processo Organizacional DFP
Avaliao e Melhoria do Processo Organizacional AMP
Medio MED
Garantia da Qualidade GQA
Gerncia de Portflio de Projetos GPP
Gerncia de Configurao GCO
Aquisio AQU
Gerncia de Requisitos GRE
Gerncia de Projetos GPR
Atributos
AP 1.1, AP 2.1, AP 2.2,
AP 3.1,AP 3.2, AP 4.1,
AP 4.2 , AP 5.1 e AP 5.2
AP 1.1, AP 2.1, AP 2.2,
AP 3.1 e AP 3.2,
AP 4.1 e AP 4.2
AP 1.1, AP 2.1, AP 2.2,
AP 3.1 e AP 3.2
AP 1.1, AP 2.1, AP 2.2,

AP 3.1 e AP 3.2
AP 1.1, AP 2.1, AP 2.2,

AP 3.1 e AP 3.2
AP 1.1, AP 2.1 e AP 2.2
AP 1.1 e AP 2.1
2.6
29
Mtodos de avaliao de processos
Cada uma das normas e modelos citados neste trabalho possui um determinado
mtodo de avaliao previsto. No caso da ISO 15504, ela prev requisitos mnimos para
que uma avaliao seja realizada. O CMMI utiliza o mtodo SCAMPI (Standard CMMI
Appraisal Method for Process Improvement) que define detalhadamente as atividades que
devem ser realizadas para avaliao. O mtodo de avaliao utilizado pelo MPS.BR o
MA-MPS (SOFTEX, 2012).
2.6.1
SCAMPI
O SCAMPI o mtodo de avaliao desenvolvido para o modelo CMMI (embora

possa ser utilizado em outros modelos) que ajuda as organizaes a identificarem os
pontos fortes e fracos em seus processos, assim como definir seus respectivos nveis
de maturidade e capacidade. Ele inclui trs classes de avaliaes: SCAMPI A, B e C
(CMMI-INSTITUTE, 2014b).
SCAMPI A: mtodo que resulta em uma classificao capaz de comparar nveis
de maturidade e capacidade entre organizaes. Esse mtodo o mais rigoroso
e confivel, consequentemente o que possui um maior custo. A classificao
resultante do SCAMPI A vlida por trs anos.
SCAMPI B: mtodo um pouco menos rigoroso, pois vrios requisitos do SCAMPI
A no so exigncias desse mtodo. Esse mtodo recomendado para avaliaes
iniciais em organizaes que esto comeando a usar o modelo CMMI. No resulta
em uma classificao.
SCAMPI C: ainda menos rigososo que o SCAMPI A e B. No resulta em uma
classificao e geralmente utilizado para auto-avaliaes peridicas.
O SCAMPI possui quatro fases e vrios processos que so essenciais para sua
execuo. A Figura 6 exemplifica essas fases e processos, que so descritas a seguir.
Fase 1: Planejar e Preparar a Avaliao
A fase de planejamento comea entendendo os objetivos, requisitos e limitaes
da organizao que receber a avaliao. O tempo gasto para avaliao deve ser acordado entre o patrocinador da avaliao e o lder da equipe que ir realiz-la, assim
como o escopo do modelo de referncia (reas de processo).
Durante a avaliao, a equipe avaliadora verifica e valida as evidncias objetivas
providas pela organizao para identificar os pontos fortes e fracos de acordo com
30
Figura 6 Fases e processos do SCAMPI
o modelo de referncia. Evidncias objetivas podem ser artefatos ou afirmaes, que

podem ser usadas como indicadores da implementao e institucionalizao das prticas
ou componentes do modelo. Antes de comear a fase de conduo da avaliao,
extremamente importante que a equipe avaliadora juntamente com a organizao
avaliada renam toda a documentao de evidncias objetivas, caso contrrio, a falta de
informaes pode atrasar ou prejudicar a avaliao em etapas posteriores. importante
que seja feito um planejamento para coletar esses dados. A prpria organizao avaliada
pode antecipadamente separar toda a documentao que julgar necessria para facilitar
e melhorar a eficincia da equipe avaliadora.
Fase 2: Conduzir a Avaliao
Durante essa fase, o foco principal da equipe coletar os dados da organizao
avaliada para julgar a extenso com que o modelo implementado. O escopo definido
na Fase 1 guiar a coleta de dados de acordo com cada componente do modelo. O plano
de coletas de dados deve continuar em execuo e ser refinado at que seja alcanada a
quantidade suficiente de informaes. Depois de determinar a cobertura suficiente do
modelo de referncia de avaliao, os resultados podem ser gerados.
Fase 3: Reportar os resultados
Nessa fase os resultados so fornecidos para o patrocinador da avaliao e para
a organizao avaliada. Esses dados tornam-se parte do registro da avaliao e devem
ser protegidos de acordo com a declarao de divulgao acordada durante a Fase 1.
Uma parte do registro da avaliao enviada para o CMMI Institute que adiciona os
dados em uma base confidencial que fornece perfis globais da comunidade.
31
Fase 4: Planejar as aes de re-avaliao

Caso o resultado da avaliao em um ou mais objetivos forem classificados
como "no satisfeito"ou "no classificado", a organizao tem a opo de resolver os
pontos fracos em um plano de ao. O plano de ao para re-avaliao realizado
em uma parte do escopo do modelo aps serem corrigidos os ponto fracos reportados
na avaliao inicial, a fim de atualizar a classificao da organizao. A re-avaliao
executada dentro de 4 meses aps a avaliao inicial e s permitida uma re-avaliao
por SCAMPI A.
2.6.2
MA-MPS
O MA-MPS o mtodo que permite uma avaliao objetiva dos processos de

software e de servios de uma organizao. Ele utilizado para definir um nvel de
maturidade do MR-MPS-SW e MR-MPS-SV com base em seus resultados. Para este
trabalho, necessrio focar apenas na parte referente ao MR-MPS-SW.
O processo de avaliao consiste em uma srie de atividades e tarefas para
avaliar o nvel de maturidade da organizao. Ao todo existem cinco subprocessos:
1. Contratar a avaliao;
2. Preparar a realizao da avaliao;
3. Realizar a avaliao inicial;
4. Realizar a avaliao final;
5. Documentar os resultados da avaliao.
Primeiramente deve ser escolhida uma instituio avaliadora (IA) que ser
responsvel por realizar a avaliao. Ao final, registrado o resultado da avaliao
na base de dados confidencial da SOFTEX. Assim como o SCAMPI A, a avaliao do
MA-MPS possui validade de trs anos a partir da data da avaliao final (SOFTEX,
2013).
Cada uma das tarefas do processo podem ser definidas conforme o Quadro 2.
2.6.2.1
Descrio dos processos de avaliao
Cada um dos subprocessos possuem atividades e objetivos especficos. A seguir,

cada um deles so descritos brevemente, conforme a SOFTEX (2013).
32
Quadro 2 Itens para descrio de uma tarefa

Nome da tarefa
Descrio
Pr-tarefa
Critrio de Entrada
Critrio de Sada
Responsveis
Participantes
Produtos Requeridos
Produtos Gerados
Ferramentas
Ps-tarefa
Identifica a tarefa por um nome.

Descreve a tarefa em detalhes.
Tarefa que deve ser executada antes da tarefa em questo.
Condies a serem atendidas para que a tarefa seja iniciada.
Condies a serem atendidas para que a tarefa seja considerada finalizada.
Quem responde pela execuo da tarefa.
Quem so os envolvidos na execuo da tarefa.
Relaciona os insumos necessrios para executar a tarefa.
Relaciona os produtos a serem gerados na execuo dessa
tarefa.
Relaciona as ferramentas que devem ser utilizadas para a
execuo da tarefa.
Relaciona a tarefa que deve ser executada aps esta ser
finalizada.
Subprocesso 1: Contratar a avaliao

Esse subprocesso possui duas atividades: pesquisar instituies avaliadoras (IA)
e estabelecer um contrato. O objetivo desse subprocesso que seja contratada uma IA
para realizar a avaliao, solicitada por uma organizao para avaliar os seus processos
ou processos de outra.
Subprocesso 2: Preparar a realizao da avaliao
Esse subprocesso possui trs atividades: viabilizar a avaliao, planejar a avaliao e preparar a avaliao. Os objetivos de cada atividade so:
Viabilizar a avaliao: informar a SOFTEX a contratao da IA, indicar o auditor
da avaliao e solicitar a organizao a participao de um avaliador em formao,
alm de pagar a contribuio a SOFTEX.
Planejar a avaliao: elaborar o Plano de Avaliao a ser seguido para se realizar a
avaliao na organizao.
Preparar a avaliao: enviar a planilha de indicadores para a organizao a ser
avaliada, para que seja preenchida de forma a comprovar a implementao dos
processos e atributos do processo a partir de seus resultados esperados.
33
Subprocesso 3: Realizar a avaliao inicial

Esse processo possui duas atividades: conduzir a avaliao inicial e completar
a preparao da avaliao. O objetivo desse subprocesso fazer uma avaliao inicial
para verificar se a organizao est pronta para ser avaliada no nvel de maturidade
pretendido.
Subprocesso 4: Realizar a avaliao final
Esse processo possui duas atividades: conduzir a avaliao final e avaliar a
execuo do processo de avaliao. O objetivo desse subprocesso treinar a equipe
para a realizao da avaliao final, conduzir a avaliao final, comunicar seus resultados unidade organizacional avaliada e avaliar a execuo do processo de avaliao
na unidade organizacional. Nessa etapa so apresentados os pontos fortes, fracos e
oportunidade de melhoria no processo.
Subprocesso 5: Documentar os resultados da avaliao
Esse processo possui duas atividades: relatar os resultados e registrar os resultados. O objetivo desse subprocesso elaborar o Relatrio da Avaliao e enviar toda a
documentao da avaliao final para o auditor do processo. O auditor responsvel
por enviar a documentao da avaliao SOFTEX, que ir armazenar a documentao
e divulgar os resultados em seu site.
2.6.3
Mtodo a ser aplicado no EP
Com base nos estudos realizados a partir da reviso da literatura neste trabalho,
observa-se que existe compatibilidade entre o modelo proposto pelo MPS.BR e o CMMI.
A Tabela 4 mostra a relao direta entre os nveis de maturidade de cada modelo.
Embora exista tal compatibilidade, para realizao deste trabalho, faz-se necessrio
definir um modelo a ser seguido devido a certas especificidades contidas em cada um
deles. Um exemplo a quantidade de nveis de classificao de maturidade, sendo sete
nveis no MPS.BR e cinco no CMMI, sendo quatro deles avaliveis.
Conforme a Tabela 5, foram identificadas algumas diferenas entre cada um dos
modelos. Tais diferenas so discutidas a seguir e so a base da escolha do modelo
escolhido para a conduo das anlises realizadas no restante deste trabalho.
1. Reconhecido nacionalmente X Reconhecido internacionalmente: o modelo CMMI
amplamente divulgado e reconhecido internacionalmente, enquanto o MPS.BR
um modelo voltado para o pblico brasileiro. Como o EP uma unidade organi-
34
Tabela 4 Mapeamento entre os nveis de maturidade do MR-MPS e CMMI

Nveis MR-MPS
G
F
E
D
C
B
A
Nveis CMMI
3
4
5
Tabela 5 Comparao entre MR-MPS e CMMI

MR-MPS
Reconhecido nacionalmente
Mais fragmentado
7 nveis de maturidade, tornando o processo
mais suave para a organizao.
Custo da certificao mais acessvel
CMMI
Reconhecido internacionalmente
Menos fragmentado
5 nveis de maturidade, sendo 4 avaliveis
Custo da certificao alto
zacional focada no desenvolvimento de sistemas e tecnologias para dar suporte

ao CEFET-MG, no um dos dos objetivos da equipe o mercado internacional.
2. Menos fragmentado X Mais fragmentado: o termo "fragmentado"aqui refere-se
quantidade de nveis do modelo. Assim, o MPS.BR mais fragmentado que o
CMMI porque sua diviso se d em mais nveis, ao todo 7 nveis de maturidade,
permitindo uma implementao mais gradual do processo de melhoria.
3. Custo da certificao acessvel X Custo da certificao alto: um dos objetivos do
MPS.BR construir um modelo economicamente vivel para as pequenas e mdias
empresas, portanto o custo de uma certificao nesse modelo menos onerosa do
que no CMMI. Embora no momento no seja objetivo do EP realizar a certificao
em nenhum dos modelos, o custo uma caracterstica a ser considerada caso,
futuramente, esse cenrio venha a mudar.
Com base nessas diferenas, optou-se pelo mtodo de avaliao MA-MPS que
descreve os processos para classificar uma organizao de acordo com o MR-MPS.
Como no foi contratada uma IA, o que foi realizado neste trabalho uma adaptao
do mtodo para ser realizado pela prpria equipe do EP. Para tal, tomou-se como base
o guia de avaliao disponibilizado pela SOFTEX, visando, ao final, a obteno de uma
classificao de maturidade, embora no oficial, mas que servir para orientar o EP no
processo de melhoria.
O nvel (A, B, C, D, E, F ou G) da avaliao do EP ser definido posteriormente
com base no levantamento inicial do processo atual. Sero coletados todos os documen-
35
tos necessrios e definido junto com a equipe em qual nvel deve ser feita a avaliao.
36
3 Trabalhos relacionados
Neste captulo so discutidos dois trabalhos referentes a implantao da melhoria

de processos de software baseadas no MPS.BR em um ambiente da administrao
pblica similar ao EP. O primeiro o Diagnstico da Implantao da MPS.BR Nvel G
na Administrao Pblica: Estudo de Caso na Prodabel (SOUZA; PINTO, 2008) e o
segundo o Melhoria de Processos de Software com base no nvel G do MPS.BR na
Prodemge (RIBEIRO, 2007).
3.1
Prodabel
A Prodabel, instituio responsvel pela gesto da tecnologia de informao no

mbito da Prefeitura Municipal de Belo Horizonte, uma empresa de economia mista,
criada em 10 de Janeiro de 1974.
Em janeiro de 2007 teve incio o projeto MpsPdbl (Melhoria do Processo de
Software da Prodabel) com o objetivo de aplicar as melhorias associadas ao nveis G e
F do modelo MPS.BR. Esse projeto teve a durao de 15 meses. A implementao foi
dividida em dois mdulos, sendo o primeiro referente aderncia plena aos processos
de Gerncia de Requisitos (GRE) e Gerncia de Processos (GPR) conforme o MPS.BR,
e o segundo mdulo, aderncia parcial aos processos de Gerncia de Configurao,
Aquisio e Garantia da Qualidade.
Durante o processo de implementao foram identificados alguns riscos que se
concretizaram durante o desenvolvimento:
Mudana na alta direo da empresa. Como em toda a empresa pblica, quando
h mudanas governamentais, podem haver mudanas na direo da empresa, o
que aconteceu na Prodabel. Foi necessrio um trabalho de sensibilizao junto a
nova direo e patrocinadores para que no houvesse impacto no andamento do
projeto.
Diversidade de capacitao da equipe. Em diversas situaes, a heterogeneidade
da equipe de projeto acarretou retrabalho e dificuldade para se definirem algumas
tarefas. A organizao da equipe em torno do consenso e a liderana para tomada
de decises mitigaram os problemas ocorridos.
Indisponibilidade de membros da equipe de projeto. Cada um dos participantes
manteve suas obrigaes originais e participou do projeto de acordo com sua
disponibilidade e urgncia das atividades. Isso, por vezes, provocou atrasos e falta
Captulo 3. Trabalhos relacionados
37
de paralelismo nas atividades. Alm disso, alguns membros originais do projeto

deixaram a equipe.
Incapacidade de implementar o projeto-piloto. Devido ao elevado backlog de
sistemas, o projeto-piloto teve seu incio adiado diversas vezes por incapacidade
de priorizao pela rea responsvel. Cabe destacar que a viabilizao s foi
possvel pela total adeso por parte do gerente da rea executante. natural
que, em uma organizao, as demandas corriqueiras e emergenciais atropelem os
projetos devido sua natureza emergencial.
Vale ressaltar que os riscos levantados pela Prodabel so perfeitamente passveis
de ocorrer no ambiente do EP que compartilha de um cenrio similar.
Ao final do projeto foram levantadas diversas lies apreendidas durante o
processo, sendo as duas das que mais se destacaram:
Abordar a melhoria de processos como um projeto. Essa foi a diretriz mais importante que se pode tirar das lies apreendidas, pois permitiu gerenciar as
expectativas dos envolvidos no projeto, escopo e tempo disponvel.
Utilizar uma ferramenta especializada para gerenciar o processo proposto. A
ferramenta utilizada foi o Eclipse Process Framework (EPF), que foi um dos fatores
que mais trouxe ganhos ao projeto, resolvendo principalmente as questes da
arquitetura do processo.
O Processo de Software da Prodabel foi avaliado em junho de 2008, tornando a
Prodabel a primeira empresa municipal de servios de informtica pblica e a segunda
empresa pblica no Brasil certificada no MPS.BR nvel G.
3.2
Prodemge
A Prodemge uma empresa de tecnologia da informao, de economia mista,

do Governo do Estado de Minas Gerais, com mais de 40 anos a servio da modernizao do setor pblico. Ela atua em diversas reas como desenvolvimento de sistemas,
hospedagem de servios, gesto de rede, consultoria e emisso de certificados digitais.
Para o projeto de melhoria de processo, as atividades de desenvolvimento de
sistemas so as mais afetadas pelo MPS.BR. So elas:
Especificao, construo e capacitao de usurios de sistemas transacionais
(plataforma alta e baixa).
Captulo 3. Trabalhos relacionados
38
Datawarehouses e sistemas de BI (Business Intelligence).

Sistemas georreferenciados.
Sistemas de workflow e de gerenciamento eletrnico de documentos.
O processo de software da Prodemge que foi modificado pelo projeto de melhoria
foi o PDSOO (Processo de Desenvolvimento de Software Orientado a Objetos), que
um processo baseado em dois processos j conhecidos: RUP (Rational Unified Process) e
Praxis (PAULA FILHO, 2009). Foram necessrias algumas modificaes para garantir
a aderncia ao nvel G no MPS.BR. As principais delas foram a criao de critrios
explcitos de aceitao de requisitos e a criao de um modelo de rastreabilidade entre
requisitos e produtos de trabalho. O projeto teve incio em 2007 e a Prodemge conquistou
a certificao no nvel G em 2011.
Algumas das lies aprendidas durante o projeto foram:
Se est difcil definir para usar, use para definir: utilizar-se da experimentao
pode poupar horas de discusso para decidir qual a melhor forma de se cumprir
um determinado resultado esperado do modelo. Tal mtodo mostrou-se mais
eficiente em alguns casos, como por exemplo na definio de como deveria ser
feito o planejamento de recursos humanos.
A capacitao dos funcionrios que utilizaro o processo fundamental.
Sempre h muito mais para melhorar do que a empresa suporta no momento, por
isso preciso ter foco.
No se deve realizar definies sem interlocuo com as pessoas que executaro
as atividades.
O uso de uma ferramenta especificamente desenhada para descrio de processos,
como o caso do EPF, facilita muito a definio, descrio e publicao de uma
arquitetura de processos.
importante analisar as lies aprendidas durante o projeto de melhoria do processo da Prodemge, pois, essas podem ser adotadas no processo de melhoria realizado
no EP.
39
4 Metodologia
Neste captulo, descrita a metodologia utilizada neste trabalho.
4.1
Reviso bibliogrfica
Para a realizao deste trabalho, foi necessrio realizar uma reviso bibliogrfica
sobre melhoria de processos de software e os principais modelos e mtodos de avaliao
de processos existentes. As principais fontes bibliogrficas foram o livro Engenharia
de Software: conceitos e prticas (WAZLAWICK, 2013) e as normas ISO/IEC 25000
(2014), ISO/IEC 9001 (2008) e ISO/IEC 15504 (2008).
4.2
Definio do modelo e mtodo a ser utilizado
O modelo e mtodo a ser utilizado foi definido a partir de uma anlise comparativa entre as opes identificadas aps a reviso bibliogrfica. O mtodo nesse
comparativo considerado mais adequado ao cenrio do caso em estudo foi o escolhido
para ser utilizado neste trabalho.
4.3
Levantamento do processo atual
Antes de aplicar o mtodo escolhido, necessrio obter uma viso geral do

ambiente em estudo. Para isso foi necessrio levantar toda a documentao existente
sobre o processo de desenvolvimento de software do EP e, nos casos em que esta foi
omissa, foram realizadas consultas informais aos membros da equipe do EP.
4.4
Definio do nvel de maturidade a ser avaliado
O nvel de maturidade em que ser feita a avaliao do processo foi definido em

conjunto com a equipe do EP.
4.5
Avaliao da capacidade atual dos processos
Definido em qual nvel de maturidade o EP ser avaliado, os processos do

EP foram comparados ao modelo de referncia e identificados os nveis em que se
encontram. Essa avaliao permitiu identificar os pontos fracos e fortes do processo
atual.
Captulo 4. Metodologia
4.6
40
Avaliao dos resultados e definio de plano de melhorias
Com base no nvel de maturidade dos processos avaliados e nos objetivos e

necessidades da equipe do EP, foi definido um plano de melhorias que auxiliar o
alcance do nvel desejado.
4.7
Avaliao do plano de melhorias
Aps a confeco do plano de melhorias, foi elaborado um questionrio para a

sua avaliao. O questionrio foi aplicado aos integrantes da equipe do EP. O intuito foi
verificar a receptividade da equipe s mudanas propostas, o que influi significativamente na execuo do plano.
41
5 Avaliao do Processo de Software no EP
Neste captulo, descrita a avaliao do processo de software do Escritrio

de Projetos. O processo e o mtodo utilizados para a avaliao ser baseado no MAMPS (SOFTEX, 2013). Como este projeto se trata de um trabalho acadmico, a avaliao
realizada no ter efeito para a SOFTEX. Algumas tarefas descritas no Guia de Avaliao
(SOFTEX, 2013) foram adaptadas para a realidade do EP.
5.1
Processo de software do EP
O Escritrio de Projetos (EP), tambm conhecido como SINAPSE, a unidade

organizacional vinculada a Secretaria de Governana da Informao (SGI), que responsvel por elaborar e executar os projetos, sistemas e tecnologias de gesto da informao
no CEFET-MG. O EP possui atualmente uma equipe composta por 17 pessoas: 11 analistas de Tecnologia da Informao, 4 tcnicos de Tecnologia da Informao, 1 estagirio
e 1 bolsista do curso de Engenharia de Computao.
Neste captulo descrito o processo atual de desenvolvimento de software do EP,
com base no Documento de Processo de Desenvolvimento de Software (GONTIJO, 2013)
e, para os casos em que este for omisso ou divergente da realidade, foram utilizadas as
observaes realizadas pelo prprio autor que faz parte da equipe desde Outubro de
2013, como estagirio, e desde Julho de 2014 como Tcnico de Tecnologia da Informao.
O objetivo que o processo de desenvolvimento de software levantado seja o mais
fidedigno possvel para que se alcance uma avaliao do processo condizente com a
realidade.
5.1.1
Levantamento do processo atual
O processo de desenvolvimento de software do EP tem sofrido alteraes contantes a fim de melhorar a qualidade do produto de software desenvolvido. Por isso
algumas das informaes obtidas ao longo do levantamento so informaes divergentes ou complementares ao documento utilizado como base, que descreve oficialmente o
processo atual.
O ciclo de vida do processo dividido em 7 etapas:
1. Solicitao de Sistema/Mdulo
2. Levantamento de Requisitos
3. Anlise de Requisitos
Captulo 5. Avaliao do Processo de Software no EP
42
4. Projeto
5. Implementao
6. Testes
7. Implantao
Os atores desse processo so descritos conforme a Tabela 6:
Tabela 6 Atores do processo de desenvolvimento de software do EP
Identificao
Cliente
SGI
DITIC
EP
Responsabilidade
Definir os requisitos e modo de funcionamento das funcionalidades
desejadas para o software solicitado.
Intermediar e gerenciar as demandas e prioridades de desenvolvimento.
Implantar e dar suporte parte de infraestrutura dos sistemas.
Analisar, acompanhar, desenvolver, testar e implantar funcionalidades
de software solicitadas.
Fonte: Adaptado de Gontijo (2013)
A relao entre cada ator e as etapas do processo pode ser vista na Figura 7. A
seguir so descritas cada uma das etapas desse processo.
5.1.1.1
Solicitao de Sistema/Mdulo
A solicitao de um novo sistema ou mdulo a primeira etapa do processo.

Nessa etapa realizada uma reunio entre a equipe do EP e, se necessrio, com outros
integrantes da SGI, em conjunto com o cliente para discutir e apresentar as demandas.
extremamente importante que ao final de toda reunio seja gerada uma ata para
registrar tudo que foi discutido e evitar divergncias.
5.1.1.1.1
Levantamento de Requisitos
Nessa etapa os desenvolvedores em conjunto com o cliente se renem para

compreender o problema, buscando levantar e priorizar os requisitos do software.
Essa uma das etapas mais importante do processo, no que diz respeito ao retorno
de investimentos no projeto. Vrios projetos so abandonados pela deficincia no
levantamento de requisitos (GONTIJO, 2013). A falta de compreenso da demanda do
cliente podem prejudicar as etapas posteriores do processo, por isso imprescindvel
que o cliente faa parte dessa etapa e que a equipe do EP disponibilize tempo suficiente
para a concluso da mesma.
43
Figura 7 Diagrama geral do processo
Fonte: Adaptado de (GONTIJO, 2013)
5.1.1.1.2
Verificao de viabilidade
Aps o levantamento de requisitos, necessrio que a equipe do EP, em conjunto

com SGI, analise o custo, as prioridades e a viabilidade tcnica para o desenvolvimento
do software solicitado. Caso a anlise resulte em uma inviabilidade de desenvolvimento,
o cliente dever ser contactado e informado sobre a deciso, sendo apresentadas todas
as justificativas que levaram a essa concluso.
5.1.1.2
Anlise de Requisitos
A Anlise de Requisitos a etapa em que os desenvolvedores fazem um estudo

mais detalhado dos requisitos levantados. Nessa etapa os desenvolvedores devem
pensar em quais problemas devem ser solucionados pelo sistema, e no como eles sero
44
solucionados. So definidos tambm o modelo de dados que representa o sistema a ser

desenvolvido. Durante essa etapa, o cliente dever estar disponvel para solucionar as
possveis dvidas em relao ao entendimento da demanda.
5.1.1.3
Projeto
Nessa fase deve-se pensar em como resolver os problemas levantados na etapa

de Anlise de Requisitos. Alguns pontos especficos devem ser considerados nessa
etapa como: arquitetura do sistema, linguagem de programao utilizada, Sistema
Gerenciador de Banco de Dados (SGBD) utilizado, padro de interface grfica, entre
outros. importante que ao final dessa etapa a arquitetura do sistema esteja totalmente
definida para dar incio fase de Implementao.
5.1.1.4
Implementao
Na fase de implementao que ocorre a codificao do sistema utilizando a

arquitetura previamente estabelecida. importante que a implementao esteja de
acordo com os requisitos levantados anteriormente e, caso necessrio, o cliente deve ser
contactado para solucionar dvidas que impeam a continuidade do desenvolvimento.
5.1.1.5
Testes
Depois de concluda a fase de implementao, necessrio validar o que foi feito.

Para isso deve-ser verificar se o que foi produzido est de acordo com os requisitos levantados. Primeiramente, os prprios desenvolvedores so responsveis por realizar os
testes. Caso esteja tudo conforme o esperado, devem ser realizados testes pelos usurios
finais para que o sistema possa ser validado antes de entrar na fase de implantao.
5.1.1.6
Implantao
Como ltima etapa do processo, feita a implantao do sistema. Nessa fase

o sistema instalado no ambiente de produo e estar acessvel para o cliente e
usurios. Manuais, importaes de dados e treinamento tambm fazem parte dessa
fase. A DITIC, que responsvel pelo planejamento da infraestrutura da SGI, a
responsvel por fornecer e manter os equipamentos necessrios para que o sistema
possa ser disponibilizado aos usurios.
5.1.2
Metodologia de desenvolvimento
A metodologia utilizada no EP uma metodologia gil, desenvolvida baseandose em alguns princpios do Scrum (WAZLAWICK, 2013). Ao longo do tempo, foram
realizadas algumas modificaes em relao ao Scrum para melhor adaptao equipe.
45
Assim como no Scrum, o modelo de desenvolvimento utilizado iterativo e

incremental. Cada iterao chamada de sprint e so realizadas reunies para planejamento (sprint planning) e reviso de cada sprint (sprint retrospective). Uma adaptao
feita pela equipe a realizao do sprint planning e sprint retrospective em uma mesma
reunio. A durao dessas reunies so de 60 minutos e todas as reunies realizadas
pela equipe do EP, sejam relacionadas a uma sprint ou uma reunio com um cliente,
devem ser registradas em ata. Atualmente, a durao de cada sprint foi alterada de
uma semana para duas semanas, visando aumentar o tempo para desenvolvimento
das tarefas, e com isso, aumentar o nmero de tarefas produzidas em um sprint (sprint
backlog).
Para suprir a necessidade de um Scrum Master, foi criado o papel do Gerente
de Projetos. Esse papel itinerante, sendo assumido a cada sprint por um membro da
equipe. Essa medida visa fomentar na equipe uma maior participao e compromisso
com os projetos desenvolvidos, uma vez que todos, em algum momento, assumiro as
responsabilidades pelo sucesso da sprint.
Para auxiliar o gerenciamento dos projetos, utilizada a ferramenta Redmine,
que permite a gesto de tarefas, criao de uma base de conhecimento em formato wiki
e integrao com o sistema de controle de verso GIT.
5.2
Planejamento da avaliao
A primeira etapa do nosso processo de avaliao o seu planejamento, que

consiste em definir o nvel de maturidade em que o processo de desenvolvimento
de software do EP ser avaliado, quais projetos sero utilizados para essa avaliao,
a equipe responsvel pelo processo, a data da avaliao inicial, as tarefas a serem
realizadas e seu cronograma. O escopo deste trabalho se restringe a realizao da
avaliao inicial e a construo do plano de melhorias, portanto, no ser realizada
a avaliao final. Entende-se que ser necessrio ao EP aplicar o plano de melhorias
proposto por este trabalho para se adequar ao nvel de maturidade escolhido, essa etapa
demanda um tempo superior ao disponvel, tornando invivel a avaliao final.
5.2.1
Definio do nvel a ser avaliado
A escolha do nvel de maturidade em que o processo do EP ser avaliado foi

definida em conjunto com a equipe do EP. Como o processo utilizado pelo EP no foi
desenvolvido visando o MR-MPS ou mesmo a ISO/IEC 15504, considerou-se, neste
trabalho, que uma avaliao no primeiro nvel do MPS.BR (Nvel G) deva ser o primeiro
passo para a adoo de uma poltica de melhoria de processos de software de forma
mais gradual possvel.
5.2.2
46
Seleo de projetos
A escolha dos projetos que sero utilizados crucial para o sucesso da avaliao.
Para o nvel G, que foi o escolhido pela equipe do EP, devem ser selecionados pelo menos
dois projetos, estando pelo menos um deles no estado de concludo. considerado
concludo um projeto que tenha gerado todos os resultados que sero avaliados na
avaliao inicial (SOFTEX, 2013).
Para seleo dos projetos, foi enviado um formulrio para preenchimento de
todos os projetos executados pelo EP e, dentre os processos listados, foram escolhidos
dois, conforme o recomendado pelo guia de avaliao MA-MPS. O Quadro 3 mostra os
projetos executados e os projetos em andamento.
Foram escolhidos os projetos Encargos acadmicos e Infraestrutura, pois
esses so os mais recentes, dos que esto concludos, realizados pelo EP. A justificativa
para a escolha de projetos mais recentes se baseia na premissa de levantamento do
processo atual de forma mais fidedigna possvel, ou seja, escolhendo projetos mais
recentes, espera-se uma fonte de consulta que fruto de um processo que est mais
prximo ao processo atual, j que esse sofre mudanas constantemente no EP.
5.2.3
Definio da equipe de avaliao
A equipe de avaliao a responsvel por auxiliar e executar a avaliao na

unidade organizacional. So suas atribuies, de acordo com o guia de avaliao do
MPS.BR:
participar da avaliao inicial e da avaliao final;
verificar os resultados a partir dos indicadores;
realizar as entrevistas;
caracterizar o grau de implementao dos resultados;
identificar pontos fortes, pontos fracos e oportunidades de melhoria;
decidir o nvel de maturidade MR-MPS a ser atribudo unidade organizacional
avaliada;
avaliar a execuo da avaliao, a fim de fornecer feedback.
Segundo o guia, a equipe de avaliao deve ser composta por membros internos
e externos unidade organizacional. Essa medida visa garantir que a equipe possuir
membros que conhecem a unidade organizacional a ser avaliada (membros internos)
e membros que no possuem interesse direto em relao ao resultado da avaliao
47
Quadro 3 Projetos executados no EP

Nome
Credencial
Oramentrio
Refeitrio
Crditos
Ensino
Extenso
Currculo
Lattes
Recursos
Humanos
Veculos
GRU
Telefonia
Eleio
Guich
eletrnico
Encargos
acadmicos
Infraestrutura
Ponto
Eletrnico
Conta
unificada
Restaurante
Interior
Aplicativo
refeitrio
Descrio
Mdulo para gerenciamento das credenciais
dos usurios do CEFET-MG.
Mdulo de controle oramentrio.
Mdulo para gerenciamento do refeitrio.
Mdulo para gerenciamento dos crditos
dos usurios do CEFET-MG.
Mdulo de controle dos planos de ensino.
Mdulo para gerenciamento das atividades
de extenso.
Mdulo para controle das competncias do
CEFET-MG.
Data incio
Mdulo de recursos humanos.

Mdulo para controle dos veculos dos
usurios do CEFET-MG.
Mdulo para criao e controle das GRUs
Mdulo para controle de senhas de telefone.
Mdulo de controle de eleies.
Mdulo para gerenciamento dos processos
de submisso de projetos de pesquisa.
Mdulo para controle dos encargos
acadmicos dos docentes.
Mdulo para reserva de equipamentos.
Sistema para controle do ponto dos
servidores do CEFET-MG. Ser integrado
aos relgios biomtricos de ponto.
Sistema para unificao das contas
institucionais de todos os usurios do
CEFET-MG.
Sistema offline para integrar com o mdulo
refeitrio. Ser utilizado em restaurantes
contratados pelo CEFET-MG.
Aplicativo mvel para acessar algumas
informaes do mdulo refeitrio
Fase
28/4/09
Concludo
11/5/09
8/6/09
Concludo
Concludo
31/07/09
Concludo
01/09/09
Concludo
10/11/09
Concludo
23/11/09
Concludo
22/12/09
Concludo
21/01/10
Concludo
15/09/10
09/12/10
29/03/11
Concludo
Concludo
Concludo
13/04/11
Concludo
19/08/11
Concludo
29/09/14
Teste
09/12/14
Construo
27/03/15
Anlise/
projeto
30/03/15
Teste
25/03/15
Construo
(membro externos). Neste trabalho, como ser realizada apenas a avaliao inicial,
que no possui vnculo com a SOFTEX, ou com alguma Instituio Avaliadora, no
existe interesse dos membros internos em interferir na avaliao, pois seu resultado no
certificar o EP em nvel algum de maturidade. O resultado da avaliao representa um
diagnstico da situao atual do processo. Dessa forma, a equipe ser composta apenas
por membros internos. Outra recomendao do guia que no faam parte da equipe
de avaliao membros que so hierarquicamente superiores ao entrevistados ou que
tiveram participao significativa nos projetos selecionados para avaliao.
48
O Quadro 4 mostra a relao entre a composio da equipe e o tempo estimado

para realizao da avaliao.
Quadro 4 Tabela com orientao de tempo e composio da equipe de avaliao
Nvel
MR-MPS
Durao da
Avaliao
Inicial (dias)
Durao da
Avaliao
Final (dias)
4-5
3-5
4-5
3-5
3-4
3-5
3-4
3-5
2-3
2-3
2-3
2-3
1-2
1-2
Composio da equipe de avaliao

Av. lder (1), av. adjunto (1 ou mais), representante
unidade organizacional (1 ou mais)
Diante das recomendaes feitas pelo guia MA-MPS, a equipe de avaliao

composta como indicado no Quadro 5.
Quadro 5 Equipe de avaliao
Nome
Higor Augusto Madureira Pereira
Paulo Vitor de Campos Souza
5.2.3.1
Papel na equipe
Avaliador Lder
Avaliador Adjunto
Instituio
CEFET-MG
CEFET-MG
Equipe envolvida com os projetos
Os membros das equipes que participaram em cada um dos projetos selecionados

para a avaliao so considerados como colaboradores do projeto.
O papel dos colaboradores preencher a planilha de indicadores e dar apoio
equipe de avaliao fornecendo subsdios e esclarecimentos para que esta realize seu
trabalho. O Quadro 6 lista todos os colaboradores do projeto:
5.2.4
Cronograma geral
O cronograma geral contm todas as etapas do processo de avaliao, indicando

as datas de incio e fim de cada uma delas. Ele foi definido conforme o Quadro 7:
49
Quadro 6 Colaboradores no projeto

Nome
Projeto
Artur
Encargos
Acadmicos
Lucas
Infraestrutura
Renato
Infraestrutura
Vitor
Encargos
Acadmicos
Papel no projeto
Levantamento de requisitos,
Anlise de requisitos, Projeto,
Implementao, Testes,
implantao
implantao
implantao
implantao
Cargo
Chefia
Analista de Sistemas
Marcos
Fernando
Tecnlogo em Anlise
e Desenvolvimento de
Sistemas
Artur
Tecnlogo em Anlise
e Desenvolvimento de
Sistemas
Artur
Analista de Sistemas
Artur
Quadro 7 Cronograma geral da avaliao

Atividade
Preenchimento da planilha de
seleo de projetos
Elaborao do plano de avaliao
Preenchimento da planilha de
indicadores
Avaliao do processo
Elaborao do plano de melhorias
5.2.4.1
Responsvel
Data Incio
Data Fim
Avaliador lder
08/09/15
10/09/15
Avaliador lder
11/09/15
15/09/15
Empresa
16/09/15
17/09/15
Equipe de avaliao
Avaliador lder
Empresa
28/09/15
05/10/15
14/10/15
30/09/15
09/10/15
16/10/15
Cronograma das atividades da avaliao
Para realizao da avaliao inicial foram necessrias a realizao de algumas

atividades. O Quadro 8 descreve o cronograma dessas atividades, informando os participantes de cada uma delas.
Quadro 8 Cronograma das atividades da avaliao
Data
Atividade
16/09/15
Treinamento da avaliao
16/09/15
17/09/15
17/09/15
21/09/15
21/09/15
Preencher Planilha de indicadores

Verificar os indicadores de implementao
Identificar pontos fortes, fracos e
oportunidades de melhorias
Analisar os dados da avaliao inicial
Participantes
Artur, Higor, Jonata, Lucas,
Paulo, Renato e Vitor
Higor e Paulo
Higor e Paulo
5.3
50
Avaliao inicial
O objetivo da avaliao inicial verificar se a unidade organizacional, no caso, o

Escritrio de Projetos, est pronta para realizar a avaliao MR-MPS-SW. Com base nos
resultados dessa etapa, foi desenvolvido um plano de melhorias para que o EP adeque
seu processo de acordo com os processos definidos no nvel G do MPS.BR.
5.3.1
Treinamento da equipe
Antes das atividades da avaliao inicial, foi necessrio a realizao de um breve

treinamento da equipe avaliadora e dos colaboradores. O intuito desse treinamento
foi o nivelamento de todos os participantes sobre as particularidades do MPS.BR. Os
tpicos abordados no treinamento foram:
Avaliao de processos
MPS.BR
Processos do nvel G no MPS.BR
Avaliao inicial
Planilha de indicadores
O treinamento foi realizado no mesmo dia agendado para preenchimento da
planilha, de forma a subsidiar as equipes no desempenho de suas atividades.
5.3.2
Planilha de indicadores
A planilha de indicadores possui evidncias que comprovam a implementao

dos processos e dos atributos do processo a partir de seus resultados esperados (SOFTEX,
2013). Existem trs tipos de indicadores de implementao:
1. Indicadores diretos: o produto principal da realizao de uma tarefa.
2. Indicadores indiretos: os artefatos gerados em consequncia da realizao de
uma tarefa e que indicam a implementao de um resultado.
3. Afirmaes: coletadas durante as entrevistas e apresentaes e confirmam a implementao dos processos, atributos e seus resultados.
Durante a avaliao inicial so obrigatrios apenas os indicadores diretos. As
afirmaes devem ser coletadas durante as entrevistas na avaliao final. Os indicadores
51
indiretos so opcionais e devem ser includos quando a organizao julgar que eles
auxiliaro no entendimento da implementao.
Como ser realizada apenas a avaliao inicial, devem ser coletados somente
indicadores diretos e, quando necessrio, indiretos, para comprovar os resultados
esperados dos processos e dos atributos de processo.
Para o nvel G, h dezenove resultados esperados necessrios para o processo
Gerncia de Projetos e cinco para o de Gerncia de Requisitos. Somando a esses, existe
um resultado esperado para o atributo de processo AP 1.1 - O processo executado - e
existem nove para o AP 2.2 - O processo gerenciado. A Figura 8 exemplifica a planilha
de indicadores que deve ser preenchida.
Figura 8 Planilha de indicadores
Para o preenchimento da planilha de indicadores, foi realizada uma reunio com

os colaboradores dos projetos e a equipe de avaliao, na data definida pelo cronograma
geral, para realizarem o levantamento das evidncias necessrias para cada um dos
resultados esperados. Esse processo foi feito pelos colaboradores, com auxlio da equipe
de avaliao, atravs de consultas em toda documentao disponvel nos repositrios do
EP. Foram avaliados os dois projetos selecionados previamente: Encargos Acadmicos
e Infraestrutura.
5.3.3
Verificao dos indicadores de implementao
De posse da planilha de indicadores, iniciou-se o processo de verificao dos

indicadores de implementao. Essa etapa de responsabilidade da equipe de avaliao,
que deve reunir-se para analisar se as evidncias apresentadas pelos colaboradores,
para cada um dos projetos, realmente satisfazem cada um dos resultados esperados.
52
Durante a verificao surgiram algumas dificuldades para aplicao do mtodo

de avaliao em uma metodologia gil, utilizada pelo EP. Primeiramente, iniciou-se
uma verificao tendo como base as orientaes da planilha de indicadores, que foram
pensadas para um modelo de processo mais tradicional, conhecidos por produzirem
um nmero elevado de documentao.
O principal problema encontrado nessa primeira abordagem foi encontrar a
documentao que evidenciasse o cumprimento dos resultados esperados, uma vez
que o desenvolvimento gil valoriza o software em funcionamento mais que documentao abrangente (BECK et al., 2001). Depois de algumas pesquisas, encontrou-se o
mapeamento do MPS.BR para o Scrum, escrito por Carlos Barbieri, implementador,
avaliador, instrutor oficial MPS.BR e coordenador do ncleo de qualidade da FUMSOFT
- Sociedade Mineira de Software (PALESTINO, 2010). De posse dessas informaes,
iniciou-se uma segunda verificao, desta vez, tomando como base as informaes
fornecidas por Barbieri.
A seguir so apresentados e classificados cada um dos resultados esperados. A
descrio dos processos e seus respectivos resultados so aqueles dadas pelo guia do
SOFTEX (2012). A classificao dos resultados observados na avaliao foi realizada da
seguinte forma:
Totalmente implementado (T):
A evidncia est presente e julgada adequada;
No foi notado ponto fraco algum na avaliao.
Largamente implementado (L):
A evidncia est presente e julgada adequada;
Foi notado um ou mais pontos fracos na avaliao.
Parcialmente implementado (P):
A evidncia no est presente ou julgada inadequada;
Foi notado um ou mais pontos fracos na avaliao.
No implementado (N):
Qualquer situao diferente das acima.
No avaliado (NA):
O projeto no est na fase de desenvolvimento que permite atender ao resultado esperado;
No faz parte do escopo do projeto atender ao resultado esperado.
53
Resultados esperados - Gerncia de Projetos

O objetivo desse processo determinar e manter planos que definem as atividades, os recursos e as responsabilidades do projeto, bem como a monitorao do projeto
de forma que, quando houver desvios significativos, permitam-se realizar correes.
GPR 1. O escopo do trabalho para o projeto definido
O objetivo deste resultado esperado encontrar evidncias que comprovem que
o escopo do projeto foi definido, ou seja, o que precisa ser realizado, as caractersticas e
limites do projeto e seus produtos e servios e critrios de aceitao do produto, foram
definidas em algum momento do projeto. As evidncias encontradas para este resultado
esperado esto relacionadas no Quadro 9.
Quadro 9 Evidncias GPR 1
Encargos
Acadmicos
-Reunio para apresentao do projeto infraestrutura contendo o escopo

do projeto
-Documento da Solicitao do projeto
-Escopo do projeto definido no Documento de Viso
-Ata da reunio para definio do escopo do projeto realizada no dia
18/08/2011
Grau de implementao
Infraestrutura
Evidncias
x
x
x
x
T
Nos documentos apresentados, foram percebidas informaes referentes a especificao do escopo do projeto, definindo o que precisa ser realizado e quais os produtos
e servios desejados.
GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados utilizando
mtodos apropriados
a complexidade ou tamanho das tarefas foram dimensionadas de acordo com mtodos
adequados. As evidncias encontradas para este resultado esperado esto relacionadas
no Quadro 10.
Atravs das evidncias encontradas, observa-se que realizado o dimensionamento das tarefas utilizando o conhecimento da equipe baseando-se em dados histricos.
No foram encontrados registros de como feito esse dimensionamento. Porm, consultando os colaboradores do projetos, foi verificado que para definir a complexidade
54

Encargos
Acadmicos
-O tamanho das tarefas so estimadas em relao ao tempo estimado, que

definido baseando-se em dados histricos e experincia dos membros
da equipe
-O tempo dos requisitos, de forma geral, foi definido no documento
PlanejamentoEncargosAcademicos.doc
-O dimensionamento das tarefas so realizados durante reunio com a
equipe
Grau de implementao
Infraestrutura
Evidncias
x
x
ou tamanho de cada tarefa, feita uma consulta aos membros da equipe para se chegar
em um consenso sobre o valor estimado.
GPR 3. O modelo e as fases do ciclo de vida do projeto so definidos
foi definido o modelo e as fases do ciclo de vida do projeto, indicando a relao de
sequncia e interdependncia entre elas. As evidncias encontradas para este resultado
esperado esto relacionadas no Quadro 11.
Encargos
Acadmicos
-A definio das fases, a relao de sequncia entre elas e etapas de

reviso e aceitao esto presentes no documento que define o processo
do EP
-Foram encontradas evidncias das reunies para sprint planning e sprint
retrospective
Grau de implementao
Infraestrutura
Evidncias
GPR 4. O esforo e o custo para a execuo das tarefas e dos produtos de trabalho
so estimados com base em dados histricos ou referncias tcnicas
O objetivo deste resultado esperado encontrar evidncias que comprovem
que foram realizadas estimativas de custo e esforo para as tarefas baseadas em dados
55
histricos ou mtodos de estimativas e foram documentadas as suas justificativas. As

evidncias encontradas para este resultado esperado esto relacionadas no Quadro 12.
Encargos
Acadmicos
-O tempo estimado das tarefas definido baseando-se na experincia dos

membros da equipe
-No foram encontradas evidncias documentando as justificativas
Grau de implementao
Infraestrutura
Evidncias
x
P
x
P
Com base nas evidncias apresentadas, verifica-se que, embora as estimativas

de esforos e custo sejam obtidas, no foram encontradas registros documentando as
suas justificativas.
GPR 5. O oramento e o cronograma do projeto, incluindo a definio de marcos e
pontos de controle, so estabelecidos e mantidos
que foi definido um cronograma, contendo marcos, pontos de controle e relao de
dependncia entre as tarefas, e este cronograma foi revisto e atualizado durante o
desenvolvimento do projeto. As evidncias encontradas para este resultado esperado
esto relacionadas no Quadro 13.
Encargos
Acadmicos
-Marcos do projetos so definidos como verses. Cada verso possui

uma lista de tarefas a serem realizadas. Verses so entregues ao cliente
regularmente (+/- a cada 15 dias)
-Oramento no contexto do EP o tempo gasto, que estimado na criao
de cada tarefa, e revisado/atualizado durante o desenvolvimento
-As relao entre as tarefas mantida utilizando a ferramenta Redmine.
Dependncia entre tarefas so registradas atravs de um relacionamento
entre elas
-Foi definida uma data prevista para cada uma das tarefas do sprint,
formando assim um cronograma
Grau de implementao
Infraestrutura
Evidncias
x
L
56
No foram encontradas evidncias de uma cronograma explcito para o projeto,

mas so definidas durante as sprints, datas para entregas das verses, que so os marcos
dos projetos.
GPR 6. Os riscos do projeto so identificados e o seu impacto, probabilidade de
ocorrncia e prioridade de tratamento so determinados e documentados
foram identificados e monitorados os riscos para os projetos. As evidncias encontradas
para este resultado esperado esto relacionadas no Quadro 14.
-No foram encontradas definies de riscos do projeto

-Foram levantados os riscos do projeto ser abandonado diante da eminn- x
cia do principal cliente mudar de funo no CEFET. Foram levantados
outros possveis clientes para o projeto
-Na listagem de requisitos foram informados os riscos associados eles. x
Grau de implementao L
Encargos
Acadmicos
Infraestrutura
Evidncias
Para o projeto Infraestrutura, foram feitos levantamentos de possveis riscos,

sendo um deles o principal cliente do projeto deixar a funo atual, como consequncia de uma possvel troca de gesto do CEFET-MG. O impacto desse risco poderia
resultar em um abandonamento do projeto, caso o substituto do cliente atual no tivesse alinhado com os mesmo objetivos. Para mitigar esse risco, buscaram-se outros
possveis clientes interessados no projeto. No foram encontradas evidncias de uma
levantamento de riscos semelhante no projeto Encargos Acadmicos.
GPR 7. Os recursos humanos para o projeto so planejados considerando o perfil e
o conhecimento necessrios para execut-lo
foi definido um plano de gerenciamento de recursos humanos, considerando os papeis
ou as habilidades requeridas para execuo das atividades do projeto e o perfil dos
candidatos. As evidncias encontradas para este resultado esperado esto relacionadas
no Quadro 15.
57

Encargos
Acadmicos
-Alocao da equipe foi selecionada durante reunio com toda a equipe

do EP
-Como os recursos humanos do EP eram escassos, todos participaram da
equipe
-Foram realizados treinamentos pela Squadra para toda equipe
Grau de implementao
Infraestrutura
Evidncias
x
x
x
P
x
P
No foram encontrados uma definio clara dos perfis dos funcionrios, mas na
definio da equipe para o projeto Infraestrutura foram consideradas as habilidades
de cada um, de acordo com as atividades a serem desenvolvidas.
GPR 8. Os recursos e o ambiente de trabalho necessrios para executar o projeto so
planejados
que foram planejados os recursos e o ambiente de trabalho e foram analisadas as
compatibilidades entre o ambiente do cliente e o do EP, e caso necessrio, as adaptaes
tambm foram planejadas. As evidncias encontradas para este resultado esperado
Encargos
Acadmicos
-Os recursos fsicos necessrios que diferem do usual (mquinas com

acesso a internet) foram definidos em reunio com o cliente
-No foram identificados recursos diferentes do usual (mquinas com
acesso a internet)
Grau de implementao
Infraestrutura
Evidncias
x
x
T
NA
Usualmente, os recursos de ambiente de trabalho e recursos necessrios para os

projetos so sempre os mesmos (computadores com acesso a internet), mas quando so
necessrios recursos diferentes do usual, como no projeto Infraestrutura, por exemplo,
leitores de cdigo de barras foram considerados como requisitos.
58
GPR 9. Os dados relevantes do projeto so identificados e planejados quanto forma

de coleta, armazenamento e distribuio. Um mecanismo estabelecido para acesslos, incluindo, se pertinente, questes de privacidade e segurana
existe um plano para gerncia de dados, relacionando todos os artefatos gerados e sua
forma de proteo, obedecendo as polticas de privacidade e segurana. As evidncias
encontradas para este resultado esperado esto relacionadas no Quadro 17.
Encargos
Acadmicos
-Os artefatos gerados no projeto esto distribudos em uma estrutura de

pastas definida e armazenada no repositrio
-Existe um sistema interno para controle e gerenciamento das atas geradas
-Somente usurios com as devidas permisses podem acessar os documentos
Grau de implementao
Infraestrutura
Evidncias
x
x
x
x
Para gerncia de dados, foi criada pelo EP um mdulo de documentao para

manter os registros das atas, do documento de viso, dos casos de usos e dos requisitos.
GPR 10. Um plano geral para a execuo do projeto estabelecido com a integrao
de planos especficos
existe um plano de projeto geral que integra todos os planos do projeto, relacionandoos entre si. O plano de projeto deve conter todas as informaes necessrias para a
realizao do projeto. As evidncias encontradas para este resultado esperado esto
relacionadas no Quadro 18.
GPR 11. A viabilidade de atingir as metas do projeto explicitamente avaliada considerando restries e recursos disponveis. Se necessrio, ajustes so realizados
foi realizada uma anlise de viabilidade para o projeto, considerando os objetivos do
projeto e dos recursos financeiros, tcnicos, humanos, bem como das restries impostas
pelo cliente. As evidncias encontradas para este resultado esperado esto relacionadas
no Quadro 19.
59

Encargos
Acadmicos
Infraestrutura
Encargos
Acadmicos
-O planejamento do projeto foi realizado durante reunio com a equipe

e documentada em ata. Foram planejados quais as prioridades para o
prximo semestre
-Foi documentado na ferramenta Redmine informaes sobre o planejamento geral do projeto e relacionadas tarefas menores mais especficas
-Foram realizadas reunies para planejamento do projeto. Definido o planejamento geral, foram realizadas reunies de sprints para planejamento
das tarefas
Grau de implementao
Infraestrutura
Evidncias
Evidncias
-Pedido de anlise de viabilidade feito pelo cliente

-Resultado da reunio de anlise de viabilidade documentado na tarefa
no Redmine
-No foram encontradas evidncias que comprovem existir uma anlise
de viabilidade
Grau de implementao
x
x
x
L
Para o projeto Infraestrutura foi encontrada evidncias de uma anlise de

viabilidade, embora, no tenha sido definida de forma explicita, foram realizadas
reunies para avaliar se o projeto seria vivel de acordo com os objetivos do cliente.
GPR 12. O Plano do Projeto revisado com todos os interessados e o compromisso
com ele obtido e mantido
todos os interessados possuem conhecimento e revisaram o plano de projeto quando
necessrio. As evidncias encontradas para este resultado esperado esto relacionadas
no Quadro 20.
60
-O planejamento do projeto feito durante reunio com a equipe e docu- x

mentada em ata. Todos os participantes da reunio recebem um cpia da
ata e se comprometem com o que foi discutido. O recomprometimento
ocorre durante as prximas reunies
Grau de implementao T
Encargos
Acadmicos
Infraestrutura
Evidncias
GPR 13. O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto

so monitorados em relao ao planejado
foi feito uma comparao entre o realizado e o planejado em relao ao escopo, prazo,
esforos, custos e cronograma. As evidncias encontradas para este resultado esperado
Encargos
Acadmicos
-Foram realizadas reunies semanalmente para acompanhamento entre o

planejado e o realizado. Todas as reunies foram documentadas em ata.
-Foram realizadas reunies a cada 15 dias para acompanhamento entre o
planejado e o realizado. Todas as reunies foram documentadas em ata.
Grau de implementao
Infraestrutura
Evidncias
x
x
T
De acordo com as evidncias, observa-se que foram realizadas um monitoramento em relao s tarefas durante reunies semanais ou quinzenais no decorrer do
projeto. Essas reunies so denominadas reunies de sprint.
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do projeto
so monitorados em relao ao planejado
que foram monitorados os recursos materiais e humanos em relao ao planejado. As
61
-O monitoramento dos recursos humanos e materiais foi realizado du- x

rante as reunies de sprint realizadas quinzenalmente. Ajustes foram
realizados quando necessrio. Todas as reunies foram documentadas
em ata.
-O monitoramento dos recursos humanos e materiais foi realizado durante as reunies de sprint realizadas semanalmente. Todas as reunies
foram documentadas em ata.
Encargos
Acadmicos
Infraestrutura
Evidncias
GPR 15. Os riscos so monitorados em relao ao planejado

que foram comparados os riscos planejados com o que foi realizado. As evidncias
encontradas para este resultado esperado esto relacionadas no Quadro 23.
Encargos
Acadmicos
-No foram planejados os riscos em relao ao projeto

-No foram encontradas evidncias do do processo de monitoramento
dos riscos
Grau de implementao
Infraestrutura
Evidncias
x
x
N
GPR 16. O envolvimento das partes interessadas no projeto planejado, monitorado

e mantido
As evidncias encontradas para este resultado esperado esto relacionadas no
Quadro 24.
foi planejado o envolvimento das partes interessadas, e os compromissos assumidos
foram cumpridos ou negociados.
Durante a busca de evidncias para esse resultado esperado, observou-se que
uma prtica do EP realizar reunies com os interessados, sendo que nunca devem ser
realizadas por apenas um integrante da equipe e sempre devem ser registradas em ata.
62

Encargos
Acadmicos
-Os compromissos assumidos so feitos durante reunies e registrados

em ata. As atas so enviadas para todos os participantes das reunies
-As reunies ocorreram regularmente entre os interessados
Grau de implementao
Infraestrutura
Evidncias
x
T
x
T
GPR 17. Revises so realizadas em marcos do projeto e conforme estabelecido no

planejamento
ocorreram revises nos marcos do projeto e em outros pontos estabelecidos no planejamento. As evidncias encontradas para este resultado esperado esto relacionadas no
Quadro 25.
-Marcos so definidos como verses do projeto que representam o desen- x

volvimento em um sprint. Aps cada sprint realizado uma reunio para
revisar tudo o que foi feito. Todas as reunies so documentadas em ata.
-O desenvolvimento de uma sprint considerado como um marco do
projeto. Aps cada sprint realizado uma reunio para revisar tudo o
que foi feito
Encargos
Acadmicos
Infraestrutura
Evidncias
So realizadas reunies de sprint retrospective ao final de cada sprint.

GPR 18. Registros de problemas identificados e o resultado da anlise de questes
pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas
existem registros dos problemas ocorridos durante o projeto, e estes problemas foram
tratados com os interessados. As evidncias encontradas para este resultado esperado
63

Encargos
Acadmicos
-Os problemas ocorridos nos projetos so documentados nas tarefas no

Redmine
-Os problemas so tratados com os interessados em reunies e registrados
em ata
Grau de implementao
Infraestrutura
Evidncias
GPR 19. Aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas
at a sua concluso
Quadro 27.
Encargos
Acadmicos
Infraestrutura
Evidncias
- feita a documentao dos problemas e quando necessrio documen- x

tada a soluo na wiki
-Aes para corrigir os problemas so documentadas em ata quando

decididas durante reunies
-So criadas tarefas para correo dos problemas, estas so acompanhadas

e analisadas antes de serem concludas
Grau de implementao
Existe uma seo na wiki, no Redmine, para resoluo e preveno de problemas

comuns de ocorrerem.
Resultados esperados - AP 1.1 - O processo executado - Gerncia de Projetos
RAP 1. O processo atinge seus resultados definidos
Quadro 28.
64
Quadro 28 Evidncias RAP 1 - Gerncia de Projetos
Grau de implementao
Encargos
Acadmicos
-Os produtos do processo so gerados
Infraestrutura
Evidncias
x
T
x
T
O processo de Gerncia de Projetos foi executado pelo EP. O planejamento das

atividades e o acompanhamento das mesmas so executados por toda a equipe.
Resultados esperados - AP 2.1 - O processo gerenciado - Gerncia de Projetos
RAP 2. Existe uma poltica organizacional estabelecida e mantida para o processo
existir normas, diretrizes gerais, apontamentos gerais que balizam o processo de Gerncia de Projetos no EP. As evidncias encontradas para este resultado esperado esto
Encargos
Acadmicos
-Polticas organizacionais foram disponibilizadas em forma de wiki disponvel para todos os interessados
-Histrico de atualizaes na wiki confirma que a poltica foi atualizada
quando necessrio
-Cursos financiados pelo CEFET confirmam o respaldo da alta administrao
Grau de implementao
Infraestrutura
Evidncias
RAP 3. A execuo do processo planejada

que existe uma planejamento das atividades do processo de Gerncia de Projetos. As
65

Encargos
Acadmicos
-So planejadas a cada reunio as atividades para o prximo sprint (sprint

planning)
Grau de implementao
Infraestrutura
Evidncias
x
T
RAP 4. A execuo do processo monitorada e ajustes so realizados

Quadro 31.
Encargos
Acadmicos
-So realizadas regularmente reunies para monitoramento das tarefas

do sprint (sprint retrospective)
Grau de implementao
Infraestrutura
Evidncias
RAP 5. As informaes e os recursos necessrios para a execuo do processo so

identificados e disponibilizados
esto disponveis as informaes para execuo do projeto, como por exemplo: guias,
modelos, padres e processos. As evidncias encontradas para este resultado esperado
RAP 6. As responsabilidades e a autoridade para executar o processo so definidas,
atribudas e comunicadas
Quadro 33.
Embora, no caso de uma metodologia gil, as responsabilidades e autoridade
sejam diludas por toda a equipe, so definidas responsabilidades especficas durante
as reunies de planejamento da sprint.
66
-So disponibilizados guias, tutoriais, modelos e padres na wiki para x

facilitar a execuo do processo
-As informaes necessrias para execuo da sprint so divididas em ta- x
refas e as informao necessrias para sua execuo so disponibilizadas
no Redmine
Encargos
Acadmicos
Infraestrutura
Evidncias
x
x
Evidncias
Infraestrutura
Encargos
Acadmicos
-Foram documentadas as responsabilidades nas reunies de sprint

Grau de implementao
x
L
x
L
RAP 7. As pessoas que executam o processo so competentes em termos de formao,

treinamento e experincia
Quadro 34.
Encargos
Acadmicos
-Todos os participantes so competentes em termos de formao e feito

uma espcie de mentoria pelos integrantes mais experientes quando
necessrio. So realizados cursos para aprimoramento das habilidades
Grau de implementao
Infraestrutura
Evidncias
Para este resultado esperado, foram encontradas evidncias de cursos de Scrum

e outros cursos oferecidos pelo CEFET-MG, ministrados pela SQUADRA.
67
RAP 8. A comunicao entre as partes interessadas no processo planejada e executada de forma a garantir o seu envolvimento
Quadro 35.
-A comunicao entre as partes interessadas realizada atravs de reu- x

nies que so todas registradas em ata e troca de e-mails
Encargos
Acadmicos
Infraestrutura
Evidncias
x
T
RAP 9. Os resultados do processo so revistos com a gerncia de alto nvel para

fornecer visibilidade sobre a sua situao na organizao
Quadro 36.
-So realizadas reunies para reviso dos resultados. Quando necessrio, x

so envolvidas a gerncia de alto nvel
Encargos
Acadmicos
Infraestrutura
Evidncias
x
T
RAP 10. O processo planejado para o projeto executado

O objetivo deste resultado esperado encontrar registros de execuo das atividades do processo com base no seu planejamento. As evidncias encontradas para este
resultado esperado esto relacionadas no Quadro 37.
Resultados esperados - Gerncia de Requisitos
GRE 1. O entendimento dos requisitos obtido junto aos fornecedores de requisitos
que foram levantados os requisitos para o projeto e estes foram aceitos pelos clien-
68

Encargos
Acadmicos
-So registradas no Redmine e em ata de reunies as informao referente

ao monitoramento das atividades do processo
Grau de implementao
Infraestrutura
Evidncias
tes ou representantes. As evidncias encontradas para este resultado esperado esto

Quadro 38 Evidncias GRE 1
Encargos
Acadmicos
-Existe um documento de requisitos que fruto de uma reunio entre os

responsveis pelo projeto e o cliente. Essa reunio foi registrada em ata
-Foi realizada uma reunio para anlise e levantamento dos requisitos do
projeto
-Existe um documento com o levantamento dos requisitos do sistema
Grau de implementao
Infraestrutura
Evidncias
x
x
x
T
GRE 2. Os requisitos so avaliados com base em critrios objetivos e um comprometimento da equipe tcnica com estes requisitos obtido
Quadro 39.
Encargos
Acadmicos
-O comprometimento da equipe tcnica com os requisitos feito no

momento da reunio com o cliente, onde so coletados os requisitos para
o sistema. Reunio registrada em ata
-Nova reunio para adio de requisitos para o projeto
Grau de implementao
Infraestrutura
Evidncias
x
T
69
GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho

estabelecida e mantida
Quadro 40.
-Existem rastreabilidade dos requisitos para as tarefas criadas no Red- x

mine e das tarefas para as partes do cdigo alteradas em funo da tarefa
-Existem rastreabilidade entre as tarefas criadas para cada requisito e as
partes do cdigo alteradas em funo delas
Encargos
Acadmicos
Infraestrutura
Evidncias
x
L
No projeto Infraestrutura, existe na planilha de requisitos uma referncia

para a tarefa criada no Redmine para o desenvolvimento de cada requisito. No foi
encontrado uma ligao entre os requisitos e as tarefas, de uma forma to explcita, no
projeto Encargos Acadmicos.
GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas visando
identificar e corrigir inconsistncias em relao aos requisitos
Quadro 41.
-So realizadas reunies ao final de cada sprint para revisar o que foi x
produzido. So definidos encaminhamentos caso sejam encontrados inconsistncias
Encargos
Acadmicos
Infraestrutura
Evidncias
GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto

Quadro 42.
70

Encargos
Acadmicos
-O histrico de solicitaes existente so as atas das reunies e e-mails

trocados com o cliente
-O impacto discutido entre a equipe e com o cliente. Quando feito em
reunio, registro em ata
-So criadas tarefas para as alteraes e o histrico mantido pelo sistema
de versionamento
Grau de implementao
Infraestrutura
Evidncias
Resultados esperados - AP 1.1 O processo executado - Gerncia de Requisitos

RAP 1. O processo atinge seus resultados definidos
O objetivos desse resultado esperado verificar se o processo de Gerncia de
Requisitos foi executado. As evidncias encontradas para este resultado esperado esto
Quadro 43 Evidncias RAP 1 - Gerncia de Requisitos
-Foram gerados os produtos do processo, como por exemplo, o docu- x

mento de levantamento dos requisitos
Encargos
Acadmicos
Infraestrutura
Evidncias
x
T
Resultados esperados - AP 2.1 O processo gerenciado - Gerncia de Requisitos

RAP 2. Existe uma poltica organizacional estabelecida e mantida para o processo
Quadro 44.
Assim como existem polticas organizacionais para o processo de Gerncia de
Projetos, tambm foram definidas as polticas para Gerncia de Requisitos.
71
-Polticas organizacionais foram disponibilizadas em forma de wiki dis- x

ponvel para todos os interessados
-Histrico de atualizaes na wiki confirma que a poltica foi atualizada x
quando necessrio
Encargos
Acadmicos
Infraestrutura
Evidncias
x
x
T
RAP 3. A execuo do processo planejada

existe uma planejamento das atividades do processo de Gerncia de Requisitos. As
Encargos
Acadmicos
-O planejamento est presente no documento que define o processo de

levantamento e anlise de requisitos.
Grau de implementao
Infraestrutura
Evidncias
RAP 4. A execuo do processo monitorada e ajustes so realizados

Quadro 46.
-So realizadas regularmente reunies para monitoramento das ativida- x

des do sprint (sprint retrospective)
Encargos
Acadmicos
Infraestrutura
Evidncias
x
T
72
Durante a fase de levantamento de requisitos dos projetos, as reunies de sprint

planning e sprint retrospective so voltadas Gerncia de Requisitos.
RAP 5. As informaes e os recursos necessrios para a execuo do processo so
identificados e disponibilizados
Quadro 47.
Encargos
Acadmicos
-Todos os requisitos levantados so documentados e esto disponveis

para toda a equipe.
Grau de implementao
Infraestrutura
Evidncias
RAP 6. As responsabilidades e a autoridade para executar o processo so definidas,

atribudas e comunicadas
Quadro 48.
-Foram documentadas as responsabilidades nas reunies de sprint plan- x

ning e sprint restrospective
Encargos
Acadmicos
Infraestrutura
Evidncias
x
L
RAP 7. As pessoas que executam o processo so competentes em termos de formao,

treinamento e experincia
Quadro 49.
Na metodologia adotada pelo EP, todos os integrantes da equipe podem executar
o processo de Gerncia de Requisitos. Esses integrantes so competentes de acordo com
sua formao e cursos de capacitao realizados.
73

Encargos
Acadmicos
-Todos os participantes so competentes em termos de formao e feito

uma espcie de mentoria pelos integrantes mais experientes quando
necessrio. So realizados cursos para aprimoramento das habilidades
Grau de implementao
Infraestrutura
Evidncias
RAP 8. A comunicao entre as partes interessadas no processo planejada e executada de forma a garantir o seu envolvimento
Quadro 50.
-A comunicao entre as partes interessadas realizada atravs de reu- x

nies, que so todas registradas em ata, e troca de e-mails
Encargos
Acadmicos
Infraestrutura
Evidncias
x
T
RAP 9. Os resultados do processo so revistos com a gerncia de alto nvel para

fornecer visibilidade sobre a sua situao na organizao
Quadro 51.
-So realizadas reunies para reviso dos resultados. Quando necessrio, x

so envolvidas a gerncia de alto nvel.
Encargos
Acadmicos
Infraestrutura
Evidncias
x
L
74
RAP 10. O processo planejado para o projeto executado

O objetivo deste resultado esperado encontrar registros de execuo das atividades do processo com base no seu planejamento. As evidncias encontradas para este
resultado esperado esto relacionadas no Quadro 52.
5.3.4
Encargos
Acadmicos
-So registradas no Redmine e em ata de reunies as informao referente

ao monitoramento das atividades do processo
Grau de implementao
Infraestrutura
Evidncias
Pontos fortes, fracos e oportunidades de melhorias
Diante do resultado da verificao dos indicadores de implementao, na avaliao inicial, foram analisados os pontos fortes, fracos e as oportunidades de melhoria. A
definio para cada um destes itens, se d de acordo ao disposto no Guia Geral MPS de
Software (SOFTEX, 2012):
Pontos fortes: uma implementao excepcionalmente boa de um resultado de
processo ou de algo acima do requerido do nvel de maturidade que foi avaliado;
Pontos fracos: uma implementao inadequada ou que no atende aos requisitos
de um resultado requerido por algum processo do nvel de maturidade que foi
avaliado;
Oportunidade de melhoria: uma implementao de um resultado de processo
que pode ser melhorada, mas que atende aos requisitos mnimos de um resultado
requerido que foi avaliado.
Foram registradas observaes para os resultados esperados de acordo com sua
implementao, seguindo os critrios acima definidos, conforme mostra o Quadro 53.
5.4
Consideraes
Realizada a avaliao inicial, observou-se que o processo de desenvolvimento

de software do EP est prximo de alcanar o nvel G, escolhido para avaliao. Foram
levantados algumas oportunidades de melhorias e pontos fracos que ainda precisam ser
75
Quadro 53 Relao de pontos fortes, pontos fracos e oportunidades de melhorias

Resultado esperado
GPR 2, GPR 4
Observao
-No foram encontradas as
justificativas para os mtodos
utilizados.
Classificao
Oportunidade de melhoria
GPR 5, GPR 13
-No foi definido um cro- Oportunidade de melhoria

nograma
explicitamente.
-Planejamento de tarefas
maiores dificultam o monitoramento e manuteno do
planejado.
GPR 6, GPR 15
-Faltam evidncias de geren- Ponto fraco

ciamento de risco no projeto
Encargos Acadmicos.
GPR 7, GPR 14
-No foram encontradas as Oportunidade de melhoria

definies de perfis dos membros da equipe.
-No foram encontradas as definies de papis para o EP.
GPR 9
-Existe dentro do sistema de- Ponto forte

senvolvido pelo EP um mdulo para controle da documentao.
GPR 11
-No foram encontradas evi- Ponto Fraco

dncias de anlise de viabilidade para o projeto Encargos
Acadmicos
GPR 18, GPR 19
-So documentados os proble- Ponto forte

mas ocorridos no Redmine. Quando necessrio foram adicionadas na wiki os passos
para soluo de problemas recorrentes.
ajustados, mas em geral, grande parte dos processos de Gerncia de Projetos e Gerncia
de Requisitos so executados. Pensando nisso, no prximo captulo ser discutido
um plano de melhorias para auxiliar as mudanas necessrias, a fim de se adequar
completamente ao nvel proposto.
76
6 Plano de melhorias
Neste captulo, apresentado o plano de melhorias proposto com base nos

resultados da avaliao do processo de software no EP.
O plano de melhorias constitudo por um conjunto de atividades que tm como
objetivo auxiliar o processo de desenvolvimento de software a satisfazer os resultados
esperados para o nvel G do MPS.BR e, assim, melhorar o processo atual. Para a definio
do plano de melhorias, foram priorizados os pontos fracos e oportunidades de melhorias
levantadas durante a avaliao, mostradas no Quadro 53.
As atividades que fazem parte do plano de melhorias so descritas neste captulo.
6.1
Atividade 1: Gerenciamento de riscos
A primeira atividade do plano de melhorias referente ao gerenciamento de

riscos. Foi identificada durante a avaliao uma certa deficincia no processo de gerenciamento de riscos, portanto, pretende-se implantar no processo do EP uma etapa para
levantamento e monitoramento dos riscos identificados para o projeto.
O gerenciamento de riscos uma atividade que deve ser executada na etapa
de concepo e deve ser monitorada durante todo o desenvolvimento do projeto.
interessante que o gerenciamento de riscos passe a ser um tema regularmente abordado
nas reunies de sprint.
6.1.1
Ferramentas utilizadas
Para a execuo desta atividade, ser necessria a utilizao do plugin para o

Redmine chamado RedRisk. Esse plugin permite o cadastro de riscos, definio de
probabilidades, impactos e aes para mitig-los. A Figura 9 mostra a interface do
plugin.
6.1.2
Artefatos produzidos
Com a utilizao da ferramenta, ser produzida uma lista de riscos identificados

para o projeto, contendo uma anlise de impactos, probabilidade, prioridades e aes a
serem executadas.
6.1.3
Resultados esperados atendidos

Com a realizao dessa atividade, os seguintes resultados sero atendidos:
Captulo 6. Plano de melhorias
77
Figura 9 Plugin RedRisk
GPR 6. Os riscos do projeto so identificados e o seu impacto, probabilidade de

ocorrncia e prioridade de tratamento so determinados e documentados.
GPR 15. Os riscos so monitorados em relao ao planejado.
6.1.4
Restries para implantao
Para implantar essa atividade no processo atual, deve-se atentar para as restries
de infraestrutura. Ser necessrio a atualizao da ferramenta Redmine para uma verso
superior a 2.6.x e instalao do plugin RedRisk.
6.2
Atividade 2: Anlise de complexidade das tarefas
Foram percebidas durante a avaliao algumas dificuldades ao buscar as justificativas utilizadas na definio do tamanho das tarefas. Embora as estimativas sejam
realizadas, o mtodo utilizado para esta definio pode ser muito subjetivo em algumas
ocasies. Isso ocorre porque a medida utilizada para complexidade e custo so feitas
em relao ao tempo estimado para concluso da tarefa; esse valor varia de acordo
com cada membro da equipe, podendo ser um estagirio ou servidor, experiente ou
no com a atividade a ser desenvolvida. Esse modelo de estimativa de tempo tem se
mostrado no ser muito efetivo. Para solucionar esse problema, a estratgia desacoplar
o tempo estimado da complexidade da tarefa, adicionando o atributo complexidade no
78
gerenciamento das mesmas. Outra sugesto utilizar uma tcnica como o ideal days 1 ou
planning poker2 para o clculo desse atributo.
6.2.1
Para a execuo desta atividade no ser necessria ferramenta nova. Faz-se

necessria apenas uma configurao na ferramenta Redmine j utilizada no EP. Ser
necessrio adicionar o campo complexidade nas tarefas, podendo assumir um valor
numrico que indicar a sua complexidade.
6.2.2
Sero adicionadas s tarefas informaes referentes s complexidades das mes-
mas.
6.2.3

GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados

utilizando mtodos apropriados.
GPR 4. O esforo e o custo para a execuo das tarefas e dos produtos de trabalho
so estimados com base em dados histricos ou referncias tcnicas.
6.2.4

Esta atividade pode ser implantada de imediato sem restrio.
6.3
Atividade 3: Gerenciamento dos recursos humanos
Essa atividade foi criada para garantir que os recursos humanos disponveis
esto sendo distribudos da melhor forma possvel. Para essa atividade devem ser identificados os papis necessrios no EP, descrevendo suas responsabilidades e qualificaes
necessrias. Posteriormente definio de papis necessrios, deve ser construdo um
mapa com os perfis de cada um dos membros da equipe, identificando as habilidades
e competncias individuais. Essa medida visa facilitar a definio das subequipes e
identificar possveis deficincias, permitindo, assim, direcionar cursos e treinamentos
para esses casos.
1
2
Tcnica para estimativa de esforo e tamanho que se baseia no tempo que seria gasto, caso a tarefa
seja a nica a ser realizada, sem interrupes e todos os recursos disponveis.
Tcnica para estimativa de esforo e tamanho comumente utilizada no Scrum.
79
O Quadro 54 sugere a definio de papis, e o Quadro 55, o mapa de perfis:

Quadro 54 Modelo para descrio dos papis
Papel
Tester
Descrio
Responsvel pelas
principais atividades de teste
Habilidades
Responsabilidades
Conhecimento de Testar os sistemas
abordagens e tcni- desenvolvidos
cas de teste
Quadro 55 Modelo para o mapa de perfis

Funcionrio
Funcionrio 1
6.3.1
Habilidades
Experincia
Cursos realizados
Conhecimentos de 2 anos como tester Mtodos geis em
automao de tes- na empresa X
Teste de Software
tes
No so necessrias ferramentas extras para execuo desta atividade.
6.3.2
Ser produzido com a execuo desta tarefa o mapa de perfis e a descrio de

papis.
6.3.3

GPR 7. Os recursos humanos para o projeto so planejados considerando o perfil

e o conhecimento necessrios para execut-lo.
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do
projeto so monitorados em relao ao planejado.
6.3.4

6.4
Atividade 4: Anlise de viabilidade
A incorporao desta atividade ao processo tem como objetivo explicitar a anlise

de viabilidade do projeto. Como foi observada na avaliao, no foi realizada a anlise
de viabilidade para o projeto Encargos Acadmicos e, apesar de ter sido realizada
a anlise para o projeto Infraestrutura, as informaes do resultado desta anlise
80
no estavam documentadas de forma explcita, dificultando a visibilidade para todos

os interessados. Essa atividade consiste na insero de uma reunio de viabilidade
para todo novo projeto. Como toda reunio, deve ser registrada em ata os resultados e
ponderaes realizadas.
6.4.1
No so necessrias ferramentas extras para execuo desta atividade.
6.4.2
Ser produzido com a execuo desta atividade uma anlise de viabilidade do

projeto.
6.4.3

GPR 11. A viabilidade de atingir as metas do projeto explicitamente avaliada

considerando restries e recursos disponveis. Se necessrio, ajustes so realizados.
6.4.4

6.5
Atividade 5: Melhorias no planejamento da sprint
Esta no uma nova atividade, mas sim, uma srie de sugestes para melhorias
na atividade de planejamento da sprint, j presente no processo do EP.
Com base nas observaes realizadas durante a avaliao, foram sugeridas as
seguintes alteraes:
1. Particionar tarefas em tarefas menores: foi observado que regularmente eram
atribudas tarefas com tamanho maior do que uma sprint para membros da equipe.
O procedimento utilizado nesses casos era de postergar a concluso da tarefa em
uma ou mais sprints, sendo realizado apenas uma atualizao do andamento da
tarefa durante as reunies realizadas nesse intervalo de tempo. A recomendao
do Scrum de manter sempre tarefas pequenas. Com base nisso, sugere-se que
essas tarefas sejam divididas em tarefas menores, com o escopo adequado para
uma sprint.
81
2. Separar sprint backlog da verso do projeto: atualmente as tarefas que so planejadas para serem executadas em uma sprint entram automaticamente na prxima
verso do projeto. O problema que algumas destas atividades no podem entrar
para produo e, por isso, algumas tarefas realizadas durante uma sprint precisam
ser retiradas da verso. Visando contornar esses problemas, sugere-se manter um
controle distinto entre verso e sprint backlog.
3. Planejamento das tarefas: foi observado que uma prtica utilizada pela equipe
no projeto Encargos Acadmicos, mas que no foi aplicada no projeto Infraestrutura. Trata-se do registro de estimativa de data para incio e trmino das
tarefas. Essa prtica permite gerar um cronograma mais detalhado, facilitando o
monitoramento do projeto.
6.5.1
Para realizao destas melhorias, sero necessrias duas novas ferramentas:
1. Para separar o acompanhamento das tarefas de uma sprint da verso do projeto,

ser necessrio a instalao do plugin Scrum para o Redmine, que permite o
gerenciamento de tarefas por sprint, conforme exemplifica a Figura 10:
Figura 10 Plugin Scrum
2. Para facilitar o planejamento das tarefas, definindo a data de incio e trmino das
mesmas, recomenda-se a instalao do plugin Redmine Planning. Embora no
seja essencial, um facilitador para registrar as previses de incio e trmino das
tarefas. A Figura 11 mostra a ferramenta.
82
Figura 11 Plugin Redmine Planning
6.5.2
Ser produzido um cronograma detalhado do projeto e o Sprint Backlog, desta

vez, separado do versionamento do projeto.
6.5.3

GPR 5. O oramento e o cronograma do projeto, incluindo a definio de marcos

e pontos de controle, so estabelecidos e mantidos.
GPR 13. O escopo, as tarefas, as estimativas, o oramento e o cronograma do
projeto so monitorados em relao ao planejado.
6.5.4
Para implantao das melhorias sugeridas, necessrio a atualizao da verso

do Redmine para a 3.0.x.
6.6
Como forma de avaliar o plano de melhorias proposto, do ponto de vista da

equipe do Escritrio de Projetos, foi aplicado um questionrio entre os membros da
equipe com o objetivo de verificar:
o nvel de satisfao dos membros da equipe com o plano de melhorias proposto;
83
o impacto na qualidade dos projetos desenvolvidos;

a possibilidade de implantao;
a facilidade de adequao da equipe;
a priorizao das atividades.
Para isso foram elaboradas cinco questes, contendo quatro afirmativas e uma
pergunta, e verificado o nvel de concordncia dos integrantes do EP com cada uma
delas (com exceo da pergunta). Foram utilizadas o formato tpico de item de Likert
(FITZGERALD, 2001):
1. No concordo totalmente
2. No concordo parcialmente
3. Indiferente
4. Concordo parcialmente
5. Concordo totalmente
O questionrio foi respondido por onze integrantes do EP. A seguir so apresentadas as questes do questionrio e apresentaremos o resultado e anlise de cada uma
delas:
Questo 1: Em geral, o plano de melhorias foi satisfatrio.
Opes disponveis: No concordo totalmente; No concordo parcialmente; Indiferente; Concordo parcialmente; Concordo totalmente. A Figura 12 indica o resultado
da questo.
Para a primeira pergunta do questionrio, que tem o objetivo de verificar o grau
de satisfao dos integrantes do EP com o plano desenvolvido, observa-se que todos
concordam que este foi satisfatrio, sendo que cinco pessoas concordam parcialmente e
seis concordam totalmente.
Questo 2: O plano de melhorias proposto impactar positivamente na qualidade dos projetos produzidos pelo EP.
da questo.
Com o objetivo de verificar a percepo da equipe do impacto que as mudanas
propostas teriam na qualidade do produto produzido pelo EP, a segunda pergunta do
84
Figura 12 Resultados da questo 1
questionrio indica que todos concordam que o plano de melhorias proposto possui
impacto positivo, sendo que sete pessoas concordam totalmente e quatro parcialmente.
Questo 3: O plano de melhorias proposto totalmente IMPOSSVEL de ser
implantado no EP.
85
da questo.
Para verificar a opinio da equipe em relao a possibilidade de implantao do

plano proposto, foi elaborado a terceira questo do questionrio. O intuito verificar se
as propostas desenvolvidas so factveis de serem implantadas no processo do EP. Os
resultados indicam que todos concordam quanto a possibilidade de implantao, sendo
que cinco pessoas no concordaram totalmente e seis no concordaram parcialmente
sobre a impossibilidade de implantao do plano proposto.
Questo 4: possvel me adequar as atividades propostas sem grandes dificuldades.
da questo.
A quarta questo do questionrio verifica a facilidade de adequao da equipe as
propostas realizadas. Os resultados indicam que a maioria concorda sobre a facilidade de
adequao, sendo que trs pessoas concordam totalmente e cinco parcialmente. Outras
trs pessoas so indiferentes em relao a facilidade de adequao. Este resultado sugere
que no haver grandes dificuldades na adaptao da equipe.
86
Questo 5: Qual a atividade sugerida pelo plano de melhorias voc considera

a mais importante (prioritria)?
Opes disponveis: Atividade 1: Gerenciamento de riscos; Atividade 2: Anlise de complexidade das tarefas; Atividade 3: Gerenciamento dos recursos humanos;
Atividade 4: Anlise de viabilidade; Atividade 5: Melhorias no planejamento da sprint;
Nenhuma delas importante. A Figura 16 indica o resultado da questo.
87
A ltima questo visa elencar as atividades mais importantes para definir uma
possvel sequncia de implantao. Os resultados indicam que a atividade 5 (Melhorias
no planejamento da sprint), com seis votos, uma forte candidata a ser primeiramente
adicionada ao processo. As outras indicadas foram: atividade 1 (Gerenciamento de
riscos) com trs votos; atividade 2 (Anlise de complexidade das tarefas) com um voto;
atividade 3 (Gerenciamento dos recursos humanos) com um voto.
88
7 Concluso
Neste trabalho foram revisados os conceitos de qualidade de software e qualidade de processo. Considera-se que a qualidade do processo de software aplicado em
uma organizao tem grande influncia na qualidade do produto de software final. Partindo desse princpio, neste trabalho foi conduzido um projeto de avaliao do processo
de desenvolvimento de software do EP para, ento, se definir um plano de melhorias
baseado nos pontos fracos, pontos fortes e oportunidades de melhorias encontradas
atravs da avaliao.
Foi realizada a avaliao utilizando o mtodo do MPS.BR: MA-MPS, sendo
avaliado conforme o nvel de maturidade G. Com base nos resultados da avaliao,
concluiu-se que o EP, apesar de possuir alguns pontos fracos para serem corrigidos, est
prximo do nvel requerido. Para suprir os pontos fracos encontrados, foi elaborado um
plano de melhorias, composto por cinco atividades. Esse Plano de melhorias foi bem
aceito pela equipe integrante do EP, conforme verificao feita atravs dos resultados
da aplicao de um questionrio.
Espera-se que o EP siga as sugestes de melhorias, para assim, aperfeioar a
qualidade do software desenvolvido pela equipe e, consequentemente, melhorar a prestao de servios comunidade do CEFET-MG, bem como alcanar a compatibilidade
com o nvel de maturidade G do MPS.BR.
7.1
Trabalhos futuros
Como forma de dar continuidade a este trabalho e, consequentemente, ao processo de melhoria do processo de desenvolvimento de software no EP, foram identificados os seguintes trabalhos futuros:
Implantar as melhorias propostas no processo do EP;
Realizar uma nova avaliao, verificando se as melhorias propostas foram suficientes para alcanar o nvel G, sendo esta preferencialmente realizada por uma
Instituio Avaliadora, a fim de certificar o EP no nvel G;
Buscar implantar outras melhorias, objetivando os demais nveis de maturidade
do MPS.BR.
89
Referncias
ANACLETO, A. Mtodo e Modelo de Avaliao para Melhoria de Processos de Software em Micro e Pequenas Empresas. Dissertao (Mestrado) Universidade Federal
de Santa Catarina, Florianpolis SC, Novembro 2004. Citado na pgina 1.
BECK, K.; BEEDLE, M.; BENNEKUM, A. van; COCKBURN, A.; CUNNINGHAM,
W.; FOWLER, M.; GRENNING, J.; HIGHSMITH, J.; HUNT, A.; JEFFRIES, R.; KERN,
J.; MARICK, B.; MARTIN, R. C.; MELLOR, S.; SCHWABER, K.; SUTHERLAND, J.;
THOMAS, D. Manifesto for Agile Software Development. 2001. Disponvel em: <http:
//www.agilemanifesto.org/>. Citado na pgina 52.
CD-049. CD-049. 2012. Disponvel em: <http://www.conselhodiretor.cefetmg.br/
galerias/Arquivos_ConDir/Resolucoes/Resolucoes_2012/RES_CD_049_12.htm>.
Acesso em: 29 de maro de 2015. Citado 2 vezes nas pginas 1 e 2.
CMMI-INSTITUTE. Introduction to CMMI Appraisals. 2014. Disponvel em:
<http://cmmiinstitute.com/sites/default/files/resource_asset/Introduction%20to%
20CMMI%20Appraisals.pdf>. Acesso em: 02 de Junho de 2015. Citado 2 vezes nas
pginas 1 e 19.
R Appraisal Method for Process Improvement
CMMI-INSTITUTE. Standard CMMI
(SCAMPI SM ) Version 1.3b: Method Definition Document for SCAMPI A, B, and C.
2014. Disponvel em: <http://cmmiinstitute.com/sites/default/files/resource_asset/
SCAMPI%20MDD%20V1%203b%202014.pdf>. Acesso em: 05 de Junho de 2015. Citado
na pgina 29.
FITZGERALD, J. Stems and Scales. 2001. <http://www.actualanalysis.com/likert.

htm>. (Visitado em 17/11/2015). Citado na pgina 83.
GONTIJO, V. T. Documento de Processo de Desenvolvimento de Software. Belo Horizonte, 2013. 8 p. Sistema Integrado de Administrao Processos e Servios - SINAPSE.
Citado 3 vezes nas pginas 41, 42 e 43.
ISO/IEC 12207. Engenharia de sistemas e software - Processos de ciclo de vida de
software. [S.l.], 2008. Citado na pgina 1.
ISO/IEC 15504. Tecnologia da informao - Avaliao de processo. [S.l.], 2008. Citado
3 vezes nas pginas 1, 15 e 39.
ISO/IEC 25000. Systems and software engineering - Systems and software Quality
Requirements and Evaluation (SQuaRE) - Guide to SQuaRE. [S.l.], 2014. Citado 2
vezes nas pginas 4 e 39.
ISO/IEC 25010. Systems and software engineering - Systems and software Quality
Requirements and Evaluation (SQuaRE) - System and software quality models. [S.l.],
2011. Citado 2 vezes nas pginas iv e 5.
ISO/IEC 33001. Tecnologia da informao - Avaliao de processo. [S.l.], 2015. Citado
na pgina 15.
Referncias
90
ISO/IEC 9000-3. Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation
and maintenance of computer software. [S.l.], 1997. Citado na pgina 10.
ISO/IEC 90003. Software engineering - Guidelines for the application of ISO
9001:2008 to computer software. [S.l.], 2014. Citado na pgina 10.
ISO/IEC 9001. Quality management systems Requirements. [S.l.], 2008. Citado 2
vezes nas pginas 10 e 39.
KALINOWSKI, M.; SANTOS, G.; REINEHR, S.; MONTONI, M.; ROCHA, A. R.; WEBER, K. C.; TRAVASSOS, G. H. Promovendo a adoo de boas prticas de engenharia
de software pela indstria brasileira. In: CIbSE - XIII Congreso Iberoamericano en
"Software Engineering". Universidad del Azuay, Cuenca, Ecuador: [s.n.], 2010. Citado
na pgina 21.
PALESTINO, C. V. B. Blog do Barbi-Carlos Barbieri: Mapeamento entre
MPS.BR e Scrum-Introduo. 2010. <http://blogdobarbi.blogspot.com.br/2010/09/
mapeamento-entre-mpsbr-e-scrum.html>. (Visitado em 12/11/2015). Citado na pgina
52.
PAULA FILHO, W. de P. Engenharia de Software - Fundamentos, Mtodos e Padres.
[S.l.]: LTC, 2009. Citado na pgina 38.
PRESSMAN, R. S. Engenharia de Software - Uma Abordagem Profissional. [S.l.]: Mc
Graw Hill, 2011. v. 7. Citado na pgina 1.
RIBEIRO, A. F. Melhoria de processos de software com base no nvel g do mps.br na
prodemge. PROQUALITY Qualidade na Produo de Software, v. 3, n. 2, p. 8790,
2007. Citado na pgina 36.
ROUT, T. P.; EMAM, K. E.; FUSANI, M.; GOLDENSON, D.; JUNG, H.-W. Spice in
retrospect: Developing a standard for process assessment. J. Syst. Softw., Elsevier
Science Inc., New York, NY, USA, v. 80, n. 9, p. 14831493, set. 2007. ISSN 0164-1212.
Disponvel em: <http://dx.doi.org/10.1016/j.jss.2007.01.045>. Citado na pgina 15.
SILVA, J. V. L. da. Desenvolvimento de um Modelo para Melhoria e Avaliao da
Pesquisa em Laboratrios Universitrios. Tese (Doutorado) Universidade Estadual
de Campinas, Faculdade de Engenharia Qumica, Campinas - SP, 2007. Citado 2 vezes
nas pginas 15 e 16.
SOFTEX. Guia Geral MPS de Software. 2012. Disponvel em: <http://www.softex.br/
wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf>.
Acesso em: 04 de Junho de 2015. Citado 6 vezes nas pginas 1, 23, 28, 29, 52 e 74.
SOFTEX. Guia de Avaliao. 2013. Disponvel em: <http://www.softex.br/
wp-content/uploads/2013/07/MPS.BR_Guia_de-Avaliacao_2013.1.pdf>. Acesso em:
04 de Junho de 2015. Citado 6 vezes nas pginas 31, 32, 41, 46, 48 e 50.
SOFTEX. Guia Geral MPS de Gesto de Pessoas. 2014. Disponvel em:
<http://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_
RH_2014_Versao_Beta.pdf>. Acesso em: 04 de Junho de 2015. Citado na pgina 22.
Referncias
91
SOUZA, J. P.; PINTO, M. V. Diagnstico da implantao da mps.br nvel g na administrao pblica: Estudo de caso na prodabel. iP - Informtica Pblica, v. 10, n. 2, p.
5363, 2008. Citado na pgina 36.
WAZLAWICK, R. S. Engenharia de Software: conceitos e prticas. Rio de Janeiro:
Elsevier, 2013. Citado 7 vezes nas pginas 1, 4, 5, 6, 10, 39 e 44.

A Valiação de P Rocessos de S Oftware em Um Ambiente Da Administração Pública

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A Valiação de P Rocessos de S Oftware em Um Ambiente Da Administração Pública

Hochgeladen von

Copyright:

Verfügbare Formate

C ENTRO F EDERAL DE E DUCAO T ECNOLGICA DE M INAS G ERAIS

AVALIAO DE P ROCESSOS DE S OFTWARE EM UM

H IGOR A UGUSTO M ADUREIRA P EREIRA

Orientadora: Prof.a Dr.a Kecia Aline Marques Ferreira

H IGOR A UGUSTO M ADUREIRA P EREIRA

AVALIAO DE P ROCESSOS DE S OFTWARE EM UM

Kecia Aline Marques Ferreira

C ENTRO F EDERAL DE E DUCAO T ECNOLGICA DE M INAS G ERAIS

Centro Federal de Educao Tecnolgica de Minas Gerais

Aluno: Higor Augusto Madureira Pereira

O presente Trabalho de Concluso de Curso foi avaliado pela seguinte banca:

Figura 1 Organograma da SGI . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tabela 1 Nveis de capacidade e atributos a serem atendidos conforme

Modelo de qualidade da ISO 25010 . . . . . . . . . . . . . . . . . . .

Evidncias RAP 10 - Gerncia de Projetos . . . . . . . . . . . . . . .

Lista de Abreviaturas e Siglas

Centro Federal de Educao Tecnolgica de Minas Gerais

Capability Maturity Model

Capability Maturity Model Integration

CMMI para desenvolvimento

CMMI para aquisio

CMMI para servios

Diviso de Infraestrutura de Tecnologia da Informao e Comunicao

International Organization for Standardization

Mtodo de Avaliao MPS

Modelo de Negcios MPS

Melhoria de Processos do Software Brasileiro

Modelo MPS Gesto de Pessoas

Modelo de Referncia para Melhoria de Processo de Software

Modelo de Referncia MPS para Software

Modelo de Referncia MPS para Servios

Pequenas e mdias empresas

Resultados esperados de Atributos de Processos

Rational Unified Process

Subsecretaria de Tecnologia da Informao e Comunicao

Standard CMMI Appraisal Method for Process Improvement

Setor de Atendimento ao Usurio

Software Engineering Institute

Secretaria de Governana da Informao

Software Process Improvement and Capability dEtermination

Software Product Quality Requirements and Evaluation

5 Avaliao do Processo de Software no EP . . . . . . . . . . . . . . . . . . . . .

6.5.4 Restries para implantao . . . . . . . . . . . . . . . . . . . . . .

Desenvolvimento de software um processo no qual o conhecimento, que

O Centro Federal de Educao Tecnolgica de Minas Gerais (CEFET-MG)

Figura 1 Organograma da SGI

O Escritrio de Projetos, ao qual est vinculado o autor do presente trabalho

O EP, nos ltimos anos, tem vivenciado um aumento elevado em relao ao

foi realizada a anlise dos processos atuais e definido um plano de melhorias de

O objetivo geral deste projeto avaliar os processos de software atuais do EP,

Realizar uma reviso bibliogrfica sobre os modelos e mtodos de avaliao de

O restante deste documento est organizado da seguinte forma: o Captulo 2

Neste captulo, so apresentados os principais conceitos que so aplicados neste

O uso de sistemas de software tem se tornado cada vez mais frequente e o

Captulo 2. Referencial terico

Fonte: (WAZLAWICK, 2013)

Captulo 2. Referencial terico

Quadro 1 Modelo de qualidade da ISO 25010

Fonte: adaptado de Wazlawick (2013)

Captulo 2. Referencial terico

Captulo 2. Referencial terico

4. Segurana: est relacionada capacidade do produto ou sistema em proteger seus

Captulo 2. Referencial terico