WAMPS 2009
O V Workshop Anual do MPS (WAMPS 2009) tem por
objetivo reunir os representantes da Indústria, Governo,
Academia, SOFTEX, ETM, FCC, BID e países latinoamericanos envolvidos e interessados na utilização e
evolução tanto do Modelo MPS quanto do Programa
MPS.BR – Melhoria de Processo do Software Brasileiro.
Este evento anual permite que os diferentes
colaboradores e usuários possam compartilhar suas
experiências e adquirir informações atualizadas sobre o
Modelo MPS e o Programa MPS.BR.
Apoio:
Ministério da
Ciência e Tecnologia
ISBN 978–85–99334–17–1
www.softex.br/mpsbr
334171
V Workshop Anual do MPS
Campinas-SP, 19 a 22 de outubro de 2009
Nestes Anais do WAMPS 2009 (V Workshop Anual do
MPS) encontram-se as palestras convidadas (position
papers), os artigos aceitos e os trabalhos em andamento.
9 788599
WAMPS 2009
WAMPS 2009
V Workshop Anual do MPS
Campinas-SP, 19 a 22 de outubro de 2009
2 WAMPS 2009
FICHA CATALOGRÁFICA ELABORADA PELO
Sistemas de Bibliotecas da UNICAMP /
Diretoria de Tratamento da Informação
W892a
Workshop Anual do MPS, 5., Campinas, SP, 2009. Anais do WAMPS 2009, realizado em Campinas, de 19 a 22 de Outubro de 2009; organizadores: Guilherme Horta Travassos, Ana Regina Cavalcanti da Rocha, Kival Chaves Weber -- Campinas, SP: Associação para Promoção da Excelência do Software Brasileiro - SOFTEX, 2009. 185 p.
1. Software – Congressos. 2. Programas de computador – Congressos. I. Travassos, Guilherme Horta. II. Rocha, Ana Regina Cavalcanti. III. Weber, Kival Chaves. IV. Título.
CDD - 001.6425 - 001.642
ISBN 978-85-99334-17-1
Índices para Catálogo Sistemático
1. Software - Congressos - 001.6425
2. Programas de computador - Congressos - 001.642
WAMPS 2009 3
Sumário
Apresentação
6
Organização do WAMPS 2009
7
Programação do WAMPS 2009
8
1 – Palestras convidadas
1.1 - “O Desafio da Ética Empresarial na Tecnologia da Informação”. Márcia May Gomel
(UFPR)
12
1.2 - “It’s Not Just Software: Software Quality in a Business Context”. Shari Lawrence Pfleeger
(RAND Corporation)
18
1.3 - “Variação de Desempenho nas Empresas que Adotaram o Modelo MPS: resultados
iniciais iMPS 2009”. Guilherme Horta Travassos e Marcos Kalinowski (COPPE/UFRJ)
20
1.4 - “Who Are the Enemies; What Can They Do? Internet/Software Security Issues in the
Software Development Process”. Charles P. Pfleeger (Pflegeer Consulting Group)
30
2 – Artigos aceitos
2.1 - “Gestão Integrada da Melhoria de Processos em Organizações de Software”, Marcelo
Santos de Mello, Ana Regina Rocha (Informal e COPPE/UFRJ)
34
2.2 - “Implementação do MPS.BR Nível F e CMMI-DEV Nível 2 na Red & White IT Solutions”,
Denia Kuhn Resende, João Batista Grego, Neide Pimentel, Cleomar Aparecido Gonçalves,
Edson Neves Vieira Junior, Ariel Crezo Ferreira, Fabricio Kruel, Paulo Roberto Batista Júnior,
Olavo Cardoso Terra Neto, Walison Cavalcanti, Henrique Godinho , Mariano Montoni, Elaine
Nunes, Andrea Barreto, Ana Regina Cavalcanti da Rocha (Red&White e COPPE/UFRJ)
42
2.3 - “Avaliação Conjunta CMMI Nível 3 e MPS Nível C: Lições Aprendidas e Recomendações”,
Ana Regina Rocha, Andrés Rubinstein, Ana Liddy Magalhães, Anne Elise Katsurayama,
Arley Duque, Carlos Barbieri Palestino, Crhistian Souza, Cristina Cerdeiral, Leandro Teixeira,
Nelson Serranegra de Paiva, Leonardo Barros (COPPE/UFRJ; Liveware; QualityFocus; Synos
Technologies; FUMSOFT)
52
2.4 - “Aplicação de Controle Estatístico de Processo (CEP) no contexto do MR-MPS em uma
Fábrica de Software”, Thercio Rodrigues do Nascimento, Cristiane Soares Ramos, Luiz Carlos
Miyadaira Ribeiro Jr. (Politec e UnB)
62
4 WAMPS 2009
2.5 - “Um relato dos desafios encontrados e dos benefícios conseguidos com a implantação
das práticas propostas pelo nível F do modelo MPS.Br”, Gustavo Vaz Nascimento, Wander
Marcelo Lorencin, Felício Fadlalla Nassif (SHIFT)
72
2.6 - “O Guia de Aquisição do MPS.BR e o Pregão Eletrônico”, Danilo Scalet, Edmeia Leonor
Pereira de Andrade (CELEPAR e EMBRAPA)
82
2.7 - “Comparação entre a Instrução Normativa SLTI/MP nº 04 e o Guia de Aquisição do
MPS.BR”, Eric Robert Gillis, Edméia Leonor Pereira de Andrade (UCB e EMBRAPA)
92
2.8 - “Implantação do Processo Aquisição na Synapsis Brasil”, Carlos Simões, Ana Regina
Rocha, Gleison Santos (SYNAPSIS, COPPE/UFRJ e UNIRIO)
102
2.9 - “Lições Aprendidas em uma Iniciativa de Melhoria de Processos de Software na
Perspectiva dos Gerentes de Projetos de um Grupo de Empresas Alagoanas”, Lívia Omena,
Klevison Matias, Marcelo Silva, Joyce Marinho e Reinaldo Cabral (KMF, Ntech, Inform,
Jetdata, COPPE/UFRJ)
110
2.10 - “Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada”, Geovane Nogueira Lima, Marcos André Gomes (SOFTEX RECIFE)
120
2.11 - “A Experiência de Implantação dos Processos Gerência de Reutilização e Desenvolvimento
para Reutilização na Synapsis-Brasil”, Gleison Santos, David Zanetti, Morisson Maciel, Carlos
Alberto Simões, Claudia Werner e Ana Regina Rocha (SYNAPSIS, COPPE/UFRJ e UNIRIO)
128
2.12 - “Estudo de Viabilidade de Domínio para Avaliar o Potencial da Organização Quanto
à Implementação do Processo Desenvolvimento para Reutilização do MR-MPS”, Mylene
Lisbôa Cabral, Thiago Moreira da Costa, Cláudia Maria Lima Werner (COPPE/UFRJ)
136
3 – Trabalhos em andamento
3.1 - “Identificação e Seleção de Inovações Tecnológicas e de Processo em Organizações de
Software”, Cristina Cerdeiral, Ana Regina Rocha (COPPE/UFRJ)
146
3.2 - “Implantação do MPS.BR (Melhoria do Processo de Software Brasileiro), nível F, com
TFS (Team Foundation Server) no Desenvolvimento Eficiente de Sistemas”, Larissa Lopes de
Araujo e Adriana Barreto Mello (ECO Sistemas e RIOSOFT)
154
3.3 - “Uma Proposta de Mapeamento dos Processos Existentes no Guia de Aquisição do
MPS.BR e no CMMI-ACQ”, Julio Cezar Costa Furtado, Sandro Ronaldo Bezerra Oliveira (UFPA
e SWQuality)
164
3.4 - “Riscos e Fatores de Influência na definição de Estratégias para Projetos de Implementação
de Melhoria de Processos de Software em Grupos de Empresas”, Gisele Villas Bôas, Ana
Regina Cavalcanti Rocha (COPPE/UFRJ)
176
WAMPS 2009 5
Apresentação
O V Workshop Anual do MPS (WAMPS 2009) tem por objetivo reunir os representantes da Indústria,
Governo, Academia, SOFTEX, ETM, FCC, BID e países latino-americanos envolvidos e interessados na
utilização e evolução tanto do Modelo MPS quanto do Programa MPS.BR – Melhoria de Processo do
Software Brasileiro.
A partir deste ano, visando dar mais abrangência e intensificar a integração entre os principais atores
do Programa MPS.BR, o Workshop Anual do MPS passa a promover, de forma integrada, os eventos
anteriormente executados e representados pelos IV Workshop de II – Instituições Implementadoras
MPS, III Workshop de IA – Instituições Avaliadoras MPS, III Workshop de IOGE – Instituições
Organizadoras de Grupos de Empresas MPS.BR e II Workshop de Empresas MPS.BR.
O objetivo da integração é aproveitar as experiências, aumentar a sinergia entre os grupos e tirar
proveito da maturidade adquirida ao longo de quase 6 anos de trabalho intenso com o Modelo
MPS e o Programa MPS.BR, uma realidade viável para as organizações que procuram aprimorar seus
processos de software.
Este evento anual permite que os diferentes colaboradores e usuários possam compartilhar suas experiências e adquirir informações atualizadas sobre o Modelo MPS e o Programa MPS.BR.
Durante a semana do workshop, a programação do WAMPS 2009 inclui tanto cursos oficiais e especiais, palestras e painéis quanto palestras convidadas internacionais e nacionais e a apresentação
de artigos aceitos e trabalhos em andamento que apresentam evidências obtidas com a experiência
da utilização do Modelo MPS nas organizações. Também, estão programadas reuniões do CGP –
Conselho de Gestão do Programa MPS.BR e de Coordenadores de II, IA e IOGE.
Os artigos aceitos e os trabalhos em andamento, submetidos em atenção a uma Chamada de
Trabalhos, foram selecionados por um Comitê de Programa composto por profissionais especialistas
no Modelo MPS.
Nestes Anais do WAMPS 2009 (V Workshop Anual do MPS) encontram-se as palestras convidadas
(position papers) , os artigos aceitos e os trabalhos em andamento.
Campinas, outubro de 2009
Guilherme Horta Travassos (COPPE/UFRJ)
Coordenador científico do WAMPS 2009 – V Workshop Anual do MPS
Ana Regina Rocha (COPPE/UFRJ)
Coordenadora da ETM – Equipe Técnica do Modelo MPS
Kival Weber (SOFTEX/MPS.BR)
Coordenador executivo do Programa MPS.BR – Melhoria de Processo do Software Brasileiro
6 WAMPS 2009
Organização do WAMPS 2009
Coordenação Geral
José Antonio Antonioni (SOFTEX) Kival Weber (SOFTEX/MPS.BR) Ana Regina Rocha (COPPE/UFRJ) Nelson Franco (SOFTEX)
Coordenação Científica
Guilherme Horta Travassos (COPPE/UFRJ)
Comitê de Programa
Adriana Silveira de Souza (Estratégia) Adriano Bessa Albuquerque (UNIFOR) Alexandre Marcos Lins de Vasconcelos (UFPE) Ana Cecília P. Zabeu (ASR) Ana Liddy Cenni de Castro Magalhães (FUMEC e QualityFocus) Ana Paula Terra Bacelo (PUCRS) Carla Alessandra Lima Reis (UFPA) Carlos Barbieri (FUMSOFT e FUMEC) Carlos Pietrobom (UFOP e PUC Minas) Christiane Gresse von Wangenheim (UFSC) Cristina Filipak Machado (CELEPAR e QualityFocus) Danilo Scalet (CELEPAR) Edmeia L. P. de Andrade (EMBRAPA) Fábio Bianchi Campos (UCB) Gleison Santos (UNIRIO) Juliano Lopes de Oliveira (UFG e Estratégia) Leonardo Gresta Paulino Murta (UFF) Marcello Thiry (UNIVALI e Incremental) Marcelo Hideki Yamaguti (PUCRS) Marcos Kalinowski (COPPE/UFRJ) Mariano Angel Montoni (COPPE/UFRJ) Ricardo de Almeida Falbo (UFES) Rosângela Míriam Lemos Oliveira Mendonça (FUMSOFT) Sarah Kohan (Fundação Carlos Alberto Vanzolini) Sheila Reinehr (PUCPR) Tayana Uchôa Conte (UFAM)
WAMPS 2009 7
Programação do WAMPS 2009
WAMPS 2009 – V WORKSHOP ANUAL DO MPS – 19 a 22 de outubro de 2009
Local: Hotel Tryp Campinas (by Sol Meliá) - Rua Severo Penteado, 140 – Cambuí, Campinas, SP
Coordenação Geral: José Antonio Antonioni, Kival Weber, Ana Regina Rocha e Nelson Franco
Coordenação Científica: Guilherme Horta Travassos
2ª feira - 19 de outubro de 2009
8:00–10:00
Curso especial de Controle Estatístico de Processo, instrutor:
Gleison dos Santos Souza
Curso oficial de Introdução ao MPS.BR (C1-MPS.BR),
instrutoras: Ana Liddy Cenni de Castro Magalhães e
Sarah Kohan
10:00-10:30
Intervalo
Intervalo
10:30-12:00
Continuação do Curso especial de Controle Estatístico de
Processo, instrutor: Gleison dos Santos Souza
Continuação do Curso oficial de Introdução ao MPS.
BR (C1-MPS.BR), instrutoras: Ana Liddy Cenni de Castro
Magalhães e Sarah Kohan
12:00-12:30
12:30-14:00
14:00-15:30
Almoço
Almoço
Palestrante Nacional: Márcia May Gomel (UFPR) ”O Desafio da Ética Empresarial na Tecnologia da Informação”
15:30-16:00
Intervalo
Intervalo
16:00-16:30
Artigo aceito I: “Gestão Integrada da Melhoria de Processos
em Organizações de Software”, Marcelo Santos de Mello,
Ana Regina Rocha (Informal e COPPE/UFRJ)
16:30-17:00
Artigo aceito II: “Implementação do MPS.BR Nível F e
CMMI-DEV Nível 2 na Red & White IT Solutions”, Denia
Kuhn Resende, João Batista Grego, Neide Pimentel, Cleomar Aparecido Gonçalves, Edson Neves Vieira Junior, Ariel Crezo Ferreira, Fabricio Kruel, Paulo Roberto Batista
Júnior, Olavo Cardoso Terra Neto, Walison Cavalcanti,
Henrique Godinho , Mariano Montoni, Elaine Nunes, Andrea Barreto, Ana Regina Cavalcanti da Rocha
(Red&White e COPPE/UFRJ)
17:00-17:30
Artigo aceito III: “Avaliação Conjunta CMMI Nível 3 e MPS
Nível C: Lições Aprendidas e Recomendações”, Ana Regina
Rocha, Andrés Rubinstein, Ana Liddy Magalhães, Anne
Elise Katsurayama, Arley Duque, Carlos Barbieri Palestino,
Crhistian Souza, Cristina Cerdeiral, Leandro Teixeira,
Nelson Serranegra de Paiva, Leonardo Barros (COPPE/UFRJ;
Liveware; QualityFocus; Synos Technologies; FUMSOFT)
17:30-19:00
Reunião Coordenadores de IA
Continuação do Curso oficial de Introdução ao MPS.
BR (C1-MPS.BR), instrutoras: Ana Liddy Cenni de Castro
Magalhães e Sarah Kohan
20:00-21:00
Abertura do WAMPS 2009 e Entrega de Placas MPS.BR
21:00-22:00
Coquetel do WAMPS 2009
8 WAMPS 2009
Programação do WAMPS 2009
3ª feira - 20 de outubro de 2009
8:00–9:00
Curso especial de Implementação MPS níveis E, D e C,
instrutor: Gleison dos Santos Souza
Continuação do Curso oficial
de Introdução ao MPS.BR
(C1-MPS.BR), instrutoras:
Ana Liddy Cenni de Castro
Magalhães e Sarah Kohan
10:00-10:30
Intervalo
Intervalo
10:30-11:00
Artigo aceito IV: “Aplicação de Controle Estatístico de
Processo (CEP) no contexto do MR-MPS em uma Fábrica
de Software”, Thercio Rodrigues do Nascimento, Cristiane
Soares Ramos, Luiz Carlos Miyadaira Ribeiro Jr. (Politec e
UnB)
11:00-11:30
Artigo aceito V: “Um relato dos desafios encontrados e dos
benefícios conseguidos com a implantação das práticas
propostas pelo nível F do modelo MPS.Br”, Gustavo Vaz
Nascimento, Wander Marcelo Lorencin, Felício Fadlalla
Nassif (SHIFT)
11:30-11:45
Trabalho em andamento I: “Identificação e Seleção de
Inovações Tecnológicas e de Processo em Organizações de
Software”, Cristina Cerdeiral, Ana Regina Rocha (COPPE/
UFRJ)
11:45-12:00
Trabalho em andamento II: “Implantação do MPS.BR
(Melhoria do Processo de Software Brasileiro), nível F, com
TFS (Team Foundation Server) no Desenvolvimento Eficiente
de Sistemas”, Larissa Lopes de Araujo e Adriana Barreto
Mello (ECO Sistemas e RIOSOFT).
9:00–10:00
12:00-12:30
12:30-14:00
14:00-15:30
Almoço
Continuação do Curso oficial
de Introdução ao MPS.BR
(C1-MPS.BR), instrutoras:
Ana Liddy Cenni de Castro
Magalhães e Sarah Kohan
Almoço
Reu CGP - Conselho de
Gestão do Programa
MPS.BR (9:00 - 12:00h)
Almoço
Palestrante Internacional: Shari Lawrence Pfleeger (RAND Corporation) ”It’s Not Just Software: Software Quality in a Business Context”
15:30-16:00
Intervalo
16:00-16:30
Palestra “Cartão BNDES apoia implementação e avaliação
MPS”, Gustavo Nonato (BNDES).
16:30-17:00
Artigo aceito VI: “O Guia de Aquisição do MPS.BR e o
Pregão Eletrônico”, Danilo Scalet, Edmeia Leonor Pereira de
Andrade (CELEPAR e EMBRAPA)
17:00-17:30
Artigo aceito VII: “Comparação entre a Instrução Normativa
SLTI/MP nº 04 e o Guia de Aquisição do MPS.BR”, Eric
Robert Gillis, Edméia Leonor Pereira de Andrade (UCB e
EMBRAPA)
17:30-18:00
Palestra: “Apresentação do Guia de Implementação – Parte
8: Implementação do MR-MPS em organizações que
adquirem software”, Ana Regina Rocha (COPPE/UFRJ)
18:00-18:30
Artigo aceito VIII: “Implantação do Processo Aquisição na
Synapsis Brasil”, Carlos Simões, Ana Regina Rocha, Gleison
Santos (SYNAPSIS, COPPE/UFRJ e UNIRIO)
18:30-18:45
Trabalho em andamento III: “Uma Proposta de
Mapeamento dos Processos Existentes no Guia de Aquisição
do MPS.BR e no CMMI-ACQ”, Julio Cezar Costa Furtado,
Sandro Ronaldo Bezerra Oliveira (UFPA e SWQuality)
18:45-20:00
Reunião Coordenadores de II
Intervalo
Intervalo
Continuação do Curso oficial
de Introdução ao MPS.BR
(C1-MPS.BR), instrutoras:
Ana Liddy Cenni de Castro
Magalhães e Sarah Kohan
WAMPS 2009 9
4ª feira - 21 de outubro de 2009
8:00–10:00
Continuação do Curso especial de Implementação MPS
níveis E, D e C, instrutor: Gleison dos Santos Souza
Curso oficial de Aquisição
de Software (C4-MPS.BR),
instrutor: Danilo Scalet
10:00-10:30
Intervalo
Intervalo
10:30-11:00
Artigo aceito IX: “Lições Aprendidas em uma Iniciativa
de Melhoria de Processos de Software na Perspectiva
dos Gerentes de Projetos de um Grupo de Empresas
Alagoanas”, Lívia Omena, Klevison Matias, Marcelo Silva,
Joyce Marinho e Reinaldo Cabral (KMF, Ntech, Inform,
Jetdata, COPPE/UFRJ)
11:00-11:30
Artigo aceito X: “Fatores críticos de sucesso em programas
de melhoria de processo de forma cooperada”, Geovane
Nogueira Lima, Marcos André Gomes (SOFTEX RECIFE)
11:30-11:45
Trabalho em andamento IV: “Riscos e Fatores de Influência
na definição de Estratégias para Projetos de Implementação
de Melhoria de Processos de Software em Grupos de
Empresas”, Gisele Villas Bôas, Ana Regina Cavalcanti Rocha
(COPPE/UFRJ)
12:00-12:30
Almoço
12:30-14:00
Intervalo
Continuação do Curso oficial
de Aquisição de Software
(C4-MPS.BR), instrutor
Danilo Scalet
Almoço
Almoço
Palestrante Nacional: Guilherme Horta Travassos (COPPE/UFRJ) ”Variação de Desempenho nas Empresas que Adotaram o Modelo MPS: resultados iniciais iMPS 2009”
14:00-15:30
15:30-16:00
Intervalo
16:00-18:00
Painel: “Organização de Grupos de Empresas no MPS.BR”,
moderador: Kival Weber, painelistas: Edvar Pera Jr (IOGE
SOFTEX CAMPINAS), Carlos Barbieri (IOGE FUMSOFT),
Márcio Pecegueiro do Amaral (IOGE RIOSOFT), Adriana
Martins (IOGE SOFTSUL), Maria Tereza Anastácio (IOGE
CITS) e Wagner Paulino Palheta (AMAZON SOFTWARE
- Grupo de Empresas de Manaus). Após apresentações
sucintas dos painelistas (12’ cada), haverá uma sessão de
Perguntas e Respostas (Q&A) com participação dos seis
painelistas e de mais dois convidados especiais: Marcos
André Wanderley Gomes (IOGE SOFTEX RECIFE) e Reinaldo
Cabral (IOGE COPPE/UFRJ - Grupo de Empresas de Maceió).
18:00-20:00
Continuação do Curso especial de Implementação MPS
níveis E, D e C, instrutor: Gleison dos Santos Souza
10 WAMPS 2009
Intervalo
Intervalo
Continuação do Curso oficial
de Aquisição de Software
(C4-MPS.BR), instrutor
Danilo Scalet
Reunião Coordenadores
de IOGE
Programação do WAMPS 2009
5ª feira - 22 de outubro de 2009
8:00–10:00
Continuação do Curso oficial
de Aquisição de Software
(C4-MPS.BR), instrutor
Danilo Scalet
Curso especial de
Gerência de Portfólio
de Projetos, instrutora:
Sheila Reinehr
Intervalo
10:00-10:30
Intervalo
Intervalo
10:30-12:00
Painel: “Medição de Processos de Software”, moderadora:
Ana Regina Rocha (COPPE/UFRJ), painelistas: Adriana Costa
(BRQ), Ana Zabeu (ASR), Andrés Rubinstein (Liveware),
Cristina F. Machado (QualityFocus), Mauricio Aguiar (ti
MÉTRICAS).
Continuação do Curso oficial
de Aquisição de Software
(C4-MPS.BR), instrutor
Danilo Scalet
12:00-12:30
12:30-14:00
14:00-15:30
Almoço
Almoço
Almoço
“Palestrante Internacional: Charles P. Pfleeger (Pfleeger Consulting Group) ”Who Are the Enemies; What Can They Do? Internet/Software Security Issues in the Software Development Process”
15:30-16:00
Intervalo
16:00-16:30
Palestra: “Apresentação do Guia de Implementação – Parte
9: Implementação do MR-MPS em organizações do tipo
Fábrica de Software e do Guia de Implementação – Parte
10: Implementação do MR-MPS em organizações do tipo
Fábrica de Teste”, Ana Regina Rocha, Sheila Reinehr e
Cristina Machado (COPPE/UFRJ e QUALITYFOCUS)
16:30-17:00
Artigo aceito XI: “A Experiência de Implantação dos
Processos Gerência de Reutilização e Desenvolvimento para
Reutilização na Synapsis-Brasil”, Gleison Santos, David
Zanetti, Morisson Maciel, Carlos Alberto Simões, Claudia
Werner e Ana Regina Rocha (SYNAPSIS, COPPE/UFRJ e
UNIRIO)
17:00-17:30
Artigo aceito XII: “Estudo de Viabilidade de Domínio
para Avaliar o Potencial da Organização Quanto à
Implementação do Processo Desenvolvimento para
Reutilização do MR-MPS”, Mylene Lisbôa Cabral, Thiago
Moreira da Costa, Cláudia Maria Lima Werner (COPPE/UFRJ)
17:30-18:00
Encerramento do WAMPS 2009
Intervalo
Continuação do Curso oficial
de Aquisição de Software
(C4-MPS.BR)
Intervalo
Continuação do Curso
especial de Gerência de
Portfólio de Projetos,
instrutora: Sheila
Reinehr
18:00-20:00
WAMPS 2009 11
Palestras convidadas
O Desafio da Ética Empresarial na Tecnologia da
Informação
Márcia May Gomel ([email protected])
Centro de Pesquisa e Pós-Graduação em Administração - CEPPAD Universidade Federal do Paraná - UFPR Av.Pref.Lothário Meissner, 3400 – Campus III – Jardim Botânico 80210-170 - Curitiba, PR - Brasil
Resumo: A inserção de princípios éticos nas organizações é iminente. Quem ainda não o fez, prepara-se para
adotar práticas que indiquem correção e transparência em suas atividades. Em informática, a discussão é premente. Embora ainda não se tenha constituída uma discussão teórica consistente sobre o tema, o setor demanda práticas éticas que permitam a escolha inequívoca de empresas, parceiros e fornecedores de serviços de TI.
Abstract: An urgent use of ethical principles at organizations is necessary. Who have not done it yet, must
be ready to adopt practical issues that bring correction and transparency to their activities. In IT environment,
the discussion is inevitable. Although this issue does not have consistent theoretical bases, the sector demands
ethical practices that allow choosing unequivocally the best companies, partners and IT service suppliers.
Introdução
“Há uma necessidade profunda e intensamente humana de confiança, honestidade, integridade e
conduta ética nas pessoas com quem criamos relacionamentos importantes. Acredito que este imperativo moral deve motivar as pessoas a se esforçarem para satisfazer a necessidade que diz respeito
a todos os seus constituintes, clientes, empregados, todos os que dela dependem. As empresas que
são mais consistentemente éticas em sua conduta serão, em média, mais bem sucedidas.”
James Burke, Executivo-chefe da Johnson & Johnson.
A Ética é uma daquelas práticas controversas que ocupam a rotina dos empresários. Por um lado, há
a certeza de que deve ser enaltecida, e que sua inserção na empresa é iminente; porém, sua aplicação
é cercada de problemas, de temas espinhosos, que talvez fosse melhor manter adormecidos. Esse dilema é uma realidade e uma preocupação mundial, e se revela no instante em que se tenta implantar
princípios éticos no meio organizacional. A dicotomia entre o que deve ser feito e o que é viável na
prática confunde o administrador. Em alguns casos, leva à paralisia de suas ações, e conduz o tema
ética empresarial a um segundo plano. Até que a realidade o obrigue a tomar decisões.
1. Ética Empresarial
As definições sobre ética empresarial dizem respeito a conceitos morais sobre o que é certo e errado
em situações específicas. Para Ferrel et al. (2001), em termos simples, ética empresarial compreende
princípios e padrões que orientam o comportamento no mundo dos negócios. Se um comportamento
12 WAMPS 2009
O Desafio da Ética Empresarial na Tecnologia da Informação
específico exigido é certo ou errado, ético ou antiético, é determinação dos stakeholders, tais como
investidores, clientes, grupos de interesse, empregados, o sistema jurídico vigente e a comunidade.
Esses grupos não estarão necessariamente “corretos” em seus pontos de vista, mas determinarão a
aceitação ou não, pela sociedade, da empresa e de sua conduta.
Mas por que o empresário deveria se preocupar com a ética empresarial, uma vez que não há queixas
sobre sua conduta? Sabe-se que a aplicação de práticas éticas implica em investimentos, eventuais
perdas de posições competitivas, descontentamentos internos e o desconforto causado à categoria
denominada pigeonholing people1, que reluta em abandonar a zona de conforto. Além da produção
de outro efeito: o surgimento de expectativas irrealistas sobre como as práticas relacionadas à ética
influenciarão a rotina.
Aguilar (1996) responde: o problema da forma de raciocínio que ignora a conduta ética é que ela
desconhece riscos e custos dessa conveniência. A ampla exposição na mídia sobre práticas desonestas e escândalos envolvendo empresários serve como aviso sobre a existência desses riscos. A pública
manifestação judicial, a perda de posição competitiva, o desgaste diante dos concorrentes, o embaraço pessoal são algumas das conseqüências que resultam da abstinência ética. E também servem
como incentivo para que os empresários se dediquem ao assunto.
Entretanto, a principal razão de se dar atenção às questões éticas reside nos impactos dessa conduta
sobre o desempenho empresarial. A construção do senso de respeito e confiança mútua é fundamental para a liberação de energias inovadoras e empreendedoras latentes na empresa (AGUILAR, 1996).
Para que a empresa mantenha-se num círculo virtuoso de práticas inovadoras, será necessário que
se cerque de pessoas com formação adequada, que se engajem nos negócios e consigam perceber
oportunidades e prever ameaças. Porém, grandes inovações e decisões estratégicas implicam em geral
em grandes incertezas e riscos, o que pode abalar relações tradicionais com clientes, modificar rotinas
preestabelecidas de produção e demandar, inclusive, um realinhamento das estruturas de poder.
Aguilar defende que a adoção de condutas éticas cria uma relação de confiança que torna os funcionários mais envolvidos com o destino de suas organizações. Alguns processos organizacionais – tais
como o emprego de equipes, medições apropriadas de desempenho e recompensas por sucesso embora possam estimular o pensamento inovador, a disposição do indivíduo de se arriscar é influenciada pela maneira como espera ser tratado caso o curso da ação que propôs não corresponda às
expectativas de seus superiores. Desta forma, à medida que o compromisso da administração com
a ética empresarial gera respeito e confiança, criam-se condições favoráveis à aceitação de riscos e à
inovação. A construção e a manutenção da confiança na empresa dependem das pessoas se tratarem
com consideração e interesse mútuo. Esse comportamento constitui o núcleo da ética empresarial.
2. Ética Empresarial e TI: O Que Já Existe
O tema Ética Empresarial há muitos anos vem sendo bastante explorado. Autores como Arruda,
Chauí, Faria, Lopes de Sá, Srour são considerados clássicos da biografia nacional sobre a gestão da
1) O termo pigeonholing people foi originalmente definido por Andriopoulos e Gotsi (2002), e se refere àquelas pessoas que relutam em
abandonar seus hábitos e atividades cotidianas (ou, literalmente, o ninho do pombo).
WAMPS 2009 13
Palestras convidadas
ética. Sem mencionar os títulos estrangeiros, uma série de livros e artigos explora o tema de modo
consistente.
Porém, a produção científica específica sobre Ética e TI está longe de ser profícua. Em breves levantamentos sobre o tema, nota-se que há poucos trabalhos que tratem simultaneamente destes assuntos. E a discussão que há não se faz suficiente.
Mas a preocupação não é recente. Em 1981, o Serviço Federal de Processamento de Dados (SERPRO),
publicou uma série de ensaios e artigos sobre o tema “Ética em Processamento de Dados”, escrita
por profissionais da área. Delineado em pleno regime militar, dentre as atribuições, constava a normalização dos produtos e serviços, e a definição dos contornos políticos da atuação do Estado na
atividade (SOARES, 2004).
Há poucas empresas que adotam códigos de ética aplicados a real prática de TI. E muitos deles não
refletem o pensamento da cúpula da organização, ou não são compreendidos por seu público. Uma
pesquisa realizada em 2004 revela que a existência de um código de ética não pressupõe a imediata compreensão e aplicação de seu conteúdo – o que torna ainda mais complexo o tratamento da
questão (SOARES, 2004).
No âmbito internacional, algumas discussões se destacam. É o caso do artigo de TURILLI e FLORIDI
(2009), publicado no periódico britânico Ethics and Information Technology; nele os autores defendem a necessidade de um elemento pré-ético, uma espécie de condição para a instauração de práticas éticas: a transparência da informação. Eles argumentam que explicitar o design ético, de modo
a descrever como princípios éticos serão introduzidos na prática de desenvolvimento de software,
representa um valioso instrumento. A organização que se dispõe a revelar essa estrutura reforça
francamente sua intenção ética. E constrói um ambiente de confiança mútua.
Portanto, há que se observar e refletir sobre as práticas e realidades éticas já adotadas no País e no
exterior, e adaptá-las à realidade de cada organização.
3. Novos Rumos
Dentre as iniciativas de se formalizar as práticas éticas nas empresas de TI, duas publicações se destacam. A primeira é o Código de Ética adotado pelo Software Engineering Institute (SEI). Denominado
Code of Professional Conduct (CoPC) for SEI Services, o Código sintetiza as expectativas e práticas para aqueles que trabalham sob licença ou por meio de instrumento de acordo com a Carnegie Mellon
University, através do SEI. O objetivo do Código é estabelecer padrões de conduta profissional para
seus parceiros e candidatos2.
O Código do SEI trata, de modo bastante específico, dos padrões esperados de comportamento e
das respectivas sanções em caso de violação. A qualidade do profissionalismo almejado é exposta em
seu conteúdo. Aos profissionais certificados e autorizados, candidatos ou parceiros SEI são aplicados
os seguintes princípios de conduta:
2) O código se aplica a SEI-Authorized or Certified Professionals, Candidates for SEI authorizations or certifications and SEI Partners.
14 WAMPS 2009
O Desafio da Ética Empresarial na Tecnologia da Informação
• Profissionalismo. Exercitar o dever de compreender e aderir às obrigações profissionais. Tratar
clientes, colegas, concorrentes e outros de modo respeitável e de maneira honesta, de modo
a preservar a reputação dos serviços SEI e da comunidade de usuários e fornecedores desses
serviços.
• Objetividade. Evitar conflitos de interesse ou o surgimento de conflitos de interesse, e evitar que
suas opiniões pessoais sejam interpretadas como posicionamentos do SEI. Revelar conflitos às
partes interessadas, e cuidar para que esses conflitos não interfiram na objetividade do trabalho.
• Confidencialidade. Respeitar a confidencialidade da informação adquirida no desempenho de
suas funções profissionais, incluindo dados sobre clientes, informações, comunicações e identidades, de maneira a preservar sua própria reputação e de sua relação com o Cliente.
• Aderência a Materiais e Métodos. Utilizar metodologia SEI conforme documentado ou informado em treinamentos, e agir de maneira consistente com a intenção de que esses materiais e
métodos preservem a qualidade e a consistência dos serviços SEI.
• Integridade de Dados. Exercitar o dever de reportar resultados dos serviços de modo completo,
objetivo e acurado a todos os stakeholders, de modo a preservar a validade dos dados, seu próprio
trabalho e a reputação coletiva do SEI.
• Respeito à Propriedade Intelectual. Respeitar o direito à propriedade intelectual e manter-se
informado, e agir de acordo com as leis aplicáveis à preservação da integridade de seu próprio
trabalho e dos produtos SEI.
O Código segue com explanações a respeito das sanções cabíveis em caso de violações desses
princípios.
Outro documento que trata da ética no gerenciamento de projetos é o Código de Ética e Conduta
Profissional do Project Management Institute (PMI). De acordo com o documento, sua intenção é
“incutir confiança na profissão de gerenciamento de projetos e auxiliar as pessoas a se tornarem
melhores profissionais”. Seus principais valores, definidos em acordo pela comunidade mundial de
gerenciamento de projetos, enaltecem a responsabilidade, respeito, justiça e honestidade.
A viabilidade da tradução de instrumentos dessa natureza à realidade brasileira demandará um intenso debate, que certamente envolverá os stakeholders de TI e, em especial, os profissionais que
compõem a massa crítica do setor.
4. Considerações Finais
Não se pode falar em ética em TI sem atentar ao fato de que muito mudou desde que os primeiros
ensaios foram publicados no Brasil. Por mais que tenhamos avançado e sofisticado a tecnologia e
suas aplicações, os estudos acerca das questões éticas na automação são ainda incipientes.
Entretanto, a demanda por definições acerca do tema urgem, e aproximam os profissionais de TI de
uma discussão em profundidade sobre o tema, onde se poderá conhecer, discutir e refletir sobre as
práticas que nortearão os novos rumos da ética do setor.
WAMPS 2009 15
Palestras convidadas
Referências
AGUILAR, F. A ética nas empresas: maximizando resultados através de uma conduta ética nos negócios. Rio de Janeiro: Jorge Zahar, 1996.
ANDRIOPOULOS, C.; GOTSI, M. Lessons from a creative culture. Design Management Journal, Boston,
Spring, 2002.
ARRUDA, M. C. C. de. Código de ética: um instrumento que adiciona valor. São Paulo: Negócio
Editora, 2002.
CHAUÍ, M. Convite à filosofia. 3. ed. São Paulo: Ática, 2005.
CMU/SEI. Code of professional conduct for SEI services. Version 1.0. CMU/SEI: Pittsburgh, Sep.
2004.
FARIA, J. H. de. Ética, moral e democracia: paradoxos da práxis organizacional. Lisboa: Comportamento
e Gestão Organizacional, Universidade Técnica de Lisboa, 2001.
FERREL, O.; FRAEDRICH, J.; FERREL, L. Ética empresarial: dilemas, tomadas de decisões e casos. 4. ed.
Rio de Janeiro: Reichmann & Affonso, 2001.
PMI. Código de Ética e Conduta Profissional.
SÁ, A. L. de. Ética profissional. 4. ed. São Paulo: Atlas, 2001.
SOARES, T. O. R. Dimensões éticas nas organizações de Tecnologia da Informação. In: ENCONTRO
ANUAL DA ASSOCIAÇÃO NACIONAL DOS PROGRAMAS DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO
- ENANPAD, 29., 2004, Curitiba. Anais... Curitiba: ANPAD, 2004.
SROUR, R. H. Poder, cultura e ética nas organizações. Rio de Janeiro: Camus, 1998.
TURILLI, M.; FLORIDI, L. The ethics of information transparency. Ethics Information Technology, Oxford,
UK, v.11, p.105-112, 10 Mar 2009.
16 WAMPS 2009
O Desafio da Ética Empresarial na Tecnologia da Informação
Sobre a autora
Márcia May Gomel é formada em Ciência da Computação pela Pontifícia Universidade Católica
do Paraná (1988), mestre em Administração pela Universidade Federal do Paraná (1996) e doutora em Administração pela Universidade de São Paulo (2006). Atualmente é professora adjunta do
Departamento de Administração Geral e Aplicada da Universidade Federal do Paraná. Leciona as
disciplinas de graduação: Administração de Sistemas de Informação, Gestão da Qualidade e Ética
nas Organizações. Possui experiência em Tecnologia da Informação e atua como pesquisadora nas
seguintes áreas: Indústria de Software, Capacitação Tecnológica, Inovação, Gestão da Qualidade e
Ética Empresarial.
WAMPS 2009 17
Palestras convidadas
It’s Not Just Software: Software Quality in a
Business Context
Shari Lawrence Pfleeger
RAND Corporation
As software developers, we often think only about the process of specifying, designing, building
and testing the software. But software is used in a business context, and design and development
tradeoffs must be made based on business need, not just on technology. In this talk, Shari Lawrence
Pfleeger will discuss the four areas that have bearing on the software process: the organization, the
environment, the system, and the individual using the software. She will show how sometimes the
best decisions for software are not the best decisions for the business, and how the software development process must take these four perspectives into account. She will use examples from criminal
justice, homeland security, intellectual property protection, and more, to illustrate her points.
About the author
Shari Lawrence Pfleeger is a senior researcher at the RAND Corporation, a not-for-profit company
doing high-quality, high-impact research in the public interest. At RAND, she works on policy and
decision-making issues that help organizations and government agencies understand whether and
how information technology supports their mission and goals. From 1982 to 2003, Dr. Pfleeger
was president of Systems/Software, Inc., a consultancy specializing in software engineering and technology. From 1997 to 2000, she was also a visiting professor at the University of Maryland’s
computer science department. Prior to that, she was founder and director of Howard University’s
Center for Research in Evaluating Software Technology (CREST), and was a visiting scientist at the City
University (London) Centre for Software Reliability, principal scientist at MITRE Corporation’s Software
Engineering Center, and manager of the measurement program at the Contel Technology Center.
Her publications include “Software Engineering: Theory and Practice” (4th edition, with Joanne Atlee,
2009, Prentice Hall), “Security in Computing” (4th edition, with Charles P. Pfleeger, 2007, Prentice
Hall), “Solid Software” (2001, with Les Hatton and Charles Howell, Prentice Hall), and “Software
Metrics: A Rigorous and Practical Approach” (2nd edition, with Norman Fention, 1996, Boyd and
Fraser Publishers). Dr. Pfleeger was book review editor for IEEE Security and Privacy magazine until
2007. She was for several years the associate editor-in-chief of IEEE Software, where she edited
the Quality Time column, and then associate editor of IEEE Transactions on Software Engineering.
From 1998 to 2002, she was a member of the editorial board of Prentice Hall’s Software Quality
Institute series. She is a senior member of IEEE, the IEEE Computer Society, and the Association
for Computing Machinery. She has been on the executive council of the IEEE Technical Council
on Software Engineering, and was the vice chair of the executive committee for the Institute for
Information Infrastructure Protection from 2005 to 2008.
18 WAMPS 2009
It’s Not Just Software: Software Quality in a Business Context
WAMPS 2009 19
Palestras convidadas
Variação de Desempenho nas Empresas que
Adotaram o Modelo MPS: resultados iniciais
iMPS 2009
Guilherme Horta Travassos e Marcos Kalinowski {ght, mkali}@cos.ufrj.br
Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brasil
Resumo: Este artigo apresenta uma síntese dos resultados iniciais da rodada de 2009 do projeto iMPS (informações para acompanhar e evidenciar variação de desempenho nas empresas que adotaram o Modelo
MPS), apresentados sob duas perspectivas: caracterização e análise de variação 2008/2009. De forma geral, a
satisfação das empresas com o modelo é notória, com mais de 98% das empresas se dizendo parcialmente ou
totalmente satisfeitas. Além disso, as empresas relataram que o retorno do investimento foi obtido e, principalmente, para aquelas empresas que evoluíram ou internalizaram o MPS em seus processos foi possível observar
tendência a melhoria de custo, qualidade, prazo e produtividade, princípios básicos quando se desenvolve
software seguindo os preceitos de engenharia.
1. Introdução
A melhoria contínua da capacidade de desenvolvimento de software é fundamental para que empresas
prosperem em mercados competitivos. Ao longo dos anos modelos de referência têm surgido para
guiar a melhoria da capacidade de processos de engenharia de software. Entretanto, a melhoria baseada neste tipo de modelo costuma ser de longo prazo e requer grandes investimentos [Goldenson
e Gibson, 2003]. Estes obstáculos podem se tornar impeditivos para que empresas melhorem seus
processos, especialmente para pequenas e médias empresas (PMEs) que operam sob rígidas restrições
financeiras [Staples et al., 2007]. No Brasil, onde aproximadamente 73% da indústria de software é
constituída por PMEs, poucas empresas tem adotado modelos de referência [MCT, 2008].
Neste contexto, em dezembro de 2003, foi criado o programa MPS.BR, representando uma iniciativa
para melhorar a capacidade de desenvolvimento de software nas empresas Brasileiras. Em relação
a empresas avaliadas, até setembro de 2009 contava-se com 174 avaliações MPS publicadas. Os
resultados destas avaliações estão disponíveis na seção Avaliações em www.softex.br/mpsbr. Num
cenário referente aos próximos anos, espera-se ter no mínimo 200 empresas avaliadas oficialmente
até dezembro de 2009 e alcançar 300 até dezembro de 2010.
Considerando a adoção do modelo MPS pelas empresas brasileiras, revela-se o interesse por compreender qualitativamente resultados de desempenho obtidos por estas empresas, tais como prazo,
produtividade, custo e qualidade. Com este objetivo, o projeto iMPS (informações para acompanhar
e evidenciar variação de desempenho nas empresas que adotaram o Modelo MPS) foi iniciado junto
ao Grupo de Engenharia de Software Experimental (http://ese.cos.ufrj.br) da COPPE/UFRJ. O objetivo
global do iMPS é planejar um survey, seguindo os princípios da Engenharia de Software Experimental,
20 WAMPS 2009
Variação de Desempenho nas Empresas que Adotaram o Modelo MPS: resultados iniciais iMPS 2009
e periodicamente executá-lo para acompanhar e evidenciar resultados de desempenho nas empresas
de software que adotaram o modelo MPS. Maiores detalhes sobre o plano da pesquisa, os momentos
de captura das informações e o tratamento dado às ameaças à validade podem ser encontrados em
[Kalinowski et al., 2008]. A rodada de 2008 do iMPS forneceu evidências objetivas iniciais [Travassos
e Kalinowski, 2008], a serem complementadas anualmente por outras rodadas iMPS que permitirão
análises comparativas em relação ao retrato da situação em 2008 (baseline).
Este artigo apresenta uma síntese dos resultados iniciais da rodada de 2009. Neste ano, os resultados
do iMPS serão apresentados sob duas perspectivas: caracterização e análise de variação 2008/2009.
O objetivo da caracterização é delinear o desempenho das empresas que adotaram o MPS em 2009.
Por sua vez, o objetivo da análise da variação 2008/2009 é observar a variação do desempenho das
empresas que adotaram o MPS entre 2008 e 2009. É importante ressaltar que a empresa é comparada
somente com ela mesma e que dados de desempenho individuais das empresas não são divulgados.
O restante deste artigo está organizado da seguinte maneira. Na seção 2, os resultados preliminares
da caracterização 2009 são apresentados. Na seção 3, os resultados preliminares da análise de variação 2008/2009 são apresentados. Na seção 4 as considerações finais do artigo são apresentadas.
2. Resultados iMPS 2009: Caracterização
A análise de caracterização visa delinear o desempenho das empresas que adotaram o MPS em 2009.
Assim, apenas dados de 2009 foram considerados nesta análise. No total, questionários de 135
empresas diferentes (20 iniciando a implementação MPS, 24 em processo de avaliação, 58 avaliadas
MPS nível G, 26 avaliadas MPS nível F e 7 avaliadas MPS níveis E-A) foram utilizados.
Tendo em vista a concentração da maioria das empresas ainda nos níveis iniciais de maturidade, optouse por dividir o conjunto de dados nas seguintes 4 categorias: Empresas Iniciando a Implementação,
Empresas Avaliadas em Nível de Maturidade G, Empresas Avaliadas em Nível de Maturidade F e
Empresas Avaliadas em Níveis de Maturidade E-A. Como a análise de caracterização agrega dados
de diferentes empresas, é natural que as medidas apresentem desvios padrão muito altos. Assim,
acreditamos que a mediana, representando o valor central para a medida, possa fornecer informação mais adequada para a caracterização das empresas. Adicionalmente, durante a preparação dos
dados, medidas com valores a mais de três desvios padrão da média (outliers) foram descartadas até
que o conjunto final de dados não contivesse mais medidas nesta situação. Desta forma foi possível
aproveitar o máximo possível de respostas e ao mesmo tempo não influenciar os resultados com
dados eventualmente distorcidos. Neste processo foi possível identificar que a maioria dos outliers se
encontrava nas empresas iniciando a implementação ou no nível G, onde o desvio padrão das medidas também se mostrava maior. Isto pode estar relacionado com o fato de o processo de medição
ser do nível F do MPS, o que nos leva a acreditar que os resultados das medidas das empresas sejam
mais confiáveis a partir deste nível de maturidade. Seguem alguns resultados preliminares desta dimensão de análise.
Satisfação dos Clientes. A satisfação dos clientes relatada pelas empresas é maior para as empresas que adotaram o MPS. Das empresas iniciando a implementação 50% possuem clientes totalmente ou largamente satisfeitos. Entre as empresas com avaliação MPS este número sobe para 68,13%.
WAMPS 2009 21
Palestras convidadas
Considerando apenas as empresas avaliadas entre os níveis E-A a satisfação dos clientes chega a
71,43%.
Satisfação com o Modelo MPS. Em relação à satisfação das empresas com o modelo MPS, 71,11%
(96 empresas) relataram estar totalmente satisfeitas com o modelo e 27,41% relataram estar parcialmente satisfeitas. Apenas 0,74% (1 empresa) relatou estar insatisfeita e 0,74% (uma empresa)
informou ainda não conhecer o seu nível de satisfação. Todas as empresas com nível de maturidade
acima de F se declararam totalmente ou parcialmente satisfeitas. Este resultado demonstra um quadro de ampla satisfação.
Outros Modelos de Maturidade. Entre os outros modelos e normas, o mais citado pelas empresas
foi o CMMI. Este modelo se mostra mais presente nas empresas que adotaram o MPS. Das empresas
iniciando a implementação 10% possuem algum nível de maturidade CMMI. No nível G o percentual
de empresas com CMMI é 10,53%. No nível F este número sobe para 11,54% e entre os níveis E-A
chega a 57,14%.
Tamanho dos Projetos. Em relação ao tamanho dos projetos, das 135 empresas consideradas, 44
(33,9%) mencionaram medir o tamanho de seus projetos em pontos de função. Esta foi a medida de
tamanho mais utilizada, seguida por pontos de caso de uso, utilizada por 20 empresas (14,81%).
A Figura 1 apresenta as medianas do tamanho médio dos projetos das empresas que utilizam pontos de função para cada agrupamento utilizado no estudo. Enquanto a mediana do tamanho para
empresas iniciando a implementação é de 200 pontos de função, a mediana para as empresas nos
níveis E-A é de 260. Existe uma correlação positiva entre o aumento da mediana e o aumento do
nível de +0,72.
Figura 1. Mediana do tamanho dos projetos
Precisão de Estimativa de Prazo. Para precisão de estimativa levamos em consideração apenas as
empresas dos níveis de maturidade G, F e E-A. Um dos motivos é que antes do nível G as empresas
não necessariamente realizam estimativas de prazo e, em função disto, os dados para estas empresas
se mostraram improváveis (58,89% destas empresas relataram estimar o prazo dos projetos exatamente igual ao tempo que os projetos realmente levaram, este número cai para 46,29% no nível G,
43,47% no nível F e 33,3% nos níveis E-A).
Assim, como muitas empresas informaram realizar estimativas exatas, acreditamos que esta variável
seja melhor observada olhando a variação dentro de cada conjunto de empresas. A Figura 2 ilustra
22 WAMPS 2009
Variação de Desempenho nas Empresas que Adotaram o Modelo MPS: resultados iniciais iMPS 2009
esta variação, através de um boxplot, que destaca os valores máximo, mínimo e a mediana. Enquanto
a mediana apresenta variação pequena, as empresas de níveis de maturidade E-A apresentaram uma
menor variação e uma precisão de estimativa mínima maior.
Figura 2. Boxplot da Precisão de Estimativa
Produtividade. A produtividade se apresenta maior para as empresas que adotaram o MPS. A
maior mediana foi a das empresas do nível G. Entretanto, é importante ressaltar que produtividade
está sendo observada de forma isolada e que a produtividade se mostra naturalmente diferente de
acordo com o tipo de projeto e as expectativas em relação à qualidade1 e ao custo2. Adicionalmente,
o cálculo da produtividade leva em consideração outras medidas base, que, conforme discutido anteriormente, podem ser mais confiáveis para empresas a partir do nível de maturidade F, que possuem
um processo de medição institucionalizado.
Figura 3. Mediana da Produtividade (em PF/Mês)
A Figura 3 apresenta as medianas da produtividade dos projetos das empresas que utilizam pontos
de função para cada agrupamento utilizado no estudo. Enquanto a mediana da produtividade para
empresas iniciando a implementação é de 40 pontos de função por mês, a mediana para as empresas
1) A qualidade é capturada nos questionários como número de defeitos por unidade de tamanho. Como muitas empresas tratam defeitos
de uma forma distinta estas respostas são consideradas somente na dimensão de análise de variação, ou seja, comparando a empresa com
ela mesma no decorrer do tempo.
2) O custo não pôde ser analisado na dimensão de caracterização, porque as medidas apresentadas demonstram uma falha de interpretação da pergunta do questionário por grande parte das empresas. Ou seja, o cálculo do custo foi realizado de forma diferente do
esperado.
WAMPS 2009 23
Palestras convidadas
nos níveis E-A é de 62,32 pontos de função por mês. Existe uma correlação positiva entre o aumento
da mediana e o aumento do nível de +0,46.
Apresentado este resumo da caracterização das empresas em 2009, a seção seguinte apresentará a
variação de desempenho entre 2008 e 2009 das empresas que adotaram o MPS.
3. Resultados iMPS 2009: Análise da Variação 2008/2009
Para análise dos dados enviados pelas empresas que responderam ao questionário periódico e já
haviam também fornecido informações em 2008 foi utilizado o mesmo conjunto de critérios, com
análise e eliminação de pontos extremos. Os indicadores que estão sendo analisados foram aqueles
definidos no plano de estudo do iMPS [Travassos e Kalinowski, 2008]: A. Variação do Faturamento, B.
Número de Clientes no País, C. Número de Funcionários, D. Custo Médio dos Projetos, E. Prazo Médio
dos Projetos, F. Tamanho Médio dos Projetos, G. Produtividade, H. Qualidade, I. Satisfação do Cliente
e J. Retorno do Investimento (ROI). No total foram consideradas 43 empresas, com um questionário
para o ano de 2008 e outro para o ano de 2009, agrupadas seguindo os mesmos critérios da avaliação de 2008 em Nível G (22); Nível F (17); Níveis E-A (4). Em complemento, um novo grupo com 9
empresas pôde ser organizado incluindo aquelas que renovaram/mudaram de nível nesse período e
responderam o questionário periódico. O cálculo dos indicadores seguiu rigorosamente as fórmulas
definidas no plano estudo do iMPS. Em adição, a interpretação dos resultados associados aos indicadores teve como base as premissas de comportamento apregoadas na Engenharia de Software para
projetos de software, que se diferenciam naturalmente dos processos produtivos tradicionais. Por
exemplo, o conceito de produtividade no contexto iMPS se refere a ´tamanho médio de projeto dos
últimos 12 meses / tempo médio gasto nos projetos dos últimos 12 meses`, portanto relacionando
exclusivamente características de projeto de software e apresentando uma representação simplificada se comparada ao conceito usual de produtividade utilizada em processos produtivos.
A seguir serão apresentados os resultados iniciais obtidos a partir dos dados enviados. Conforme
definido no iMPS, os dados são sempre coletados de forma a não permitir comparação competitiva
entre as empresas. Por estar tratando de variação de desempenho o valor individual do indicador de
cada empresa faz sentido apenas para a própria empresa, perdendo significado se ocorrer tentativa
de comparação. Para observar o comportamento em cada grupamento foi gerada então uma distribuição contendo 3 faixas para categorizar o desempenho das empresas em cada indicador, indicando
o percentual relativo de empresas (baseado no número de respostas válidas) que tiveram aumento,
redução ou não sofreram alteração. A avaliação do significado do impacto do aumento ou redução
de um indicador depende do indicador e, em algumas situações, pode ser relacionado com outro
indicador. Por exemplo, espera-se que o custo médio dos projetos reduza ao mesmo tempo em que
produtividade aumente. Portanto, neste caso, tanto redução quanto aumento representa impacto
positivo para as empresas em análise. Por isso, acreditamos que apresentar as tendências de comportamento das empresas pode ajudar a ter uma melhor compreensão geral dos benefícios do MPS
ao mesmo tempo em que pode indicar os pontos onde exista necessidade de investir esforços para
aprimorar o rendimento geral do modelo. O nível de confiança [Gardner e Altman, 1989] para as respostas referentes a cada indicador foi calculado considerando-se a população como sendo o número
total de questionários válidos para cada grupo e a amostra o número de respostas válidas para cada
24 WAMPS 2009
Variação de Desempenho nas Empresas que Adotaram o Modelo MPS: resultados iniciais iMPS 2009
questão. A finalidade é tentar sugerir o quanto o comportamento descrito pelo indicador poderia
estar representando o comportamento das empresas considerando o grupo específico sob análise.
Como se pode observar na Figura 4, os resultados gerais indicam tendências interessantes em relação às empresas que enviaram os questionários. Por exemplo, é possível perceber que as empresas
relataram aumento no Faturamento, Número de Clientes no País, Número de Funcionários e Retorno
de Investimento. Por outro lado, alguma influência pode ser observada em relação ao Custo Médio
dos Projetos que aumentou e a Produtividade que diminuiu. Entretanto, análise adicional precisa ser
realizada para identificar se o impacto é positivo ou negativo, pois, aparentemente ocorreu alteração
na capacidade de identificação de defeitos (observada no indicador qualidade), um leve aumento no
tamanho dos projetos e, como já identificado, aumento no número de funcionários, com influência
na satisfação do cliente. A questão do comportamento do indicador Qualidade precisa ser analisada
de forma mais detalhada. O cálculo do indicador é realizado através de comparação do número de
defeitos identificados em cada ano pela empresa.
Indicador
A
B
C
D
E
F
G
H
I
J
Respostas Válidas
27
35
37
29
40
39
25
15
43
22
88,3
92,7
93,9
89,4
95,8
95,1
87,1
79,2
100
85,1
Nível de Confiança (%)
Figura 4. Variação de Desempenho de 43 Empresas com MPS – Níveis G-A
Desta forma, algumas empresas relataram estarem identificando mais defeitos e outras empresas
menos defeitos. Entretanto, se comparado com os resultados apresentados pelas empresas no nível
F (Figura 6) ou que revalidaram/mudaram de nível (Figura 8) pode se perceber que o comportamento
do indicador Qualidade tende a apresentar comportamento de maior capacidade de identificação de
defeitos, com tendência a menor custo médio dos projetos. Assumindo que, normalmente, novos
processos e práticas devem ser inseridos no contexto do desenvolvimento do software para aumentar
a qualidade final do produto, isso poderia nos levar a conjecturar que houve realmente tendência de
aumento da qualidade (maior capacidade de identificação de defeitos) por parte das empresas, pois
se estaria conseguindo antecipar o risco da falha com a identificação e remoção dos defeitos ao longo do desenvolvimento do software, reduzindo o retrabalho. Entretanto, análise complementar deve
ser realizada para verificar este comportamento já que existe alguma contradição com o que pode
ser observado para as empresas Níveis E-A (Figura 7). Estas empresas, por estarem em níveis mais
altos de maturidade, já deveriam ter incorporado grande parte das práticas e processos necessários a
cobrir as atividades de garantia de qualidade ao longo do processo de desenvolvimento de software.
Porém a falta de qualidade dos dados limita a capacidade de observação.
WAMPS 2009 25
Palestras convidadas
Indicador
A
B
C
D
E
F
G
H
I
J
Respostas Válidas
16
16
20
16
20
20
11
5
22
11
86,9
86,9
93,3
86,9
93,3
93,3
78,7
60,7
100
78,7
Nível de Confiança (%)
Figura 5. Variação de Desempenho de 22 Empresas com MPS – Nível G
Na Figura 5, os resultados da variação de desempenho das empresas nível G indicam que estas empresas aparentam ter apresentado aumento no Faturamento, Número de Clientes no País, Número
de Funcionários e Retorno de Investimento. Por outro lado, alguma influencia pode ser observada em
relação ao Custo Médio dos Projetos que aumentou e a Produtividade que diminuiu. Entretanto, análise adicional precisa ser também realizada para identificar se o impacto é positivo ou negativo, pois
aparentemente ocorreu melhora da qualidade, com maior capacidade de identificação de defeitos,
um aumento no tamanho dos projetos e, como já identificado, aumento no número de funcionários,
com alguma melhora na satisfação do cliente.
Indicador
A
B
C
D
E
F
G
H
I
J
Respostas Válidas
10
15
15
13
15
15
11
8
17
8
79,7
91,1
91,1
86,5
91,1
91,1
82,1
74,3
100
77,1
Nível de Confiança (%)
Figura 6. Variação de Desempenho de 17 Empresas com MPS – Nível F
Os resultados da variação de desempenho das empresas nível F indicam que estas empresas tiveram
aumento no Faturamento, Número de Funcionários, (redução) Custo Médio dos Projetos, Qualidade
e Retorno de Investimento, conforme pode ser visto na Figura 6. Por outro lado, alguma influencia pode ser observada em relação ao Tamanho dos Projetos e a Produtividade que diminuíram.
26 WAMPS 2009
Variação de Desempenho nas Empresas que Adotaram o Modelo MPS: resultados iniciais iMPS 2009
Entretanto, análise adicional precisa ser realizada para identificar se o impacto é positivo ou negativo, pois aparentemente ocorreu melhora da qualidade, com maior capacidade de identificação de
defeitos e, como já identificado, aumento no número de funcionários, sem influenciar a satisfação
do cliente, que ainda é elevada.
Indicador
A
B
C
D
E
F
G
H
I
J
Respostas Válidas
1
4
3
0
4
4
3
2
4
1
13,4
100
71,1
0
100
100
71,1
50
100
13,4
Nível de Confiança (%)
Figura 7. Variação de Desempenho de 4 Empresas com MPS – Níveis E-A
Os resultados da variação de desempenho das empresas Níveis E-A pode ser visto na Figura 7. O baixo número de respostas válidas dificulta uma observação mais elaborada deste grupo de empresas.
Entretanto, é possível observar que o número de clientes aumentou, com uma aparente redução do
número de funcionários. A redução de pessoal pode ter sido provocada pela redução do prazo e
tamanho médio dos projetos, exigindo equipes menores. Entretanto, é preciso aumentar o número
de empresas e a qualidade dos dados deste grupo para que se possa identificar mais claramente o
comportamento dos indicadores.
Indicador
A
B
C
D
E
F
G
H
I
J
Respostas Válidas
5
8
8
6
8
7
7
3
9
4
70,2
88,2
88,2
76,4
88,2
82,2
82,2
52,3
100
62,7
Nível de Confiança (%)
Figura 8. Variação de Desempenho de 9 Empresas com MPS que Revalidaram/Mudaram de Nível
WAMPS 2009 27
Palestras convidadas
Na Figura 8, os resultados da variação de desempenho das empresas que mudaram ou revalidaram
seus níveis de maturidade junto ao MPS. A característica principal destas empresas, independente do
nível a que estejam avaliadas, se refere a adoção do MPS e continuidade do desenvolvimento seguindo as diretrizes oferecidas por ele. É possível observar que, de acordo com os dados fornecidos pelas
empresas, os indicadores apresentam comportamento coerente com as hipóteses associadas à utilização de processos de desenvolvimento de software combinado com boas práticas da engenharia de
software. Por exemplo, é possível observar a tendência à redução de custos e prazos em combinação
com o aumento de qualidade e produtividade. Acreditamos que esta combinação de eventos possa
estar influenciando positivamente os outros indicadores referentes a estas empresas, e relacionados
ao aumento de faturamento, número de clientes, funcionários, satisfação dos clientes e ROI. Uma
investigação adicional precisa ser realizada no sentido de se tentar identificar possíveis fatores de
confusão que possam estar influenciando estes resultados.
4. Considerações Finais
Neste artigo apresentamos os resultados iniciais da rodada 2009 do iMPS, que visa caracterizar e
compreender a variação do desempenho das empresas em função da adoção do modelo MPS.
Em relação à caracterização 2009, foi possível observar que as empresas que adotaram o modelo
MPS apresentam uma maior satisfação dos seus clientes, lidam com projetos maiores, apresentam
menores erros em suas estimativas de prazo e se mostram mais produtivas, quando comparadas às
empresas que estão iniciando a implementação do MPS. Adicionalmente, o modelo CMMI se mostra
mais presente. A satisfação das empresas com o modelo é notória, com mais de 98% das empresas
se dizendo parcialmente ou totalmente satisfeitas.
Para as empresas que vem utilizando o MPS, foi possível observar que, independente do nível de
maturidade, a adoção do MPS pode ter contribuído para o aumento do numero de clientes, faturamento e número de funcionários, sem afetar satisfação dos clientes. De forma geral, as empresas
relataram que o retorno do investimento foi obtido e, principalmente, para aquelas empresas que
evoluíram ou internalizaram o MPS em seus processos foi possível observar tendência a melhoria de
custo, qualidade, prazo e produtividade, premissas básicas quando se desenvolve software seguindo
os preceitos de engenharia.
Análises adicionais necessitam ainda ser realizadas com o objetivo de reduzir possíveis ameaças a validade de conclusão que ainda possam existir. Existem algumas variáveis de contexto não identificadas
que podem estar influenciando estes resultados. Entretanto, esperamos que estes resultados iniciais
sirvam para motivar as empresas que já adotam o MPS a dar continuidade nas atividades de melhoria e aprimoramento de seus processos e, também, como motivador para as empresas que desejam
passar a adotar o MPS em um futuro próximo.
Agradecimentos
Este trabalho não teria sido possível sem a participação das empresas e dos profissionais Kival Chaves
Weber (Coordenador Executivo do Programa MPS.BR), Nelson Henrique Franco de Oliveira e André
Luis Chamelet Sotovia (Gerência de Operações do MPS.BR), Virgínia Costa Duarte e Daniela Albini
Pinheiro (Observatório SOFTEX) os quais agradecemos imensamente sua contribuição.
28 WAMPS 2009
Variação de Desempenho nas Empresas que Adotaram o Modelo MPS: resultados iniciais iMPS 2009
Bibliografia
Gardner, M.J; Altman, D. G. (1989), “Statistics with Confidence: confidence intervals and statistical
guidelines”. London: BMJ Publishing Group
Goldenson, D.R., Gibson, D.L. (2003) Demonstrating the Impact and Benefits of CMMI: An Update
and Preliminary Results, SEI Special Report, CMU/SEI-2003-SR-009, Oct. 2003.
Kalinowski, M., Weber, K. and Travassos, G.H. (2008). iMPS: An Experimentation Based Investigation
of a Nationwide Software Development Reference Model. ACM/IEEE 2nd International Symposium
on Empirical Software Engineering and Measurement. October, 9-10. Kaiserslautern. Germany.
MCT. Qualidade e Produtividade no Setor de Software Brasileiro em 2008. Ministério da Ciência e
Tecnologia (MCT). Brasília: 2008.
Staples, M., Niazi, M., Jeffery, R., Abrahams, A., Byatt, P., Murphy, R., (2007) An exploratory study of why organizations do not adopt CMMI. The Journal of Systems and Software 80 (2007)
883–895
Travassos, G. H. e Kalinowski, M. (2008). iMPS: Resultados de desempenho de empresas que adotaram o modelo MPS. – Campinas, SP: SOFTEX, 2008 (ISBN 978-85-99334-11-9) (disponível em
http://www.softex.br/mpsbr/_livros/imps/imps.pdf último acesso em 29/09/2009)
Sobre os autores
Guilherme Horta Travassos é doutor em Engenharia de Sistemas e Computação pela COPPE/
UFRJ e realizou estágio de pós-doutorado em Engenharia de Software Experimental na University of
Maryland-College Park. Professor de Engenharia de Software do Programa de Engenharia de Sistemas
e Computação da COPPE/UFRJ. Pesquisador 1D CNPq. Líder do Grupo de Engenharia de Software
Experimental. Atualmente é Diretor de Planejamento e Administração da COPPE/UFRJ, membro da
ISERN e da Comissão de Educação da SBC – Sociedade Brasileira de Computação. Atua em projetos
de P&D com a indústria através da Fundação COPPETEC. Informações adicionais podem ser obtidas
em http://www.cos.ufrj.br/~ght.
Marcos Kalinowski é mestre e doutorando em Engenharia de Software pela COPPE/UFRJ. Bacharel
em Ciência da Computação pela UFRJ. Membro do Grupo de Engenharia de Software Experimental
da COPPE/UFRJ. Instrutor, Implementador, Avaliador e membro da equipe técnica do MPS.BR, sendo
afiliado à Instituição Implementadora e Avaliadora COPPE/UFRJ e tendo participado da avaliação de
diversas empresas em diferentes estados do país. Professor da pós-graduação e-IS Expert da UFRJ.
Diretor da Kali Software desde 2004, tendo participado de treinamentos e consultorias em engenharia de software para empresas de diferentes portes, dentro e fora do país.
WAMPS 2009 29
Palestras convidadas
Who Are the Enemies; What Can They Do?
Internet Software Security Issues in the
Software Development Process
Dr. Charles P. Pfleeger
Pfleeger Consulting Group
Software development involves success: We take a problem, derive a set of requirements, build
software to meet those requirements, test it to confirm it works as expected, and deliver it as a solution to the problem. Success occurs if the software meets explicit and implicit requirements. Explicitly
it has to do all the things in the requirements; implicitly it has to satisfy the customer in such areas as
performance, interface design and usability, stability, or appeal.
Organizations developing software perform certain best practices. Eliciting, documenting, analyzing
and codifying requirements is a key starting point. If the requirements are incomplete, inconsistent
or impossible, the resulting product will not satisfy the customer’s needs. From a set of solid requirements, the development organization carefully transforms those requirements into specifications
and then code in a way that is both rigorous and creative. Quality assurance measures are employed
at several points during development to help ensure that the finished product will meet it explicit and
implicit requirements, and thereby satisfy its original purpose.
Throughout the development process, there is a positive emphasis, that is, ensuring that the software
does do what it is supposed to. If I supply this input the software will produce that output. If the
system receives n inputs in k amount of time it will process those inputs successfully.
Sometimes a developer will decide to offer a bonus, adding functionality not stated in the requirements (but not contradictory to them). For example, software expecting a date as an input might
treat “09” as “2009,” as if the user chose to enter a short form of the year. In most situations this
would be a pleasant outcome, making data entry easier and less restrictive for the user. (Historians
entering dates from 2000 years ago might not find this a useful addition, however.) It is very difficult
to think of all requirements and phrase them so that they include all possibilities. There will always
be ambiguity between the explicitly stated requirements and the real, unspoken requirements. For
example, a simple program whose only requirement is to receive two numbers as input and produce their sum as output seems as if it should have just that one functional requirement. But a user
might reasonably reject a program that performed that calculation correctly but required ten years
to produce the answer. The development process should have elicited a timeliness requirement, but
without such a requirement nobody can say the ten-year program failed. Consider the output: Is it
meeting the requirement to produce an output of “1,000” for inputs of 400 and 600, or is “1000”
the only acceptable output? The developer might have chosen to produce the output in binary or
scientific notation, or displayed in white text on a white background, again, not failing because the
output format was not a requirement. And the lengths of the two input numbers are not stated:
30 WAMPS 2009
Who Are the Enemies; What Can They Do?
should the program be able to handle 100-digit (or 1,000,000,000-digit) numbers? Is the program
compliant if it handles correctly only numbers up to, say, 1 billion, or if the program produces an
error message for numbers larger than a certain size?
Admittedly, these examples sound like trying to pick apart the rather simple requirement of adding
two numbers. Security professionals have to look at both the positive and negative. Not only should
a system do all things in the explicit requirements, it also should do nothing more. But as just argued,
it can be difficult to state precisely what “nothing more” means. What security professionals really
mean is “nothing more that is significant.” Thus in most situations, 1,000 versus 1000 would not be
significant. In most situations, when asked to produce a list of names, producing the list sorted in
alphabetic order would not be significant. Or phrased differently, the list must be produced in some
order and, because programs tend to be regular, there will be some basis for the order presented.
If the list is apparently in alphabetic order, that is likely the basis. But suppose the names are not
in alphabetic order and the basis is not obvious. Is it acceptable if the names are ordered by body
weight or personal wealth or number of convictions for murder (even if these other values are not
displayed)? The “nothing more that is significant” condition can be very difficult to assess.
The software developer tends to be positive: A good developer is someone who can take a difficult situation with many complicated requirements, and produce a design and then code that does meet those
requirements. A security person has to consider the negative side: What are the limits or edges of the
requirements? What has the developer perhaps not considered? How can I make this system fail?
In additional to the standard aspects of the software development process, a security development
process involves a threat and vulnerability analysis. The analysts must consider who and what would
threaten this system with harm, and what potential weaknesses in the system these threats could
exploit. Part of the threat analysis involves considering motives and opportunity, to determine who
might have a motive for causing harm and who might have the opportunity. Unfortunately, threat
agents have many possible motives, from amateur hackers intent on just exploring failures for any
systems, to targeted, well-financed agents who want a specific system to fail, for motives of revenge,
espionage, profit or competition. And there are also motive-less attackers, ranging from employees
making a simple, honest mistake, to uncontrollable events such as earthquakes or power failures.
Each of these threats is important only against a particular vulnerability or weakness; if there is no
vulnerability, the attack causes no harm, in the same way that a rainstorm causes no harm to people
who are protected inside a building.
For potential vulnerabilities the security analyst considers controls or countermeasures. An attacker
might try to make a system fail by entering a number that is too big. If the system checks for the size
of its inputs, and rejects all that are too large, the checking is a control. The security analyst considers
the controls, assesses their strengths, sees if they overlap or interfere, determines if two together are
stronger than either alone, and generally tests whether the system controls seem to protect all vulnerabilities against all attacks. Obviously, completeness is nearly impossible to determine.
Until now, security often operates separately from software development. Clearly, threat and vulnerability analysis can be a useful aspect of specification and design, implementation, and testing.
Similarly, documentation of this process adds considerably to the evidence of security and quality
in the system. Several initiatives have tried to see security integrated into the software development
process, but so far there has been only limited success.
WAMPS 2009 31
Palestras convidadas
This talk will review security requirements and propose how they can be integrated into a software
development process to improve security.
About the author
Charles P. Pfleeger is an independent consultant with the Pfleeger Consulting Group, specializing
in computer and information system security. Among his responsibilities are threat and vulnerability
analysis, risk analysis, system security design and review, certification preparation, training, expert
testimony and general security advice. His customers include government and commercial clients
throughout the world.
Dr. Pfleeger was previously a Master Security Architect on the staff of the Chief Security Officer
of Cable and Wireless, and Exodus Communications, and before that he was a Senior Computer
Scientist and Director of Research for Arca Systems, Director of European Operations for Trusted
Information Systems, Inc. (TIS), and a professor in the Computer Science Department of the University
of Tennessee.
Dr. Pfleeger was chair of the IEEE Computer Society Technical Committee on Security and Privacy
from 1997-1999 and has been a member of the executive council of that committee since 1995. He
is on the board of reviewers for Computers and Security and the editorial board of IEEE Security and
Privacy.
Dr. Pfleeger has lectured throughout the world and published numerous papers and books. His book
Security in Computing (of which the fourth edition—co-authored with Dr. Shari Lawrence Pfleeger—
was published in 2006) is the standard college textbook in computer security. He is the author of
other books and articles on technical computer security and computer science topics.
He holds a Ph.D. degree in computer science from The Pennsylvania State University and a B.A. with
honors in mathematics from Ohio Wesleyan University. He is a Certified Information Systems Security
Professional (CISSP).
32 WAMPS 2009
Who Are the Enemies; What Can They Do?
WAMPS 2009 33
Artigos aceitos
Gestão Integrada da Melhoria de Processos em
Organizações de Software
Marcelo Santos de Mello1,2, Ana Regina Rocha2
[email protected], {msmello,darocha}@cos.ufrj.br
Informal Informática Ltda.
Rua do Catete, 311, Gr 1311 - CEP 22220-001 - Rio de Janeiro - RJ – Brasil
1
COPPE/UFRJ – Universidade Federal do Rio de Janeiro
Programa de Engenharia de Sistemas e Computação Av. Horácio Macedo, 2030, Prédio do Centro de Tecnologia, Bloco H, Sala 319 Caixa Postal 68511 – CEP 21941-914 – Rio de Janeiro, RJ
2
Abstract: The software organizations generally adopt quality norms and reference models are usually adopted
as a guide in process definition, practical execution and revision of procedures, being necessary in some situations the use of more than a norm or model. However, some difficulties are noticed in organizations that implement multi-models improvement projects. This work reports the experience of Informal Informática with the
MR MPS deployment project together with ISO 9001, which was accomplished in 2 (two) serial improvement
cycles from April, 2006 to May, 2009, and includes the presentation of the approach defined for the models,
the arisen difficulties and the factors of success for the project.
Resumo: As organizações de software geralmente adotam normas de qualidade e modelos de referência como guia para definição dos processos, implantação de melhores práticas e/ou revisão de procedimentos, sendo
necessária em determinadas situações a utilização de mais de uma norma ou modelo. Entretanto, algumas dificuldades são percebidas nas organizações que implementam projetos de melhoria multi-modelos. Este trabalho
relata a experiência da Informal Informática no projeto de implementação do MR-MPS em conjunto com a ISO
9001, realizado em 2 (dois) ciclos consecutivos de melhoria, entre abril de 2006 e maio de 2009, com apresentação do mapeamento definido entre os modelos, dificuldades encontradas e fatores de sucesso do projeto.
1. Introdução
Alcançar a estabilidade e o crescimento contínuo para as organizações de software implica tanto na
melhoria dos seus produtos de trabalho e serviços correlatos quanto dos processos de produção e
distribuição de software [SOFTEX, 2009]. Grande parte das empresas deste ramo nasceu pequena
e desenvolveu uma cultura própria de trabalho que, em um primeiro momento, se mostrou eficaz
e possibilitou o seu crescimento. Com o passar do tempo, novas necessidades internas e externas à
empresa surgiram, gerando uma necessidade de adequação à realidade que se apresenta.
Da mesma forma, nestas organizações há uma evolução natural do processo de desenvolvimento
devido à constante mudança de tecnologias, tendências e soluções disponíveis, porém nem sempre
realizada de forma organizada, convergente e alinhada aos objetivos estratégicos. Para tratar desafios desta natureza, a utilização de modelos de referência, normas de qualidade, padrões e outras
tecnologias de melhoria é o caminho adotado pelas organizações de melhor desempenho [SIVIY et
al., 2008].
34 WAMPS 2009
Gestão Integrada da Melhoria de Processos em Organizações de Software
Nos últimos anos, diversos modelos de referência para práticas de desenvolvimento de software
foram desenvolvidos, similarmente a outras áreas de produção. De maneira geral, as organizações
selecionam um modelo como guia para a definição de seus processos, quer estejam buscando certificações, quer estejam visando o estabelecimento de novas práticas, organização e melhoria de seus
processos de trabalho [ARAÚJO et al.,2004].
Neste contexto, existem organizações que utilizam em seus projetos de melhoria mais de um modelo
ou padrão. Nos projetos de melhoria multi-modelos, as normas e os modelos costumam ser combinados para complementar áreas e estratégias diferentes, potencializando os resultados da melhoria
para a organização.
Entretanto, algumas dificuldades são percebidas nas organizações que implementam iniciativas desta natureza. Segundo SIVIY (2008), em ambientes onde os projetos de melhoria multi-modelos são
realizados concorrentemente em diferentes níveis hierárquicos e funções organizacionais, há uma
possível concorrência de tecnologias e iniciativas, ocasionando divisão de recursos, esforços e da
infra-estrutura para implementação, podendo reduzir os benefícios esperados.
Atuando no mercado brasileiro desde 1987, a Informal Informática apóia seus clientes na aplicação
de soluções de tecnologia da informação com qualidade, flexibilidade e compromisso com os resultados. Segundo definido em sua visão, a Informal busca ser uma empresa de referência técnica na
área de tecnologia da informação, para o que privilegiou, nos últimos anos, ações para consolidação
dos seus serviços segundo práticas e modelos de excelência reconhecidos no mercado.
Este artigo relata a experiência da empresa no projeto de implementação do MR-MPS [SOFTEX,
2009] em conjunto com a ISO 9001 [NBR ISO 9001:2000], realizado em 2 (dois) ciclos consecutivos
de melhoria, entre abril de 2006 e maio de 2009, com apresentação do mapeamento definido entre
os modelos, dificuldades encontradas e fatores de sucesso do projeto.
De forma mais detalhada, a seção 2 apresenta a organização do projeto de melhoria em seus 2 (dois)
ciclos. A seção 3 apresenta o mapeamento definido entre os modelos, enquanto a seção 4 descreve
as dificuldades encontradas e ações de resolução para cada ciclo de melhoria. A seção 5 apresenta
os fatores de sucesso observados ao longo do projeto de melhoria. Na seção 6 é apresentada uma
abordagem para os projetos de melhoria multi-modelos e, por fim, na seção 7 são descritas as considerações finais.
2. Organização do Projeto
Em seu ciclo de planejamento estratégico para o biênio 2006/2007, em dezembro de 2005, a Informal
identificou a necessidade de evoluir, estabilizar e disseminar seus processos internos para garantir a
qualidade na prestação de serviços. Isto porque a empresa cresceu e diversificou sua atuação, não
sendo mais possível contar somente com a competência técnica dos colaboradores para obter níveis
crescentes de satisfação dos clientes. Trabalhar dentro de uma mesma linha base, em termos de procedimentos e instrumentos de trabalho, passou a ser obrigatório para melhorar a produtividade das
equipes técnicas.
WAMPS 2009 35
Artigos aceitos
Na busca deste objetivo, e aproveitando as facilidades oferecidas pela Assespro (Associação das
Empresas de Tecnologia de Informação), pela Riosoft (Organização da Sociedade Civil de Interesse
Público que integra o Programa Softex) e pela SOFTEX, a empresa iniciou o primeiro ciclo de melhoria
em 2006, com participação nos projetos Rumo à ISO 9000 e Qualisoft 2006, tendo como referência
técnica, respectivamente, a norma ISO 9001 e o MR-MPS.
O projeto Rumo à ISO 9000 teve início em abril de 2006, com objetivo de implantação do Sistema de
Gestão da Qualidade contemplando todas as áreas da empresa, no qual a Informal integrou um grupo de 10 (dez) empresas, coordenado pela Riosoft, com consultoria da BCTEC – Brasil Conhecimento
e Tecnologia, tendo como principais etapas: treinamento básico, visitas, reuniões de detalhamento,
consultoria individual, treinamento institucional e auditoria interna.
Em junho de 2006 foi iniciada a implantação do nível G do MR-MPS com escopo voltado para os
processos de Gerência de Projetos e Gerência de Requisitos, onde a empresa integrou o grupo de
empresas também coordenado pela Riosoft, com consultoria da COPPE/UFRJ e subsídios do BID e do
SEBRAE/RJ. Neste projeto as principais etapas foram: análise inicial, treinamento, definição do processo padrão, instalação do framework TABA [ROCHA et al., 2005], projeto piloto e avaliação.
Depois de 12 meses, em maio de 2007 o projeto Qualisoft 2006 foi concluído com sucesso, tanto pela aprovação na avaliação quanto pela incorporação dos novos processos, ferramentas, instrumentos
e práticas, já com sinais diretos na prestação dos serviços. Encerrando o primeiro ciclo de melhoria,
o projeto Rumo à ISO 9000 foi concluído com sucesso pela empresa, com a aprovação na auditoria
externa realizada em agosto de 2007.
Com segurança de estar no caminho certo, em outubro de 2007 foi iniciado o segundo ciclo de
melhoria para evolução do nível de maturidade, desta vez tendo como meta o alcance do nível E
do MR-MPS. Nesta fase, o escopo contemplou a implantação de todos os processos exigidos pelo
modelo, exclusive o de aquisição. Da mesma forma que na implantação do nível G, a Informal também fez parte do grupo de empresas organizado pela Riosoft e tendo a consultoria da COPPE/UFRJ.
Depois de 20 meses, o segundo ciclo foi encerrado, com a aprovação na avaliação realizada em maio
de 2009.
3. Mapeamento entre o MR MPS e a ISO 9001
Um dos fatores de sucesso do projeto de melhoria da empresa foi a implantação do Sistema de
Gestão da Qualidade – SGQ Informal – organizado segundo os itens da norma ISO 9001 [NBR ISO
9001:2000], o que facilitou a identificação da correspondência no SGQ Informal entre os requisitos
e processos exigidos nos 2 (dois) modelos.
Na implantação do nível G do MR-MPS foram definidos os Processos de Gerência de Projetos e
Gerência de Requisitos. Neste caso, observou-se uma relação direta com o item 7.3 – Projeto e
Desenvolvimento da ISO 9001, que teve os dois processos incorporados para apoio à execução das
atividades.
Outro aspecto definido na época foi considerar os artefatos produzidos no processo de desenvolvimento como específicos do projeto, ficando apenas o relatório de situação de processos, gerado no
36 WAMPS 2009
Gestão Integrada da Melhoria de Processos em Organizações de Software
âmbito organizacional, previsto no Controle de Documentos do SGQ Informal – item 4.2.3 da ISO
9001 [NBR ISO 9001:2000]. Para identificação da relação dos artefatos foi criada uma lista, denominada LIS 7.3. Diretrizes de apoio à execução dos processos também foram definidas, sendo unificadas em outra lista do SGQ Informal.
Na implantação do nível E do MR-MPS foi revista a definição dos Processos de Gerência de Projetos
e Gerência de Requisitos e foram definidos os processos de Gerência de Configuração, Garantia
da Qualidade, Medição, Avaliação e Melhoria do Processo Organizacional, Definição do Processo
Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização.
Sendo o processo de desenvolvimento de software o principal produto da empresa, para planejamento da sua realização segundo o item 7.1 da ISO 9001, foram incorporados como processos de
apoio os Processos de Avaliação e Melhoria do Processo Organizacional e Definição do Processo
Organizacional.
No caso do Processo de Medição, foi estabelecida relação direta com o item 8.4 – Análise de Dados,
que em sua definição assegura a identificação, coleta e a análise dos dados apropriados para demonstrar a adequação e a eficácia do Sistema de Gestão da Qualidade e para avaliar a implementação das melhorias contínuas.
Para complementar as atividades de projeto e desenvolvimento, e segundo análise feita, os processos de Gerência de Configuração, Garantia da Qualidade e Gerência de Reutilização também foram
relacionados ao item 7.3 da ISO 9001. Já a correspondência do Processo de Recursos Humanos foi
realizada de forma direta com o item 6.2 da ISO 9001.
Tanto para a implantação dos processos do nível G quanto do nível E, foi adotada uma estrutura padrão de documento, diferente da estrutura dos procedimentos definidos para a ISO 9001. Com isso,
houve certa independência dos processos para melhor atendimento às exigências de cada modelo,
sem prejuízo à integração.
Cabe registrar que não foram observadas lacunas no mapeamento entre os modelos durante o projeto de melhoria. Por outro lado, foram percebidas exigências diferentes em alguns itens comuns,
como Recursos Humanos, que no MR-MPS prevê atividades de Gerência de Conhecimento, não contempladas nos requisitos da ISO 9001.
4. Dificuldades Encontradas e Ações de Resolução
Durante a execução do projeto de melhoria, foram encontradas algumas dificuldades, para as quais
houve definição de ações e encaminhamento para solução. As dificuldades foram percebidas pelas
equipes dos projetos, pela consultoria ou apontadas pela diretoria da empresa nas reuniões de análise crítica.
No primeiro ciclo de melhoria, abrangendo a implantação do Sistema de Gestão da Qualidade baseado na ISO 9001 e do nível G do MR-MPS, as seguintes dificuldades foram identificadas, com
respectiva ação de resolução (Tabela 1).
WAMPS 2009 37
Artigos aceitos
Tabela 1: Dificuldades Encontradas e Ações de Resolução. 1º ciclo de melhoria
Dificuldades
Ações
1 Pouca disponibilidade dos integrantes do Alinhamento constante dos envolvidos para facilitar os
Comitê de Qualidade para realização das encontros. Elaboração do resumo das reuniões, facilitando o
reuniões.
acompanhamento no caso de ausência.
2 Alocação paralela dos responsáveis dos
processos em atividades de cliente.
Negociação com gestores de contrato nos períodos críticos.
Divisão de tarefas para melhor aproveitamento dos recursos.
3 Baixo conhecimento dos conceitos de
Engenharia de Software.
Inscrição nos cursos oferecidos pela Riosoft. Incentivo ao
estudo.
4 Baixo conhecimento dos modelos de
referência.
Organização de palestras específicas e participação dos
colaboradores nas reuniões e atividades com a consultoria
externa.
Já no segundo ciclo do projeto de melhoria, que objetivou a implantação dos processos do nível E de
maturidade, novas dificuldades e ações de resolução foram percebidas, algumas comuns ao primeiro
ciclo (Tabela 2).
Duas dificuldades percebidas no final do projeto serão tratadas no próximo ciclo de melhoria: ausência de resultados efetivos para alguns processos e baixa percepção da integração dos processos.
Adicionalmente, existem outros pontos de evolução para tratamento no ciclo 2009/2010, os quais devem ser atendidos pelos objetivos de melhoria que serão definidos e aprovados no Plano de Melhoria.
Tabela 2: Dificuldades Encontradas e Ações de Resolução. 2º ciclo de melhoria
Dificuldades
Ações
1 Alocação paralela dos responsáveis dos Negociação com gestores de contrato nos períodos críticos.
processos em atividades de cliente.
Divisão de tarefas para melhor aproveitamento dos recursos.
2 Pouco conhecimento dos processos
pelas equipes.
Organização de treinamento específico para cada processo.
Realização de reuniões regulares do grupo de processos. Criação
de lista de distribuição para facilitar canal de comunicação.
3 Conhecimento restrito dos conceitos
de Engenharia de Software.
Inscrição nos novos cursos oferecidos pela Riosoft. Incentivo ao
estudo, inclusive cursos de pós-graduação.
4 Conhecimento restrito dos modelos de
referência.
Participação dos colaboradores nas reuniões e atividades com a
consultoria externa. Disseminação da prática de leitura no caso
de dúvida.
5 Comprometimento parcial dos
responsáveis dos processos.
Sensibilização. Em alguns casos, substituição por outro
colaborador.
6 Contexto de negócio menos favorável
Foco nos clientes fixos em detrimento a expansão, até a
estabilização.
7 Experiência restrita e limitação na
utilização do framework Taba.
Substituição de algumas atividades para outras ferramentas
(SVN, por exemplo). Treinamento “on the job” pelo PMO.
8 Pouco conhecimento das ferramentas
implantadas
Elaboração de guias de utilização. Treinamento “on the job”
pelo PMO ou responsável por processo.
9 Baixo comprometimento para coleta
das métricas
Melhoria da comunicação. Alinhamento direto. Escalonamento
para diretoria.
38 WAMPS 2009
Gestão Integrada da Melhoria de Processos em Organizações de Software
5. Fatores de Sucesso
Ao final dos dois ciclos de melhoria, os principais fatores de sucesso do projeto, classificados em
aspectos técnicos e organizacionais, foram:
Aspectos Técnicos:
• Liderança efetiva do projeto de melhoria, contribuindo para a definição dos novos processos e
cumprimento de prazos;
• Processo de desenvolvimento padrão desde o nível G, facilitando a implantação das práticas com
toda a equipe;
• Comprometimento das equipes dos projetos, permitindo execução das atividades definidas;
• Padrão e qualidade dos roteiros dos artefatos, facilitando o entendimento e uniformização;
• Compartilhamento regular da situação do projeto com colaboradores, possibilitando correção de
rotas de maneira mais fácil;
• Framework padrão (TABA), que facilitou a implantação do processo padrão e integração das
ferramentas;
• Adoção de ferramentas para registro de solicitação, unificando o canal de comunicação para pedidos de ajustes, registro de não conformidades e solicitações de melhoria, dentre outros;
• Melhor utilização da ferramenta para apoio a gerência de configuração, potencializando o controle de versão e realização de auditorias de configuração.
Aspectos Organizacionais:
• Visão integrada da gestão pela diretoria, evitando re-trabalho e possibilitando o alcance de mais
efetividade na definição dos processos;
• Comprometimento da alta direção, tornando os projetos corporativos;
• Treinamentos organizacionais, aumentando as competências e habilidades dos colaboradores;
• Implantação dos processos em nível organizacional, abrangendo a atuação em todos os clientes;
• Estratégia do projeto de melhoria, que privilegiou em seu primeiro ciclo projetos de clientes onde a
equipe possuísse maior domínio, facilitando a propagação nos demais clientes no segundo ciclo;
• Criação do grupo de processos, gerando sinergia e facilitando a troca de informações;
• Treinamento preparatório para as avaliações e auditorias, dando mais segurança as equipes envolvidas na avaliação;
• Consultoria da COPPE/UFRJ, permitindo constante troca de conhecimento, aprendizado, entendimento do modelo e capacitação nas ferramentas;
• Participação de colaboradores comprometidos na avaliação, facilitando os esclarecimentos necessários para os demais avaliadores.
WAMPS 2009 39
Artigos aceitos
6. Uma Abordagem para Melhoria de Processos Multi-Modelos
Embora a melhoria de processos seja demorada e consuma recursos significativos, as evidências mostram que o retorno do investimento é alto. Melhorias podem ser implementadas tendo como base
demandas eventuais (ad hoc), mas processos sistemáticos de melhoria orientados por modelos ou
padrões são mais efetivos e eficientes [MUTAFELIJA E STROMBERG, 2003].
A partir da experiência relatada nas seções 3, 4 e 5, estamos definindo uma abordagem cujo objetivo
é apoiar o tratamento das dificuldades de implementação de projetos de melhoria multi-modelos nas
organizações de software. Neste trabalho, estão sendo considerados os modelos MR-MPS [SOFTEX,
2009], CMMI [CHRISSIS et al., 2006] e a norma ISO 9001 [NBR ISO 9001:2000], de forma que, quando combinados em projetos de melhoria possíveis dificuldades possam ser identificadas, analisadas e
tratadas previamente, maximizando os benefícios esperados.
Para que a abordagem seja o mais próxima possível das necessidades das organizações de software,
será realizado um estudo experimental do tipo survey, com a finalidade de identificar as principais dificuldades encontradas pelas empresas na implementação dos projetos de melhoria multi-modelos, com
adoção de ao menos dois entre os modelos CMMI, ISO 9001 e MR-MPS. O survey será conduzido em
retrospecto e os dados serão coletados por meio de entrevistas e/ou questionários [PFLEEGER, 2004].
Para complementar o conhecimento necessário e definição da abordagem, bem como para facilitar um melhor entendimento dos modelos e normas contemplados no trabalho, será realizado um
mapeamento entre os resultados esperados do MPS, objetivos e práticas genéricas e específicas do
CMMI e requisitos da norma ISO 9001, com identificação das diferenças e pontos de convergência.
A partir deste mapeamento, os resultados serão analisados para se chegar a uma proposta de harmonização entre os modelos.
Durante o trabalho de mapeamento, um cuidado adicional com as diferenças muito sutis entre os modelos será considerado, pois segundo ROUT E TUFFLEY (2007), o mapeamento deve ser completo, claro
e não ambíguo, visto que enquanto em geral há condições para identificação da semelhança entre os
itens dos modelos, por outro lado percebe-se que há áreas específicas onde a cobertura é fraca.
7. Conclusão
O artigo apresentou a experiência do projeto de implementação do MR-MPS [SOFTEX, 2009] em
conjunto com a ISO 9001 [NBR ISO 9001:2000] da Informal Informática, realizado em 2 (dois) ciclos
consecutivos de melhoria, entre abril de 2006 e maio de 2009, com alcance dos níveis G e E do MRMPS e da certificação ISO 9001. Além da organização do projeto de melhoria, foram apresentados o
mapeamento definido entre os modelos, as dificuldades encontradas e ações de resolução para cada
ciclo de melhoria, os fatores de sucesso observados ao longo do projeto de melhoria e a proposta de
uma abordagem para os projetos de melhoria multi-modelos.
Apesar de não estar prevista a elevação do nível de maturidade da empresa nos próximos 2 (dois)
anos, o ciclo de melhoria 2009/2010 já começou, tendo como base as ações estratégicas: consolidar o processo de software de nível E de maturidade; promover o melhor uso das ferramentas de
40 WAMPS 2009
Gestão Integrada da Melhoria de Processos em Organizações de Software
gerência de projeto; promover prestação de serviços segundo modelo de fábrica de software; e evoluir solução técnica do processo de software.
Agradecimentos
Os autores agradecem a Eduardo Costa Carvalho, sócio-diretor, ao Grupo de Processos e as equipes
que participaram dos ciclos de melhoria da Informal Informática. Agradecemos ainda a Mariano
Montoni e Anne Elise Katsurayama da COPPE/UFRJ pelas importantes sugestões para este artigo.
Referências
ARAÚJO, R., CAPPELLI, C.; GOMES, A.; PEREIRA, M.; IENDRIKE, H.S.; IELPO, D.; TOVAR, J.A, 2008; “A
Definição de Processos de Software sob o ponto de vista da Gestão de Processos de Negócio”. VI
Simpósio Internacional de Melhoria de Processos de Software, São Paulo.
CHRISSIS, M. B., KONRAD, M., SHRUM, S., 2006, CMMI (Second Edition): Guidelines for Process
Integration and Product Improvement, Addison Wesley Professional
FERREIRA, A.I.F., SANTOS, G., CERQUEIRA, R., SANTOS, G.; MONTONI, M.; BARRETO, A.S.; ROCHA,
A.R, 2006, “ISO 9001:2000, MPS.BR Nível F e CMMI Nível 3: Uma Estratégia de Melhoria de
Processos na BL Informática”. Simpósio Brasileiro de Qualidade de Software 2006. SBQS 2006.
NBR ISO 9001:2000 – ABNT / Sistemas de Gestão da Qualidade – Requisitos.
MENDES, F. F.; OLIVEIRA, J. L., 2009. “Melhoria de Processos de Tecnologia da Informação MultiModelos”. UFG. Simpósio Brasileiro de Qualidade de Software 2009. SQBS 2009.
MUTAFELIJA, B; STROMBERG, H., 2003. “Systematic Process Improvement Using ISO 9001:2000 and
CMMI”, ARTECH HOUSE
SOFTEX, 2009. “MPS.BR: Melhoria de Processo do Software Brasileiro”, Guia Geral 2009, Disponível
em: http://www.softex.br/mpsbr.
PFLEEGER, S. L., (2004) Engenharia de Software: Teoria e Prática, 2ª Edição, Prentice Hall, São Paulo,
Brasil.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de Software: Teoria e Prática. São
Paulo: Prentice Hall, 2001
ROCHA, A. R.; MONTONI, M.; SANTOS, G.; MAFRA, S.; FIGUEIREDO, S.; BESSA, A.; MIAN, P., 2005
“Estação TABA: Uma Infra-estrutura para Implantação do Modelo de Referência para Melhoria de
Processo de Software”, IV SBQS, Porto Alegre, Brasil.
ROUT, T.P; TUFFLEY, A., 2007. “Harmonizing ISO/IEC 15504 AND CMMI”. SPI; 2007;12: 361-371,
InterScience
SIVIY, J.; KIRWAN, R.; MORLEY, J.; MARINO. J. “Maximizing your process improvement roi through
harmonization”. Software Engineering Institute, Carnegie Mellon, 2008.
WAMPS 2009 41
Artigos aceitos
Implementação do MPS.BR Nível F e CMMI-DEV
Nível 2 na Red & White IT Solutions
Denia Kuhn Resende1, João Batista Grego1, Neide Pimentel1, Cleomar Aparecido Gonçalves1, Edson Neves
Vieira Junior1, Ariel Crezo Ferreira1, Fabricio Kruel1, Paulo Roberto Batista Júnior1, Olavo Cardoso Terra Neto1,
Walison Cavalcanti1, Henrique Godinho1, Mariano Montoni2, Elaine Nunes2, Andrea Barreto2, Ana Regina
Cavalcanti da Rocha2
Red & White IT Solutions
Rua 8, número 73, Setor Central - Goiânia - GO - CEP: 74.013-030 {denia.kuhn, joao.grego, neide.pimentel, cleomar.goncalves, edson.junior, crezo.ferreira, fabricio.kruel,
paulo.batista, olavo.terra, walison.moreira, henrique.godinho}@rwit.com.br
1
COPPE/UFRJ - Universidade Federal do Rio de Janeiro
Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brasil {mmontoni, elaine, ansoares, darocha}@cos.ufrj.br
2
Abstract: This work reports the experience related to the implementation of the MPS.BR level F and the CMMIDEV level 2 at the Red & White IT Solutions, a start-up software development organization. This work also
presents the strategy adopted to define, implement and follow-up the defined processes. Quantitative results
are also presented not only as a mean to provide evidence of the initiative success, but also to reinforce the
organization recognition of the benefits achieved with the software process improvement initiative.
Resumo: Este trabalho apresenta um relato da experiência de implementação do MPS.BR nível F e do CMMIDEV nível 2 na Red & White IT Solutions, uma empresa nascente de desenvolvimento de software. Neste trabalho, é apresentada a estratégia de implementação utilizada para definição, implementação e acompanhamento
dos processos. Resultados quantitativos também são apresentados como forma de evidenciar o sucesso da iniciativa de melhoria e reforçar o reconhecimento da organização sobre o benefícios alcançados com a iniciativa
de melhoria de processo de software.
1. Introdução
Normas e modelos de referência de processo de software têm sido desenvolvidos e aprimorados
nos últimos 20 anos com o propósito de estabelecer melhores práticas para orientar a definição de
processos de software, bem como para servir de apoio à avaliação da capacidade e maturidade das
organizações na produção de software. No entanto, a implementação de melhoria de processo de
software baseada em modelos e padrões de referência de processo é uma iniciativa complexa e de
longa duração que envolve uma quantidade considerável de recursos financeiros [1].
O retorno do investimento em melhoria de processo de software é difícil de ser mensurado. Mesmo
organizações grandes e estabelecidas no mercado tendem a apresentar fortes resistências em implementar programas de melhoria de processo por falta de evidências tangíveis que comprovem a relação entre a qualidade de processo e a qualidade de produto. É comum que as iniciativas de melhoria
comecem de forma pontual nas organizações para que seja possível obter visibilidade dos resultados
obtidos com as melhorias antes que estas sejam largamente adotadas nas organizações. Esse fato é
42 WAMPS 2009
Implementação do MPS.BR Nível F e CMMI-DEV Nível 2 na Red & White IT Solutions
evidente nos resultados de estudos que mostram que uma questão crítica na implementação de melhoria de processo é convencer as empresas, principalmente as pequenas e médias, dos benefícios de
negócio que podem ser alcançados com melhoria de processo de software [2][3]. Nesse contexto, a
Red & White IT Solutions (R&W), uma organização focada em soluções de Tecnologia da Informação,
é uma exceção à regra.
Criada em meados de 2008 para ser a referência de desenvolvimento de software do Grupo José
Alves na cidade de Goiânia, os fundadores e diretores da R&W consideraram como essenciais, desde
a concepção da organização, a garantia da qualidade do processo de software, bem como a excelência dos produtos de software desenvolvidos. Essa preocupação se traduziu em objetivos claros e
metas bem definidas de melhoria de processo de software pela alta gerência, como a definição e
implementação em todos os projetos da organização de um processo de software padrão compatível
com os requisitos dos processos do nível F do modelo MPS.BR e do nível 2 do CMMI-DEV. A escolha
desses modelos e níveis como meta para melhoria dos processos da R&W se deveu a compatibilidade
dos modelos e a viabilidade de realizar com sucesso avaliações oficiais nesses dois modelos em um
prazo de 12 meses a contar do início da operação da empresa. Apesar de essas metas terem sido
traçadas de forma ambiciosa, o comprometimento da alta direção, bem como do grupo de processos formado para dirigir a iniciativa foram fundamentais para que as metas fossem alcançadas
com sucesso. A avaliação do nível F do MPS.BR foi realizada com sucesso em Dezembro de 2008 e a
avaliação do nível 2 do CMMI-DEV foi também realizada com sucesso em Maio de 2009. Para apoiar
a definição e implementação dos processos, a R&W contou com o apoio da equipe de consultores
em melhoria de processo de software da COPPE/UFRJ. A escolha da R&W na consultoria da COPPE/
UFRJ se deveu ao fato dessa instituição ter experiência em implementação e avaliação em níveis altos
de maturidade no modelo CMMI-DEV e MPS.BR, que é o objetivo de longo prazo para melhoria dos
processos da R&W.
Este trabalho apresenta um relato da experiência da implementação do MPS.BR nível F e do CMMIDEV nível 2 na R&W. A próxima seção apresenta a estratégia utilizada para definição, implementação
e acompanhamento dos processos dos modelos na empresa. A seção 3 apresenta os resultados
quantitativos da melhoria de processos da organização. A seção 4 apresenta as conclusões do trabalho e os próximos passos da organização para alcançar os mais altos níveis de maturidade em
desenvolvimento de software.
2. Estratégia de Implementação de Melhoria de Processos de
Software na R&W
Segundo Zaharan [4], a falta de estratégias adequadas para apoiar a implementação de melhoria
de processo de software é uma das razões mais comuns do fracasso de iniciativas de melhoria de
processo. Portanto, a R&W se preocupou desde o início com a definição de uma estratégia adequada
de implementação de melhoria de processo de software capaz de apoiar o alcance das metas estabelecidas. A definição da estratégia de implementação de melhoria de processos de software na R&W
envolveu o tratamento de diversas questões, tais como:
• A definição do escopo da implementação de melhoria de processos de software.
WAMPS 2009 43
Artigos aceitos
• A definição da estrutura analítica do trabalho (EAP) de implementação de melhoria de processos
de software.
• A identificação das partes interessadas críticas a serem envolvidas na iniciativa de melhoria.
• A definição das necessidades de melhoria de processos de software da organização.
• A identificação dos métodos e ferramentas para serem utilizados na definição, implementação e
acompanhamento das melhorias nos processos de software.
• O dimensionamento do esforço e prazo da implementação de melhoria de processos de software.
• A escolha dos membros da equipe de consultoria de apoio à implementação da melhoria nos
processos de software.
• A freqüência de consultoria necessária para acompanhar a implementação da melhoria nos processos de software.
• A definição dos indicadores de sucesso da implementação da melhoria nos processos de software.
• O planejamento dos treinamentos necessários para a capacitação dos membros da organização
na melhoria nos processos de software.
• A identificação dos mecanismos de tratamento das barreiras críticas para a implementação das
melhorias nos processos de software.
2.1. Escopo da implementação
Levando em consideração que a empresa R&W foi criada para atender à carência de empresas de
serviços de software tanto das empresas do Grupo José Alves quanto do mercado da região e num
futuro próximo o mercado nacional, era essencial garantir a institucionalização de processos capazes
de atender a diversidade dos clientes e domínios de negócio da corporação (o Grupo José Alves é
composto de empresas atuantes no segmento de bebidas por meio da Refrescos Bandeirantes, bem
como fazem parte do grupo outras empresas como as Faculdades Alves Faria (ALFA), a Rembal, fabricante de garrafas PET descartáveis, a Rebica, empresa de água mineral, a 3T Systems, organização especializada em sistemas de mobilidade voltados para a área de logística, Atlanta Locação de Veículo
e a NL – Negócios Imobiliários). Portanto, foi definido desde o início da implementação que todos os
projetos de software, independente do domínio de aplicação, tivessem que adotar processos padrões
aderentes aos requisitos dos processos do nível F do modelo MPS.BR e nível 2 do CMMI-DEV.
2.2. Estrutura Analítica do Trabalho
A definição da estrutura analítica do trabalho (EAP) de implementação de melhoria de processos de
software envolve definir os marcos da iniciativa de melhoria, bem como as atividades e os principais
produtos de trabalho para serem produzidos pela equipe de consultoria. A definição da EAP, também
chamada de WBS (Work Breakdown Structure) pode ser apoiada por um modelo de implementação
de melhoria de processo de software como o IDEAL [5]. No caso da iniciativa de melhoria na R&W foi
adotado o modelo SPI-KM desenvolvido pela própria consultoria da COPPE/UFRJ [6]. A partir desse
modelo foi definida a seguinte estrutura de trabalho: (i) diagnóstico, (ii) planejamento da melhoria
44 WAMPS 2009
Implementação do MPS.BR Nível F e CMMI-DEV Nível 2 na Red & White IT Solutions
dos processos, (iii) definição do processo, (iv) treinamento, (v) estabelecimento da infra-estrutura
de apoio, (vi) acompanhamento na implementação das melhorias em projetos, (vii) mentoring, (viii)
aquisição de conhecimento sobre os processos, (ix) aquisição de oportunidades de melhoria nos processos, (x) avaliação das oportunidades de melhoria nos processos, (xi) preparação para a avaliação
oficial MPS.BR e CMMI-DEV e (xii) avaliação oficial dos processos.
2.3. Partes interessadas críticas
Pode-se considerar que uma iniciativa de melhoria teve sucesso, se uma situação de ganho-ganho
(win-win) for alcançada, isto é, se todas as partes interessadas críticas na iniciativa tiverem as suas
necessidades atendidas adequadamente. Para atingir essa situação, é fundamental identificar todas
as partes interessadas críticas cujas necessidades de melhoria de processos de software devem ser
compreendidas e consideradas durante a definição dos processos e melhorias a serem implementadas. No contexto da implementação de melhoria de processos na R&W, foram consideradas como
partes críticas a alta gerência, os gerentes de projetos e um grupo selecionado de analistas de sistemas e desenvolvedores.
2.4. Necessidades de melhoria de processos de software
Cada uma das partes interessadas críticas identificadas foram questionadas quanto às necessidades
a serem atendidas pela iniciativa de implementação de melhoria de processos. Para a alta gerência
era necessário padronizar o desenvolvimento de software. Para os gerentes de projeto era necessário
que os processos atendessem os dois maiores domínios de produtos de software da corporação,
sistemas de informação e Business Intelligence (BI). Para os analistas de sistemas e desenvolvedores
era necessário que os processos fossem apoiados por ferramentas que minimizassem a sobrecarga
de trabalho gerada pela implementação das melhorias de processo de forma a aumentar a produtividade da equipe.
2.5. Métodos e ferramentas
O método selecionado para definição e implementação de processo capaz de atender as necessidades
das partes interessadas críticas supracitadas foi o seguinte: (i) inicialmente a COPPE/UFRJ, consultoria
contratada pela R&W, definiu um processo padrão com base no conhecimento sobre boas práticas
de desenvolvimento de software que tiveram resultados satisfatórios em outras iniciativas passadas
coordenadas pela consultoria, (ii) em seguida, com base nessas práticas, foi definido um processo
padrão específico para o domínio de desenvolvimento de sistemas de informação e outro processo
padrão similar para o domínio de BI, bem como um conjunto de critérios de adaptação para atender
as especificidades de cada um desses domínios, (iii) por último, foi selecionada a suíte de ferramentas
de desenvolvimento da Estação Taba para apoiar as atividades de definição do processo do projeto
e planejamento do projeto [7], bem como outras ferramentas avançadas para apoiar atividades de
modelagem e análise de produtos de software como o Enterprise Architect e assim garantir mais
agilidade na etapa de desenvolvimento dos requisitos dos produtos de software. A seleção dessas
ferramentas foi realizada com base em critérios como custo de aquisição e capacitação, bem como
facilidade de implantação e utilização do apoio ferramental aos processos.
WAMPS 2009 45
Artigos aceitos
2.6. Estimativas de esforço e prazo
Uma das atividades mais complexas no planejamento de uma iniciativa de melhoria envolve dimensionar o esforço e prazo para definição, implementação e acompanhamento das melhorias nos processos da organização. A grande experiência da consultoria da COPPE/UFRJ ajudou a R&W a obter
uma estimativa bastante precisa do esforço de consultoria necessário para alcançar os objetivos da
organização. Foi definida, inicialmente, uma equipe de 2 consultores durante 2 meses para apoiar
a etapa de definição dos processos. Durante a etapa de implementação e acompanhamento dos
processos, foi definida uma equipe de 1 consultor trabalhando em média 3 dias por mês durante
um período de 10 meses. O esforço total dimensionado no início do projeto foi em torno de 350
homens-hora. O prazo de 10 meses para implementar os processos do nível F do MPS.BR e de 12
meses para implementar os processos do nível 2 do CMMI-DEV foi definido inicialmente pela alta
gerência por considerar estratégico para a empresa a rápida avaliação dos processos em modelos de
referência reconhecidos tanto em âmbito nacional, quanto internacional. A equipe de consultoria da
COPPE/UFRJ considerou esse prazo viável contanto que os primeiros projetos da empresa já adotassem os processos-padrão definidos.
2.7. Equipe de consultoria
A atividade de consultoria em melhoria de processo de software é uma atividade intensa em conhecimento. Um bom consultor é aquele capaz de transmitir conhecimento certo à pessoa certa no
momento em que ela mais precisa. Dessa forma, o conhecimento é realmente percebido como útil
pelos demais envolvidos e aplicado de forma eficaz e eficiente. Nesse contexto, é fundamental selecionar consultores com perfil adequado para participar de iniciativas de melhoria. No caso da R&W,
os seguintes requisitos foram considerados na seleção dos consultores: (i) alto nível de experiência
passada de sucesso em iniciativas de implementação do MPS.BR nível F e CMMI nível 2, (ii) alta disponibilidade para viagens (os consultores teriam que viajar mensalmente para prestar a consultoria na
empresa), (iii) alto grau de disciplina (os consultores trabalhariam sozinhos sem supervisão contínua),
e (iv) alto grau de comunicação e escrita (os consultores teriam que se comunicar na maior parte do
tempo por emails e apresentações à alta gerência). A formação de uma equipe de consultoria que
atendesse todos esses requisitos foi essencial para garantir a qualidade dos serviços prestados.
2.8. Freqüência de consultoria
Basicamente, a implementação de melhoria de processo envolve mudança organizacional. Novos
papéis e estruturas organizacionais são criados, bem como rotinas operacionais já estabelecidas são
alteradas para se adequar aos requisitos de modelos de referência de processos. É comum que as
mudanças decorrentes da condução de iniciativas de melhoria tendam a retroceder ao estado que
a organização se encontrava antes da iniciativa ser iniciada (no caso da R&W, por se tratar de uma
nova empresa, esse retrocesso pode ser representado como o abandono do uso dos processos). Um
dos mecanismos para tratar esse problema é definir uma freqüência adequada de consultoria. Foi
estabelecido no caso da R&W, que a freqüência de consultoria seria presencial, devendo ocorrer uma
vez ao mês durante, no mínimo, 3 dias consecutivos. Cada visita da consultoria era iniciada com a
verificação da situação das ações de implementação definidas na visita anterior. Ao final da visita,
novas ações de implementação eram definidas e comunicadas aos membros da empresa para serem
46 WAMPS 2009
Implementação do MPS.BR Nível F e CMMI-DEV Nível 2 na Red & White IT Solutions
tratadas ao longo do mês. Também se combinou entre a equipe de consultoria e o grupo de processos, reuniões de áudio-conferência ao longo do mês em dias pré-definidos para funcionar como
pontos de controle e possibilitar a execução de ações corretivas necessárias para corrigir desvios na
implementação das melhorias.
2.9. Indicadores de sucesso
Iniciativas de implementação de melhoria de processo são atividades complexas que envolvem alto
custo e é difícil perceber resultados tangíveis em curto prazo. Portanto, é fundamental controlar, de
preferência quantitativamente e de forma contínua, a capacidade da iniciativa de melhoria atingir
os objetivos definidos. No caso da R&W, foram utilizados como indicadores de sucesso da implementação, métricas relacionadas ao processo Garantia da Qualidade, bem como outras métricas de
controle de prazo e custo da iniciativa de melhoria. As métricas do processo Garantia da Qualidade
mediam a quantidade de problemas encontrados nas auditorias de qualidade de processo e de produto. Essas métricas eram analisadas periodicamente e caso houvesse algum desvio significativo, a
consultoria atuava diretamente junto com o grupo de qualidade para resolver os problemas o mais
cedo possível antes que esses problemas se tornassem em um risco maior, como não poder utilizar os
artefatos de um projeto como evidência para uma avaliação oficial da implementação dos processos.
Métricas relacionadas ao desempenho de prazo e custo, como índices de desempenho de custo e de
prazo (CPI e SPI), ajudaram a controlar o orçamento do projeto, bem como a dar uma visibilidade à
alta gerência de que as avaliações oficiais poderiam ser agendadas para serem realizadas nas datas
previstas sem riscos para a organização.
2.10. Capacitação
Para uma utilização adequada dos processos definidos para a R&W, foram definidos dois mecanismos de capacitação dos membros da organização na melhoria nos processos de software definidos:
treinamentos teóricos e mentorings conduzidos pelos consultores da COPPE/UFRJ. A realização de
treinamentos teóricos no início da implementação é importante para nivelar o conhecimento dos
membros da equipe e compreender a necessidade de realizar práticas novas na organização. A realização de mentorings ao longo da execução dos processos em pontos críticos foi fundamental para
garantir a utilização adequada dos processos. Os pontos considerados mais críticos para ter um mentoring dos consultores foram as atividades de planejamento e monitoração do projeto, bem como
atividades de avaliação da qualidade de produtos e processos, elaboração de relatórios de medição
e de situação de processos e atividades de auditoria de gerência de configuração. Cada treinamento
do tipo mentoring foi planejado com no mínimo 30 dias de antecedência de forma alinhada ao cronograma dos projetos.
2.11. Tratamento de barreiras críticas
As principais barreiras críticas para a implementação das melhorias de processos na R&W estavam
relacionadas à inexperiência dos membros da empresa no uso dos processos, à pressão em realizar
as avaliações oficiais no modelo de maturidade dentro das restrições de prazo impostas pela alta gerência e à distância geográfica entre a empresa e a equipe de consultoria. Para minimizar a barreira
relacionada à inexperiência dos membros da empresa nos processos, tanto a consultoria quanto o
WAMPS 2009 47
Artigos aceitos
grupo de processos atuou de forma próxima aos responsáveis pela execução dos processos para solucionar dificuldades e problemas encontrados durante a execução dos processos. Apesar da distância
geográfica, a regularidade da freqüência da consultoria permitiu que a consultoria atuasse junto a
equipe dos projetos e da organização nas atividades mais críticas da implementação dos processos,
procurando conciliar as visitas da consultoria com o planejamento das atividades dos projetos, bem
como o planejamento das atividades organizacionais. Com relação à pressão da alta gerência em alcançar os níveis pretendidos no prazo, procurou-se garantir uma correta adoção dos processos desde
os primeiros projetos, de forma que artefatos gerados nesses projetos pudessem ser utilizados como
evidências para as avaliações oficiais, o que de fato realmente ocorreu. As dificuldades de interação
entre a equipe de consultoria e os membros da R&W foram minimizadas a partir do estabelecimento de mecanismos de interação síncrona e assíncrona para discutir detalhes da implementação e
responder dúvidas dos executantes dos processos, como reuniões de áudio-conferência, troca de
mensagens instantâneas e e-mails.
3. Resultados Quantitativos da Iniciativa de Melhoria de Processos na
R&W
Os resultados quantitativos mais expressivos da implementação de melhoria de processos na R&W
estão relacionados ao nível de aderência dos projetos aos processos-padrão definidos. Para ilustrar
esses resultados, são apresentados nas Figuras 1 e 2, respectivamente, os desempenhos das métricas
de não-conformidades e de inadequações encontradas nas auditorias dos processos implementados
durante 3 períodos distintos. O objetivo da métrica de não-conformidade é avaliar a aderência da
execução dos processos definidos dos projetos ao processo padrão da organização. Quanto menor
for o valor dessa métrica, mais aderentes são os processos. O objetivo da métrica de inadequações é
avaliar os problemas de adequação do processo padrão à realidade da organização e dos seus projetos. Um problema de adequação indica que algum aspecto da definição do processo padrão não é
adequado e precisa ser revisto para ajustar o processo à realidade dos projetos e da organização.
Figura 1 - Número de não-conformidades encontradas na auditoria de qualidade dos processos
48 WAMPS 2009
Implementação do MPS.BR Nível F e CMMI-DEV Nível 2 na Red & White IT Solutions
A partir dos dados apresentados na Figura 1, pode-se perceber que foram encontradas diversas
não-conformidades durante os 3 períodos de auditoria da qualidade dos processos. Isso indica que
o grupo de qualidade procurou, em cada período de auditoria, identificar o máximo de não-conformidades possíveis nos processos. Todas essas não-conformidades foram tratadas juntamente com a
consultoria da COPPE/UFRJ de forma a minimizar os riscos para as avaliações programadas.
Figura 2 - Número de inadequações encontradas na auditoria de qualidade dos processos
Os dados da Figura 2 indicam que, inicialmente, os processos não estavam totalmente adequados à
realidade da organização e dos seus projetos. No entanto, esses problemas foram tratados ao longo
da implementação e no último período de auditoria, os processos se demonstraram 100% adequados. Esse fato é demonstrado pela ausência de inadequações nos processos avaliados pelo grupo de
qualidade no último período de auditoria da qualidade dos processos.
Os resultados apresentados nas Figuras 1 e 2 mostraram que houve um comprometimento constante
da organização com a implementação de melhoria de processos de software. Uma conseqüência
direta disso foi o sucesso da avaliação oficial do MPS.BR Nível F após 10 meses do início de operação
da R&W e, após 2 meses, uma outra avaliação oficial de sucesso do CMMI-DEV Nível 2 com base nas
mesmas evidências de projetos apresentadas na avaliação do MPS.BR.
4. Conclusão
Este trabalho apresentou um relato da experiência de implementação do MPS.BR nível F e do CMMIDEV nível 2 na Red & White IT Solutions, uma empresa nascente de desenvolvimento de software.
Também foi apresentada neste trabalho, a estratégia de implementação utilizada para definição,
implementação e acompanhamento dos processos na empresa. Os resultados quantitativos foram
apresentados como forma de evidenciar o sucesso da iniciativa de melhoria.
Os benefícios com a iniciativa de melhoria de processo de software são reconhecidos pela alta gerência da R&W por meio da percepção do aumento da satisfação dos seus clientes, bem como da equipe
de projetos. A preocupação pela busca contínua da melhoria dos processos da R&W é uma questão
estratégica da empresa que pretende ser uma referência em desenvolvimento de software tanto na
WAMPS 2009 49
Artigos aceitos
região centro-oeste, quanto em todo o território nacional. Para tanto, o planejamento estratégico da
R&W estabeleceu como meta para ser alcançada em 2010, a implementação de melhoria de processos com base tanto no nível C do modelo MPS.BR, quanto no nível 3 do modelo CMMI-DEV.
Referências
[1] Goldenson, D. R., Gibson, D. L., 2003, “Demonstrating the Impact and Benefits of CMMI: An
Update and Preliminary Results”, SEI Special Report; CMU/SEI-2003-SR-009.
[2] Wangenheim, C. G., Varkoi, T., Salviano, C. F., 2006, “Standard based software process assessments in small companies. Software Process: Improvement and Practice”; v. 11, n. 3, pp. 329-335.
DOI: 10.1002/spip.276
[3] Cater-Steel, A., Toleman, M., Rout, T., 2006 “Process improvement for small firms: An evaluation
of the RAPID assessment-based method. Information and Software Technology”. v. 48, n. 5, pp.
323-334. DOI: 10.1016/j.infsof.2005.09.012
[4] Zaharan, S., 1998, “Software Process Improvement – Practical Guidelines for Business Success”,
Addison-Wesley
[5] Mcfeeley, B., 1996, IDEAL: A User’s Guide for Software Process Improvement Pittsburgh, Software
Engineering Institute.
[6] Montoni, M., Santos, G., Vasconcellos, J., et al., 2008, “Application of the SPI-KM Approach to
Support the Implementation of the MPS Model in Small- and Medium-Sized Enterprises in Brazil”,
Software Quality Professional Journal, v. 11, n. 1, pp. 34-45.
[7] Montoni, M., Santos, G., Rocha, A.R., et al., 2007, “MPS Model and TABA Workstation:
Implementing Software Process Improvement Initiatives in Small Settings”. In: Fifth Workshop
on Software Quality held in conjunction with the 29th Int. Conference on Software Engineering
(ICSE), Minneapolis, USA, May.
50 WAMPS 2009
Implementação do MPS.BR Nível F e CMMI-DEV Nível 2 na Red & White IT Solutions
WAMPS 2009 51
Artigos aceitos
Avaliação Conjunta CMMI Nível 3 e MPS Nível C:
Lições Aprendidas e Recomendações
Ana Regina Rocha1, Andrés Rubinstein2, Ana Liddy Magalhães3, Anne Elise Katsurayama1, Arley Duque4,
Carlos Barbieri Palestino5, Crhistian Souza4, Cristina Cerdeiral1, Leandro Teixeira4, Nelson Serranegra de Paiva4,
Leonardo Barros4
COPPE/UFRJ; 2Liveware; 3QualityFocus; 4Synos Technologies; 5FUMSOFT
1
Resumo: Este artigo relata a experiência da avaliação conjunta CMMI/MPS realizada na Synos Technologies sob
quatro pontos de vista: dos avaliadores MPS, do lead appraiser CMMI, da Instituição Implementadora MPS e da
empresa avaliada. São apresentadas as lições aprendidas e um conjunto de recomendações para as próximas
avaliações em que se deseje utilizar esta nova modalidade.
1. Introdução
Recentemente a coordenação do Programa MPS.BR introduziu a modalidade de avaliações conjuntas
CMMI/MPS . Estas avaliações podem ser realizadas obedecendo-se às seguintes condições:
• O avaliador líder MPS deve ser um avaliador experiente;
• O lead appraiser CMMI deve ser membro da equipe de avaliação MPS, deve ter cursado C1 e não
pode ter nenhuma vinculação com a empresa responsável pela implementação do CMMI ou do
MPS na empresa que será avaliada;
• Toda a equipe de avaliação deve ter cursado o C1 e o curso de Introdução ao CMMI e cumprir as
exigências para ser membro da equipe de avaliação MPS e CMMI;
• A avaliação inicial deve coincidir com o readiness CMMI e ser presencial, com duração maior ou
igual à duração recomendada para o nível MPS que será avaliado;
• Todos os membros da equipe de avaliação devem estar presentes na avaliação inicial e na avaliação final;
• A avaliação deve ser aprovada pela SOFTEX considerando-se, além dos itens acima:
• o processo de avaliação que será adotado pelo lead appraiser CMMI, que deve ser descrito em
detalhes e anexado à comunicação de contratação de avaliação enviada pela IA contratada
para a avaliação MPS à SOFTEX;
• declaração do lead appraiser CMMI de que nem ele, nem a II e/ou SEI Partner a que pertence
deu consultoria nos últimos 3 anos à empresa que será avaliada.
Obedecendo a estes critérios a primeira avaliação conjunta CMMI/MPS foi realizada, com sucesso, na
empresa Synos Technologies. Nesta avaliação atuou como lead appraiser CMMI Andrés Rubinstein
da Liveware e como avaliador líder MPS, Ana Regina Rocha da Instituição Avaliadora COPPE/UFRJ.
52 WAMPS 2009
Avaliação Conjunta CMMI Nível 3 e MPS Nível C: Lições Aprendidas e Recomendações
A avaliação teve, ainda, a participação de três avaliadores adjuntos, sendo dois da COPPE e um da
QualityFocus, e dois representantes da Synos. As Instituições Implementadoras que atuaram na empresa foram a FUMSOFT e a ASR. Este artigo descreve as lições aprendidas nesta avaliação conjunta e
algumas recomendações para novas avaliações, considerando diferentes pontos de vista: dos avaliadores MPS, do lead appraiser CMMI, da Instituição Implementadora MPS e da empresa avaliada.
2. A Synos
A Synos Technologies foi fundada em Fevereiro de 2003 com uma visão de negócios baseada na
experiência de seus parceiros, empresas consagradas mundialmente no setor de TI. Com fortes relacionamentos de mercado, a Synos é reconhecida pelo seu profissionalismo pelas grandes empresas
globais, tais como Oracle, IBM, Microsoft e Red Hat, com as quais possui parcerias. Em seu primeiro
ano de operação, a Synos atingiu seu primeiro milhão em vendas. Em seu segundo ano, ela conseguiu um crescimento de 300%. Atualmente, seu faturamento é da ordem de R$12.000.000,00 por
ano e com previsão de faturamento para 2009 de R$20.000.000,00.
A Synos Technologies é uma empresa focada em soluções de integrações tecnológicas. Por meio de
suas linhas de negócio, que são fábrica de software, outsourcing/body shop, consultoria, treinamento e licenciamento de software, ela opera nos mais diversos setores do mercado nacional, sempre
fornecendo soluções com os maiores padrões de qualidade e fidelidade às demandas de seus clientes. Com mais de 90 clientes em todas as regiões do país, tendo realizado mais de uma centena de
projetos, a Synos conta atualmente com 120 colaboradores, sendo 50 alocados em sua Fábrica de
Software.
A Synos possui uma filosofia fortemente orientada a processos e qualidade de software. Seu principal
processo de desenvolvimento de software, o Synos UP, tem passado por melhorias contínuas objetivando aprimorar a sua produtividade, incorporar novas técnicas de Engenharia de Software e estar
aderente com os principais modelos de qualidade em processos do mercado, tais como o CMMI [SEI,
2006], o MR MPS [SOFTEX, 2009a] e a ISO 9001 [ABNT, 2000].
O Synos UP foi criado com o propósito de organizar e otimizar a produção de software da Fábrica
de Software da Synos. Seus processos foram estruturados com base em vários modelos, referências
e técnicas consolidados no mercado, tais como UML, PMBOK e metodologias ágeis. A partir de
março de 2006, a Synos decidiu investir na implantação do MR MPS, começando pelo nível F, com
investimento aproximado de R$ 600.000,00, tendo sido avaliada em maio de 2007. Em novembro
de 2007 iniciou um novo ciclo de melhoria, desta vez buscando o nível C do MR MPS. Este novo ciclo
foi um desafio para a empresa, por tratar-se de um grande salto de maturidade, com a incorporação
de doze novos processos, além da evolução dos processos já implantados para a nova capacidade
exigida pelo nível C. O SEPG da empresa foi reestruturado com a entrada de novos colaboradores e
capacitado nos novos processos que deveriam ser implementados. Os trabalhos seguiram o fluxo de
melhoria de processos do próprio Synos UP, que consiste nas fases Concepção (definição do escopo
e metas do trabalho), Elaboração (criação dos novos processos e aprimoramento dos já existentes),
Implantação (definição de projetos piloto, treinamento das equipes e acompanhamento da utilização
do processo) e Avaliação (avaliação oficial em algum modelo de maturidade).
WAMPS 2009 53
Artigos aceitos
Quando o projeto de melhoria estava próximo da fase de avaliação, uma grande oportunidade surgiu
para a empresa, com a possibilidade de realizar a avaliação nos modelos CMMI (nível 3) e MPS (nível
C) simultaneamente. Apesar da maior complexidade derivada da adequação a estes dois modelos
simultaneamente e do fato de os trabalhos originalmente visarem apenas o nível C do MR MPS, a
Diretoria da Synos, a Diretoria da Fábrica de Software e o SEPG decidiram aceitar este grande desafio,
sabendo que os ganhos seriam igualmente grandes para a empresa e que os dois modelos, MPS e
CMMI, são compatíveis, o que tornaria possível a avaliação simultânea.
Foi assim que a Synos iniciou a sua avaliação simultânea no CMMI e MPS em junho de 2009, atingindo a conquista inédita no mês seguinte, onde tornou-se a primeira empresa a realizar e ter sucesso
numa avaliação conjunta nestes dois modelos. Este foi o melhor prêmio para dezoito meses de esforço, aproximadamente R$ 500.000,00 de investimentos e dezenas de colaboradores empenhados
nesta conquista. Logo após a avaliação, os trabalhos de melhoria de processos continuaram com
a preparação para os níveis A do MR MPS e 5 do CMMI, além da continuidade de seu projeto ISO
9001:2008, que visa a certificação de toda a empresa neste modelo de qualidade e que está em fase
final de implantação.
3. Lições Aprendidas da Avaliação Conjunta CMMI/MPS
Esta primeira avaliação conjunta CMMI/MPS foi uma experiência muito rica e que propiciou inúmeras
lições aprendidas, que para efeito de melhor entendimento serão agrupadas de acordo com quatro
pontos de vista: dos avaliadores MPS, do lead appraiser CMMI, da Instituição Implementadora MPS e
da empresa avaliada. Para melhor se apreciar cada depoimento, estes serão transcritos a seguir.
Lições aprendidas do ponto de vista dos avaliadores MPS
“Realizar uma avaliação conjunta CMMI/MPS não é uma tarefa trivial. Exige experiência em avaliações, conhecimento profundo dos dois modelos e bastante habilidade para tratar os pontos onde
existem diferenças. Não apenas o avaliador líder MPS e o lead appraiser CMMI devem ser experientes
e conhecedores dos dois modelos. Os avaliadores adjuntos têm papel fundamental nas avaliações e
também devem conhecer profundamente os dois modelos e terem experiência em avaliações CMMI
e MPS. Outro fator decisivo para o sucesso da avaliação é o processo de avaliação do lead appraiser
CMMI (dado não existir um processo único para avaliações SCAMPI) ser compatível com o processo
de avaliação MPS”.
“As diferenças de exigência observadas entre os dois modelos foram muito interessantes, gerando
resultados diferentes para as caracterizações dos processos da organização em cada modelo. Por ser
a primeira avaliação conjunta, algumas adaptações foram necessárias em ambas as metodologias
dos avaliadores líderes MPS e CMMI, conforme as necessidades foram sendo visualizadas. Ficou clara a necessidade de flexibilidade de ambas as metodologias para viabilizar a avaliação conjunta. A
equipe de avaliação foi composta por profissionais com larga experiência e capacitação em ambos os
modelos, o que proporcionou um aprendizado ainda mais rico”.
“Durante a avaliação conjunta da Synos, pôde-se observar que a participação de uma equipe de
avaliadores experientes e com conhecimento abrangente tanto no modelo CMMI quanto no modelo
54 WAMPS 2009
Avaliação Conjunta CMMI Nível 3 e MPS Nível C: Lições Aprendidas e Recomendações
MR-MPS possibilitou a redução do tempo de discussão das diferenças entres estes modelos e, consequentemente, do tempo total da avaliação. Além disso, é importante que os avaliadores e os representantes da empresa na equipe de avaliação entendam previamente as sutis diferenças e as compatibilidades entre estes modelos, a fim de que não seja realizada uma avaliação dupla no lugar de
uma avaliação conjunta. Também é importante destacar que a sinergia entre os membros da equipe
de avaliação facilita o consenso quando surgem diferenças de entendimento durante a avaliação”.
“De uma maneira geral, a avaliação conjunta fluiu muito bem, mesmo considerando as diferenças
entre os métodos de avaliação (MA-MPS [SOFTEX, 2009b] e SCAMPI A [SEI, 2006b]) e os modelos
(MR MPS e CMMI). Possibilitou otimizar tempo e custos envolvidos, não só mobilizando os colaboradores da empresa apenas uma vez, mas também reduzindo custos com logística e propiciando ao
Coordenador Local um foco maior nos trabalhos de preparação e condução de ambas as avaliações.
Por outro lado, dificultou de certa modo o trabalho do Coordenador Local pela necessidade de atendimento simultâneo às demandas de dois líderes (Avaliador Líder MPS e Lead Appraiser CMMI), o que
em momento algum comprometeu o andamento dos trabalhos.
Uma apresentação inicial dos processos bastante detalhada e a utilização de uma planilha conjunta
CMMI e MPS facilitou a revisão de indicadores, uma vez que uma mesma evidência era usada para
satisfazer tanto um resultado esperado quanto uma prática relacionada, possibilitando atender simultaneamente aos dois modelos. Isto, porém, não reduziu o tempo total de revisão planejado, pois
a interpretação diferente entre os modelos, necessária para alguns resultados esperados ou práticas,
dificultou um pouco a elaboração do Relatório da Avaliação Inicial, levando à atribuição distinta de
alguns problemas detectados como “item requerido” ou “oportunidade de melhoria”, após discussões que se prolongaram por algum tempo. Da mesma forma, já na Avaliação Final, uma mesma
afirmação em uma entrevista pôde ser usada para satisfazer tanto um resultado esperado quanto
uma prática relacionada, possibilitando atender simultaneamente aos dois modelos. Se por um lado
a presença de dois líderes propiciou uma entrevista mais dinâmica, com perguntas mais direcionadas
à cobertura dos modelos, por outro lado foi um pouco mais difícil, durante as entrevistas, acompanhar simultaneamente a cobertura já obtida em relação aos dois modelos. O uso de um check-list
com resumo de ambos os modelos facilitou esta tarefa. A Reunião de Consenso acabou consumindo
mais tempo que o inicialmente planejado, em decorrência principalmente de discussões sobre o
atendimento às particularidades de cada modelo.
Os trabalhos da avaliação foram facilitados pela objetividade e experiência anterior da equipe com os
processos de avaliação CMMI e MPS. Os avaliadores adjuntos já haviam participado de diversas avaliações MPS e algumas CMMI, e os representantes da empresa já haviam vivenciado uma experiência
anterior de avaliação MPS. Ambos os líderes conheciam os dois processos de avaliação, estavam sempre atentos ao seu processo específico e procuravam conciliar as necessidades das duas avaliações.
A preocupação e o interesse dos líderes em definir uma forma de trabalho adequada e comum para
ambos os processos de avaliação e em gerar uma apresentação (preliminar e final) conjunta para os
modelos tornou a exposição dos achados e resultados dinâmica e interessante. Juntam-se a estes
fatores o excelente acompanhamento e preparo para a avaliação que a empresa recebeu do CCOMP/
FUMSOFT, o que com certeza facilitou os trabalhos e conduziu a empresa ao sucesso. Enfim, a avaliação conjunta possibilitou equilibrar, com qualidade, o esforço, o tempo e os recursos empreendidos
para as duas avaliações, obtendo-se um resultado muito bem sucedido, tanto para a empresa ava-
WAMPS 2009 55
Artigos aceitos
liada quanto para ambos os modelos. Sem dúvida, uma vitória, não só da empresa, mas também do
CMMI e do Programa MPS.BR!”
Lições aprendidas do ponto de vista do lead appraiser CMMI
“Na avaliação conjunta que realizamos sobre os modelos MPS e CMMI, além de ter sido uma experiência muito boa tanto pessoal quanto profissional, posso destacar entre outros os seguintes
pontos:
No que se refere à comparação entre os modelos:
• Embora o modelo CMMI esteja estruturado em Áreas de Processo, com objetivos específicos
implementados no nível de práticas, e o modelo MPS se estruture em Processos com resultados
esperados, em geral os dois modelos têm um grande paralelismo, permitindo interpretações similares, o que torna possível uma visão compartilhada;
• No modelo CMMI a institucionalização se manifesta, em seus diferentes níveis, através das Práticas
Genéricas (GP) dos Objetivos Genéricos por Área de Processo, enquanto que no MPS se vê através de Atributos de Processo, implementados através dos Resultados esperados de Atributos de
Processo (RAP). Mesmo existindo essa diferença verifica-se existir uma grande semelhança entre
as GP e os RAP.
No que se refere à comparação entre os métodos de avaliação:
• Os dois métodos partem de uma base comum no que se refere à revisão de evidências, com foco
em indicadores diretos e corroboração através de indicadores indiretos e afirmações, sendo a
principal diferença a avaliação da cobertura destas últimas e as diferenças entre as caracterizações
de implementação no nível organizacional, particularmente no que se refere à institucionalização
(Objetivos Genéricos no CMMI, Atributos de Processo no MPS), onde o modelo MPS, a partir do
nível C, tem uma exigência maior sobre os Atributos de Processo dos níveis inferiores.
• Embora os dois métodos contemplem a realização de uma primeira etapa de revisão do estado
das evidências, logística e equipe (Avaliação Inicial no MPS, Readiness no SCAMPI), o MA-MPS
exige uma revisão formal com a presença de toda a equipe de avaliação, enquanto o SCAMPI permite uma maior flexibilidade, sendo de responsabilidade exclusiva do Lead Appraiser.
• Para formação da equipe de avaliação, os dois métodos exigem que a avaliação seja conduzida
por um avaliador líder (Avaliador Líder no MA-MPS, Lead Appraiser no SCAMPI), certificado ou
autorizado por um organismo competente (SOFTEX para MA-MPS, SEI para SCAMPI) e a participação de uma equipe capacitada com uma introdução oficial para cada Modelo. Além disso, o
método MA-MPS tem uma exigência a mais, referente à participação de pelo menos um avaliador
adjunto (papel inexistente no SCAMPI)”.
Lições aprendidas do ponto de vista da Instituição Implementadora
“Um dos fatores críticos de sucesso de uma avaliação conjunta, como a realizada pela Synos, é
a química entre os avaliadores dos dois modelos. Embora convergentes, os modelos apresentam
pontos que exigem uma perfeita sintonia de conceitos, sem o quê, o processo de avaliação pode se
56 WAMPS 2009
Avaliação Conjunta CMMI Nível 3 e MPS Nível C: Lições Aprendidas e Recomendações
tornar lento e improdutivo. Essa afinidade de visões, passa diretamente pelo estilo pessoal de cada
avaliador, na medida em que exigirá, em momentos de divergências, posicionamentos adotados com
maturidade e equilíbrio. Daí a importância desses avaliadores envolvidos, principalmente os líderes de
cada modelo, apresentarem uma ampla experiência em avaliações, e terem desenvolvido uma certa
afinidade pessoal, que os permitirá abdicarem de inflexibilidades e focarem no sucesso dessa nova
modalidade”.
Lições aprendidas do ponto de vista da empresa
“Para nós da Diretoria da Synos esta avaliação conjunta CMMI e MPS trouxe diversas vantagens,
sendo a principal delas a certeza de um maior reconhecimento do mercado quanto à qualidade dos
produtos criados pela Synos e no nosso esforço em realizar a melhoria contínua de nossos processos.
Para nós, obter simultaneamente o Nível 3 do CMMI e o Nível C do MPS é mais uma prova de que
vale à pena investir em processos. Além disso, tivemos um grande ganho de tempo e esforço com a
realização de duas avaliações de uma só vez, além de ter sido uma grande oportunidade para nós.
Gostaríamos de destacar também a forma transparente com que os trabalhos foram conduzidos pela
equipe de avaliação, tornando todo o processo único e imperceptível para a Diretoria, que sempre
recebeu os feedbacks como se fossem de um só modelo, e não de dois, como na verdade estava
acontecendo.”
“Como Diretor Técnico, entendo que independente do modelo implementado, seja MPS ou CMMI,
o nível de controle e qualidade que esperávamos seriam atingidos. Porém, no momento em que tivemos a oportunidade de sermos avaliados conjuntamente, percebemos que poderíamos participar
de uma nova forma de avaliar, economizando recursos e tempo. Acreditamos que o resultado seria
positivo e agora somos pioneiros em um formato de avaliação que certamente será o objetivo de
muitas empresas.
Tínhamos uma grande preocupação com a diferença de visão dos modelos e a percepção dos avaliadores. Mas a experiência e transparência das pessoas que conduziram a avaliação trouxeram-nos
tranqüilidade e sabíamos que a Synos seria muito bem avaliada por eles. Outra importante lição foi
que mesmo com o aumento do rigor e de requisitos que o nível 3 do CMMI e o MPS.BR nível C nos
trariam, conseguimos elaborar um excelente planejamento que possibilitasse a redução dos investimentos em relação ao primeiro ciclo de melhoria do Synos UP, com o qual na época conquistamos o
MPS nível F. E por fim, o apoio e envolvimento da Direção foram fundamentais para a institucionalização do processo e a conquista dos níveis de maturidade.”
“Participar da equipe de avaliação conjunta CMMI e MPS foi uma experiência inédita e de muito
aprendizado para mim. Nesta avaliação, pude trabalhar com avaliadores MPS e lead appraiser CMMI
muito experientes, que ditaram o padrão de qualidade desta avaliação. E, no fim, ficou claro que
esta experiência é um requisito fundamental para avaliações deste tipo. Além da experiência, o bom
entrosamento da equipe de avaliação foi muito importante para a condução eficiente dos trabalhos,
diante da maior complexidade exigida nesta avaliação. Ficaram evidentes para mim também os seguintes valores para este tipo de avaliação: necessidade de flexibilidade dos dois métodos (SCAMPI e
MA-MPS) para atingir um denominador comum; capacidade de ser transparente para os envolvidos,
tornando a avaliação independente dos dois modelos; agilidade, planejamento e organização da
equipe de avaliação, devido ao volume maior de trabalho proveniente dos dois modelos.”
WAMPS 2009 57
Artigos aceitos
“A Synos Technologies é uma empresa de oportunidades. Esta frase há muito tempo circula pela
empresa e esta avaliação conjunta é o retrato do que a empresa representa. A Synos foi a empresa
pioneira avaliada MPS nível F em Minas Gerais e hoje é também pioneira na avaliação conjunta em
dois modelos de maturidade de software. Existiu o desafio, a superação e a colheita dos frutos de um
trabalho bem planejado, executado e auxiliado pela contribuição de cada colaborador da empresa.
Nossa empresa teve novamente uma oportunidade, a de mostrar para o mercado que os modelos
MPS e CMMI são compatíveis e factíveis de serem implementados simultaneamente. A conquista dos
níveis C do MPS e 3 do CMMI simultaneamente foi muito mais que um desafio, foi a comprovação
da maturidade do nosso processo e da empresa e a consolidação dos dois modelos.”
4. Recomendações para Avaliações Conjuntas CMMI/MPS
Do conjunto de lições aprendidas pelos envolvidos, resultaram várias recomendações para novas
avaliações conjuntas CMMI/MPS:
Recomendações do ponto de vista dos avaliadores MPS
“Considero que alguns aspectos podem ser decisivos para o sucesso de uma avaliação conjunta e,
para tratá-los recomendo: (i) como a necessidade de experiência em avaliações nos dois modelos é
muito importante, considero desejável que o avaliador líder e o avaliador adjunto tenham experiência
em avaliações CMMI e MPS; (ii) com relação à experiência do lead appraiser recomendo que só sejam
aprovadas, pela SOFTEX, avaliações conjuntas onde este demonstre já ter liderado, com sucesso, um
certo número de avaliações SCAMPI A no nível que será avaliado; (iii) as características pessoais dos
dois avaliadores que irão liderar a avaliação conjunta são de extrema importância e o contratante
deve buscar, entre outras, capacidade de trabalho em equipe e flexibilidade.”
“Os avaliadores líderes de ambos os modelos devem adaptar suas metodologias de avaliação, de
forma a viabilizar a avaliação conjunta dentro de um prazo favorável, quando comparado ao tempo
das duas avaliações separadamente. Seria interessante, para as próximas avaliações conjuntas com os
modelos MPS e CMMI, preparar um material de apoio já adaptado de forma a atender às demandas
de ambos os modelos. Algumas sugestões são: (i) criar uma planilha de indicadores contendo as
descrições tanto das práticas do CMMI como dos resultados esperados do MPS, além de um mapeamento entre eles; (ii) criar modelos para as apresentações realizadas para a organização prevendo
as informações necessárias em ambos os modelos; e (iii) criar um material de apoio para a coleta de
informações das entrevistas contendo todas as práticas e resultados esperados avaliados, facilitando
a verificação da cobertura destes itens e otimizando o tempo da avaliação”.
“Para facilitar a condução de outras avaliações conjuntas, é importante que os documentos e as apresentações utilizados durante a avaliação também sejam unificados, facilitando o seu preenchimento
e reduzindo o tempo de avaliação. Uma planilha de avaliação unificada, reforçando as diferenças entre os modelos em cada resultado esperado ou prática, também facilitaria o consenso dos resultados.
Além disso, em uma avaliação conjunta é importante que os representantes da empresa na equipe
de avaliação tenham amplo conhecimento sobre os processos da organização e possam ajudar de
maneira pró-ativa os avaliadores na solução das dúvidas”.
58 WAMPS 2009
Avaliação Conjunta CMMI Nível 3 e MPS Nível C: Lições Aprendidas e Recomendações
“Às empresas que pensam em fazer tanto avaliações CMMI quanto MPS.BR, seja em conjunto ou separado, recomendo que procurem iniciar o processo em conjunto. Caso, durante ou após a Avaliação
Inicial, seja notado ser improdutivo continuar o processo em conjunto, a Avaliação Final/On-Site poderia ser realizada em separado. De toda forma, a empresa deve disponibilizar mais tempo e recursos
para a coordenação local dos trabalhos, visando conciliar e atender às necessidades de ambos os
líderes das avaliações. À Softex e à Equipe Técnica do Modelo, sugiro elaborar um quadro comparativo entre os modelos, a ser apresentado e discutido durante o treinamento da avaliação, bem como
material de apoio à realização de avaliações conjuntas, incluindo planilhas específicas, templates e
check-lists de cobertura dos modelos. Para avaliações conjuntas, as Instituições Avaliadoras deverão
alocar os seus avaliadores líderes e adjuntos mais experientes, visando otimizar o tempo das avaliações e garantir um alto nível para os achados obtidos. Aos avaliadores CMMI, sugiro que otimizem
o planejamento para avaliações SCAMPI A conjuntas, considerando a alocação de uma equipe experiente, de forma a consumir menos tempo que o usualmente definido, uma vez que um dos objetivos
do MPS.BR é diminuir custos mantendo a qualidade das avaliações.”
Recomendações do ponto de vista da Instituição Implementadora
“Um fator que deve ser considerado nessas avaliações é o mapeamento feito sobre os resultados
esperados de cada modelo. Embora sejam modelos convergentes, MPS e CMMI oferecem pontos
sobrepostos nos seus resultados. É extremamente recomendável que seja feita e/ou revista a tabela
de mapeamento de resultados entre as duas propostas, de forma a facilitar a condução dos trabalhos de avaliação. Os implementadores MPS que desenvolverem o apoio centrado nos conceitos do
MPS, deverão observar este mapeamento atentando para as sobreposições e diferença de rigor nos
resultados exigidos. Existem graduações diferentes de requeridos e não requeridos (oportunidade de
melhoria), principalmente entre as práticas genéricas do CMMI (GP) e os resultados de atributos de
processos (RAPs) do MPS, que sugerem essa atenção. A planilha de avaliação, no caso da Synos, foi
inicialmente definida para o MPS e depois ajustada para o CMMI, ficando os processos exclusivos do
MPS em documentos separados. Os implementadores deverão definir previamente com os avaliadores qual a planilha que deverá ser apresentada na avaliação, antes de preencher uma das alternativas,
evitando perda de tempo na preparação. No caso da Synos, a planilha guia foi a do CMMI, prática
que talvez seja a adotada daqui em diante, em outras avaliações conjuntas.”
Recomendações do ponto de vista da empresa
“Nossas recomendações estão organizadas em três itens: para as empresas que desejam ser avaliadas, para as Instituições Avaliadoras e para os avaliadores CMMI e MPS.
• Recomendações às empresas que desejam ser avaliadas:
• Tomar o MPS como referência para elaboração dos processos, pois facilita o atendimento aos
resultados do CMMI, visto que o MPS é um modelo de maior exigência e abrangência.
• Durante a elaboração dos processos garantir o atendimento dos resultados que forem específicos do CMMI, para evitar problemas na avaliação conjunta.
• Procurar manter a cultura de processos da empresa sempre fluente nos dois modelos, CMMI e
MPS. Além disso, é fundamental a capacitação do SEPG (grupo de processos da empresa) nos
dois modelos.
WAMPS 2009 59
Artigos aceitos
• Recomendações às Instituições Avaliadoras:
• Manter seu pessoal sempre capacitado e atualizado com relação aos dois modelos, CMMI e MPS.
• Procurar elaborar um método de avaliação especializado que favoreça a avaliação conjunta nos
aspectos de organização, padronização e produtividade. Este método seria uma especialização
dos métodos SCAMPI e MA-MPS.
• Atentar para o prazo total da avaliação, que não pode ser longo, mesmo atendendo a dois
modelos, devido à viabilidade de mercado.
• Recomendações aos avaliadores MPS e CMMI:
• Capacidade de adaptar-se às exigências dos dois modelos, aplicando-se a ambos com o mesmo
grau de dedicação e interesse.
• Capacidade de ser flexível para encontrar a melhor forma de realizar a avaliação conjunta.
• Alto grau de organização e método, o que é muito importante frente ao maior volume e complexidade de trabalho em uma avaliação conjunta.”
5. Conclusões
A avaliação conjunta, realizada na Synos, mostrou que é possível a realização desta modalidade
com benefícios para a empresa avaliada e sem riscos, desde que observadas algumas condições.
Sintetizando, os seguintes pontos positivos podem ser apontados para a realização de avaliações
conjuntas CMMI/MPS:
• Otimiza o tempo dos colaboradores da empresa consumido com a avaliação (ao invés de mobilizar a empresa duas vezes, mobiliza apenas uma), o que também ajuda a reduzir custos de alocação dos colaboradores com as atividades ligadas à avaliação;
• Otimiza custos com logística para realização da avaliação;
• Possibilita obter dois “selos” distintos de uma única vez;
• A avaliação conjunta tende a ter preço menor do que se fossem realizadas duas avaliações;
• Permite montar uma planilha de indicadores única (o que consome bastante tempo da empresa
avaliada), a ser usada para ambos os modelos e processos de avaliação;
• Uma mesma evidência objetiva (artefato direto ou indireto) pode ser usada para satisfazer tanto
um resultado esperado quanto uma prática relacionada, possibilitando atender simultaneamente
aos dois modelos e reduzir o tempo total da avaliação;
• Ambos os avaliadores líderes estão atentos ao seu processo de avaliação, o que diminui a chance
de haver falhas no processo de avaliação como um todo;
• Os avaliadores líderes conhecem os dois processos de avaliação, tentam conciliar seus interesses
e buscam definir uma forma de trabalho adequada e comum para ambos, o que contribui para a
melhoria do processo de avaliação como um todo;
60 WAMPS 2009
Avaliação Conjunta CMMI Nível 3 e MPS Nível C: Lições Aprendidas e Recomendações
• Maior qualidade dos achados e resultados da avaliação, por poder contar com a experiência e o
conhecimento de dois avaliadores líderes.
Visando formalizar as avaliações conjuntas como uma prática alternativa para avaliações MPS e
CMMI, sugere-se:
• Garantir a experiência do avaliador líder MPS e do lead appraiser CMMI em várias avaliações anteriores no nível CMMI/MPS que está sendo avaliado;
• Garantir experiência anterior do avaliador líder MPS e dos avaliadores adjuntos em avaliações
CMMI;
• Se possível, garantir experiência do lead appraiser com o MPS;
• Elaborar um material de apoio específico, sobretudo uma planilha de avaliação evidenciando o
mapeamento entre os dois modelos e destacando suas diferenças.
Pode-se afirmar, portanto, que esta avaliação conjunta CMMI/MPS foi mais uma demonstração explícita da convergência dos dois modelos, além de evidenciar que a alta coesão entre os avaliadores
é o grande fator crítico de sucesso dessa nova modalidade. Assim, a empresa contratante da avaliação conjunta deverá observar cuidadosamente a escolha da equipe de avaliação, a fim de evitar
descontinuidade e riscos nessa etapa, que arremata todo o intenso trabalho desenvolvido em meses
de implementação.
Finalmente, conclui-se que para as organizações que desejam participar tanto no mercado interno
como no mercado externo, uma avaliação conjunta com os dois modelos (MPS e CMMI) é uma ótima estratégia, pois os modelos são similares o suficiente para que os mesmos projetos e processos
possam ser utilizados nas duas avaliações.
Referências
[ABNT, 2000] ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS - ABNT. NBR ISO 9001:2000
– Sistemas de gestão da qualidade – Requisitos. Rio de Janeiro: ABNT, 2000.
[SEI, 2006] SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV), Version 1.2,
Technical Report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering Institute, Carnegie
Mellon University, 2006.
[SEI, 2006b] SOFTWARE ENGINEERING INSTITUTE. Appraisal Requirements for CMMI(ARC), Version
1.2 Technical Report CMU/SEI-2006-TR-011. Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University, 2006.
[SOFTEX, 2009a] - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX. MPS.BR – Guia Geral:2009, maio 2009. Disponível em www.softex.br
[SOFTEX, 2009b] - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX. MPS.BR – Guia de avaliação:2009, maio 2009. Disponível em www.softex.br.
WAMPS 2009 61
Artigos aceitos
Aplicação de Controle Estatístico de Processo
(CEP) no contexto do MR-MPS em uma Fábrica
de Software
Thercio Rodrigues do Nascimento1, Cristiane Soares Ramos1, Luiz Carlos Miyadaira Ribeiro Jr.2
[email protected], [email protected], [email protected]
Politec Tecnologia de Informação S.A
SIG Quadra 4 Lote 173 CEP 70.610-440 Brasília – DF
1
Universidade de Brasília - UnB
Faculdade Gama – FGA Área Especial 2 Lote 14 Setor Central CEP 72.405-610 Gama - DF
2
Resumo: Conforme definido no modelo de qualidade MR-MPS [6], os níveis de alta maturidade (Níveis B e
A) exigem que alguns processos da Fábrica de Software - selecionados conforme os objetivos estratégicos da
empresa - sejam controlados estatisticamente, isto é, sejam previsíveis, capazes e estáveis. Tais processos devem
ser objetos de inovações que permitam a eliminação de causas comuns de variação, proporcionando melhorias
quantitativamente perceptíveis. Este artigo apresenta um caso de sucesso para um ciclo de melhoria, executado
na Politec Tecnologia da Informação S.A., em uma de suas unidades de Fábrica, bem como algumas técnicas
estatísticas utilizadas para realização das análises dos dados resultantes dos processos da Fábrica.
1. Introdução
Nos altos níveis de maturidade, de acordo com os objetivos de negócio da empresa, processos são
selecionados para que sejam controlados estatisticamente. Técnicas estatísticas podem ser utilizadas
para controlar esses processos a fim de torná-los previsíveis, capazes e estáveis. Algumas dessas
técnicas são: Box Plot [8], Cartas de Controle [1], Análise de Distribuição de Dados [1], Simulações e
Testes de Hipóteses. Se usadas de forma combinada, tais técnicas permitem mostrar a previsibilidade
dos processos e provar estatisticamente a estabilidade, capacidade e diferenças entre amostras de
dados.
Nesse sentido, este trabalho apresenta um caso de sucesso para o ciclo de melhoria previsto pelos
altos níveis de maturidade do modelo MR-MPS. Na seção 2, será apresentado um breve resumo da
empresa e o contexto em que se insere este trabalho. Na seção 3, será apresentado o relato de experiência, os processos críticos e medições correspondentes, as etapas realizadas para estabilização e
melhoria dos processos e as técnicas e ferramentas estatísticas utilizadas para as análises. Finalmente,
na seção 4 são apresentas as conclusões deste trabalho.
62 WAMPS 2009
Aplicação de Controle Estatístico de Processo (CEP) no contexto do MR-MPS em uma Fábrica de Software
2. A Politec Tecnologia de Informação S.A.
A empresa possui 39 anos de existência, sendo uma das pioneiras na prestação de serviços de TI no
Brasil. Atualmente, está presente em praticamente todos os estados brasileiros, mantendo em vários
deles Fábricas de Software para desenvolvimento e manutenção de sistemas de software e mais
de 5.500 colaboradores. Ainda, atua em mais quatro países, sendo eles: Argentina, Chile, Estados
Unidos e Japão.
Há mais de oito anos a empresa tem investido em melhoria de processos de desenvolvimento e
manutenção de software, com o objetivo estratégico de se consolidar no cenário nacional e internacional como excelência em desenvolvimento de software. Em Janeiro de 2003, a organização conseguiu realizar, com sucesso, a primeira avaliação em um modelo de qualidade sólido e reconhecido
internacionalmente, o SW-CMM. Desde então, a empresa intensificou os investimentos em Fábricas
de Software, e consequentemente em processos de desenvolvimento e manutenção de software,
sendo a primeira empresa a obter o nível A de maturidade do modelo MR-MPS, em Maio de 2006, e
a primeira a renovar a avaliação, em Maio de 2009.
2.1. Breve histórico
Há vários anos a empresa tem investido na qualidade dos seus processos de software. O quadro abaixo apresenta o histórico de avaliações que foram realizadas na organização desde 2003.
Quadro 1 – Histórico da empresa em avaliações em modelos de qualidade
Janeiro/2003
Obtenção do SW-CMM nível 2 (fábrica de software)
Setembro/2004
Obtenção do SW-CMM nível 3 (fábrica de projetos)
Fevereiro/2006
Maio/2006
Outubro/2006
Maio/2009
Obtenção do CMMI nível 5 (fábrica de software)
Obtenção do MR-MPS nível A (fábrica de software)
Obtenção do CMMI nível 3 (fábrica de projetos)
Reavaliação do nível A do MR-MPS (fábrica de software)
3. O ciclo de melhoria gerenciado quantitativamente
O ciclo de melhoria de processos, gerenciado de maneira quantitativa, segundo o modelo MR-MPS
[6] é coberto nos níveis de maturidade A e B. O nível B possui uma evolução do processo Gerência
de Projetos (gestão quantitativa nos projetos) e a adição dos Atributos de Processo 4.1 e 4.2, que
demonstram a previsibilidade, estabilidade e capacidade de processo.
O nível A garante o processo em Otimização. Isto significa que alguns processos, já estabilizados e
controlados, devem ser priorizados para identificação de causas comuns de variação (Processo ACP)
e que essas causas serão eliminadas por meio de inovações ou melhorias (Atributos de Processo 5.1
e 5.2).
WAMPS 2009 63
Artigos aceitos
Segundo Oliveira [2], o que permite que um mesmo método de trabalho seguido por um determinado grupo de pessoas produza resultados bons ou ruins é chamado de variação. De outro modo, ou
seria somente possível resultados bons ou somente resultados ruins. Um processo estável, portanto,
consiste em minimizar as fontes de variação até um nível controlável. As variações não vão deixar de
existir, principalmente quando considerados fatores humanos, porém as fontes de variação devem
ser mínimas e conhecidas, chamadas de causas comuns de variação [1] [3].
Controladas as fontes de variação, o processo pode ser considerado estável, portanto, previsível.
Processo previsível significa a possibilidade de determinar um desempenho futuro de algum resultado, fundamentado na previsibilidade de um processo e a partir disso, determinar a viabilidade de
atingir um determinado objetivo.
O processo de melhoria nesse contexto, utilizado na organização (Fábrica de Software – unidade
reavaliada MR-MPS, Nível A), seguiu as etapas apresentadas a seguir (Figura 1):
Figura 1 – Etapas do Processo de Melhoria
Etapa 1: Seleção de processos críticos
Os processos críticos foram selecionados a partir dos objetivos de negócio da empresa, voltados para
qualidade e produtividade. Sendo assim, foram selecionados os processos de Verificação, Validação
e de Construção de Software.
Selecionados os processos críticos, foi necessário identificar as medições mais adequadas para aferir o comportamento do processo e o atendimento das metas. Critérios para seleção das medições
incluem:
• Relacionamento das medições e os objetivos de negócio da empresa
• Disponibilidade de dados para a medição
• Freqüência da medição
As medições selecionadas foram:
• Produtividade da Ordem de Serviço – Consiste no esforço dispensado para desenvolver, revisar e
testar cada unidade de tamanho da Ordem de Serviço1.
1) Uma demanda de construção, geralmente um Caso de Uso e a especificação técnica.
64 WAMPS 2009
Aplicação de Controle Estatístico de Processo (CEP) no contexto do MR-MPS em uma Fábrica de Software
PRD =
∑ Esforço
Tamanho da Solicitação
• Densidade de Defeitos de Teste – Consiste na quantidade de defeitos que ocorrem para cada unidade de tamanho da Ordem de Serviço.
DDT =
∑ Defeitos
Tamanho da Solicitação
Ao final da primeira etapa, foi obtido o relacionamento entre Objetivos de Negócio -> Processos
Críticos -> Medições (Figura 2).
Figura 2 – Relacionamento entre objetivo, processo e medição
Etapa 2: Estabilizar os processos críticos
Para demonstrar o comportamento dos processos, foi necessário selecionar a técnica estatística adequada ao tipo de dado existente. A técnica selecionada foi o Controle Estatístico do Processo (CEP)
baseado na análise de gráficos de controle.
O estudo do controle estatístico do processo apresenta uma diversidade de gráficos de controle,
como os listados a seguir [2].
• Média e Amplitudes (X e R)
• Média e Desvio-Padrão (X e S)
• Mediana e Amplitude (X e R)
• Individual e Amplitude (X e R)
• Valor Individual e Amplitude Móvel (X e mR)
Cada tipo de carta apresenta a recomendação de uso conforme o tipo de processo e o volume de dados envolvido na análise [1]. Neste trabalho, foi adotada a carta de controle X e mR. Segundo Florac
[1], esta é a mais adequada para processos de desenvolvimento de software, tendo em vista o fato
que a coleta de dados não obedece a uma periodicidade específica, ou seja, os dados que compõem
a carta são apresentados de forma esporádica e em baixo volume de ocorrências.
A estabilização do processo consiste em identificar e eliminar suas fontes de variação. De acordo com
Florac [1], para se efetuar a estabilização é necessário seguir os seguintes passos: coletar, avaliar a
WAMPS 2009 65
Artigos aceitos
estabilidade, identificar e remover as fontes de variação, executar o processo e coletar novamente,
estes passos devem ser repetidos até que o processo esteja estável (Figura 3).
Selecionar as características do produto ou processo que descrevem a
performance do processo
Selecionar o processo
Selecionar a carta de
controle adequada
Medir a performance do processo por um período de tempo
Determinar a linha central e os limites de controle para as características de desempenho
Plotar os dados da medição na Carta de
Controle
Processo estável
Sim
Todos os valores estão dentro dos limites e distribuídos randomicamente em volta da linha central?
Identificar e eliminar as causas especiais
Processo não estável
Não
Figura 3 – Fluxo de estabilização do processo [5]
O Quadro 2 apresenta o conjunto de técnicas e ferramentas estatísticas adotada para auxiliar no
controle estatístico do processo.
Quadro 2 – Lista de técnicas e ferramentas estatísticas
Técnica Estatística
Descrição
Gráfico de Controle
Representa o comportamento do processo a partir da
QI Macros for MS
medição selecionada e demonstra a estabilidade do processo Excel 2007
Box Plot
Por meio da análise do Quartil permite eliminar a ocorrência
de valores extremos da amostra.
Teste de Hipótese
Utilizada com técnica para avaliar hipóteses estatisticamente. MS Excel 2007
Análise de Distribuição
estatística Normal
Análise utilizada para avaliar se a amostra utilizada possui
um comportamento normal [3].
MS Excel 2007
Regressão Linear
Utilizada para descrever a relação estatística entre duas
variáveis e estabelecer um Modelo de Desempenho
MS Excel 2007
Simulação de Monte
Carlo
Baseado nos Modelos de Desempenho permite estabelecer
um modelo estatístico de predição através de simulações [9].
Oracle Cristal Ball2
2) http://www.oracle.com/crystalball/index.html
66 WAMPS 2009
Ferramenta
Plugin do MS
Excel 2007
Aplicação de Controle Estatístico de Processo (CEP) no contexto do MR-MPS em uma Fábrica de Software
Usando procedimentos baseados nos princípios de Análise de Causa Raiz, tais como a análise de
Pareto [2] para definir a priorização das classes de defeitos mais significativas, análise de correlação
de variáveis [2] para verificar o nível de influência entre atributos, Diagrama de Ishikawa [2] para
mapear a causa raiz que mais influenciou a classe priorizada e os atributos, entre outros, foi possível
identificar que as fontes de desestabilização se encontravam nos processos de Verificação (VER) e
Validação (VAL). Tais fontes de desestabilização afetavam a medição de produtividade, principalmente em aspectos relacionados ao re-trabalho e esforço aplicado aos testes, em decorrência de
ineficiência dos Testes de Software aplicados na fábrica e a falta de uma ferramenta para garantir que
todos os defeitos encontrados fossem corrigidos. A Figura 4 apresenta o gráfico de controle para a
medição de Produtividade.
Figura 4 – Medição de Produtividade
A carta de controle da Figura 4 representa o processo através de pontos em função do tempo. A técnica consiste em diagnosticar a ocorrência das fontes de variação observando os pontos que mais se
distanciam da linha central. Para determinar a instabilidade, os pontos são confrontados em função
de faixas de trabalho definidas a partir do estabelecimento de 6 Sigmas [1] e a aplicação de testes
observando os limites estabelecidos. Na literatura podem ser encontrados vários testes estatísticos
[3]. Conforme sugerido por Florac [1] os testes adotados na Fábrica foram:
• Teste 1: Um ponto acima do 3º Sigma ou limite de controle superior.
• Teste 2: Dois pontos acima do 2º Sigma de três pontos consecutivos do mesmo lado da média.
• Teste 3: Quatro pontos acima do 1º Sigma de cinco pontos consecutivos do mesmo lado da média.
• Teste 4: oito pontos do mesmo lado da linha central.
A estabilização do processo foi conseguida por meio de melhorias nos processos de VER e VAL. Em
resumo, foram elas:
• Maior rigor na validação dos requisitos de entrada de cada Ordem de Serviço, com a adoção de
padrões a serem seguidos e critérios objetivos de validação, com envolvimento dos papéis de
Desenvolvedores, Arquitetos e Analistas de Testes.
WAMPS 2009 67
Artigos aceitos
• Maior rigor na verificação dos Casos de Testes
• Maior investimento no subprocesso de planejamento de Testes de Software, com objetivo de adequar o processo para cada projeto em particular.
• Implantação de uma ferramenta para gestão de defeitos, o que garantiu maior controle dos defeitos abertos, tanto de Verificações como de Validações.
A Figura 5 apresenta o gráfico de controle para a medição de produtividade, antes e após as melhorias citadas.
Figura 5 – Estabilização do Processo
A partir do processo estabilizado foi iniciado um novo estágio de gerenciamento do processo, que
é intitulado gerenciamento quantitativo. Este gerenciamento consiste em acompanhar o processo a
partir de uma base de referência, a Linha de Base de Desempenho do Processo [1] de modo que o
projeto de desenvolvimento de software é planejado e controlado utilizando esta referência. Dessa
maneira, qualquer sintoma de instabilidade pode ser diagnosticado e tratado de forma imediata.
Esses aspectos caracterizam nível B de maturidade do MR-MPS [6].
Etapa 3: Implantar a inovação para otimizar o processo
Esta etapa consiste em identificar causas comuns de variação em um processo estável e implantar
uma melhoria ou inovação para eliminar tais causas comuns. A abordagem adotada consistiu em
efetuar um estudo sobre as fontes de variação comuns no processo de Construção.
O estudo indicou que muitos Ativos de Software desenvolvidos nas Fábricas eram recorrentes. Isso
significava que as Fábricas definiam Arquiteturas de Software, soluções de negócio e soluções técnicas para problemas parecidos, mas fazia pouco reuso dessas soluções.
Um Ativo de Software é uma coleção de artefatos relacionados que provê uma solução para um dado
problema. Os Artefatos são produtos de trabalho resultantes do ciclo de vida do desenvolvimento de
software, tais como: requisitos, modelos, código fonte, descritores de implantação, casos ou scripts
de teste, etc. Um Ativo poderá ser relevante para um ou mais contextos, tais como desenvolvimento,
implantação ou negócio e deverá conter regras e instruções de uso.
68 WAMPS 2009
Aplicação de Controle Estatístico de Processo (CEP) no contexto do MR-MPS em uma Fábrica de Software
Entre os vários Tipos de Ativos de Software, pode-se citar: componentes, padrões, web services, frameworks e modelos de documentos. No entanto, algumas das falhas mais freqüentes em iniciativas
de reuso são [7]:
• Não modificar processos existentes que não consideravam reuso;
• Não introduzir processos específicos de reuso;
• Não considerar fatores humanos como parte do processo.
Os processos existentes precisam ser modificados principalmente porque o consumo de ativos de
software reusáveis ocorre dentro dos projetos de desenvolvimento de sistemas. Assim, os processos
que orientam o desenvolvimento devem conter tarefas de busca, seleção e adaptação de itens previamente produzidos, a fim de que estes possam ser adicionados a um projeto em particular. Também
é durante os projetos de desenvolvimento que surgem as necessidades e soluções recorrentes que
proporcionam novas oportunidades de reuso e é necessário que os processos ofereçam maneiras
para se perceber e aproveitar essas oportunidades.
Embora a identificação e o consumo dos ativos de software aconteçam ao longo dos projetos de
desenvolvimento de sistemas, geralmente eles possuem um ciclo de vida que extrapola o período de
execução dos projetos. Além disso, a produção e a gestão dos ativos são ações que envolvem interesses organizacionais e que ultrapassam os limites das equipes de projeto, o que justifica a necessidade
de se introduzir um processo específico para tratar a questão.
Nesse sentido, a abordagem na organização foi orientada nos seguintes pilares:
Definição de
processos
para gestão,
produção
e consumo
de ativos de
software
Os objetivos principais do processo de Gestão, Produção e Consumo de Ativos Reusáveis
foram:
• Estabelecer estratégias claras para a reutilização de ativos, tais como categorização
(aplicação, arquitetura, componente, ferramenta, framework), regras de certificação,
regras para documentação e medições
• Estabelecer papéis e responsabilidades na Fábrica para administração dos serviços do
repositório
• Estabelecer pontos no processo de desenvolvimento para identificação de oportunidades de reuso (produção de ativos)
• Estabelecer pontos no processo de desenvolvimento para utilização da biblioteca e dos
ativos (consumo de ativos)
Este processo está conforme o processo Gerência de Reutilização – GRU do modelo MRMPS, nível E de maturidade [6].
WAMPS 2009 69
Artigos aceitos
Identificação de
oportunidades
na vasta
experiência
passada da
organização
nas Unidades
de Fábrica e
a construção
de Linhas de
Produto
Foi realizado o trabalho de inventariar os projetos desenvolvidos na empresa. Este
trabalho resultou em 88 projetos mapeados de acordo com as seguintes características:
• Uso de ativos de terceiros
• Características dos ambientes de desenvolvimento e de produção dos sistemas
desenvolvidos
• Linhas de negócio
• Clientes
• Tecnologias utilizadas
• Frameworks e padrões de projeto
• Linguagem de programação
• Ferramentas
Esse mapeamento foi importante para identificar áreas em que as oportunidades de
reuso seriam mais promissoras, de acordo com o histórico da própria empresa. A partir
disso, foi construída uma Linha de Produto com ativos relacionados ao negócio (verticais)
e tecnológicos (horizontais).
Criação de
um grupo de
Arquitetos de
Software que,
ao mesmo
tempo, possuem
a responsabilidade de atuar
nos projetos de
desenvolvimento
e gerenciar a
base de ativos
de software
A estrutura totalmente orientada a projetos não se mostrou favorável, em outras
iniciativas, para manter o processo de Gestão de Ativos em constante atualização a uso.
Isso ocorreu pois a tendência natural é a perda da coesão técnica ao longo do tempo,
ocasionando problemas de consistência da base de ativos em curto prazo.
A solução adotada foi criar uma estrutura matricial para o perfil de Arquiteto de
Software. A atuação destes profissionais no projeto é organizada e controlada pelo
grupo de Arquitetura, sob gestão funcional do Gerente de Projetos.
Essa mudança tem proporcionado maior controle do processo, permitindo, entre outros
benefícios, os seguintes:
• Apropriação correta dos custos de produção de ativos
• Patrocínio dos gerentes de projeto
• Disseminação de conhecimento entre Arquitetos e Desenvolvedores
• Uniformização do conhecimento técnico
• Maior conformidade às políticas e regras do processo de Gestão de Ativos Reusáveis
Após a implantação e execução desse novo processo de Construção, baseado em Linhas de Produto,
o resultado da medição de Produtividade demonstrou uma melhoria significativa. A Figura 6 apresenta o gráfico de controle.
Figura 6 – Implantação da inovação
70 WAMPS 2009
Aplicação de Controle Estatístico de Processo (CEP) no contexto do MR-MPS em uma Fábrica de Software
4. Conclusões
Este trabalho apresentou um relato de experiência que demonstra um ciclo de melhoria de acordo
com os níveis B e A de maturidade do MR-MPS. No entanto, não foi explorado neste trabalho o uso
dos modelos de desempenho para predição dos resultados no contexto da gestão quantitativa de
projetos e também para seleção de melhorias / inovações. Tais modelos podem ser utilizados para
predizer o resultado da execução de determinados processos por meio de simulações [4]. O resultado
das simulações oferece maior segurança para a tomada de decisões sobre os investimentos necessários para executar as inovações.
O gráfico da Figura 6 apresentou a melhoria obtida na medição de produtividade. Melhorias em
outras medições também foram percebidas, principalmente naquelas relacionadas à qualidade do
produto. Um estudo de retorno sobre investimentos mostrou que o resultado pode ser bastante satisfatório, a depender do volume de demandas em um determinado período de tempo.
5. Referências bibliográficas
[1] FLORAC W. A .; CARLENTON, A . D.; Measuring the Software Process: Statistical Process Control
for Software Process Improvement. Reading, MA, EUA: Addison-Wesley. SEI Series in Software
Engineering; 1999.
[2] OLIVEIRA, Marcelo S.; Qualidade de Processo Software: Medição e Análise; Lavras – UFLA, 2006.
[3] WHEELER, D. J.; CHAMBERS, D. S.; “Understanding Statistical Process Control”; Knoxville, TN: SPC
Press, 1992.
[4] FENTON, N., MARSH, W., CATES, P., FOREY, S., TAYLOR, M., “Making Resource Decisions for
Software Projects”. Proceedings of the 26th International Conference on Software Engineering,
Escócia 2004.
[5] CARLENTON, A . D.; FLORAC W. A .; PARK R. E.; “Pratical Software Measurement: Measuring for
Process Management and Improvment”; GUIDEBOOK – CMU/SEI-97-HB-003.
[6] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR
– Guia de geral, v 2009, 2009. Disponível em www.softex.br. Acesso em 21/08/2009.
[7] MORISIO, M.; EZRAN, M.; TULLY, C. Success and failure factors in software reuse.Software
Engineering, IEEE Transactions on Volume 28, Issue 4, pp. 340 – 357. Apr 2002.
[8] FRIGGE, M; HOAGLIN, D.; IGLEWICZ, B. Some Implementations of the Boxplot. The American
Statistician. Vol. 43 (1), February 1989. 50–54.
[9] SOBOL, Ilya Meerovich; A primer for the Monte Carlo Method; CRC Press, Inc; 1994.
WAMPS 2009 71
Artigos aceitos
Um Relato dos Desafios Encontrados e dos
Benefícios Conseguidos com a Implantação das
Práticas Propostas pelo Nível F do Modelo de
Referência de Processo MPS.Br
Gustavo Vaz Nascimento, Wander Marcelo Lorencin, Felício Fadlalla Nassif {gustavo, marcelo, felicio}@shift.com.br
Shift Consultoria e Sistemas
Resumo. Este artigo tem o objetivo de relatar as experiências vividas pela Shift na implantação dos processos
do nível F do MPS.Br. O artigo descreve os principais desafios encontrados durante a caminhada e as soluções
adotadas para superá-los. São relatados também os principais benefícios conseguidos com a implantação dos
processos e os motivos que fizeram com que a Shift optasse pela avaliação oficial.
1. Introdução
A Shift é uma empresa de tecnologia que oferece sistemas e serviços a laboratórios clínicos. As
soluções Shift podem ser vistas sob três focos principais: sistemas de informações laboratoriais, sistemas de interfaceamento de equipamentos laboratoriais e sistemas de controles administrativos e
financeiros.
Embasada em sua experiência de mais de 17 anos no mercado laboratorial, a Shift sempre está a
procura de desafios que possam possibilitar oportunidades de negócio à própria empresa e a seus
clientes. Com esta visão estratégica, a empresa identificou a necessidade de re-desenvolver suas aplicações, visando fornecer, a seus clientes, aplicativos mais robustos, seguros e com maior qualidade.
Para alcançar tais objetivos, a Shift investiu em novas tecnologias e conceitos que envolvem orientação a objetos, orientação a serviços e desenvolvimento orientado a componentes.
Durante o período de estudos envolvendo algumas tecnologias que permitem a aplicação de tais
conceitos, a empresa percebeu que a aplicação desses conceitos de forma satisfatória só seria possível com o auxílio de uma metodologia de desenvolvimento que possibilitasse controle e qualidade de
seus processos. Desta forma, dois grandes desafios precisavam ser transpostos: a “nova tecnologia”
e a “nova metodologia”, sendo que a metodologia é o objetivo principal deste artigo.
Com relação à “nova metodologia”, optou-se pela adoção do MPS.Br. A princípio, o modelo atenderia às expectativas da empresa e, além disso, existia uma parceria entre a APETI (Associação dos
Profissionais e Empresas de Tecnologia da Informação – São José do Rio Preto), o Núcleo SOFTEX
Campinas, o SEBRAE-SP e a ASR Consultoria (uma empresa de consultoria em qualidade altamente
reconhecida em sua área de atuação) que foi crucial para a opção da Shift em adotar o MPS.Br. A parceria possibilitava que a Shift contasse com o apoio da ASR (envolvendo treinamentos e consultorias
72 WAMPS 2009
Um Relato dos Desafios Encontrados e dos Benefícios Conseguidos com a Implantação
remotas e in loco), o que acelerou o processo e viabilizou, tecnicamente e financeiramente, a implantação do modelo.
O artigo está organizado da seguinte forma: Na Seção 2 são apresentados os problemas e soluções
levantados antes da definição da nova metodologia; Na Seção 3 são apresentados os resultados
desejados e principais dificuldades encontradas durante a implantação; Na Seção 4 é apresentada a
metodologia de desenvolvimento adotada. Na Seção 5 são apresentados os benefícios conseguidos
com a implantação dos processos; Por fim, na Seção 6 são apresentadas algumas conclusões sobre
a adoção do MPS.Br.
2. Os problemas e soluções levantados antes da definição da nova
metodologia
A definição de uma nova metodologia de desenvolvimento era vista como um assunto chave, pois a
empresa trazia consigo uma cultura de mais de 17 anos sem mudanças significativas, o que poderia
gerar resistência por parte de seus colaboradores. Os aplicativos também traziam essa “experiência”
e grande parte dos clientes eram antigos parceiros que já utilizavam os aplicativos há vários anos.
Portanto, era preciso definir uma arquitetura de software para os novos aplicativos que reduzisse os
riscos de migração para estes clientes.
Com relação à nova metodologia, a preocupação era com o fato de que a equipe de desenvolvimento era bastante familiarizada com a metodologia de desenvolvimento utilizada até então e, por esse
motivo, o risco de uma mudança cultural na empresa não ser bem aceita era grande. Embora o risco
fosse grande, a Shift não sofreu grande impacto negativo relacionado a esse aspecto. Isso ocorreu
devido ao completo comprometimento da diretoria no processo de implantação e à forma participativa com que a implantação dos processos foi conduzida. A diretoria e os colaboradores participaram
das decisões referentes à metodologia sempre que possível e, grande parte das vezes, eles eram
consultados sobre possíveis definições (Carvalho et al., 2006).
Além da mudança cultural, o que preocupava os responsáveis pela definição e implantação da nova
metodologia era a capacitação da equipe técnica. Com a implantação da nova metodologia e dos
novos conceitos trazidos com as novas tecnologias, a Shift precisou investir bastante em capacitação.
Os treinamentos referentes à tecnologia e à metodologia foram, e ainda são, frequentes durante
todo o processo de implantação. De acordo com os registros de treinamentos mantidos pela Shift,
foram empregadas 328 horas de treinamentos técnicos, visando capacitar a equipe na tecnologia e
nos conceitos de engenharia de software, e 180 horas de treinamentos nos processos, visando capacitar a equipe na metodologia de desenvolvimento adotada. No Quadro 1 estão apresentadas as
informações detalhadas dos treinamentos realizados durante a implantação da nova metodologia e
da nova tecnologia.
WAMPS 2009 73
Artigos aceitos
Quadro 1: Contabilização das horas empregadas em capacitação da equipe
Treinamento
Duração (horas)
Nova tecnologia e conceitos
Orientação a objetos
SQL
Framework de desenvolvimento
Treinamentos práticos com OO, SQL and Framework de desenvolvimento
328
30
8
40
120
Prova de conceitos e estensões do framework
40
Padrões de desenvolvimento
10
Conceitos de engenharia de software
80
Nova metodologia de desenvolvimento
180
3. Resultados desejados e principais dificuldades encontradas
durante a implantação
A Shift desejava adotar uma metodologia que fosse baseada em um modelo de processo de software
que possibilitasse um reconhecimento mercadológico e, mais do que isso, que proporcionasse
à empresa maior previsibilidade a seu processo de desenvolvimento e maior qualidade aos seus
produtos.
Os desafios a serem superados eram grandes e a empresa precisava seguir um modelo maduro o suficiente para suportar as mudanças culturais e tecnológicas que iria enfrentar. Já no princípio optou-se
pela implantação do MPS.BR, pois esperava-se que o modelo proporcionasse maior previsibilidade
aos projetos e maior controle dos requisitos. Além disso, desejava-se que o modelo auxiliasse no
controle dos artefatos dos produtos e dos artefatos gerados pelos processos e, ainda, que a empresa
pudesse ter um maior controle sobre os seus processos.
Nesse sentido, identificou-se o nível F do MPS.BR como sendo o nível que atenderia boa parte das
expectativas iniciais da empresa e decidiu-se por iniciar a implantação pelos processos do nível G
(SOFTEX, 2007).
Uma das dificuldades encontradas durante esta etapa foi relacionada à tecnologia. A empresa precisava decidir se a nova metodologia seria aplicada à manutenção aos produtos de software préexistentes ou se seria aplicada somente aos projetos de re-desenvolvimento dos produtos, que envolveria, exclusivamente, a nova tecnologia.
O fato era que os produtos de software pré-existentes eram desenvolvidos em uma tecnologia denominada D3, com conceitos de bancos de dados multivalue, interface de usuário caractere e com
paradigma de desenvolvimento baseado nos conceitos de análise estruturada. Essa tecnologia é
diferente da nova tecnologia adotada (InterSystems Caché), pois a nova tecnologia utiliza banco
de dados e paradigma de desenvolvimento orientados a objetos e propicia a criação de interface
de usuário voltada para a Web. Acreditava-se que as diferenças entre as tecnologias tornar-se-iam
um obstáculo importante na implantação do processo de gerência de configuração, principalmente
porque as ferramentas de apoio a este processo (Subversion e Mantis), conhecidas até então, não
74 WAMPS 2009
Um Relato dos Desafios Encontrados e dos Benefícios Conseguidos com a Implantação
poderiam ser integradas com as ferramentas de desenvolvimento da tecnologia D3 e, portanto, uma
parte do trabalho teria que ser feita manualmente para esta tecnologia, o que implicaria em dois
processos distintos.
Com base nessas dificuldades e, principalmente, tendo em vista os objetivos estratégicos da empresa, optou-se por implantar a nova metodologia somente para os projetos que envolvessem a nova
tecnologia.
Internamente, a decisão trouxe bons resultados. As mudanças ocasionadas pelos novos processos puderam ser implantadas em paralelo às mudanças ocasionadas pela nova tecnologia. Acredita-se que
esse fato tenha minimizado a resistência da equipe e tenha facilitado a institucionalização dos processos na empresa, pois os colaboradores envolvidos encontravam-se pré-dispostos a mudanças.
Outros aspectos que facilitaram a institucionalização dos processos foram a preocupação em não
tornar o trabalho da equipe lento e burocrático e, ainda, a preocupação com a agilidade na comunicação entre os integrantes da equipe. Visando minimizar os esforços dos colaboradores na execução
dos processos e minimizar os problemas de comunicação, a metodologia foi definida com base no
princípio de comunicação intensa e integração de ferramentas.
Para atender a esses princípios, as equipes dos projetos são alocadas em uma mesma sala, com as
estações de trabalho próximas umas das outras, visando agilidade na comunicação. Além disso, os
colaboradores dispõem de ferramentas de comunicação e documentação colaborativa. As ferramentas de desenvolvimento (Caché Studio), de controle de versões (Subversion), de comunicação (Wiki,
listas de discussão), de documentação técnica (StarUML), de gerência de defeitos e modificação
(Mantis) também são integradas e o acesso a elas é centralizado em um portal, com interface Web,
onde são disponibilizados também todos os processos que definem a metodologia.
Acredita-se que a comunicação intensa e a integração entre as ferramentas minimizaram a necessidade de documentação interna e aumentou a agilidade e corretude na execução dos processos.
Mais do que isso, as ferramentas de comunicação permitem que as discussões de projeto fiquem
documentadas e sirvam como conhecimento da empresa. A integração entre as ferramentas pode
ser visualizada na Figura 1.
4. A metodologia de desenvolvimento adotada
Atualmente, a Shift tem implantado e institucionalizado os processos do nível G (Gerência de
Requisitos e Gerência de Projetos), do nível F (Gerência de Configuração, Garantia de Qualidade e
Medição) e parte do nível D (Verificação e Validação). O processo de Aquisição, parte do nível F, não
faz parte do escopo de trabalho da Shift (SOFTEX, 2007).
WAMPS 2009 75
Artigos aceitos
Figura 1: Acesso centralizado aos recursos através de portal
A metodologia adotada foi baseada no ciclo de vida dos projetos, e a redefinição deste ciclo foi o
primeiro ponto do trabalho de adequação da consultoria. As atividades dos processos foram encaixadas no ciclo de vida visando complementá-lo e, desta forma, proporcionar qualidade na execução
dos projetos e processos. O ciclo de vida adotado e os objetivos gerais de cada fase do ciclo de vida
são apresentados de forma resumida na Figura 2.
Figura 2: Ciclo de vida dos projetos
A fase de construção é onde o software é literalmente construído. Esta fase é iterativa, ou seja, pode
ocorrer diversas vezes durante a execução de um projeto. As iterações são chamadas de ciclos de
desenvolvimento, que são compostos das seguintes etapas: planejamento do ciclo, detalhamento
dos requisitos, codificação, testes1, validação, documentação e término do ciclo. O ciclo de desenvolvimento da etapa de construção está apresentado na Figura 3.
1) A etapa de testes foi definida com base no padrão IEEE 829, que define um padrão para o processo e documentação de testes de
software (The Institute of Electrical and Electronics Engineers, 1998)
76 WAMPS 2009
Um Relato dos Desafios Encontrados e dos Benefícios Conseguidos com a Implantação
Figura 3: Ciclo de desenvolvimento da fase de construção
Ao final de cada ciclo, uma nova versão do produto de software em desenvolvimento está pronta
para ser colocada em produção, embora na prática, isso ocorra somente após o final do projeto.
O intuito é que uma versão do software com qualidade de produção seja produzida em um ciclo
de desenvolvimento. Para isso, durante a execução de um ciclo, são realizadas atividades que visam
monitorar o projeto e garantir a correta execução dos processos. Essas atividades são referentes aos
processos de garantia de qualidade, de gerência de configuração, de medição, de gerência de requisitos e de gerência de projetos e, ainda, aos processos de verificação e validação.
A divisão dos projetos em ciclos de desenvolvimento facilita o monitoramento, pois permite que o
esforço do administrador do projeto seja focado somente nos ciclos em andamento e, com isso, é
possível aumentar o comprometimento da equipe. Os ciclos também aumentam a flexibilidade dos
projetos, pois facilitam o gerenciamento dos requisitos e permitem uma priorização destes, mesmo
após o projeto ter se iniciado. Outra vantagem é que os problemas enfrentados em um ciclo servem
como lições aprendidas para os próximos ciclos. Essa abordagem tem aumentado a qualidade e agilidade na execução dos processos e tem mantido o comprometimento da equipe do projeto.
Em alguns pontos específicos do ciclo de desenvolvimento é exigida a execução de atividades que
garantem a qualidade de execução dos processos e auxiliam no monitoramento dos projetos. Esses
pontos específicos são exigidos para todos os projetos e não podem ser desconsiderados sob nenhuma justificativa, pois fazem parte da política da empresa, que deve ser seguida por todos os colaboradores. Na Figura 4 são apresentados os pontos específicos presentes no ciclo de desenvolvimento.
Figura 4: Pontos específicos do ciclo de desenvolvimento que permitem um controle de qualidade dos
processos e dos projetos
WAMPS 2009 77
Artigos aceitos
Os pontos específicos nomeados como “GQA” referem-se a atividades de garantia de qualidade.
Nesses pontos, são verificadas a qualidade dos produtos de trabalho e a qualidade na execução dos
processos. Além dos pontos específicos de “GQA”, o processo prevê a realização desta atividade
mensalmente.
Os pontos específicos nomeados como “Pto.Controle” são referentes a atividades de monitoramento
do projeto. Embora os projetos mantenham uma rotina de reuniões semanais de monitoramento,
os pontos de controle são momentos onde é feita uma análise mais crítica e é avaliada, entre outras
coisas, a viabilidade de continuação do projeto. A diretoria pode ser envolvida nesta etapa quando há
algum assunto mais crítico, porém, independente disso, a diretoria recebe as atas dessas reuniões e
pode solicitar ações específicas quando achar conveniente. Além dos pontos específicos de controle,
o processo prevê a realização de um ponto específico de controle mensalmente.
Os pontos específicos nomeados como “Pto.Medição” são referentes a coleta de medidas e geração
de indicados dos projetos. Essas medições auxiliam no monitoramento do andamento do projeto e
da qualidade de execução dos processos. Além dos pontos específicos de medição, o processo prevê
a realização de medições periódicas semanais (que geram indicadores que ajudam a avaliar o andamento dos projetos) e medições periódicas mensais (que geram indicadores que ajudam a avaliar a
qualidade de execução dos processos)
A definição de um ciclo de vida para os projetos e a implantação dos processos aumentou significativamente o controle e a previsibilidade dos resultados dos projetos. Os resultados foram ainda mais
satisfatórios após a equipe ter adquirido certa experiência na execução dos processos. Percebeu-se
uma redução média de 15% das incidências de não-conformidades (INC) desde o início da implantação até os dias atuais. Na Figura 5 é possível visualizar esta redução através da diminuição do INC
dos projetos 1 e 2, que envolveram a mesma equipe.
Figura 5: Índice de não-conformidades (INC) gerados a partir de dois projetos
chamados de Projeto 1 e Projeto 2
5. Benefícios conseguidos com a implantação dos processos
A implantação dos processos na Shift elevou consideravelmente a maturidade da empresa na construção de software. A qualidade conseguida com a implantação dos processos é bastante significativa e permitiu que o processo de construção de software adquirisse uma previsibilidade importante
para as decisões estratégicas da empresa.
78 WAMPS 2009
Um Relato dos Desafios Encontrados e dos Benefícios Conseguidos com a Implantação
Um exemplo dos benefícios conseguidos com esta implantação é relacionado ao gerenciamento de
recursos humanos e à estimativa de prazos para os projetos. O novo processo permite que a empresa
preveja, com um nível satisfatório de acerto, os prazos para a execução de um projeto e, mais do
que isso, consegue antever atrasos que antes não eram percebidos. Essa previsibilidade satisfatória só
foi possível devido a maturidade adquirida com o processo e com ajustes de estimativas que foram
realizados durante a caminhada.
Acredita-se também que este nível de assertividade, embora ainda esteja um pouco distante dos
100%, tem relação direta com o gerenciamento de recursos humanos. O gerenciamento de recursos
humanos é um dos assuntos que a Shift precisa aprimorar, porém, o nível de gerenciamento conseguido até o momento já é suficiente para permitir um controle satisfatório dentro dos projetos.
No Quadro 2 é possível visualizar, de forma resumida, esse gerenciamento de recursos através do
compartilhamento destes entre três projetos distintos e que estão em execução atualmente na empresa. Com o gerenciamento, a empresa consegue prever quando um recurso estará disponível e/ou
quando ele estará alocado em um determinado projeto, permitindo aos administradores dos projetos
uma expectativa maior de acerto em suas estimativas de prazo. Embora esse controle ainda exija uma
boa carga de esforços operacionais, ele vem se mostrando bastante satisfatório.
Quadro 2: Papéis e responsabilidades em alguns projetos executados na empresa
Papel
Equipe do
projeto Fênix
Equipe do
projeto Shiva
Equipe do
projeto Íris
Coordenador de projetos
Junior
Junior
Junior
Administrador do projeto
Thaynan
Leonardo
Rodolpho
Desenvolvedor
André, Thaynan,
Thiago, Cauê
Eduardo, André Luis,
Francisco
Rodolpho, Sérgio,
Marcelo
Projetista de testes
Giuliano, Murilo
Giuliano, Murilo
Giuliano, Murilo
Testador
Ana Cláudia
Ana Cláudia
Lucas e Paulo
Validador
Priscilla
Priscilla
Priscilla
Documentador
Priscilla
Priscilla
Priscilla
Gerente de configuração
Leonardo
Thaynan
André
Auditor de configuração
André
Thaynan
Leonardo
Analista de Negócios
Felício
André Luis, Leonardo
Rodolpho
Garantia de Qualidade
Gustavo
Gustavo
Gustavo
Outro benefício percebido que pode ser destacado é o controle que a empresa tem sobre o andamento dos projetos. A implantação do processo de medição2 e das práticas de gerência de projetos
permitiu que os administradores dos projetos e a diretoria tenham uma boa visão do andamento das
etapas/atividades previstas para o projeto, possibilitando que ações possam ser tomadas mais rapidamente e com mais precisão. Antes da implantação desses processos e práticas, o acompanhamento
dos projetos era feito unicamente através do cronograma. Na Figura 6 estão apresentados alguns dos
indicadores de andamento de projeto gerados semanalmente.
2) Para a definição do processo de medição, foi utilizada a técnica denominada Goal-Question-Metric (GQM), que permite identificar
medidas adequadas para a organização de acordo com seus objetivos de medição (Park et al., 1996)
WAMPS 2009 79
Artigos aceitos
Figura 6: Indicadores semanais de andamento do projeto Fênix OS, gerado em 24/07/2009
Os indicadores PTEA e PATE demonstram, respectivamente, os atrasos existentes nas tarefas especializadas3 e qual o impacto que tais atrasos causam no ciclo do projeto. Os indicadores SP e SCP são
relacionados, respectivamente, ao andamento do ciclo do projeto de um ponto de vista macro e de
um ponto de vista mais detalhado.
Outro ponto que pode ser destacado é o nível de controle proporcionado pelo processo de gerência
de configuração. Este processo proporcionou - através das solicitações de mudanças, congelamento
de artefatos, controle e planejamento de baselines, controle de versões e modificações, entre outros maior confiança aos desenvolvedores durante a codificação e aos administradores de projeto durante
o gerenciamento, pois garante que somente o que foi previsto para o projeto será implementado e
permite que qualquer modificação possa ser revertida a qualquer tempo (Cia, 2006). Isso também
transmite segurança a diretoria, pois a empresa passa a ter maior controle sobre a integridade de
seus aplicativos.
Esses e outros benefícios fizeram com que a Shift investisse na avaliação de sua maturidade. A
melhoria conseguida com a implantação dos processos foi a principal razão para a decisão de submeter-se a uma avaliação nível F ainda em 2009. A oportunidade mercadológica que tal conquista
trará para a empresa é notável, porém, a Shift decidiu por este caminho também como forma de
incentivo e reconhecimento aos colaboradores envolvidos no processo, pois se acredita que a avaliação traz comprometimento por parte dos colaboradores. Para validar o processo, foi feita pela ASR
Consultoria uma avaliação prévia no Nível F, a qual indicou que a Shift está no caminho certo para
obter a certificação.
3) As tarefas especializadas são tarefas chave previstas no ciclo de vida dos projetos e que tem impacto direto nos prazos dos projetos. As
tarefas especializadas são relacionadas a especificação de requisitos, codificação, produção de layout e produção de casos de teste.
80 WAMPS 2009
Um Relato dos Desafios Encontrados e dos Benefícios Conseguidos com a Implantação
6. Conclusões
O MPS.Br é um modelo de processo de software que visa direcionar as empresas de software em um
processo de melhoria, visando a construção de software com qualidade (Softex, 2007). Direcionada
por este objetivo, a Shift optou por redefinir sua metodologia de desenvolvimento com base nas
diretrizes definidas por este modelo de processo.
A implantação de processos em uma empresa não é um trabalho fácil. A conscientização dos envolvidos nestes processos exige muito esforço e muita capacitação. Conforme apresentado no Quadro
1: Contabilização das horas empregadas em capacitação da equipe, foram despendidas mais de
500 horas em capacitação. Isso exige da empresa habilidade para conseguir o envolvimento de seus
colaboradores, o que é crucial para o sucesso do processo de implantação. Neste aspecto, o comprometimento da diretoria é vital.
Em resumo, a implantação dos processos demanda bastante esforço e o custo da implantação é
alto. O custo de se manter a execução dos processos também é significativo, porém, as melhorias
conseguidas com a implantação, destacadas na Seção 6, satisfizeram as expectativas da empresa e
justificaram os investimentos realizados.
Referências
SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral (Versão 1.2). Junho,
2007.
THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC. IEEE Standard for Software Test
Documentation: IEEE Std 829-1998. Setembro, 1998.
CIA, T. M. Modelo de avaliação do processo de gerência de configuração de software. São Paulo:
Universidade de São Paulo – Instituto de Ciências Matemáticas e da Computação. Fevereiro,
2006.
PARK, R. E., GOETHERT, W. B., FLORAC, W. A. Goal-Driven Software Measurement: A Guidebook.
Pittsburgh, Software Engineering Measurement and Analysis. Agosto, 1996.
CARVALHO, A. E. S., TAVARES, H. C., CASTRO, J. B. Uma Estratégia para Implantação de uma Gerencia
de Requisitos Visando a Melhoria Dos Processos de Software. Universidade Federal de Pernambuco
– Centro de Informática. Setembro, 2006.
WAMPS 2009 81
Artigos aceitos
O Guia de Aquisição do MPS.BR e o Pregão
Eletrônico
Danilo Scalet1, Edmeia Leonor Pereira de Andrade2
[email protected], [email protected]
Companhia de Informática do Paraná (CELEPAR)
Empresa Brasileira de Agropecuária (EMBRAPA)
1
2
Resumo. Este artigo aborda o processo de aquisição de Software e Serviços Correlatos (S&SC), publicado pela
Sociedade SOFTEX no Guia de Aquisição MPS.BR Versão2009, e a sua aplicação em aquisições de S&SC realizadas por meio de licitações utilizando-se pregão eletrônico. O objetivo deste trabalho é apresentar aspectos
fundamentais a serem considerados num projeto de aquisição realizado na modalidade de pregão eletrônico
visando o sucesso de projeto e o atendimento às necessidades estabelecidas.
1. Introdução
A definição, escolha e obtenção de Software e Serviços Correlatos (S&SC) que sejam adequados
à estratégia de uma organização podem ser fatores determinantes para o sucesso de empreendimentos envolvendo instituições públicas e privadas, pois o uso das Tecnologias da Informação e
Comunicação (TIC) está intensamente presente nas atividades do dia-a-dia das pessoas e empresas.
Por outro lado, esta tarefa, que se inicia no claro entendimento das necessidades que precisam ser
atendidas e nos resultados a serem alcançados, envolve etapas desde o planejamento estratégico de
TIC, onde a necessidade é identificada e priorizada, a definição da estratégia de atendimento dessa necessidade (contratação de serviços desenvolvimento, licenças de pacotes ou desenvolvimento
próprio), definição dos S&SC adequados, até a sua obtenção e implementação quando, de fato, os
resultados começam a ser obtidos.
Aquisições de S&SC para organizações públicas, além da complexidade típica desse tipo de aquisições, têm que garantir a conformidade legal com a governança de TIC, que envolve também os processos de contratação de serviços. Essa é uma das grandes dificuldades encontradas pelos gestores
de TIC, pois as leis são dispersas e interpretadas e praticadas de forma diferente.
De acordo com [CRUZ, 2008], não há visão integrada do processo de contratação entre as áreas de
TIC, jurídica, administrativa e orçamentária. Há falhas na comunicação, medo das penalidades e ausência de padrões. Cada um dos atores envolvidos conhece a sua área.
O Tribunal de Contas da União (TCU) tem percebido que a TIC é estratégica, que faltam planejamento
institucional e de TIC, governança de TIC, pessoas capacitadas, métodos e processos de contratação,
indicadores e controles internos, como acordos de níveis de serviços, segurança da informação, legalidade e economicidade [CRUZ, 2008].
Neste cenário, o TCU tem recomendado o uso e a divulgação do Quadro Referencial Normativo
(QRN) definido por [CRUZ, 2008], [TCU, 2009] como forma de orientar a Administração Pública e a
82 WAMPS 2009
O Guia de Aquisição do MPS.BR e o Pregão Eletrônico
sociedade sobre as normas que regem as aquisições de bens e serviços de TI, o uso de padrões internacionais como o COBIT, ITIL, ISO/IEC 27000, métricas de estimativa de tamanho como a Análise de
Pontos de Função (APF) e outros padrões nacionais estabelecidos pelas normas da ABNT.
A Instrução Normativa SLTI/MP nº 04/2008 [BRASIL, 2008a] responde a essa recomendação, enfatizando o planejamento estratégico e de TI, a estratégia geral de TI, a responsabilidade da área de
negócio, ressalta o processo de contratação (planejamento, seleção e contratação de fornecedor e a
gestão do contrato, o uso de métricas e avaliação de resultados para evitar dependência danosa).
Tem sido recomendado também que o processo de contratação de serviços seja modelado a partir
da legislação e dos modelos disponíveis na literatura como o COBIT 4.1, eSCM, PMBOK, MPS.BR Guia de aquisição, PrATIco, Gespública e ser alinhado ao Controle e Governança, ao Planejamento
Institucional, ao Planejamento de TIC, ao Planejamento da Contratação e à Gestão Contratual [CRUZ,
2008]. Nesse sentido, há necessidade de personalização de um processo de contratação (por exemplo, como o que consta no Guia de Aquisição:2009 [SOFTEX, 2009]) para contratações de serviços
por entes públicos.
O Guia de Aquisição:2009 [SOFTEX, 2009] é parte do Programa de Melhoria do Processo do Software
Brasileiro (MPS.BR), e complementa os demais guias do Modelo de Referência MPS, proporcionando
um apoio técnico a organizações que adquirem software e serviços correlatos (S&SC). Esse guia de
aquisição tem como referência o Processo de Aquisição da Norma Internacional ISO/IEC 12207:2008
[ISO/IEC, 2008].
O TCU recomenda também que as contratações de serviços de TI, de forma geral, sejam realizadas por
meio de pregão eletrônico (Nota técnica 2/2008, publicada por meio do Acórdão 2471/2008-Plenário)
[TCU, 2008a]. Esta modalidade de licitação está sendo indicada para contratação de todos os bens
e serviços relacionados à TI, a partir do entendimento que estes bens e serviços podem ser perfeitamente definidos ou padronizados, inclusive a maior parte das aquisições de S&SC.
Este artigo aborda a utilização do Guia de Aquisição:2009 em contratações de S&SC por meio de
pregão eletrônico e tem como objetivo destacar as tarefas do processo de aquisição que demandam
cuidados especiais quando aplicadas em pregão eletrônico. As particularidades definidas para as tarefas mencionadas neste artigo foram estabelecidas a partir das situações práticas que ocorrem em
aquisições realizadas por meio de pregão eletrônico e de possíveis respostas que podem ser obtidas
no processo definido no Guia de Aquisição:2009. O resultado apresentado leva em conta a experiência dos autores em projetos de aquisição de S&SC. A seção 2 apresenta alguns fatores a serem
considerados no pregão eletrônico, a seção 3 resume o processo descrito no Guia de Aquisição:2009,
enquanto que a seção 4 indica como o processo de aquisição pode ser utilizado em licitações com
pregão eletrônico. A seção 5 apresenta considerações finais.
2. Aquisição de S&SC por meio de Pregão Eletrônico
De acordo com a Nota Técnica nº 2/2008 [TCU, 2008b] e o Acórdão nº 2.471/2008-TCU-Plenário
[TCU, 2008a], bens e serviços de TI comuns (aqueles que possuem padrões de desempenho e de
qualidade objetivamente definidos pelo edital, com base em especificações usuais de mercado) devem ser obrigatoriamente adquiridos por Pregão, preferencialmente eletrônico. Portanto, encontraWAMPS 2009 83
Artigos aceitos
se derrogada a obrigatoriedade de uso de “técnica e preço” para contratação de bens e serviços de
TI, expressa no § 4° do art. 45 da Lei nº 8.666/1993, porque:
• i) o Decreto 1.070/1994 desobrigou a adoção de “técnica e preço” nas contratações por convite;
• ii) o Decreto 3.555/2000 permitiu o uso de Pregão para bens e serviços de informática comuns;
• iii) a Lei 10.520/2002 permitiu o uso de Pregão para bens e serviços comuns em geral, inclusive
informática; e
• iv) a Lei 11.077/2004 alterou a Lei 8.248/1991 para permitir o uso de Pregão para bens e serviços
comuns de informática.
Considerando-se que o mercado de TI é altamente padronizado e que a complexidade ou criticidade
do objeto não descaracterizam a padronização pela qual a maioria dos bens e serviços de TI são comercializados no mercado, tais bens e serviços podem ser considerados comuns na grande maioria
das vezes. No caso de contratações complexas, deve-se conceder aos licitantes prazos maiores e mais
adequados para a apresentação de suas propostas comerciais, com o fim de obter maior competitividade. A licitação por “técnica e preço” ou “melhor técnica” deve ser realizada somente em casos de
serviços predominantemente intelectuais. A não adoção de Pregão deve ser sempre justificada.
Conforme [CASTRO, 2007], um dos principais objetivos das contratações por meio de pregão eletrônico é a busca pelo aumento da competição nos certames e, por consequência, a redução dos preços
ofertados. A utilização adequada dos recursos públicos, pagando-se o preço justo nas contratações
públicas, é uma real demanda da sociedade brasileira. Por outro lado, esta iniciativa deve estar associada a cuidados específicos, pois o acirramento da concorrência pode aumentar os riscos do empreendimento, à medida que a tentativa de contenção de custos (para equilibrar preços muito baixos
que tenham sido ofertados) pode comprometer seriamente a qualidade final esperada ou, ainda, em
situações extremas, ensejar o cancelamento de contratos em andamento, com sérios prejuízos para
todas as partes envolvidas.
Com base nos artigos 27 a 30 da Lei nº 8.666/1993, na fase de habilitação, além da habilitação jurídica, qualificação econômico-financeira e regularidade fiscal, deve-se exigir a qualificação técnica,
onde é admitida a demonstração de capacidade por meio de atestado de experiência do fornecedor
na realização dos serviços compatíveis com o objeto estabelecido no termo de referência.
Não há sustentação legal para a exigência de certificações na fase de habilitação, porém é possível
exigir que a execução do contrato obedeça ao nível de maturidade de processo estabelecido no termo de referência, para fins de aceitação dos produtos entregues. Além disso, caso absolutamente
necessária a prova de aderência a nível de maturidade de processo preestabelecido, tal exigência
pode estar entre os requisitos para assinatura do contrato, dando-se o prazo suficiente para que o
fornecedor obtenha junto a entidades avaliadoras tal prova de aderência. Caso o fornecedor vencedor do pregão não comprove tal aderência exigida para assinatura do contrato, será desclassificado,
convocando-se sucessivamente os demais classificados, pela ordem de preço.
Segundo [CRUZ, 2009], o termo de referência deve descrever de forma clara alguns pontos importantes, tais como:
84 WAMPS 2009
O Guia de Aquisição do MPS.BR e o Pregão Eletrônico
• i) o processo padrão de desenvolvimento de software e os de gestão a serem adotados durante
o desenvolvimento do projeto (por exemplo, os processos do Modelo de Referência MPS, estabelecidos até o nível F, por serem compatíveis com as normas ABNT NBR ISO/IEC 12.207, 15.504,
25.000);
• ii) a forma de pagamento, que deverá ser condicionada à entrega dos artefatos previstos no processo de desenvolvimento de software proposto;
• iii) a justificativa de adotar o rigor proposto com base, por exemplo, nas diretrizes do Programa
Brasileiro de Qualidade de Software (PBQP-SW), na Lei nº 7.232/1984, na Lei nº 8.078/1990, na
Lei nº 8.666/1993, na Estratégia Geral de TI (EGTI) estabelecida pelo MP/SLTI (que priorizou qualidade de software) e no Acórdão nº 1.603/2008-TCU-Plenário;
• iv) o modelo de gestão do contrato que não permita que o fornecedor receba o pagamento se
não entregar serviços com a qualidade desejada;
• v) os mecanismos de controle de qualidade que permitam rescindir o contrato rapidamente, caso o fornecedor não atenda os critérios de qualidade e ou de aceitação de artefatos e código
definidos;
• vi) os mecanismos que garantam que o fornecedor fique alerta constantemente quanto à qualidade dos serviços (níveis de serviço bem gerenciados);
• vii) os mecanismos necessários para que a empresa entenda que, se contratar mão-de-obra desqualificada, ela não somente deixará de receber o pagamento como também irá pagar multas e
comprometer sua imagem no mercado; e
• viii) os mecanismos para avaliar a capacidade do fornecedor durante o controle pelos órgãos
competentes e em conformidade com o Método de Avaliação estabelecido na ABNT NBR ISO/IEC
15504-2.
É muito importante ressaltar que, ao definir o modelo de gestão a ser adotado durante o contrato,
a organização contratante especifique os requisitos de controle de acordo com a sua capacidade de
gerenciar, verificar e validar os artefatos a serem entregues pelo fornecedor. Ou seja, por exemplo,
não é prudente exigir os resultados esperados dos processos do nível A do modelo de referência MPS,
se a organização não tem esse nível de maturidade. Nesse caso, a organização paga mais caro e não
garante o resultado estabelecido no contrato.
Recomenda-se, portanto, que a organização contratante defina e implante formalmente os principais processos de governança e os de Engenharia de Software que, ao serem implementados por
uma equipe capacitada, vão garantir a qualidade necessária dos resultados esperados pelos serviços
contratados. Caso isso não seja possível em curto prazo, deve-se contratar outro fornecedor para
verificar e validar a qualidade dos serviços e dos artefatos entregues pelo primeiro fornecedor.
WAMPS 2009 85
Artigos aceitos
3. Processo de aquisição do MPS.BR
O Processo de Aquisição do MPS.BR é composto por quatro atividades: Preparação da Aquisição,
Seleção do Fornecedor, Monitoração do Contrato e Aceitação pelo Cliente (ver Figura 1). O Guia de
Aquisição detalha cada atividade em termos de tarefas, em conformidade com a norma internacional
ISO/IEC 12207:2008.
Figura 1 - Processo de Aquisição MPS.BR
O Guia de Aquisição:2009 é baseado no Processo de Aquisição da ISO/IEC 12207:2008, um dos
processos fundamentais do ciclo de vida de software. A abordagem adotada pelo MPS.BR , que detalha este processo, permite a melhoria dos resultados de instituições que pretendam adquirir S&SC
e contribui com o objetivo fundamental do MPS.BR, que visa melhorar os processos de software
das organizações brasileiras, à medida que estabelece requisitos rigorosos sob o ponto de vista das
instituições adquirentes. As atividades devem ser planejadas e executadas levando-se em conta o
processo que deve ser personalizado considerando-se as especificidades da organização adquirente
e do tipo de aquisição a ser efetuada.
4. Utilização do processo de aquisição MPS em Pregão Eletrônico
4.1. Visão geral
A aquisição de S&SC por meio de pregão eletrônico, além dos seus aspectos de possível agilidade e
ampliação da concorrência, que pode levar à obtenção de preços mais favoráveis ao adquirente, introduz alguns fatores de riscos ao projeto de aquisição, que são decorrentes das características deste
certame, conforme apresentadas na seção 2.
86 WAMPS 2009
O Guia de Aquisição do MPS.BR e o Pregão Eletrônico
Os tópicos a seguir apresentam como as atividades e tarefas descritas no Guia de Aquisição:2009
podem ser adaptadas para mitigar os riscos decorrentes de uma aquisição de S&SC, por meio de
pregão eletrônico e obter melhores resultados. Foram destacadas apenas as atividades e tarefas do
guia que requeiram alguma adaptação ou interpretação específica para o caso de aquisições de S&SC
por meio de pregão eletrônico.
4.2. Preparação da aquisição
4.2.1. Estabelecer a necessidade
A especificação das necessidades da organização a serem atendidas por um projeto é a base para
todo o processo de derivação de requisitos. No caso de aquisições por meio de pregão eletrônico,
onde os requisitos a serem considerados são todos classificados como obrigatórios para o certame, o
entendimento e especificação das necessidades tornam-se fundamentais para estabelecer um equilíbrio com os custos previstos para o contrato.
4.2.2. Definir os requisitos
A definição dos requisitos precisará levar em conta que todos os requisitos a serem contemplados
no certame são de natureza obrigatória. Esses requisitos podem ser identificados considerando-se os
seguintes passos:
• i) definir os requisitos essenciais que assegurem que o S&SC atenda às necessidades
estabelecidas;
• ii) identificar requisitos desejáveis, que complementem os requisitos obrigatórios em relação à
redução do risco do projeto; à melhoria do desempenho do projeto ou dos resultados esperados;
à melhoria da qualidade em uso da solução conforme as características de eficácia, produtividade,
segurança na realização das tarefas e satisfação dos usuários envolvidos (NBR ISO/IEC 9126-1 em
[ABNT, 2003]); e à ampliação dos contextos de uso da solução;
• iii) analisar os requisitos identificados como desejáveis, classificando-os como dispensáveis ou
obrigatórios;
• iv) considerar os impactos da seleção dos requisitos em custos, esforço e prazo na licitação; e
• v) identificar os requisitos de projeto, como a tecnologia, ciclo de vida de desenvolvimento, processos a serem adotados, artefatos a serem produzidos, entre outros, e analisar se alguns destes
requisitos podem ser utilizados como fatores para habilitação técnica dos proponentes (como, por
exemplo, a comprovação de experiência na adoção de uma determinada tecnologia).
4.2.3. Desenvolver uma estratégia de aquisição
Os principais aspectos a serem contemplados no plano de aquisição para licitações por meio de pregão eletrônico estão relacionados na Tabela 1.
WAMPS 2009 87
Artigos aceitos
Tabela 1 – Aspectos a considerar no plano de aquisição
Termos contratuais: A seleção do tipo de contrato a ser adotado deve considerar que o fornecedor
pode ter que atuar sob preços bastante comprimidos durante o pregão. Neste caso, para viabilizar o seu
contrato, o fornecedor poderá tentar impor barreiras a quaisquer fatores que possam lhe pressionar os
custos. Se o contrato for por preço definido, deve-se assegurar que os requisitos são estáveis e que sua
especificação seja clara, evitando-se retrabalho ou que o esforço para a execução do contrato tenha sido
subestimado. Para contratos realizados por dimensão funcional, como o preço informado refere-se a
valores unitários, tem-se maior flexibilidade com relação ao escopo, porém se os valores unitários forem
comprimidos, qualquer esforço adicional demandado para cumprir com as funções previstas será objeto de
difíceis negociações entre as partes.
Multas contratuais: Utilizar as multas como instrumentos de gestão, principalmente para amparar a
tomada de medidas corretivas ao longo do contrato, visando à retomada de situação de normalidade ou,
em casos extremos, o rompimento do contrato quando ficar evidenciada a impossibilidade do fornecedor
atingir os objetivos contratados.
Garantia: Especificar claramente os níveis de serviços a serem cobertos pela garantia, de modo que os
proponentes possam avaliar os custos e recursos necessários para cumprir com o estabelecido, formulando
uma proposta de preços compatível.
Termos financeiros: Considerar, na definição dos valores envolvidos no contrato, os requisitos definidos
como obrigatórios, as condições gerais de prestação de serviços e o eventual impacto causado por
requisitos estabelecidos na qualificação técnica dos proponentes. A programação de pagamento deverá
estar associada a entregas parciais que permitam a monitoração do contrato, possibilitando a utilização do
pagamento como instrumento para manter a normalidade da sua execução.
Termos técnicos: Definir os procedimentos de tratamento de mudanças e de problemas, pois fatores de
compressão de preços podem causar muita reação do fornecedor na ocorrência desses eventos.
Lista de S&SC a serem entregues: Solicitar apenas os artefatos efetivamente necessários, a serem
entregues durante a execução do contrato.
Pontos de controle: A definição de marcos de controle deve ser utilizada como um instrumento
complementar de gestão do contrato visando identificar situações de crises.
Prazos estabelecidos: Apresentar um plano de projeto com especificação das tarefas, responsabilidades,
resultados, prazos e os marcos de controle estabelecidos.
Critérios de seleção do fornecedor: Poderão ser utilizados critérios técnicos de habilitação, em conjunto
com a definição de requisitos obrigatórios para a seleção do fornecedor.
Critérios de aceitação do S&SC: A aplicação de critérios de aceitação em produtos intermediários reduz
a quantidade de não-conformidades identificadas ao final do projeto. Em situações de baixa rentabilidade
do contrato, as negociações para implementação de melhorias e até mesmo de correções podem ser
bastante complexas.
Normas e modelos: A utilização de normas nacionais e internacionais ou padrões internos adotados
pela organização contratante, que sejam divulgados durante o certame, podem facilitar a compreensão de
requisitos estabelecidos por estas normas e padrões.
Responsabilidades do projeto: Definir responsabilidades do gerente do contrato e do projeto, tais como
quanto à monitoração, contratações intermediárias (por exemplo, quando utilizando ordens de serviço),
gestão de mudanças e problemas e para a aceitação.
Riscos e eventos: Identificar, analisar, mitigar e tomar ações de contingência dos riscos envolvidos,
principalmente quando se tratar de contratação de software sob encomenda ou com escopo aberto.
88 WAMPS 2009
O Guia de Aquisição do MPS.BR e o Pregão Eletrônico
Plano de testes de aceitação: Elaborar o plano de testes de aceitação visando identificar, o mais cedo
possível, problemas nos produtos e serviços entregues. A abordagem a ser adotada deverá considerar o
plano e a execução dos testes do fornecedor, que deverá prover resultados com um nível satisfatório de
qualidade, a ser confirmado nos testes complementares do adquirente.
Pedido de proposta: A proposta de preços devem ser definida de forma compatível com o escopo e
requisitos estabelecidos. Um trabalho de revisão do pedido de proposta pode ser um instrumento valioso
para aprimorar o resultado final.
4.3. Monitoração do contrato
A atividade de monitoração do contrato é crítica em projetos que apresentem riscos de aquisições
por meio de pregão eletrônico. A execução adequada de suas tarefas pode ser o diferencial para o
sucesso do empreendimento de aquisição de S&SC.
4.3.1. Revisar o desempenho do fornecedor
A execução desta tarefa, durante os marcos de projeto, deverá ser feita por meio de medidas, obtidas
no desenvolvimento do projeto, de modo a caracterizar o nível de serviço obtido e prever o resultado
final a ser atingido. Esta análise, que envolve aspectos técnicos, de qualidade, custos e prazos, possibilitará a tomada de ações gerenciais para reordenamento do projeto, quando for o caso.
4.3.2. Monitorar a aquisição
A tarefa de monitoração contínua do contrato é de responsabilidade típica do gerente de projeto e
envolve o acompanhamento das tarefas de revisão do desempenho do fornecedor durante os marcos, da entrega de produtos e qualidade obtida, dos desvios em relação aos prazos e custos, de nãoconformidades em relação ao processo de desenvolvimento estabelecido, dos níveis de retrabalho,
entre outros aspectos.
4.3.3. Obter acordo quanto às alterações
A pressão para redução de custos pode tornar bastante complexa a tarefa de negociar alterações
em requisitos. Portanto, antes da negociação com o fornecedor, as alterações deverão ser avaliadas
quanto aos aspectos de importância, prioridade e impacto e deverão ser sempre formalizadas, para
que o processo seja gerenciável pelas partes.
4.3.4. Acompanhar problemas
A solução de problemas pode ser um fator de conflitos, à medida que o adquirente venha a pressionar para que as correções ocorram no menor prazo possível, considerando-se que, para o fornecedor,
problemas significam custos adicionais e retrabalho.
WAMPS 2009 89
Artigos aceitos
4.4. Aceitação pelo cliente
O plano deve ser seguido com o rigor necessário, mantendo-se a formalidade prevista, mesmo frente
a eventuais contingências de projeto que podem pressionar para que as ações e os critérios sejam
mais flexíveis.
5. Conclusão
O processo descrito no Guia de Aquisição do MPS.BR visa propiciar aos seus usuários melhores resultados na aquisição de S&SC, com produtos de melhor qualidade e dentro de prazos e orçamentos
esperados, levando em conta as características da organização adquirente. A adoção deste processo
exige sua personalização ao contexto organizacional e às peculiaridades de cada projeto de aquisição. No caso de licitações por meio de pregão eletrônico, observa-se que, em muitos casos, são
introduzidos alguns fatores adicionais de risco que precisam ser considerados para que se obtenha
sucesso na aquisição.
Este artigo apresentou os principais aspectos que devem ser considerados na aplicação do Guia de
Aquisição do MPS.BR para aquisições de S&SC efetuadas por meio de pregão eletrônico, visando o
sucesso destes empreendimentos.
6. Referências bibliográficas
[ABNT, 2003] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 9126-1:2003 Engenharia de software - Qualidade de produto - Parte 1: Modelo de qualidade. Rio de Janeiro:
ABNT, 2003.
[BRASIL, 1993] Lei n° 8.666, de 21 de junho de 1993. Disponível em: www.planalto.gov.br/ccivil_03/
Leis/L8666cons.htm.
[BRASIL, 2008a] MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO. SECRETARIA DE
LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO. Instrução Normativa SLTI n° 4, de 19 de maio de
2008. Brasília, 2008.
[BRASIL, 2008b] MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO. SECRETARIA DE
LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO. Portaria n° 11, de 30 de dezembro de 2008. Aprova
a Estratégia Geral de Tecnologia da Informação (EGTI) no âmbito do Sistema de Administração
dos Recursos de Informação e Informática - SISP. Brasília: Diário Oficial da União, 2008.
[CASTRO, 2007] CASTRO, Adriana Mendes Oliveira de. Desburocratização e pregão eletrônico. IN:
Ministério do Planejamento, Orçamento e Gestão. Secretaria de Gestão. Programa Nacional de Gestão
Pública e Desburocratização – GESPÚBLICA. Cadernos GESPÚBLICA – Desburocratização. Brasília,
2007. Disponível em: www.gespublica.gov.br/menu_principal/folder.2007-04-04.1517049614/
publicacaoes/file.2007-06-08.0924936016. Acessado em: 18/08/2009.
90 WAMPS 2009
O Guia de Aquisição do MPS.BR e o Pregão Eletrônico
[CRUZ, 2008] CRUZ, Cláudio Silva da. Governança de TI e conformidade legal no setor público:
um quadro referencial normativo para a contratação de serviços de TI, Dissertação de mestrado.
Brasília, 2008.
[CRUZ, 2009] CRUZ, Cláudio Silva da. Curso de planejamento de contratações de serviços de TI.
Programa de capacitação dos integrantes do SISP. Brasília, 2009.
[ISO/IEC, 2008] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE
INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 12207:2008 – Systems and software
engineering – Software life cycle processes. Geneve: ISO, 2008.
[TCU, 2008a] TRIBUNAL DE CONTAS DA UNIÃO - Acórdão 2471/2008 - Plenário. Disponível em:
http://contas.tcu.gov.br.
[TCU, 2008b] TRIBUNAL DE CONTAS DA UNIÃO – Nota Técnica Sefti nº 2/2008. Disponível em: http://
portal2.tcu.gov.br/portal/page/portal/TCU/comunidades/tecnologia_informacao/notas_tecnicas/
notas_tecnicas_aprovadas
[TCU, 2009]. TRIBUNAL DE CONTAS DA UNIÃO. Acórdão 1215/2009 - Plenário. Disponível em: http://
contas.tcu.gov.br.
[SOFTEX, 2009] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX MPS.BR – Guia de Aquisição:2009. Disponível em www.softex.br/mpsbr.
WAMPS 2009 91
Artigos aceitos
Comparação entre a Instrução Normativa SLTI/
MP nº 04 e o Guia de Aquisição do MPS.BR
Eric Robert Gillis1, Edméia Leonor Pereira de Andrade2
[email protected], [email protected]
UCB – Universidade Católica de Brasília
EMBRAPA – Empresa Brasileira de Pesquisa Agropecuária
1
2
Resumo. Este artigo analisa a Instrução Normativa SLTI/MP nº 04 de 19 de Maio de 2008, que dispõe sobre o
processo de contratação de Serviços de Tecnologia da Informação pela Administração Pública Federal Brasileira
(APF), e a compara com o Processo de Aquisição do Programa de Melhoria do Processo de Software Brasileiro
(MPS.BR), descrito em seu Guia de Aquisição. Ele identifica possibilidades de melhoria relacionadas com a sistematização da estrutura do Processo de Aquisição do MPS.BR.
1. Introdução
Diversos riscos vêm sendo percebidos na terceirização de serviços de TI no setor público entre eles:
dependência de fornecedor; descontinuidade tecnológica; dificuldade com a definição do escopo
dos serviços; falta de compreensão do negócio pelos contratados; dificuldade em manter a qualidade
dos serviços; risco quanto à segurança das informações de negócio; perda de controle dos custos do
contrato; resultando em aumento de acórdãos do Tribunal de Contas da União (TCU) relacionados a
contratações de TI [Cruz, 2008].
Os Acórdãos 786 [Brasil, 2006] e 1.480 [Brasil, 2007] do TCU firmaram a decisão de recomendar à
Secretaria de Logística e Tecnologia da Informação (SLTI) do Ministério do Planejamento, Orçamento
e Gestão (MP) a elaboração de um modelo de licitação e contratação de serviços de Tecnologia da
Informação (TI) para a Administração Pública Federal (APF). Adicionalmente, faz parte do conjunto
de recomendações do Acórdão 1.480 [Brasil, 2007], a utilização de diversos modelos reconhecidos
internacionalmente como subsídio para a elaboração do modelo de contratação de serviços de TI,
entre eles o MPS.BR.
Em resposta surgiu a Instrução Normativa nº 4 (IN 4), publicada em maio de 2008, dispondo sobre
o processo de contratação de serviços de TI pela Administração Pública Federal direta, autárquica e
fundacional. Além de vedar algumas formas de contratação contrárias aos princípios administrativos
de licitações, e estabelecer elementos estratégicos para planejamento de TI na APF, este documento
estabeleceu um processo de contratação de serviços de TI [Brasil, 2008].
Este artigo, resumo do trabalho de conclusão de curso de pós-graduação em Engenharia de Software
pela Universidade Católica de Brasília, tem por objetivo analisar de que forma o processo descrito no
Guia de Aquisição do MPS.BR está representado na IN 4 avaliando os seguintes fatores: i) a equivalência do campo de aplicação; ii) a extensão dos processos; iii) a estruturação das tarefas; e iv) o conteúdo das duas fases do processo da IN 4 analisadas neste artigo com relação às atividades do pro-
92 WAMPS 2009
Comparação entre a Instrução Normativa SLTI/MP nº 04 e o Guia de Aquisição do MPS.BR
cesso do Guia de Aquisição. Espera-se como resultado delinear algumas sugestões para enriquecer o
diálogo em torno do aperfeiçoamento da aquisição de software para a APF.
A próxima seção apresenta o processo da IN 4 já com um esforço por interpretar seus principais elementos. Na terceira seção é apresentado, resumidamente, o processo do Guia de Aquisição do MPS.
BR. Em seguida, na quarta seção, busca-se comparar os modelos.
2. O processo de aquisição da IN 4
2.1. A abrangência do conceito de serviços de TI
A ementa da IN 4 abrange a contratação de todos os serviços de TI. A variedade dos serviços deve
ser entendida não apenas quanto às grandes divisões de serviços que podem ser executados, mas
também em relação ao momento do ciclo de vida em que uma determinada solução de TI se encontra, ou ainda na subdivisão de processos que venha ser utilizada para desmembrar a prestação de
um serviço, como por exemplo, a estrutura de processos da ISO/IEC 12.207 [2008]. Pode-se observar
por fim que produtos — e outros elementos não explicitamente declarados — não estão excluídos
do campo de aplicação desta Instrução Normativa, caso sua obtenção esteja vinculada à prestação
de um serviço.
2.2. Ciclo de vida do processo de aquisição
As tarefas do processo são organizadas em três fases bem definidas que transcorrem seqüencialmente, tais como: Planejamento da contratação, Seleção do Fornecedor, e Gerenciamento do Contrato.
Observa-se que as exigências estabelecidas na IN 4 restringem-se à primeira e à última fase, já que
a segunda fase, Seleção do Fornecedor possui extensa regulamentação legal e jurisprudência como
demonstra o Quadro Referencial Normativo [Cruz, 2008].
2.3. Planejamento da contratação
A redação da IN 4 denomina as subdivisões da fase de Planejamento de etapas. Esta designação também demonstra uma preocupação com a organização das tarefas ao longo do tempo. As quatro etapas elencadas explicitamente pela IN 4 são: Análise de Viabilidade, Plano de Sustentação, Estratégia
de Contratação, e Análise de Riscos. Algumas tarefas são identificadas tais como:. i) elaborar o Termo
de Referência, que é imprescindível e deve ocorrer após a conclusão da etapa de Análise de Riscos; ii)
realização de Consulta Pública, que é opcional e deve ser realizada no final da fase.
2.3.1. Análise de Viabilidade
A Análise de Viabilidade inicia com a avaliação da necessidade da organização e a explicitação da
justificativa para a contratação, conforme definida no Plano Diretor de Tecnologia da Informação,
também estabelecido na IN 4. Em uma situação de vigência integral destes instrumentos, a avaliação
da necessidade e a explicitação da justificativa da contratação consistem em uma reafirmação dos
WAMPS 2009 93
Artigos aceitos
argumentos que levaram a organização a incluir e priorizar uma determinada necessidade no PDTI,
conforme descrito na IN 4, art. 4, parágrafo único, inciso III [Brasil, 2008].
A avaliação da necessidade parte do conhecimento prévio – obtido durante a elaboração do PDTI –
da lista dos envolvidos e de sua manifestação com relação à solução a ser adquirida. Neste sentido
esta primeira etapa contribui em rever a posição de todos os envolvidos e reafirmar seu compromisso
com a continuidade da aquisição da solução de TI, e com sua contribuição com as tarefas que exigem
seu envolvimento, entre elas a especificação de requisitos que é a próxima tarefa do processo exigido
pela IN 4.
A especificação dos requisitos é uma tarefa de natureza bastante ampla, contudo, não há uma definição explícita para ‘Especificação de Requisitos’. A IN 4 limita-se a conceituar ‘Requisitos’ como
sendo o “conjunto de especificações necessárias para definir a solução de TI” e em listar os tipos de
requisitos e as responsabilidades pela definição dos mesmos.
Após a especificação de requisitos, completam a análise de viabilidade, as tarefas de identificação de
soluções possíveis e a escolha fundamentada da solução. A área de TI, com apoio do requisitante do
serviço no levantamento de alternativas é a responsável pela justificativa da solução escolhida.
2.3.2. Plano de Sustentação
Novamente não há uma definição explícita para esta etapa, tarefas, e nem de seu objetivo. Observase que esse plano deverá ser considerado durante a execução e encerramento do contrato e que a
responsabilidade para sua elaboração pertence à área de TI, que conta com o apoio do requisitante
do serviço. Os elementos a serem considerados no Plano de Sustentação são: segurança da informação; recursos materiais e humanos; transferência de conhecimento; transição contratual; e continuidade dos serviços em eventual interrupção contratual.
2.3.3. Estratégia da Contratação
A etapa da Estratégia de Contratação destina-se à avaliação sobre questões de natureza técnicas, comerciais, jurídicas, orçamentárias, financeiras e econômicas a fim de viabilizar a contratação. São definidos os tipos de serviços, os termos contratuais, cronograma entre outros tópicos listados na IN 4.
Dentre os quesitos de natureza técnica encontram-se: a definição de procedimentos e de critérios
de mensuração dos serviços prestados, abrangendo métricas, indicadores e valores; definição de
metodologia de avaliação da adequação às especificações funcionais e da qualidade dos serviços;
quantificação ou estimativa prévia do volume de serviços demandados, para comparação e controle;
e critérios técnicos de julgamento da proposta para a fase de Seleção do Fornecedor.
Destacam-se, ainda, como prerrogativas da área de TI, a indicação do Gestor do Contrato, que será
responsável por boa parte das tarefas subseqüentes, e a elaboração de uma estratégia de independência em relação à contratada.
2.3.4. Análise de Risco
A Análise de Risco é a primeira responsabilidade do Gestor do Contrato. Esta etapa consiste na caracterização de riscos, de forma diferenciada pelo ciclo de vida da contratação, e na definição de ações
94 WAMPS 2009
Comparação entre a Instrução Normativa SLTI/MP nº 04 e o Guia de Aquisição do MPS.BR
relacionadas a serem tomadas. Envolvem aspectos relativos à conclusão bem sucedida da contratação e a qualidade esperada do serviço ou produto.
Além da descrição do risco em si, estão inseridas avaliações relativas à probabilidade de ocorrência do
risco e ao dano sobre as atividades dos órgãos ou entidades da APF, caso efetivamente ocorram. As
ações a serem tomadas para prevenir a ocorrência do risco, a contingência caso o risco se concretize
e os seus responsáveis devem ser definidas.
2.3.5. Termo de referência e Consulta Pública
O Termo de Referência ou Projeto Básico, nova responsabilidade do Gestor do Contrato, não se encaixa em nenhumas das etapas explicitamente definidas na IN 4. Trata-se de um elemento indispensável para a fase de Seleção do Fornecedor. A Instrução Normativa nº 2 (IN 2) [2008], que se aplica
subsidiariamente às contratações de que trata a IN 4, define o Termo de Referência ou Projeto Básico
como “o documento que deverá conter os elementos técnicos capazes de propiciar a avaliação do
custo, pela administração, com a contratação e os elementos técnicos necessários e suficientes, com
nível de precisão adequado para caracterizar o serviço a ser contratado e orientar a execução e fiscalização contratual”.
A Consulta Pública, por sua vez, consiste em uma opção do Requisitante do Serviço com vistas a
“avaliar a completude e a coerência da especificação dos requisitos e a adequação e a exeqüibilidade
dos critérios de aceitação”.
2.4. Descrição da fase de Seleção do Fornecedor
A fase de Seleção do Fornecedor, como mencionado, não recebe nenhuma orientação na IN 4, que
apenas remete o leitor para outros textos legais pertinentes. A seleção dependerá, portanto, do tipo
de serviço a ser contratado, da legislação e das normas internas da organização.
2.5. Descrição da fase de Gerenciamento do Contrato
O objetivo desta última fase do processo de contratação de serviços de TI está definido no texto,
como, “acompanhar e garantir a adequada prestação dos serviços durante todo o período de execução do contrato”. Nesta fase as tarefas são agrupadas em quatro incisos sem uma denominação específica. Dois incisos referem-se ao momento em que as tarefas ocorrem, como, Início do
Contrato e Encerramento e Transição Contratual. Outro inciso detalha uma tarefa específica, como,
o Encaminhamento de Demandas, passível de ocorrer diversas vezes ao longo da execução do contrato. O último inciso trata do Monitoramento da Execução e contém uma relação de tarefas sem
detalhamento.
Percebem-se níveis variados de definição das tarefas. Algumas possuem natureza bastante ampla
(verificação da aderência às normas do contrato, verificação da manutenção das condições classificatórias, pontuadas e da habilitação técnica; manutenção do Plano de Sustentação, por exemplo),
permitindo interpretação diferenciada ou até certa sobreposição. Outras tarefas são bastante específicas (reunião inicial, comunicação às autoridades competentes sobre a proximidade do término do
contrato, ateste, por exemplo).
WAMPS 2009 95
Artigos aceitos
Outros elementos que caracterizam a estruturação desta fase e a diferenciam em relação à fase de
Planejamento da Contratação são: o menor detalhamento das tarefas e a ausência de descrição das
saídas, exceto pela descrição do Encaminhamento de Demandas. Além disso, há uma preocupação
em definir o objetivo da fase de Gerenciamento do Contrato que não existe nas demais fases.
Nota-se que há descontinuidade do tratamento de questões de natureza mais técnica e gerencial
iniciadas na Fase de Planejamento da Contratação. Isto pode ser observado nas tarefas de gestão
de requisitos e análise de riscos, que não encontram continuidade na fase de Gerenciamento do
Contrato. Excetua-se, porém, o Plano de Manutenção que deve ser observado ao longo da execução
do contrato e no seu encerramento.
A IN 4 exige o registro de todas as ocorrências da execução do contrato, porém não há descrição
suficiente da documentação gerada em cada tarefa. O único documento descrito em detalhes é a
demanda de correções. Outros documentos são citados, sem descrição ou conceituação, no nome
da tarefa (aditivos, pedidos de modificação contratual, glosas e sanções). Várias tarefas, no entanto,
não possuem qualquer forma de documentação ou instrumentos utilizados em sua realização, por
exemplo: Verificação da aderência às normas do contrato, Verificação da manutenção da necessidade, economicidade e oportunidade da contratação, Verificação da manutenção das condições classificatórias, pontuadas e da habilitação técnica e Manutenção do Plano de Sustentação.
3. O processo de aquisição do MPS.BR
3.1. Aplicação do Guia de Aquisição
O Guia de Aquisição tem como propósito obter Software e Serviços Correlatos (S&SC) que satisfaçam
a necessidade expressa pelo cliente [SOFTEX, 2009]. Este processo inicia com a identificação da necessidade do cliente e encerra com a aceitação do produto ou serviço.
3.2. O Processo de aquisição
O Guia de Aquisição inicia a descrição do seu processo de aquisição com a apresentação de sete resultados que devem ser alcançados após a implementação bem-sucedida do processo. A estes itens
apresentados no Guia de Aquisição, podem-se acrescentar os resultados esperados descritos no Guia
Geral.
O processo de aquisição do MPS.BR divide-se em 18 tarefas distribuídas por 4 atividades. Cada
atividade é descrita com um objetivo e suas tarefas, as quais são estruturadas de forma sistemática
mediante descrição da tarefa, produtos requeridos e gerados e relacionamento com demais processos do MR-MPS. Cada produto, tanto os requeridos como os gerados, são descritos individualmente.
Adicionalmente o MPS.BR aponta para diversos vínculos com processos de garantia da qualidade,
verificação, validação e medição. Trata-se de processos amplamente aplicáveis a todas as atividades.
96 WAMPS 2009
Comparação entre a Instrução Normativa SLTI/MP nº 04 e o Guia de Aquisição do MPS.BR
3.3. Atividades
O Guia de Aquisição define a Preparação da Aquisição como primeira atividade de seu processo
deaquisição. A escolha da organização responsável pelo software ou serviço correlato é o resultado da atividade Seleção do Fornecedor. O conjunto de atividades do modelo é completado pela
Monitoração do Fornecedor e pela Aceitação do Software pelo Cliente.
4. Comparação entre a IN 4 e o Processo de Aquisição do MPS.BR
Antes de iniciar qualquer comparação entre estes processos, é necessário considerar que o Guia de
Aquisição define um processo genérico, enquanto a IN 4 estabelece um processo com regras específicas para implementação no âmbito da APF, embora aplicável a um grande e variado número de
órgãos e entidades. Por este motivo a IN 4 define regras e vedações específicas às necessidades da
APF e que não fazem sentido para o MPS.BR. Além disso, alguns itens da IN 4 abordam tarefas em
nível de detalhes maior que o Guia de Aquisição do MPS.BR, descrevendo itens específicos a serem
incluídos na produção dos documentos. Por esta mesma razão, a IN 4 atribui responsabilidades a
atores, fato que está ausente do processo do MPS.BR pela natureza genérica deste. Tal ajuste ou customização será necessário para qualquer organização que queira implementar um processo baseado
em um modelo genérico.
4.1. Equivalência do campo de aplicação
O campo de aplicação da IN 4 é mais abrangente que aquele definido pelo Guia de Aquisição do
MPS.BR. Este último se refere especificamente a Software e Serviços Correlatos identificados como
seu desenvolvimento, operação e manutenção; ao passo que a IN 4 refere genericamente a serviços
de TI. A restrição de aplicação do Guia de Aquisição a Software permite o questionamento sobre
a aplicabilidade do processo da IN 4 a serviços de TI que ultrapassam a questões relacionadas a
Software. Tal questionamento, em especial a adequação para fins de governança de um processo genérico para todos os serviços de TI, deverá ser avaliado em outros estudos a partir de uma taxonomia
detalhada de serviços de TI.
O Guia de Aquisição é explícito quanto a sua aplicabilidade aos produtos de Software. Na IN 4 os
produtos de software estão vinculados indiretamente a uma solução de TI. A utilização do termo
serviços no título da Instrução Normativa aponta para o fato de que produtos como máquinas,
equipamentos, softwares constituem parte de uma solução acessível a partir de um serviço prestado.
Deve ser destacado, porém, que ambos tem como preocupação básica estabelecer um conjunto organizado de tarefas com o objetivo de adquirir software, ou serviço de TI, adequado aos objetivos e
restrições organizacionais.
4.2. Extensão do processo
A IN 4 preocupa-se em vincular o processo de contratação a um esforço que vai além de uma contratação específica, isto é, um contexto maior de governança de TI e a instrumentos de planejamento
institucional de TI, notadamente o PDTI, que não encontra equivalência no MPS.BR.
WAMPS 2009 97
Artigos aceitos
No entanto, o processo de contratação de serviços da IN 4 inicia com a avaliação da necessidade da
organização e com a explicitação da motivação para a contratação de forma similar ao processo do
Guia de Aquisição do MPS.BR. Nota-se que ambas as propostas possuem elementos de apoio a um
negócio específico entre adquirente e fornecedor. Neste sentido tem por objetivo básico definir com
clareza todos os elementos necessários para uma colaboração bem sucedida de parceiros em uma
determinada empreitada, e busca, naturalmente, o alcance de resultados satisfatórios na conclusão
da prestação de um serviço específico.
4.3. Estruturação dos processos
O Guia de Aquisição do MPS.BR apresenta maior sistematização da estrutura do modelo, maior rigor
na caracterização de tarefas e na conceituação dos seus diversos elementos e está em conformidade
com referências nacionais e internacionais para definição de processos de software. A IN 4, por sua
vez, estabelece formas de estruturação de fases diferenciadas e deixa algumas lacunas na conceituação de tarefas, entradas e documentos.
Vale ressaltar, porém, que a forma de agrupamento de tarefas na IN 4 é baseada em fases, e não em
atividades como no MPS.BR, que segue as recomendações da ISO/IEC 12.207 [ISO/IEC, 2008]. Não
se trata de uma divergência significativa, pois a essência do processo está no conteúdo das tarefas e
na consecução dos objetivos, os quais podem ser verificados em suas saídas.
Há também uma preocupação do Guia de Aquisição em identificar sistematicamente os objetivos
que norteiam a condução do processo e de cada atividade. Tal fato torna-se importante pela formação de critérios para a avaliação gerencial do progresso dos projetos, e, conseqüentemente, por
garantir os resultados esperados do processo.
Vale citar, finalmente, que o Guia de Aquisição possui um conjunto de documentação de apoio,
bem definida como resultado da estruturação de processos sistemática que impõe a explicitação dos
produtos gerados.
4.4. Comparação do conteúdo das fases
As diferenças descritas acima implicam normalmente em uma maior abrangência e precisão das
exigências das tarefas do Guia de Aquisição do MPS.BR. Além disso, percebe-se continuidade maior
entre as fases nas questões de natureza técnica e gerencial, notadamente na gestão de requisitos e
riscos. O agrupamento por atividade do MPS.BR pode facilitar a continuidade de ações ao longo do
processo de aquisição, uma vez que suas tarefas não estão limitadas a um período delimitado da
contratação.
4.4.1. Planejamento da Contratação
A Análise de Viabilidade na IN 4 define algumas consultas obrigatórias para escolha da solução, com
vistas a evitar duplicidade de esforços no âmbito da APF e a elaboração de soluções já disponíveis
por meio de software livre. Preocupa-se igualmente em estabelecer o uso de padrões de interoperabilidade e acessibilidade.
98 WAMPS 2009
Comparação entre a Instrução Normativa SLTI/MP nº 04 e o Guia de Aquisição do MPS.BR
No contexto das tarefas relacionadas à especificação de requisitos, a tarefa é muito mais detalhada
no MPS.BR. A explicitação na IN 4 dos requisitos funcionais e não funcionais a serem considerados
e a definição da responsabilidade por sua formulação são apenas parte das recomendações do Guia
de Aquisição, que ainda procura zelar por sua adequação para a execução de testes e aceitação e
coerência com necessidades e restrições organizacionais e em conformidade com as normas de qualidade nacionais e internacionais.
O Guia de Aquisição não apresenta um documento específico com mesmo perfil do Plano de
Sustentação exigido pela IN 4. A ausência de detalhamento impede identificar se seu conteúdo possa
estar genericamente representado nos demais elementos do Guia de Aquisição.
A Estratégia de Contratação tem preocupação específica com questões de adequação orçamentária e
o impacto financeiro econômico, preocupação constante dos gestores públicos com vistas à responsabilidade fiscal. Além disso, nesta etapa há uma preocupação em avaliar e definir uma estratégia de
independência em relação ao fornecedor, de modo a reduzir dificuldades semelhantes e detectadas
pelo TCU em suas atividades de controle.
A IN 4 trata ainda de elementos característicos das contratações no setor público. O termo de referência é um documento específico do procedimento de licitação, mas pode ser adaptado a partir do
Plano de Aquisição. Por fim, a consulta pública é uma tarefa opcional específica da Administração
Pública na busca de garantir maior transparência e publicidade em suas contratações.
4.4.2. Gerenciamento do Contrato
A descrição das tarefas para o Gerenciamento do Contrato é bastante superficial na IN 4. Não contém elementos suficientes para estabelecer com clareza as atividades de acompanhamento e monitoramento da contratação. Neste sentido o Guia de Aquisição do MPS.BR fornece subsídios para a
compreensão e execução desta fase da IN 4.
O Plano de inserção é um elemento não encontrado no processo de aquisição do MPS.BR. Esta tarefa, porém, caberia a fase de planejamento e pode ser derivada a partir da estratégia de contratação.
No entanto, parte do conteúdo do Plano está incluído em suas tarefas, como a ‘Estabelecer e manter
comunicações’ e ‘Trocar informação sobre o progresso técnico’.
Há uma ênfase grande do processo de aquisição do MPS.BR nas questões relacionadas à aceitação
dos serviços, ou produtos de software obtidos na contratação, como se pode verificar pela existência
de uma atividade e tarefas estruturadas para este fim. Na IN 4 o tema é abordado, porém com menor
nível de estruturação.
WAMPS 2009 99
Artigos aceitos
5. Conclusão
A IN 4 representa um esforço importante na definição de diretrizes e regras para a contratação de
serviços de TI na APF. Visa reduzir riscos de insucesso na contratação dos mesmos, além de eliminar
práticas de contratação criticadas recorrentemente pelo TCU. A comparação objeto deste artigo revela uma maior abrangência do campo de aplicação da IN 4, que pretende servir a todo e qualquer
serviço de TI. Além disso, esta Instrução Normativa demonstra uma extensão do processo maior que
o MPS.BR, pois vincula o processo de aquisição a outros instrumentos de planejamento, ou seja, ao
PDTI e à EGTI. Em outras palavras, pode-se dizer também que há uma maior especialização do MPS.
BR, que se restringe a serviços de Software, notadamente o desenvolvimento, operação e manutenção, e ao processo de aquisição sem interferência no planejamento estratégico, mas alinhado às
necessidades de informação da organização.
Por outro lado, nota-se na IN 4 uma menor sistematização da estruturação do processo de contratação de serviços da IN 4 quando comparado ao processo estabelecido pelo Guia de Aquisição do
MPS.BR. Além disso, neste aspecto percebe-se um desbalanceamento da sistematização entre as
fases de Planejamento da Contratação e Gerenciamento do Contrato, sendo a primeira fase bem
mais detalhada do que a última. Neste assunto em particular, a sistematização do processo, o estudo
do MPS.BR traz valiosas contribuições para o detalhamento da implementação do modelo proposto
para a APF. De uma forma geral, a análise do MPS.BR promovida por este artigo sugere a necessidade
de melhorar a clareza e o entendimento por meio do uso de terminologia comum, componentes
estruturais elaborados sistematicamente, além de buscar assegurar conformidade com as normas
internacionais e nacionais relevantes. Destacam-se especificamente as seguintes oportunidades de
melhoria: i) identificação de objetivos e resultados esperados para estabelecer bases para avaliação
do processo; ii) definição, conceituação e classificação dos diversos elementos de forma mais completa, sistemática e precisa; e iii) estruturação de um conjunto de documentação de apoio visando à
implementação prática do processo.
Considerando que a IN 4 tem interesses mais abrangente, com foco na governança de TI, é interessante uma segmentação das orientações práticas para implementação das tarefas a partir de uma
taxonomia de serviços de TI contratados pela APF, tratando cada tipo de serviço com regras específicas de acordo com suas peculiaridades. No tocante à extensão do processo, esta dimensão deve ser
avaliada em função de outros modelos além do MPS.BR.
100 WAMPS 2009
Comparação entre a Instrução Normativa SLTI/MP nº 04 e o Guia de Aquisição do MPS.BR
Referências
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR –
Guia de Aquisição, versão 2009, junho 2009.
BRASIL. Tribunal de Contas da União. Acórdão 786/2006 – Plenário.
BRASIL. Tribunal de Contas da União. Acórdão 1.480/2007 - Plenário.
BRASIL. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da
Informação. Instrução Normativa SLTI n° 2, de 30 de abril de 2008.
BRASIL. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da
Informação. Instrução Normativa SLTI n° 4, de 19 de maio de 2008.
CRUZ, Cláudio Silva da. Governança de TI e conformidade legal no setor público: um quadro referencial normativo para a contratação de serviços de TI. Brasília, 2008.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION – ISO; INTERNATIONAL ELECTROTECHNICAL
COMMISSION – IEC. ISO/IEC 12.207:2008. Systems and software engineering —Software life
cycle processes. 2008. 123 p.
WAMPS 2009 101
Artigos aceitos
Implantação do Processo Aquisição na Synapsis
Brasil
Carlos Simões1,2, Ana Regina Rocha2, Gleison Santos2,3
[email protected], {carlossimoes, darocha}@cos.ufrj.br, [email protected]
Synapsis Brasil
Av. das Américas nº 3434, Bloco 2, Sala 403 Barra da Tijuca – CEP 22640-102 – Rio de Janeiro – RJ
1
COPPE/UFRJ – Universidade Federal do Rio de Janeiro
Programa de Engenharia de Sistemas e Computação Av. Horácio Macedo, 2030, Prédio do Centro de Tecnologia, Bloco H, Sala 319 Caixa Postal 68511 – CEP 21941-914 – Rio de Janeiro, RJ
2
UNIRIO – Universidade Federal do Estado do Rio de Janeiro
Departamento de Informática Aplicada – CCET Avenida Pasteur, 458 - Urca - Rio de Janeiro/RJ - CEP 22290-240
3
Abstract. This paper presents the most recent software process improvement (SPI) initiative at Synapsis Brasil
- the Supplier Agreement Management process implementation in accordance with a reference model MPS. It
is presented the company’s motivation for this initiative, in addition to the strategy adopted in the process implementation. In addition, comments are also made based on the use of the Decision Analysis and Resolution in
the definition of supplier selection criteria. Finally, it is identified the main benefits and difficulties encountered,
success factors and lessons learned.
Resumo. Este artigo apresenta a iniciativa de melhoria de processo mais recente da Synapsis Brasil – a implantação do processo Aquisição em conformidade com o modelo de referência MPS. É apresentada a motivação
da empresa para esta iniciativa, além da estratégia adotada na implantação do processo. Em adição, são feitos
comentários sobre os fundamentos utilizados do processo de Análise de Decisão e Resolução na definição dos
critérios de seleção de fornecedor. Finalizando, são identificados os principais benefícios e dificuldades encontradas, fatores de sucesso e lições aprendidas.
1. Introdução
Com a exigência da qualidade aumentando por parte dos clientes, as organizações desenvolvedoras
de software reconhecem que tratar a questão da qualidade de forma mais profissional, investindo
em treinamento, processos, técnicas e ferramentas que permitam a melhoria da qualidade é de fundamental importância.
Atrelada a questão da exigência pela qualidade está a necessidade cada vez maior do cliente em
receber o produto em um prazo cada vez menor. O back log é cada vez maior e a necessidade de
alocação de recursos não necessariamente é constante ao longo do processo de desenvolvimento de
software, as empresas desenvolvedoras de software entram em um dilema difícil de resolver: o que
102 WAMPS 2009
Implantação do Processo Aquisição na Synapsis Brasil
fazer para manter uma equipe com conhecimento adequado em ambientes diversos para atender a
volume de demanda variada de serviços dentro do prazo desejado pelo cliente?
Em princípio, pode-se pensar em duas respostas: “vamos repassar ao cliente o custo de manter a equipe com
tamanho suficiente grande, para atender a qualquer demanda, mesmo quando estiver sendo subutilizada”. A
outra resposta seria “vamos terceirizar parte do desenvolvimento”. Porém, a questão de terceirizar não é simples, existindo grande quantidade de casos de insucessos por diversos motivos, sejam por aspectos técnicos,
sociais, administrativos, comunicação entre outras. Controlar qualidade, produtividade e prazo tanto de contratada quanto de contratante sem a adoção de modelo de qualidade de processo de software é uma tarefa
muito difícil. Com o objetivo de resolver o problema, a Synapsis adotou a linha de implantar a área processo
Aquisição.
A melhoria de processo de software assume que uma organização bem gerenciada com indicadores e processos definidos tem mais possibilidades de produzir produtos que atendem adequadamente aos requisitos
dos clientes, no prazo e no orçamento do que organizações mal gerenciadas e sem processos [SOLINGEN e
BERGHOUT, 1999].
Seguindo o conceito de melhoria dos processos, a Synapsis Brasil implantou as áreas de nível C do MPS.BR e nível 3 do CMMI sendo avaliada com sucesso em junho e julho de 2009 respectivamente. Se tornando a primeira
empresa no Brasil a ser avaliada no Processo Aquisição do MPS.BR.
Este artigo é divido em seções: na seção 2 são comentas as etapas do processo de melhoria da qualidade na
Synapsis Brasil; na seção 3, a estratégia de implantação da área de Processo Aquisição, e a seção 4 as considerações finais.
2. Etapas do Processo de Melhoria da Qualidade na Synapsis Brasil
Em um cenário de forte competição e busca pela excelência no mercado global, para apoiar seu crescimento e diferencial no mercado, a Synapsis Brasil adotou como um de seus objetivos estratégicos
a definição de um plano para investir continuamente na melhoria da qualidade de seus produtos
e serviços considerando: demanda crescente por produtos e serviços; velocidade de negócios dos
clientes (time-to-market); distribuição geográfica da equipe (duas unidades, uma em Niterói e outra
em Fortaleza), o que requer padronização, comunicação e integração eficiente; existência de sistemas
integrados utilizados por mais de um cliente, recebendo manutenções e evoluções realizadas pelas
duas unidades da Synapsis; e cenário de alta rotatividade de colaboradores.
A Synapsis Brasil é uma organização de médio porte cuja missão é satisfazer as necessidades de
serviços relacionados à Tecnologia da Informação, Telecomunicações e Telecontrole para todas as
empresas que constituem o grupo Endesa. Soluções e serviços de software também são fornecidos
a clientes externos ao grupo.
Foi elaborado o Plano Estratégico da Qualidade alinhado com as estratégias corporativas da Synapsis
Matriz localizada em Santiago, Chile, englobando os seguintes objetivos: ISO 9001:2000 (março
de 2005); CMMI Nível 2 (agosto de 2006); MPS.BR nível C (junho de 2009); CMMI nível 3 (julho de
2009); e MPS.BR nível A e CMMI nível 5 (Junho de 2012).
O plano tem como particularidade, englobar duas unidades (Niterói e Fortaleza), com processos
comuns e implantados ao mesmo tempo e a grande separação geográfica. Isto torna necessária
WAMPS 2009 103
Artigos aceitos
uma integração muito grande das duas equipes e um gerenciamento centralizado e eficaz de modo
a fazer com que as unidades caminhem em sintonia. O conhecimento precisa ser disseminado de
forma igual nas duas unidades. Além disso, a motivação e comprometimento das equipes devem ser
os mesmos.
3. Estratégia de Implantação da área de Processo Aquisição
Para apoiar a implementação do processo Aquisição e também dos outros processos necessários ao
nível C de maturidade do MPS.BR [SOFTEX, 2009], foram definidos grupos organizacionais: Grupo
de Processo, com o objetivo de definir os processos; Grupo de Garantia da Qualidade do Processo
e do Produto, com objetivo de avaliar a qualidade dos produtos gerados e também a aderência dos
processos sendo executados em relação aos processos padrão da empresa; Grupo de Gerência de
Configuração, responsável por avaliar, executar e assegurar a correta implementação da Gerência de
Configuração; Grupo de Métricas, responsável por toda medição e análise de dados da empresa, o
que inclui análise das métricas, comunicação das métricas à alta direção, entre outros. Foram realizados treinamentos e workshops relacionados às áreas de processos que seriam implementadas para
os colaboradores da empresa. Depois disso, os projetos usando o processo tiveram início.
Para apoiar a definição, implantação e execução das atividades os consultores da COPPE/UFRJ foram
considerados fator crítico de sucesso. A realização das atividades do processo era acompanhada por
um consultor experiente. Essa abordagem foi eficiente para treinar as equipes da organização nos
processos, ferramentas e nas melhores práticas da Engenharia de Software. Também foi importante
para fazer com que os profissionais se conscientizassem dos benefícios de se usar um processo de
software definido. Além disso, a presença de um consultor externo ajudava a garantir a execução
das atividades do processo, que poderiam ser consideradas, em um primeiro momento, de menor
importância pelos desenvolvedores.
A gerência de alto nível teve papel fundamental no projeto de melhoria. O nível mais alto da organização deixava claro para todos que a iniciativa de melhoria era de grande importância e prioridade
para a organização. Todos se envolveram de alguma forma: gerentes de projetos, líderes de projetos,
analistas, testadores, equipe de qualidade, programadores, e outros. Depois de pouco tempo, todos
buscavam aprender e melhorar suas próprias atividades, uma vez que houve uma percepção geral de
que o uso de um processo definido melhorou a forma de trabalho na empresa.
A avaliação foi conduzida pela Riosoft (MPS.BR) e Crest Consulting (CMMI), sendo que a avaliação
inicial foi feita em conjunto, isto é, CMMI e MPS.BR ao mesmo tempo e a avaliação final em separado
com 3 semanas de intervalo entre uma e outra.
O propósito do processo Aquisição é gerenciar a aquisição de produtos e/ou serviços que satisfaçam
a necessidade expressa pelo adquirente, tendo como objetivo assegurar a qualidade do produto de
software, independentemente de parte ou todo estar sendo desenvolvido externamente à equipe do
projeto. O processo Aquisição (AQU) [SOFTEX, 2009a] é composto de nove resultados esperados,
focando na seleção do fornecedor e no acompanhamento dos produtos (avaliação periódica dos produtos intermediários e finais) e processos (como o desenvolvedor está executando o desenvolvimento do produto). Para suportar controles e avaliações necessários todos os aspectos para assegurar
104 WAMPS 2009
Implantação do Processo Aquisição na Synapsis Brasil
a qualidade dos produtos resultantes do processo Aquisição devem estar claramente definidos no
contrato entre as partes. Esse contrato pode variar no grau de formalismo, dependendo da relação
existente entre as partes [SOFTEX, 2009a].
Devido à particularidade dos projetos da Synapsis em que nem todos os projetos contemplam a
contratação de fornecedores, optou-se por não embutir as atividades necessárias ao processo de
aquisição dentro do processo de desenvolvimento de software. Com isto, quando um projeto não
contemplar aquisição, o líder do projeto não necessita solicitar a não execução das atividades de
aquisição. Ao ser definida a necessidade de aquisição em um projeto, o processo Aquisição deve ser
executado em paralelo com o processo de desenvolvimento de software.
A contratação de aquisições pela Synapsis é realizada na forma de preço e escopo fechado. Isto é,
elabora-se a especificação funcional do produto (com lista de requisitos especificada e projeto de arquitetura definido), faz-se a estimativa de pontos de função para definir o tamanho do produto e solicita cotação ao fornecedor. O pagamento é feito por entrega do produto contratado. Negociações
sobre alteração de escopo (mudança de requisitos) ou crescimento do tamanho do produto são
realizadas em comum acordo.
O processo Aquisição (Figura 1) contempla as atividades relacionadas diretamente com o planejamento e execução do plano de aquisição, enquanto que o processo de desenvolvimento de software
contempla as atividades de apoio e engenharia de software. Portanto, alguns tópicos ou artefatos
não são descritos no processo de aquisição existindo apenas referências aos artefatos que são elaborados no processo de desenvolvimento de software. Com o objetivo de guiar o líder do projeto na
execução do processo Aquisição, foram incluídos pontos de controle, como por exemplo, na apresentação da pré-venda do projeto para a diretória e na elaboração do relatório de monitoramento do
projeto pelo líder. O processo Aquisição definido para a Synapsis deve ser adaptado a cada execução,
dependendo do contexto da execução e dos objetivos da aquisição. Este processo pode ser executado em dois contextos:
1º - Contexto Organizacional
Em algumas situações o único objetivo de execução do processo de Aquisição é manter o cadastro de
fornecedores, podendo ser executado em duas situações: (i) Para avaliar um conjunto de potenciais
fornecedores, firmar contratos e incluir os selecionados no cadastro de fornecedores da Synapsis; (ii)
Para avaliar um único fornecedor, firmar contrato e incluí-lo no cadastro de fornecedores da Synapsis.
Em qualquer uma destas duas situações o processo de aquisição deve ser adaptado contendo obrigatoriamente as seguintes macro-atividades: (i) Avaliar a Qualidade dos Produtos do Processo; (ii)
Manter Cadastro de Potenciais Fornecedores; (iii) Avaliar Aderência ao Processo.
2º - Contexto dos Projetos de Desenvolvimento de Software
Em outras ocasiões o processo é executado quando, durante a execução do processo de desenvolvimento de software em um projeto, se avalia e se toma a decisão de contratar uma fábrica de
software ou adquirir COTS (Commercial-of-the-Shelf - pacotes). Neste caso, o processo de aquisição
deve ser adaptado contendo obrigatoriamente as seguintes macro-atividades: (i) Avaliar a Qualidade
dos Produtos do Processo; (ii) Preparar Aquisição de Software; (iii) Concluir Preparação para a
WAMPS 2009 105
Artigos aceitos
Aquisição de Software; (iv) Selecionar Fornecedores (No caso de aquisição de COTS, caso pertinente,
a atividade “Identificar processos críticos do fornecedor” pode ser excluída); (v) Monitoramento do
Fornecedor (No caso de aquisição de COTS, caso pertinente, esta macro-atividade pode ser excluída);
(vi) Aceitação do Produto; (vii) Avaliar Aderência ao Processo.
No processo de desenvolvimento de software definido pela Synapsis algumas das atividades contêm a identifica da integração das atividades do processo de aquisição ao processo definido para o
projeto, indicando o momento no qual cada atividade do processo de aquisição deve ser executada,
considerando o contexto de um projeto de desenvolvimento de software.
As atividades existentes no fluxo do processo de Aquisição (Figura 1), marcada com (*) possuem correspondência com atividades do processo de desenvolvimento de software. Atividade marcada com
(**) tem correspondência com várias atividades do processo de desenvolvimento de software, sendo
executada por diversos perfiz conforme a estratégia de aquisição estabelecida.
Figura 1 - Fluxo do Processo Aquisição da Synapsis
Para todo projeto que necessita adquirir partes de seus componentes deve ser elaborado o plano de
aquisição do projeto, considerando o escopo das necessidades a serem contempladas pela aquisição.
Além disto, deve-se planejar o processo, identificar responsabilidades e cronograma, identificar riscos, planejar gerência de documentos e de comunicação. Tal plano inicia com a atividade “Analisar a
Necessidade de Aquisição de Software” em que são analisadas as necessidades, confirmado ou não
106 WAMPS 2009
Implantação do Processo Aquisição na Synapsis Brasil
ser objeto de aquisição e os resultados que se pretende atingir com a aquisição. Se for constatado,
por algum motivo, a não realização da aquisição, o processo de aquisição é encerrado.
A necessidade de aquisição pode ser identificada em qualquer ponto do processo de desenvolvimento de software. Isto está vinculado ao tipo de aquisição, isto é, se for adquirir a partir da Especificação
de Requisitos, o processo de aquisição deve ser executado na fase inicial (Planejamento) do processo
de desenvolvimento de software. Durante os monitoramentos do projeto ao longo das fases seguintes líder do projeto avalia a necessidade de aquisição, caso seja levantada a necessidade de aquisição
(Especificação Técnica ou Construção) é iniciada a execução do processo de aquisição.
Caso seja confirmada a necessidade ou interesse em realizar a aquisição, a atividade de “Analisar a
Necessidade de Aquisição de Software” é realizada com objetivo de analisar as necessidades a serem
atendidas, avaliar e decidir o que deve ser objeto de aquisição, os resultados que se a pretende atingir
e a indicação do que será contratado, isto é, o escopo e o tipo de aquisição. Pode-se tomar uma das
seguintes decisões: (i) Contratar desde a especificação de requisitos; (ii) Contratar a partir da especificação técnica; (iii) Contratar a construção; (iv) Adquirir COTS. Ao final é produzido um documento com
o conjunto de necessidades a serem contempladas pela aquisição, o escopo e o tipo de aquisição.
As funcionalidades contidas no documento “Plano de Aquisição do Projeto” devem estar descritas
em detalhes no artefato “Especificação de Requisito” aprovado previamente pelo cliente. Neste plano
devem também conter informações sobre requisitos de manutenção, requisitos de treinamento, requisitos de implantação, restrições legais, restrições financeiras, restrições de prazo, requisitos de aquisição para os testes do produto adquirido e por fim, a estratégia de aquisição, contemplando itens,
como por exemplo: termos contratuais, termos financeiros, termos técnicos, lista de produtos a serem
entregues, mecanismos de controle do projeto, normas e modelos a serem seguidos pelo fornecedor,
critérios de aceitação do produto, responsabilidades e riscos. Com o plano de aquisição aprovado, o
próximo passo é verificar potenciais fornecedores e decidir para quais serão solicitadas cotação.
Ao receber as cotações dos potenciais fornecedores, inicia-se a seleção do fornecedor a partir dos
potenciais fornecedores e da resposta à solicitação de cotação. Durante a execução desta atividade
poderão ser realizadas negociações com os fornecedores. Para a elaboração do artefato de apoio a
seleção da melhor oferta, foi utilizado o processo de Análise de Decisão e Resolução (ADR) [SOFTEX,
2009b], cujo propósito é analisar possíveis decisões usando um processo formal, com critérios estabelecidos, para avaliação das alternativas identificadas. Envolve, após identificar uma questão que
deve ser objeto de um processo de avaliação formal, aplicar o processo a esta questão. Um processo
de avaliação formal é uma abordagem estruturada para avaliar soluções alternativas em relação a critérios estabelecidos para determinar a solução a ser utilizada para resolver um problema. O principal
motivo de utilizar ADR é reduzir a subjetividade da decisão e, desta forma, se tem maior probabilidade de selecionar uma solução que atenda às múltiplas demandas dos envolvidos.
Finalizando a decisão por um fornecedor, é elaborada a ordem de compra ou aditivo em caso de contrato guarda-chuva, e iniciado monitoramento das atividades com o fornecedor como estabelecido
no contrato. Envolvendo: (i) Monitorar o progresso e desempenho do fornecedor; (ii) Realizar revisões com o fornecedor conforme o contrato; (iii) Obter acordo quanto às alterações; (iv) Acompanhar
problemas; (v) Monitorar riscos que envolvem o fornecedor e tomar medidas corretivas; (vi) Rever
contrato quando necessário. Tais atividades devem ser realizadas periodicamente pelo líder de projeto durante a execução da atividade de monitoramento do projeto.
WAMPS 2009 107
Artigos aceitos
Ao ser entregue o produto adquirido, são solucionadas quaisquer questões relacionadas à aceitação,
de acordo com os procedimentos estabelecidos na ordem de compra durante a execução das atividades “Integrar o Produto e Testar a Integração” e “Testar o Produto” do processo de desenvolvimento
de software. Caso ocorra alguma não conformidade observada durante os testes de aceitação do
produto pelo cliente, que seja caracterizada como defeito na elaboração do artefato contratado para
execução do fornecedor, esta correção deve ser realizada pelo fornecedor. Caso seja uma não conformidade gerada pelo contratante do serviço, a correção deverá ser negociada com o fornecedor. Caso
seja alguma não conformidade gerada pela diferença de regras de negócio desejada pelo cliente e
documentos previamente aprovado pelo cliente, uma negociação deverá ser realizada entre o cliente
e a Synapsis. Depois de sanados problemas (caso existam) a conformidade do produto / serviço na
Ordem de Compra é registrada. Ao final do projeto é feita uma avaliação dos serviços prestados pelo
fornecedor para realimentar as informações do cadastro de fornecedores da Synapsis.
O projeto em que foi aplicado o processo de Aquisição tinha como objetivo disponibilizar uma ferramenta com acesso através de uma interface WEB, permitindo realizar consultas sobre a base de
dados cartográfica, apresentando os dados geográficos, da rede elétrica de alta, media e baixa tensão, bem como possibilitar a localização de clientes através de endereço ou PCR (Ponto de Conexão
com a Rede). Um projeto de 63 pontos de função implementado em Java, com bom tamanho para
ser usado em função de facilitar o gerenciamento e possibilitar respostas em um curto período de
tempo. O resultado foi considerado animador, com indicadores dentro dos limites estabelecidos pela
Synapsis, como pode ser observado na Figura 2.
Figura 2 – Índice de Desempenho de Prazo e Desvio de Prazo do Fornecedor
O pequeno desvio de prazo identificado foi em função do entendimento e adequação do fornecedor
ao novo modelo de processo de Aquisição e aos templates utilizados. Observa-se que após o período
inicial não ocorreu mais desvio de prazo do fornecedor. Demonstrando que, além do processo de
Aquisição, os monitoramentos e a utilização dos artefatos foram fatores de sucesso.
4. Considerações Finais
O processo de aquisição foi executado pela primeira em um dos projetos da avaliação CMMI e
MPS. Os resultados foram considerados satisfatórios, tornando-se padrão para todas as aquisições
software.
108 WAMPS 2009
Implantação do Processo Aquisição na Synapsis Brasil
O monitoramento de indicadores de desempenho financeiro, qualidade e produtividade, que retratam o desenvolvimento de sistemas de informação, facilita muito a efetiva gerência dos projetos,
produzindo serviços com níveis de qualidade elevado, com o mínimo custo possível – ou seja, alta
produtividade - que se constitui em fator crítico de sucesso para o bom desempenho empresarial e
aumento das vantagens competitivas das organizações.
Atrelada à questão da exigência pela qualidade está a necessidade cada vez maior do cliente em receber o produto em um prazo cada vez menor. Como a demanda por desenvolvimento de software não
é constantes por parte do cliente, a terceirização do desenvolvimento passa a ser uma alternativa viável para atender às necessidades do cliente. Porém, a questão de terceirizar não é tão simples quanto
parece. Controlar qualidade, produtividade e prazo tanto de contratada quanto de contratante sem
processos e templates definidos a partir de um modelo de referência como, por exemplo, MPS.BR
não é uma tarefa trivial.
A partir da análise do resultado de desempenho do conjunto de fornecedores a Synapsis estará em
condições de decidir quais poderão atender cada um dos tipos de projetos conforme características
específicas. É essencial a adoção de modelos de referência para orientar a melhoria continua dos
processos da organização. O monitoramento de indicadores de desempenho financeiro, qualidade
e produtividade, que retratam o desenvolvimento de sistemas de informação, facilita muito a efetiva
gerência dos projetos, produzindo serviços com níveis de qualidade elevado, com o mínimo custo
possível – ou seja, alta produtividade - que se constitui em fator crítico de sucesso para o bom desempenho empresarial e aumento das vantagens competitivas das organizações.
5. Referências
[SOFTEX, 2007], “MPS.BR: Melhoria de Processo do Software Brasileiro”, Guia Geral v. 1.2, Disponível
em: http://www.softex.br/mpsbr.
[SOFTEX, 2007a], “MPS.BR: Melhoria de Processo do Software Brasileiro”, Guia de Implementação –
Parte 2: Nível F v. 1.1, Disponível em: http://www.softex.br/mpsbr.
[SOFTEX, 2007b], “MPS.BR: Melhoria de Processo do Software Brasileiro”, Guia de Implementação –
Parte 5: Nível C v. 1.1, Disponível em: http://www.softex.br/mpsbr.
[SEI, 2006], CMMI for Development, Version 1.2, Software Engineering Institute.
[ISO/IEC 12207, 2008], “Information Technology – Software Life Cycle Processes”, The International
Organization for the Standardization and the International Electrotechnical Commission, v. ISO/
IEC 12207.
[ISO/IEC 15504-2: 2003] - The International Organization for Standardization and the International
Electrotechnical Commission. ISO/IEC 15504: Information technology – Software process assessment - Part 2 - Performing an Assessment, Geneve: ISO, 2003.
[SOLINGEN e BERGHOUT, 1999] SOLINGEN, R., BERGHOUT, E. The Goal/Question/Metric Method: A
Practical Guide for Quality Improvement of Software Development. McGraw-Hill. [Chrissis et al.,
2006]
WAMPS 2009 109
Artigos aceitos
Lições Aprendidas em uma Iniciativa de
Melhoria de Processos de Software na
Perspectiva dos Gerentes de Projetos de um
Grupo de Empresas Alagoanas
Lívia Omena1, Klevison Matias2, Marcelo Silva3, Joyce Marinho4 e Reinaldo Cabral5
[email protected], [email protected], [email protected], [email protected],
[email protected]
KMF Análise e Desenvolvimento de Sistemas e Websites LTDA.
Rua Luís Ramalho de Castro, 629-A, Jatiúca, CEP 57036-380 - Maceió-AL, Brasil
1
NTech Tecnologia de Informação Ltda.
Av. Durval Guimarães, 370, sl. 102, Ponta Verde, CEP 57035-060 - Maceió-AL, Brasil
2
Inform Sistemas Ltda.
Av. Humberto Mendes, 189, Poço, CEP 57020-580 - Maceió-AL, Brasil
3
Jetdata Sistemas Ltda.
Av. Com. Francisco Amorim Leão, 155, Farol, CEP 57057-780 - Maceió-AL, Brasil
4
Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ
Caixa Postal 68511 - CEP 21941-914 - Rio de Janeiro-RJ, Brasil
5
Resumo. Este artigo apresenta um conjunto de lições aprendidas a partir de uma iniciativa de melhoria de processos de software na perspectiva dos gerentes de projetos. A iniciativa envolveu quatro microempresas alagoanas de desenvolvimento de software com o objetivo inicial de atingir o nível G do MR-MPS. O maior desafio tem
sido a mudança de cultura nas empresas para a adoção de novas práticas. Espera-se que estas lições possam ser
úteis a outras organizações de software que pretendem empreender em melhoria de processos de software.
1. Introdução
O número de iniciativas de melhoria em processos de software vem crescendo significativamente
nos últimos anos no Brasil (TRAVASSOS e KALINOVSKI, 2008). Diversos relatos de experiência têm
sido publicados para ilustrar boas práticas, desafios e lições aprendidas com tais iniciativas sob diversas perspectivas, como por exemplo, dos consultores de uma Instituição Organizadora de Grupo
de Empresas (PALESTINO e MENDONÇA, 2008), dos consultores da Instituição Implementadora
(SANTOS, 2007a) (SANTOS et al., 2007b), dos avaliadores (ROCHA et al., 2007), do grupo de processos das empresas (MACEDO et al., 2006) (GUERRA et al., 2006) (MONTEIRO et al., 2008) e uma combinação dessas perspectivas (SANTOS et al., 2009). Essas narrativas podem contribuir com o sucesso
de novas iniciativas, servindo de insumo para a elaboração de projetos de melhoria de processos e
como uma valiosa fonte de conhecimento que podem apoiar na mitigação de uma série de proble-
110 WAMPS 2009
Lições Aprendidas em uma Iniciativa de Melhoria de Processos de Software
mas relacionados à melhoria de processos de software que representam riscos para as organizações
(STATZ et al., 1997).
Independente do nível de maturidade, no MR-MPS (SOFTEX, 2009) ou CMMI (CHRISSIS et al., 2006),
o papel do gerente de projeto é essencial para institucionalização dos processos. Nos menores níveis
de maturidade, como os níveis G e F do MR-MPS ou nível 2 do CMMI, em geral, o gerente de projeto
é o responsável por prover o maior número de evidências para as avaliações.
Tendo em vista a importância dos relatos de experiência em melhoria de processos de software e do
papel do gerente de projeto nestas iniciativas, este trabalho apresenta lições apreendidas identificadas a partir da perspectiva dos gerentes de projeto durante uma iniciativa de melhoria de processos
de software. Esta iniciativa envolveu um grupo de quatro empresas alagoanas visando, inicialmente,
alcançar o nível G do MR-MPS (SOFTEX, 2009). Embora este conjunto de dez lições aprendidas não
seja restrito ao processo Gerência de Projetos, observa-se uma ênfase neste processo devido à perspectiva adotada pelos gerentes de projeto.
Um trabalho publicado recentemente apresentou lições aprendidas a partir da perspectiva da gerência de projetos (SILVA e CABRAL, 2009), entretanto a visão apresentada era restrita ao contexto de
uma empresa. Este trabalho é uma extensão e reúne experiências de gerentes de projeto de quatro
organizações.
Além desta introdução, o artigo possui mais quatro seções. A seção seguinte apresenta a estratégia
de melhoria adotada e uma breve caracterização do grupo. Na seção três, aspectos considerados relevantes pelos gerentes de projetos são apontados e as lições aprendidas associadas são descritas. A
seção quatro discorre sobre lições restritas ao contexto de algumas empresas e a quinta seção provê
algumas considerações sobre a experiência.
2. A Estratégia de Melhoria Adotada
As quatro empresas envolvidas nesta experiência participam do Arranjo Produtivo Local de Tecnologia
da Informação de Maceió1 (APL-TI) e se mobilizaram para submeter um projeto à SOFTEX para implementação de processos de forma cooperada visando atingir o MR-MPS nível G. O primeiro passo
consistiu na avaliação de propostas para a seleção da Instituição Implementadora (II), que culminou
com a escolha da COPPE/UFRJ. A COPPE/UFRJ também atuou como Instituição Organizadora de
Grupo de Empresas (IOGE) coordenando a formulação do projeto para pleitear apoio da SOFTEX-BID
e do SEBRAE de Alagoas.
A iniciativa de melhoria de processos de software teve início em outubro de 2008. No início de 2009,
duas empresas do grupo já estavam aptas a serem avaliadas no nível G do MR-MPS. Este fato fez
com que as metas do projeto fossem revistas e, em consenso, todas as empresas concordaram em
estabelecer o nível F como objetivo a ser alcançado. A Figura 1 mostra o processo para implantação
do MR-MPS que segue a estratégia de implementação SPI-KM [BARRETO et al. 2006; SANTOS et al.
2007] desenvolvida pela COPPE/UFRJ. (vide Figura 1).
1) http://www.apltimaceio.com.br/
WAMPS 2009 111
Artigos aceitos
Figura 1. A estratégia SPI-KM [BARRETO et al. 2006; SANTOS et al. 2007]
O primeiro passo da estratégia é o diagnóstico, onde se realiza a seleção do modelo de maturidade, o nível pretendido pela organização e verifica-se a cultura existente. Em seguida, planeja-se a
iniciativa de melhoria e define-se o processo de desenvolvimento de software padrão para a organização. Treinamento teórico e “mentoring” são realizados para apoiar na execução dos processos os
profissionais envolvidos na iniciativa de melhoria. A aquisição, o registro de conhecimento e coleta
de recomendações de melhoria nos processos, que, posteriormente, são avaliadas e podem levar a
mudanças na definição do processo, ocorrem ao longo da execução dos processos. O passo final da
estratégia trata da preparação da organização para a avaliação dos processos, onde todos os participantes tomam conhecimento do processo de avaliação e de seus objetivos.
A principal característica que distingue este grupo de empresas dos demais é o compartilhamento de recursos
humanos para apoiar a execução dos processos Gerência de Configuração, Medição e Garantia da Qualidade.
Neste grupo, duas empresas são orientadas a produto (Inform Sistemas e Jetdata) e duas desenvolvem software
para web sob demanda (KMF e NTech).
Atualmente o grupo está sendo preparado para a avaliação, cuja primeira etapa está prevista para
final de setembro. Vale ressaltar que neste ponto da implementação, percebe-se que não há mais
necessidade de mentoring, o que denota que a aquisição do conhecimento por parte da organização
tem sido efetiva durante a experiência nos projetos.
3. Aspectos Relevantes e Lições Aprendidas com a Experiência
Esta seção aponta alguns aspectos considerados relevantes pelos gerentes de projetos do grupo
de empresas durante a iniciativa de melhoria. Em cada etapa foram observados aspectos comuns a
todas as empresas do grupo e identificadas ações utilizadas para mitigar ou contingenciar os problemas. De forma consensual, os gerentes de projeto identificaram quais destas ações foram eficazes no
contexto de cada empresa e as descreveram neste trabalho na forma de lições aprendidas.
112 WAMPS 2009
Lições Aprendidas em uma Iniciativa de Melhoria de Processos de Software
3.1. A execução do projeto-piloto
Após a preparação para iniciar os trabalhos relacionados ao projeto de melhoria de processos de
software nas empresas, o primeiro fato relevante observado foi a seleção do projeto para realizar a
primeira experiência na execução do processo. Um processo padrão, que atendesse os resultados do
MR-MPS foi estabelecido. A alta gerência de cada empresa decidiu escolher um projeto representativo, prioritário e de importância para as organizações e voltado para atender as necessidades de seu
principal cliente. Atuando desta forma esperava-se aumentar o comprometimento com a iniciativa,
acelerar a institucionalização do processo padrão e identificar oportunidades de melhorias durante a
primeira execução do processo.
Lição aprendida 1: Escolher um projeto real para ser o projeto-piloto, que seja importante para a
empresa e com um cliente representativo aumenta o comprometimento da empresa com a iniciativa
de melhoria.
Seguindo a orientação da consultoria da Instituição Implementadora, as organizações optaram por
adicionar uma margem de segurança nas estimativas de prazo para execução do primeiro projeto
para mitigar os riscos relacionados à inexperiência de execução de processos de software. Em uma
das organizações, a margem de 20% não foi suficiente e foi necessário renegociar com o cliente.
Lição aprendida 2: Adicionar uma margem nas estimativas de esforço e prazo ao planejar o projetopiloto evita que o aprendizado no processo afete o compromisso assumido com o cliente e minimiza
o risco de não seguir o processo diante das primeiras dificuldades.
Ao iniciar a execução de atividades dos processos definidos para os projetos, foi observada uma
tendência das equipes dos projetos não quererem seguir a ordem das atividades preestabelecida no
planejamento. Neste sentido, o registro do esforço investido nas atividades do processo, auxiliou a
monitoração da aderência ao processo e no controle dos prazos estabelecidos no planejamento.
Lição aprendida 3: Manter uma monitoração constante sobre a execução do projeto através de um
mecanismo de reporte de horas facilita o controle sobre a aderência do processo.
À medida que o cliente começou a ser envolvido em algumas atividades do processo, houve resistência relacionada à formalização dos comprometimentos e à necessidade de cumprir uma sequência de
atividades previstas nos processos.
Em uma das empresas, o cliente chegou a comunicar à alta gerência que achava o processo burocrático e que preferia o processo antigo, onde, de início, partia-se de imediato para a codificação do
software. Para contornar a insatisfação momentânea do cliente, foi necessário convencê-lo do ganho
na qualidade pretendido para o produto final a ser entregue. Nesta ocasião, o cliente também sugeriu que a comunicação por email fosse facilitada e, ao invés de encaminhar documentos anexados,
que a informação relevante constasse no corpo do email de maneira objetiva, pois se perde tempo
baixando arquivos e localizando informações em documentos.
Lição aprendida 4: Ouvir o que o cliente tem a dizer sobre a implementação de melhoria do processo de software aumenta seu envolvimento na iniciativa.
WAMPS 2009 113
Artigos aceitos
Lição aprendida 5: Mostrar ao cliente as vantagens da implementação de melhoria do processo de
software facilita a negociação das restrições do projeto.
3.2. A execução de novos projetos
O Relatório de Medição é apresentado pelo Grupo de Métricas, de acordo com a periodicidade estabelecida em cada Política Organizacional das empresas. As métricas relacionadas aos objetivos organizacionais são analisadas e consolidadas para possibilitar a identificação de desvios nas atividades
dos projetos. Nos primeiros relatórios foi percebido que boa parte dos principais desvios ocorridos
incidiu sobre atividades recém incluídas no processo ou sobre aquelas que sofreram mudanças.
Lição aprendida 6: Considerar os dados consolidados de projetos anteriores que estão presentes
nos relatórios de medição e o amadurecimento dos recursos humanos no que tange a execução do
processo diminui a ocorrência de grandes desvios no projeto.
Durante a análise das medições, em algumas ocasiões, os gerentes de projetos foram questionados
sobre medidas que apresentavam valores que destoavam do conjunto de dados coletados. Na grande maioria dos casos, o registro havia sido feito de forma incorreta. Também foi possível identificar
a ausência de coletas que deveriam ter sido feitas para algumas atividades, além de problemas em
outras coletas, cujo registro do esforço não foi realizado imediatamente após a execução de determinada atividade do processo.
Lição aprendida 7: Criar mecanismos que garantam que o esforço realizado pelos envolvidos em
cada atividade seja devidamente registrado contribui com a integridade dos dados que compõem o
relatório de medição.
Após a primeira experiência com o processo os gerentes de projeto perceberam diversas oportunidades para minimizar o esforço demandado para execução das atividades. A maioria das oportunidades
era relacionada ao reuso de parte de artefatos produzidos no projeto-piloto e melhorias que poderiam ser realizadas nos modelos de documentos para acelerar a execução das tarefas.
Lição aprendida 8: Considerar os artefatos de projeto anteriores de modo a adequá-los para novos
projetos pode diminuir o esforço necessário para realização de atividades do processo.
Também foi observado que ao estabelecer critérios objetivos para registro de comprometimento com
os artefatos, a equipe passou a sugerir mais melhorias para fazer com que os artefatos atendessem
aos critérios.
Lição aprendida 9: Envolver a equipe na avaliação dos produtos de trabalho aumenta o comprometimento com a qualidade do produto final.
Diante das oportunidades para aprimorar os produtos de trabalho do processo, os gerentes de projeto, por vezes, se antecipavam e realizavam alterações no formato dos artefatos e simplificações no
processo sem comunicar ao grupo de garantia da qualidade. Então, quando avaliações da aderência
do processo ou avaliações da garantia da qualidade de algum produto de trabalho eram realizadas
após estas mudanças, não-conformidades eram identificadas e planos de ação eram elaborados para
tratar os problemas. Nestes casos, o esforço da garantia da qualidade poderia ser equacionado, caso
114 WAMPS 2009
Lições Aprendidas em uma Iniciativa de Melhoria de Processos de Software
houvesse uma comunicação prévia referente às mudanças realizadas no processo e/ou nos produtos
de trabalho a serem avaliados.
Lição aprendida 10: Informar com antecedência à Garantia da Qualidade sobre a necessidade de
adequação dos laudos de avaliação dos artefatos do projeto facilita a avaliação e aumenta as chances
de que o prazo estimado para a avaliação seja cumprido.
4. Lições Aprendidas não Consensuais
Nem todas as lições aprendidas indicadas por cada gerente de projeto foram consensuais. Algumas
ações não foram aplicadas em todas as empresas, outras foram aplicadas, mas não foi possível observar o mesmo efeito.
4.1. Lições aprendidas observadas apenas em determinadas organizações
Durante a realização do projeto-piloto, a KMF sofreu inúmeras pressões por parte do seu cliente. A
gerente de projetos passou a realizar reuniões periódicas com a alta gerência para discutir sobre o
que poderia ser feito para minimizar o impacto da institucionalização do processo para o cliente. A
partir destas reuniões foram identificadas pequenas ações de melhoria que poderiam ser aplicadas
no processo sem maiores esforços e que atenuariam a percepção do excesso de burocracia por parte
do cliente.
Lição aprendida 11: Realizar reuniões periódicas com a alta gerência para tratar as insatisfações do
cliente é uma valiosa fonte de melhorias para o processo.
As dificuldades com o cliente fez com que a KMF estreitasse a comunicação e tomasse medidas no
sentido de envolver mais o cliente na melhoria dos processos. Neste sentido, a primeira atitude com o
intuito de demonstrar para o cliente que o objetivo era beneficiá-lo, foi permitir que ele estabelecesse
quais informações ele gostaria de receber sobre o progresso do projeto e com qual periodicidade.
Lição aprendida 12: Divulgar as informações do projeto da maneira que o cliente deseja aumenta
a satisfação dos clientes.
Próximo ao término do projeto-piloto a KMF decidiu avaliar se o esforço que estava sendo realizado
para executar os projetos contribuiria efetivamente com o alcance do MR-MPS nível G. Então, para
cada resultado dos processos Gerência de Projetos e Gerência de Requisitos, foram identificados os
artefatos que poderiam servir de indicadores diretos e indiretos de implementação2. Com esta prática, foi possível perceber deficiências na gerência de requisitos, pois os artefatos gerados não estavam
bem especificados e a rastreabilidade entre os requisitos e os produtos de trabalho não havia sido
estabelecida por completo. Desse modo, melhorias foram realizadas no processo para evitar os problemas nos projetos futuros.
2) Um indicador direto é um produto de uma tarefa diretamente relacionada ao resultado requerido pelo modelo. Já o indireto, reforça a
evidência de que o artefato direto foi produzido durante a realização da tarefa (SOFTEX, 2007).
WAMPS 2009 115
Artigos aceitos
Lição aprendida 13: Realizar avaliações informais internas para os projetos concluídos auxiliam na
identificação de potenciais problemas para avaliação de maturidade e provêem importantes subsídios para a melhoria do processo.
Na NTech e na KMF, ao solicitar a avaliação informal de artefatos chave ao processo, como por exemplo, da Especificação de Requisitos e do Modelo de Análise e Projeto, foram observadas dificuldades
na comunicação oral no que tange a expressão da opinião e das dúvidas quanto à execução das atividades. Entretanto, a comunicação escrita através de laudos de avaliação mostrou-se clara e objetiva.
O modelo MR-MPS requer a formalização de algumas comunicações do projeto, e este aspecto auxiliou a enxergar a comunicação escrita como uma solução para tratar a dificuldade da comunicação
oral entre os membros da equipe.
Lição aprendida 14: Identificar e tratar aspectos relacionados à má comunicação pode influenciar
o desempenho da equipe e contribuir com o progresso do projeto.
4.2. Discordância entre os efeitos de algumas ações
Na Jetdata foi observado que a dedicação parcial do gerente de projeto dificultava a execução dos
processos. Isto motivou a alocação do gerente de projeto em tempo integral na organização e a
situação foi equacionada. Entretanto, na KMF, que também contava com o gerente de projeto em
tempo parcial, tal dificuldade não foi observada. Uma das prováveis explicações é que o ciclo dos
projetos da Jetdata (em média 20 dias) é menor que o ciclo dos projetos da KMF (em média 2 meses),
e, portanto, requer uma atenção maior por parte da gerência de projetos.
No decorrer da iniciativa, a NTech introduziu novas ferramentas para facilitar a execução do processo.
A premissa assumida pela organização era que a introdução de novas ferramentas para a realização
de atividades no projeto poderia causar um impacto no esforço necessário para executar as atividades do projeto até que houvesse o pleno domínio por parte dos usuários, o que foi confirmado
posteriormente. Contudo, na Inform também foram introduzidas novas ferramentas para apoiar a
execução do processo e foi constatado que não houve um impacto significativo do esforço. Uma
das prováveis explicações para esta discordância pode ser o nível de integração entre as ferramentas
utilizadas pela Inform.
5. Considerações Finais
Uma avaliação informal dos projetos do grupo de empresas foi realizada no início do mês de agosto
de 2009 por uma consultora da Instituição Avaliadora COPPE/RJ. Foram identificadas oportunidades
de melhoria nos processos e outras ações para aumentar as chances de sucesso das empresas na
avaliação MPS.
Até o momento, os impactos mais significativos observados pelos gerentes de projetos com a institucionalização do processo padrão foram: (i) a melhoria na qualidade dos artefatos, (ii) o cumprimento
do cronograma, (iii) a constante melhoria do processo, (iv) a busca pela otimização do tempo gasto
em cada atividade, (v) a padronização do processo e (vi) o envolvimento do cliente no processo.
116 WAMPS 2009
Lições Aprendidas em uma Iniciativa de Melhoria de Processos de Software
O compartilhamento de lições aprendidas entre o grupo de empresas apóia o desenvolvimento da
iniciativa de melhoria. A identificação de lições aprendidas é consequência da reflexão sobre a execução dos processos, que tem como objetivo aplicá-las nos demais projetos organizacionais.
Desenvolver pesquisa sobre a melhoria dos processos de software segundo a perspectiva dos gerentes de projetos é interessante e relevante para o grupo de empresas e para o estado de Alagoas, que
começa a ter destaque no cenário nacional.
Acredita-se que a organização que aplica a iniciativa de melhoria em seus processos precisa desenvolver um desejo de incorporar a execução dos processos a seus projetos e não apenas objetivar a
conquista do selo de qualidade.
Concluindo, espera-se que as lições aprendidas capturadas durante uma iniciativa de melhoria de
processos de software, sob a ótica dos gerentes de projeto, sejam úteis a outras empresas e que elas
possam aumentar as chances de sucesso ao empreender na melhoria dos seus processos.
Referências
BARRETO, A., MONTONI, M., SANTOS, G.. et al. (2006) “Gerência de Conhecimento como Apoio
para Implantação de Processos de Software”, II Workshop de Implementadores MPS.BR (W2-MPS.
BR), Rio de Janeiro, Brasil.
CHRISSIS, M. B., KONRAD, M., SHRUM, S. (2006) “CMMI (Second Edition): Guidelines for Process
Integration and Product Improvement”. SEI Series in Software Engineering. Addison Wesley
Professional.
GUERRA, E., TRAVASSOS, G.H., SANTOS, G., et al. (2006) “Melhoria de Processos no Desenvolvimento
de Software e Hardware – O Caso Maxtrack”. In: V Simpósio Brasileiro de Qualidade de Software,
pp. 326-333, Vila Velha, Brasil, Maio.
MACEDO, C.C., LIMA, S.H.C.D., ROCHA, A.R., et al., 2006, “Implantação de Melhoria de Processo de
Software no Tribunal Superior Eleitoral”. In: V Simpósio Brasileiro de Qualidade de Software, pp.
351-358, Vila Velha, Brasil.
MONTEIRO, R. W., CABRAL, R., ALHO, F. et al. (2008) “O Esforço Requerido para Institucionalização
de Processos de Software na Prodepa”. ProQuality (UFLA), v. 4, p. 65-71.
PALESTINO, C. V. B., MENDONÇA, R, M. L. (2008). “Lições Aprendidas na Organização de Grupos de
Empresas no Programa MPS.BR”, In: da Rocha, A. R. C, Weber, K. C, MPS.BR Lições Aprendidas,
Softex, pp. 19-30.
SANTOS, G., MONTONI, M., FIGUEIREDO, S., et al. (2007a) “SPI-KM – Lessons Learned from Applying a
Software Process Improvement Strategy Supported by Knowledge Management”, 8th International
Conference on Product Focused Software Process Improvement (PROFES’2007), Latvia.
SANTOS, G., MONTONI, M. A., VASCONCELLOS, J. et al. (2007b) “Implementação do MR-MPS Níveis
G e F em Grupos e Empresas do Rio de Janeiro”. ProQuality (UFLA), v. 3, p. 53-58.
WAMPS 2009 117
Artigos aceitos
SANTOS, G., KATSURAYAMA, A.E., ZANETTI, D., et al. (2009) Lições Aprendidas em uma Iniciativa
de Melhoria de Processos de Software sob Diferentes Perspectivas: Membros da Organização,
Implementadores e Avaliadores, In: VIII Simpósio Brasileiro de Qualidade de Software, pp. 334341, Ouro Preto-MG, Brasil.
SILVA, L. M. O. ; CABRAL, R. . Fatos Relevantes e Lições Aprendidas em uma Iniciativa de Melhoria de
Processos de Software na Perspectiva da Gerência de Projetos. In: II Workshop de Gerenciamento
de Projetos de Software (WGPS), 2009, Ouro Preto - MG. II Workshop de Gerenciamento de
Projetos de Software (WGPS), 2009
SOFTEX (2007) MPS.BR - Melhoria de Processo do Software Brasileiro, Guia de Avaliação (v1.1)
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro.
SOFTEX (2009) MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral 2009, SOFTEX Associação para Promoção da Excelência do Software Brasileiro.
STATZ, J., OXLEY, D., O’TOOLE, P. (1997). “Identifying and Managing Risks for Software Process
Improvement,” CrossTalk, pp. 13-18. Disponível em: http://www.stsc.hill.af.mil/crosstalk/1997/04/
identifying.asp. Último acesso: 19/03/2009.
ROCHA, A. R. C.; SANTOS, G. ; MONTONI, M. A. et al. (2007) IA COPPE/UFRJ: Lições Aprendidas e
Melhores Práticas. ProQuality (UFLA), v. 3, p. 17-20.
TRAVASSOS, G. H., KALINOWSKI, M. (2008) iMPS - Resultados de desempenho de organizações que
adotaram o modelo MPS, Campinas-SP, SOFTEX.
118 WAMPS 2009
Lições Aprendidas em uma Iniciativa de Melhoria de Processos de Software
WAMPS 2009 119
Artigos aceitos
Fatores críticos de sucesso em programas de
melhoria de processo de forma cooperada
Geovane Nogueira Lima, Marcos André Gomes [email protected], [email protected]
SOFTEXRECIFE - Centro de Excelência em Tecnologia de Software do Recife Rua Madre de Deus, 27 - Bairro do Recife - Recife - Pernambuco - Brasil
Resumo. Este trabalho descreve as experiências vivenciadas pelo SOFTEXRECIFE na organização de programas
de melhoria de forma cooperada com base no modelo MPS.BR. O principal objetivo do presente trabalho é compartilhar os aprendizados, analisando os principais pontos que foram determinantes para o sucesso obtido.
1. Introdução
O presente relato tem por objetivo, compartilhar a experiência bem sucedida vivida pelo SOFTEXRECIFE
na organização de cooperativas para implantação do programa de melhoria com base no modelo MPS.BR. De forma sucinta, esperamos repassar os aprendizados adquiridos, apresentar e discutir os principais pontos determinantes do sucesso da cooperativa, na ótica da IOGE (Instituição
Organizadora de Grupo de Empresas).
O SOFTEXRECIFE em parceria com a SWQuality organizou em 2006 o primeiro grupo de empresas
em Recife para a implantação do programa de melhoria, com base no Modelo de Referência do MPS.
BR [MR-MPS.BR] e em 2007 o segundo grupo de empresas, motivado pelo comunicado da Sociedade
SOFTEX Nacional para a formação de grupos de empresas para a implantação do MR-MPS.BR no modelo cooperado. Esta primeira cooperativa de empresas teve por objetivo apoiar a implementação do
nível G do modelo em 5 empresas de desenvolvimento de software da região Nordeste, e a avaliação
seguindo o Método de Avaliação do MPS.BR [MA-MPS.BR].
A primeira cooperativa MPS.BR nível G desenvolveu suas atividades no período de abril de 2006 a
junho de 2007, quando as últimas empresas do grupo foram avaliadas obtendo o nível G. Das 5
empresas que iniciaram o grupo, 4 empresas foram avaliadas e todas foram bem sucedidas com
as avaliações realizadas conforme previsto no projeto. Com isto obtivemos uma taxa de sucesso de
80%, maior do que a prevista inicialmente.
Em 2007 foi organizada a segunda cooperativa com 9 empresas organizadas em dois grupos, um
grupo com 5 empresas objetivando o nível G e o outro com 4 empresas objetivando o nível F. Estes
grupos foram finalizados no início de 2009, com a avaliação oficial de 3 empresas no nível F e 4 no
nível G. Com estes resultados, obtivemos um índice de 78% das empresas que iniciaram o grupo
avaliadas oficialmente, e com 100% de aproveitamento nas avaliações, ou seja todas as empresas
que se submeteram à avaliação oficial obtiveram o nível pretendido.
120 WAMPS 2009
Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada
2. A IOGE
O SOFTEXRECIFE, criado em 1994, é o Centro de Tecnologia de Software para Exportação do Recife.
Sua missão é articular, fomentar e apoiar ações direcionadas à excelência do setor de software em
Pernambuco.
No momento o SOFTEXRECIFE conta com mais de 70 empresas a ele associadas, o que significa uma
parcela importante das empresas que formam o setor de Tecnologia da Informação e Comunicação
em Pernambuco.
A principal missão do SOFTEXRECIFE é aumentar a competividade das empresas de Tecnologia da
Informação e Comunicação, buscando instrumentos para fomentar o desenvolvimento do setor de
software no Estado de Pernambuco. O SOFTEXRECIFE tem como visão tornar-se dentro de 2 anos,
um centro difusor da cultura da qualidade e referência em teste de software e, com isso, contribuir
para a consolidação do Recife como um pólo de excelência na produção de TI.
O SOFTEXRECIFE é na verdade uma comunidade viva de empresas da área de Tecnologia da Informação
que dispõe de um espaço institucional para se aperfeiçoar e promover o seu crescimento e inserção
no mercado local, nacional e internacional. Em face desse papel o SOFTEXRECIFE é, junto com outras
instituições, elemento chave de uma estratégia, em curso, para consolidar a cidade do Recife como
um pólo reconhecido e respeitado de geração, produção e difusão de Tecnologia da Informação.
O SOFTEXRECIFE atuou no papel de IOGE (Instituição Organizadora de Grupo de Empresas) na primeira e segunda cooperativa MPS.BR Recife.
Podemos observar que a organização das cooperativas está totalmente alinhada aos objetivos do
SOFTEXRECIFE, e neste ponto todos os esforços foram realizados para ajudar as empresas, na sua
busca por competividade.
3. As Cooperativas
A primeira cooperativa foi formada em abril de 2006, com o objetivo de implantação de um programa de melhoria baseado no nível G do MR-MPS.BR, além da avaliação oficial neste nível do modelo
de 5 empresas organizadas em grupo.
A cooperativa foi organizada em parceria com a SWQuality Consultoria e Sistemas, a qual atuou como II (Instituição Implementadora), ficando responsável pelas atividades de consultoria, treinamento
e comunicação do grupo.
As empresas selecionadas para compor esta primeira cooperativa foram: CAPITAL LOGIN, PROCENGE,
PROVIDER, MV SISTEMAS e NEUS. Todas as empresas são classificadas como empresas de médio ou
pequeno porte, e estão todas situadas na região Nordeste do país.
A cooperativa, conforme definido no seu próprio Plano de Projeto, teve como principais objetivos:
• Avaliar e aprovar 5 empresas de desenvolvimento no nível G do MPS.BR;
WAMPS 2009 121
Artigos aceitos
• Promover a cultura da qualidade em desenvolvimento de software no ecossistema de
Pernambuco;
• Difundir o MPS.BR.
Sendo a principal prioridade a avaliação oficial das empresas no nível G do MPS.BR, num prazo de
doze meses.
Os resultados alcançados foram bastante expressivos, atingindo todos os objetivos planejados e superando inclusive algumas das expectativas iniciais. Das 5 empresas participantes, 4 foram avaliadas
e todas obtiveram resultado positivo na avaliação, obtendo assim o nível G do modelo. A única empresa não avaliada deveu-se à mudança no seu foco de atuação, extinguindo sua área de desenvolvimento de software. Assim, obtivemos um indicador de desempenho, com 100% de sucesso.
Temos plena convicção que todo este sucesso se deve ao esforço conjunto de todos os atores envolvidos na cooperativa: IOGE, II e empresas; e principalmente a harmonia entre estes atores. Os fatores
de sucesso da cooperativa dependem da união, esforço e comprometimento de todos. Por parte da
IOGE, entendemos que o principal fator de sucesso foi assumir uma postura pró-ativa, e, sobretudo,
valorizar a comunicação entre os envolvidos.
O principal desafio enfrentado logo no início dos trabalhos foi conseguir despertar o interesse das
empresas e selecionar algumas delas para a formação do grupo. A princípio poucas empresas se interessaram pelo programa de melhoria de processo com base no MR-MPS.BR, que, de certa forma, já
era de se esperar, pois o modelo MPS.BR ainda estava se desenvolvendo e em processo de aceitação
pelo mercado. Para superar esta dificuldade o SOFTEXRECIFE atuou fortemente junto à gestão das
empresas filiadas e várias rodadas de apresentações sobre melhoria de processo e do modelo MPS.
BR foram promovidas, a fim de que os executivos das empresas tomassem conhecimento do modelo.
Esta medida surtiu o efeito desejado e conseguimos formar o primeiro grupo de empresas.
A segunda cooperativa foi formada em agosto de 2007 e se mostrou mais complexa do que a primeira, visto que o número de empresas é significativamente maior, e também por ser composta de
2 grupos, a saber: um grupo com 5 empresas trabalhando para obter o nível G, e outro grupo de
4 empresas trabalhando para obter o nível F. Estes fatores foram amplamente compensados pela
experiência adquirida com a primeira cooperativa. De forma geral todas as ações estruturantes da
cooperativa anterior foram mantidas, sendo realizados apenas alguns pequenos ajustes no modelo
de gestão.
Algumas ações foram reforçadas por terem apresentado resultados positivos na cooperativa anterior.
Dentre elas, podemos destacar: o incentivo a colaboração e, o reconhecimento das particularidades
de cada empresa. Enquanto a primeira ação aumenta o comprometimento da empresa; a segunda
diminui a resistência a mudanças, o que é muito comum em projetos desta natureza.
Os resultados alcançados, com a aprovação de 7 empresas (4 no nível G e 3 no nível F) vem confirmar a efetividade do modelo implementado pelo SOFTEXRECIFE, que tem como principio básico a
integração entre os atores do projeto (IOGE, II e empresas).
122 WAMPS 2009
Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada
4. O Aprendizado
Analisamos o desempenho obtido nas cooperativas, buscando identificar algumas das práticas adotadas que tenham contribuído para o sucesso do projeto. Pudemos observar que algumas destas
práticas não têm nada de inovador, são apenas boas práticas da Gerência de Projetos, contudo,
trouxeram uma ótima contribuição para os resultados obtidos.
Desde o início da formação da cooperativa as atividades foram tratadas como um Projeto. Observamos
que algumas práticas são próprias do contexto da organização de trabalhos de forma cooperada. A
seguir apresentaremos e comentaremos estas práticas.
Critério para formação do Grupo: ao selecionar os participantes que irão compor o grupo, é
importante buscar empresas que tenham uma boa afinidade entre si e que não tenha conflitos de interesse. Deve-se tomar o cuidado de não colocar no mesmo grupo empresas que sejam concorrentes
diretas, ou que não tenham um bom relacionamento. Na medida do possível é interessante selecionar empresas no mesmo nível de maturidade. Para que se possa fazer uma seleção e agrupamento
adequado das empresas é fundamental conhecê-las. Para tal, foram elaborados e aplicados alguns
questionários às empresas. O processo de seleção ocorreu junto com a participação da II (Instituição
Implementadora).
Subsídio vinculado ao cumprimento das metas: embora as condições estabelecidas pela
Sociedade SOFTEX Nacional permitam que as empresas recebam a primeira parcela na assinatura
do convênio, o SOFTEXRECIFE achou por bem adotar outra postura. Foi então definido que, para se
obter os subsídios, as empresas teriam que atingir primeiro as metas estabelecidas (50%, 100% e
a avaliação). Embora esta abordagem possa dificultar a participação das empresas, ela serve como
incentivo e aumenta significativamente o compromisso com o sucesso do projeto. Pudemos perceber
que além do aumento do compromisso, as empresas ficaram motivadas a atingir as metas no menor
espaço de tempo possível.
Termo de cooperação técnica: os acordos para a formação da cooperativa foram tratados como
“Termo de Cooperação Técnica Financeira” e não simplesmente como um Contrato Comercial entre
as partes. Tal abordagem explicita que o sucesso do projeto é de responsabilidade de todos, e que
depende do desempenho do grupo como um todo. Em outras palavras, o sucesso de uma das partes
está estritamente ligado ao sucesso das outras partes, sendo o contrário também verdadeiro.
Regras claramente definidas: é de extrema importância estar com todas as regras muito bem
definidas e compreendidas por todos, antes do início dos trabalhos. E tão importante quanto a sua
definição, é sua implementação. Para atender este item, realizamos reuniões onde as regras administrativas, financeiras e técnicas foram apresentadas aos participantes do grupo. Isto foi feito antes
mesmo da formação oficial do grupo.
Relacionamento estreito com a II: um relacionamento estreito entre a II e a IOGE, desde o início
dos trabalhos, foi sem dúvida, um ponto fundamental para o sucesso obtido. A relação entre IOGE
e II deve ser vista como uma parceria, e não uma simples contratação de prestação de serviço. O alinhamento entre estratégia/metodologia de implantação e a gestão da cooperativa é primordial para
um bom andamento dos trabalhos. Como a II está mais próxima das empresas, participando do seu
WAMPS 2009 123
Artigos aceitos
dia a dia e consegue identificar as dificuldades tão logo estas surjam, este relacionamento permite
que a IOGE tome medidas antecipadas e até mesmo preventivas de solução de problemas.
Metodologia de trabalho bem definida: ter uma metodologia de trabalho clara e bem definida
é importante e passa confiabilidade do processo para as empresas. É recomendável que as etapas/
fases da metodologia estejam claramente divididas. Uma divisão bem estruturada permite um acompanhamento da evolução do projeto de forma mais precisa e menos árdua. A SWQuality apresentou
uma metodologia de trabalho dividida em 8 fases bem nítidas, e com os resultados esperados para
cada uma delas claramente definidos, o que contribuiu para o acompanhamento do projeto. Outro
ponto observado, é que a utilização de uma metodologia facilita o nivelamento das expectativas entre as partes envolvidas, e serve como base para o planejamento das atividades da cooperativa.
Canal de comunicação: logo no início dos trabalhos foi criada uma intranet para que todos os
participantes da cooperativa pudessem trocar informação livremente, gerando assim um canal de
comunicação. Pela intranet podemos trocar experiências, divulgar notícias, compartilhar material e
enviar os comunicados das atividades do grupo. Foi de suma importância incentivar a comunicação
entre as empresas sem que a mesma dependesse do intermédio da IOGE, especialmente para troca
de experiências.
Incentivo à colaboração: observamos que no início do projeto as empresas ficam relativamente
tímidas e resistentes em compartilhar suas experiências, mas é função da IOGE tentar reverter esta
situação. É importante que a IOGE atue incentivando a todo o momento a constante troca de experiência. No início as empresas foram obrigadas a apresentar o andamento dos trabalhos para todo
o grupo periodicamente. Ocorreram reuniões técnicas para troca de experiências, aprendizado e
debate das dificuldades. Com a evolução do projeto a colaboração tornou-se bastante natural, não
sendo mais necessária uma forte intervenção da IOGE. Esta postura da IOGE foi bastante elogiada
pelas próprias empresas.
Reconhecer a particularidade de cada empresa: embora as atividades ocorram de forma cooperada, as particularidades de cada empresa foram a todo o momento respeitadas. Observamos que
as empresas evoluem em ritmos diferentes, seja em função de suas características ou de uma situação específica. É de extrema importância respeitar o ritmo de evolução individual de cada empresa
Para tanto, cada empresa elabora seu próprio cronograma considerando suas particularidades, mas
mantendo os pré-requisitos dos marcos definidos pelo cronograma da cooperativa. Esta abordagem
permitiu, por exemplo, que uma das empresas evoluísse mais rápido e obtivesse o nível G em menos
de 8 meses, enquanto o planejado pela cooperativa era de aproximadamente 12 meses.
Definição clara dos papéis e responsabilidades: um projeto de cooperativa envolve vários atores,
e cada um com interesses particulares. Por isso a definição clara dos papéis e responsabilidades, faz-se
extremamente necessário. A definição dos papéis e responsabilidades ocorreu logo no início do projeto e foi divulgado e aprovado por todos os envolvidos. A figura 1 ilustra o organograma do projeto.
124 WAMPS 2009
Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada
Figura 1: Organograma do projeto
Na tabela 1 é apresentado os papéis no projeto, e descrito quais são as responsabilidades de cada
uma das partes. Observe que por parte da empresa foram definidos três papéis, cada um com suas
responsabilidades bem delineadas.
Grupo Executivo: foi definido um modelo de gestão da cooperativa que estabelece a criação do
Grupo Executivo, o qual é constituído por representantes de todas as partes envolvidas: IOGE, II, e
um representante de cada empresa. Como podemos observar no Organograma (figura 1), este é o
topo da hierarquia, garantindo assim um processo democrático à cooperativa. O Grupo Executivo é
responsável por aprovar requisições de mudanças que afetam custo, prazo e/ou escopo, bem como
tratar os problemas escalados, e principalmente acompanhar a evolução do projeto. Esta prática foi
de fundamental importância para manter o comprometimento do grupo, a clareza dos trabalhos e
garantir certa flexibilidade ao grupo.
Reunião de acompanhamento: as reuniões de acompanhamento foram realizadas ao longo de
todo o projeto, sendo mais frequente nas fases iniciais. Nestas reuniões cada empresa elaborava e
apresentava um relatório de andamento do projeto e a II apresentava um acompanhamento de cada
empresa em relação aos marcos da cooperativa. Em todas as reuniões os principais pontos do projeto
eram monitorados, como por exemplo: cronograma, consumo dos recursos (horas de consultoria) e
questões financeiras. Com isto podemos observar a importância destas reuniões na redução de conflitos, comunicação e reforço no comprometimento do grupo.
WAMPS 2009 125
Artigos aceitos
Tabela 1: Definição de Papéis e Responsabilidades
Papel
Responsabilidades
Grupo Executivo
• Aprovar requisições de mudanças que afetem custo, prazo ou escopo; • Resolver conflitos e problemas escalados; • Acompanhar situação do projeto.
Gerente do Projeto Softex • Acompanhar atividades; • Resolver conflitos e problemas; • Gerenciar os riscos do projeto; • Promover reunião de acompanhamento; • Revisar relatórios de homologação; • Gerenciar recursos oriundos do Softex Nacional; • Aprovar requisições de mudanças que não afetem custo, prazo ou escopo; • Gerenciar ações corretivas e/ou preventivas; • Gerenciar a comunicação do projeto; • Disponibilizar recursos.
Coordenador Técnico
Softex
• Apoiar Gerente do Projeto Softex nas questões técnicas do projeto • Realizar homologação de produtos técnicos da SWQuality
Coordenador Técnico
SWQuality
• Preparar relatórios de acompanhamento; • Participar de reuniões de progresso; • Reportar conflitos e riscos a qualquer momento ao Gerente do Projeto Softex; • Gerenciar ações corretivas e preventivas designadas a ele; • Manter site técnico do projeto atualizado.
Equipe Consultores
• Executar treinamentos e consultorias; • Elaborar documentos técnicos; • Reportar status ao coordenador técnico SWQuality.
Patrocinador
No âmbito do projeto dentro da empresa: • Acompanhar progresso do projeto; • Resolver conflitos e problemas; • Disponibilizar recursos.
Gerente do Projeto
Melhoria
No âmbito do projeto dentro da empresa: • Acompanhar progresso do projeto; • Reportar status do projeto ao Patrocinador; • Gerenciar os riscos do projeto; • Gerenciar ações corretivas e/ou preventivas; • Homologar serviços e produtos prestados pelo projeto; • Participar das reuniões de progresso agendadas pelo Softex.
Equipe Técnica
No âmbito do projeto dentro da empresa: • Participar das reuniões de consultoria e treinamentos do projeto; • Reportar status do projeto; • Apoiar na identificação de riscos técnicos do projeto.
126 WAMPS 2009
Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada
5. Conclusões
Os resultados obtidos com a experiência da primeira cooperativa MPS.BR organizada pelo SOFTEXRECIFE
em parceria com a SWQuality, foi um projeto que conseguiu alcançar todos os seus objetivos tanto
na avaliação das empresas, quanto na divulgação do Modelo MPS.BR. O sucesso desta iniciativa pôde
ser confirmado com a formação da segunda cooperativa. Atendendo a demanda, o SOFTEXRECIFE
em parceria com a SWQuality, formaram dois novos grupos de empresa. Um grupo com 5 novas empresas para a implantação do nível G, e um outro grupo, formado por 4 empresas que participaram
da primeira cooperativa, agora com o objetivo de implementar o nível F do modelo MPS.BR.
Os dois novos grupos de empresas, nível G e nível F, adotaram a mesma abordagem da primeira cooperativa e os primeiros resultados foram bastante positivos, com a aprovação de 7 das 9 empresas
envolvidas no modelo MR-MPS.
A experiência vivida na primeira e segunda cooperativa nos mostra que o início das atividades é o
momento crucial para sucesso ou fracasso do projeto. É importante que todas as partes tenham
conhecimento dos objetivos do trabalho, o esforço esperado, e que as expectativas estejam bem
alinhadas e que tenham conhecimento da metodologia de gestão e de execução das consultorias.
Em outras palavras, é fundamental um bom planejamento, e um forte comprometimento de todos
os envolvidos.
6. Referências
[MA-MPS] Associação para Promoção da Excelência do Software Brasileiro – SOFTEX. MPS.BR - Guia
de Avaliação, v 1.0 2006. Disponível em www.softex.br.
[MR-MPS] Associação para Promoção da Excelência do Software Brasileiro – SOFTEX. MPS.BR - Guia
Geral, v 1.1 2006. Disponível em www.softex.br.
WAMPS 2009 127
Artigos aceitos
A Experiência de Implantação dos Processos
Gerência de Reutilização e Desenvolvimento
para Reutilização na Synapsis-Brasil
Gleison Santos2,3, David Zanetti2, Morisson Maciel1, Carlos Alberto Simões1,2, Claudia Werner2, Ana Regina Rocha2
[email protected], {zanetti, carlossimoes, werner, darocha}@cos.ufrj.br, {mmaciel, cs}@synapsisbrasil.com.br
Synapsis Brasil
Av. das Américas nº 3434, Bloco 2, Sala 403 Barra da Tijuca – CEP 22640-102 – Rio de Janeiro – RJ
1
COPPE/UFRJ – Universidade Federal do Rio de Janeiro
Programa de Engenharia de Sistemas e Computação Av. Horácio Macedo, 2030, Prédio do Centro de Tecnologia, Bloco H, Sala 319 Caixa Postal 68511 – CEP 21941-914 – Rio de Janeiro, RJ
2
UNIRIO – Universidade Federal do Estado do Rio de Janeiro
Departamento de Informática Aplicada – CCET Avenida Pasteur, 458 - Urca - Rio de Janeiro/RJ - CEP 22290-240
3
Resumo. Este artigo descreve a experiência da COPPE/UFRJ na implantação dos processos de Gerência de
Reutilização e Desenvolvimento para Reutilização na Synapsis-Brasil, visan-do à obtenção do Nível C do MRMPS v 1.2. São descritos os processos definidos e alguns resultados parciais da execução da estratégia de reutilização estabelecida para conduzir o programa de reutilização da organização.
1. Introdução
Devido à grande competitividade do mercado atual, as organizações desenvolvedoras de software
vêm buscando formas de melhorar a qualidade dos serviços e produtos que fornecem. Neste contexto, algumas técnicas de engenharia de software vêm ganhando destaque na indústria, como por
exemplo, a Reutilização de Software. Trata-se de uma disciplina responsável pela criação de sistemas
de software a partir de software preexistente [KRUEGER, 1992]. Parte-se do pressuposto de que
grande parte dos sistemas não é nova, mas sim variações de sistemas existentes. Diferentemente da
reutilização ad hoc, que usualmente se concretiza por meio de cópia de trechos de artefatos preexistentes, a disciplina de Reutilização de Software visa sistematizar e difundir práticas de reutilização na
organização. O intuito principal da reutilização de software é melhorar a qualidade e a produtividade
do desenvolvimento de software pela reutilização de produtos de software existentes e/ou conhecimento adquirido, possibilitando que sistemas grandes e complexos sejam desenvolvidos em menos
tempo e menor custo [FRAKES e KANG, 2005].
Neste sentido, pode-se observar o ingresso recente da reutilização de software em modelos para a
melhoria de processos de software, por exemplo, o MPS.BR [SOFTEX, 2007]. O MPS.BR define nos níveis E e C do MR-MPS os processos de Gerência de Reutilização e Desenvolvimento para Reutilização,
128 WAMPS 2009
A Experiência de Implantação dos Processos Gerência de Reutilização e Desenvolvimento
respectivamente. Pelo fato de o ingresso desses processos ter ocorrido recentemente, ainda há poucos relatos de implementação do processo de Gerência de Reutilização, como [SILVA FILHO et al.,
2008], e nenhum relato de implementação do processo de Desenvolvimento para Reutilização.
Este artigo apresenta a experiência da equipe de implementadores da COPPE/UFRJ na implementação dos processos de Gerência de Reutilização e Desenvolvimento para Reutilização do MPS.BR na
Synapsis-Brasil. Trata-se de uma organização de médio porte, geograficamente distribuída entre o Rio
de Janeiro e o Ceará, cuja missão é satisfazer as necessidades de serviços relacionados à Tecnologia
da Informação para todas as empresas que constituem o grupo Endesa. Algumas soluções e serviços
de software também são fornecidos a clientes externos. A organização foi avaliada anteriormente
no nível de maturidade 2 do CMMI [SEI, 2006], tendo contado com a consultoria da COPPE/UFRJ
também na implementação deste nível. Recentemente a organização foi avaliada com sucesso no
nível 3 do CMMI e também o nível C do MR-MPS. A seção 1 apresentou a introdução do artigo e a
caracterização da organização. A seção 2 apresenta os processos definidos para apoiar as atividades
de reutilização sistemática da organização. A seção 3 apresenta os resultados da execução dos processos definidos. E, por fim, a seção 4 apresenta as considerações finais deste artigo.
2. Processos Definidos
O modelo de referência MPS.BR [SOFTEX, 2007] define em seu conjunto de processos de nível E e de
nível C os processos de Gerência de Reutilização e Desenvolvimento para Reutilização. O propósito
do primeiro é gerenciar o ciclo de vida dos ativos reutilizáveis da organização, definindo procedimentos tanto administrativos quanto técnicos para a utilização destes ativos em uma organização,
estabelecendo e controlando uma biblioteca para armazenamento e recuperação desses ativos [IEEE,
2004]. Já o processo de Desenvolvimento para Reutilização visa aplicar técnicas de engenharia de
domínio para definir o escopo, especificar a estrutura e construir ativos reutilizáveis para uma classe
de sistemas, subsistemas ou aplicações [IEEE, 2004]. Esses ativos reutilizáveis, por serem produzidos
a partir da engenharia de domínio, são denominados ativos de domínio. Desta forma, o principal
resultado da aplicação do processo Desenvolvimento para Reutilização é a especificação, projeto
(design) e implementação de ativos de domínio que atendam a famílias de aplicações ou a domínios
de conhecimento específicos.
Baseando-se nos resultados esperados dos processos de Gerência de Reutilização e Desenvolvimento para
Reutilização no MR-MPS foram definidos dois processos de apoio às atividades de reutilização de software na
organização. Esses processos descrevem todo o fluxo de atividades necessárias para atender aos resultados
esperados e o ciclo de vida dos ativos reutilizáveis.
2.1. O Processo de Gerência de Reutilização
Este processo inicia-se a partir da identificação de um potencial ativo reutilizável. Entende-se por
ativo reutilizável qualquer artefato que apóie o desenvolvimento de um projeto e que possa compor
ao menos um dos seus respectivos produtos de trabalho. Um ativo reutilizável possui grande valor
tendo em vista seu potencial para reduzir o esforço de execução do processo e/ou pelo conhecimento
explícito que contém.
WAMPS 2009 129
Artigos aceitos
O processo é executado tanto a partir da necessidade de avaliar ativos candidatos quanto de realizar
melhorias em um determinado ativo. Esta necessidade poderá surgir a partir de problemas identificados durante o uso ou a partir de oportunidades de melhoria identificadas ao longo do tempo.
Independente da forma como o processo é iniciado, o processo é finalizado com a notificação dos interessados a respeito da disponibilidade, evolução ou descontinuidade do ativo reutilizável. A Figura
1 mostra as atividades do processo de Gerência de Reutilização.
Figura 1. Processo de Gerência de Reutilização
Na primeira atividade “Avaliar Ativo Candidato”, o ativo submetido para avaliação é analisado em termos de critérios que deve satisfazer para compor um ou mais produtos de trabalho. Esses critérios são
relacionados a aceitação e certificação dos ativos. Mesmo atendendo aos critérios de aceitação, um
ativo pode ser classificado como “Não-Certificado”, por questões relacionadas à sua qualidade (documentação, testes etc.). A Tabela 1 apresenta alguns dos critérios de aceitação e certificação dos ativos.
Tabela 1. Critérios de Aceitação de Ativos Reutilizáveis
Critério Processos
A1
O componente soluciona uma necessidade estratégica de negócio ou “para fábrica”?
A2
O componente encapsula funções com propósitos bem-definidos e a solução é limitada ao
propósito?
A3
O componente tem potencial para reutilização em projetos futuros?
C1
O componente adere à solução proposta para fins de reutilização?
C2
O componente apresenta qualidade de documentação (ou seja, apresenta documentação técnica
com as funções, entradas e saídas relacionadas ao ativo)?
C3
O componente delimita suas fronteiras e as fronteiras de comunicação com os outros ativos
(documentação)?
130 WAMPS 2009
A Experiência de Implantação dos Processos Gerência de Reutilização e Desenvolvimento
Após a avaliação, caso seja aprovado nos critérios de aceitação e certificação estabelecidos, executase a atividade “Registrar Ativo Reutilizável”. Esta atividade consiste no armazenamento e classificação
do ativo reutilizável na base de ativos da organização. Também são associadas informações sobre o
contexto ao qual pode ser aplicado e diversas outras informações gerais sobre o componente. Em
seguida, na atividade “Identificar Interessados”, é realizada uma pesquisa dos potenciais interessados no ativo reutilizável para dar ciência sobre sua existência, permitir que haja o acompanhamento
dos problemas identificados e das melhorias realizadas no ativo, bem como a notificação sobre sua
descontinuidade, caso pertinente. Neste momento, o papel responsável pela manutenção do ativo
também é identificado.
Periodicamente, executa-se a atividade “Avaliar Base de Ativos Reutilizáveis” com o intuito de identificar os ativos menos utilizados e os ativos que receberam críticas dos usuários. A partir destes
registros, são identificadas oportunidades para realizar melhorias nos ativos reutilizáveis, bem como
são identificados ativos sujeitos à descontinuação. Apenas um critério foi definido para avaliar a
descontinuidade: “Houve a aplicação de uma melhor prática ou solução para resolver o mesmo problema de outro ativo reutilizável? Se sim, indicar qual(is) componente(s) afetado(s).” Esta atividade
pode ser executada a qualquer momento com o intuito de evoluir o ativo para uma nova versão
melhorada. Para cada ativo a ser modificado ou descontinuado, uma solicitação de mudança deverá ser registrada com as respectivas ações a serem realizadas. Essas ações são então executadas no
contexto da atividade “Modificar Ativo Reutilizável”. O responsável pela manutenção do ativo deve
realizar as atividades necessárias, inclusive todas as atividades relacionadas ao processo de gerência
de configuração que são aplicáveis aos ativos reutilizáveis da organização. Após a modificação do
ativo, executa-se a atividade “Avaliar Ativo Modificado” para verificar se o ativo evoluído continua
atendendo aos requisitos para ser caracterizado como um ativo reutilizável. Esta atividade é opcional
quando a mudança consiste apenas na descontinuidade do ativo. De acordo com a pré-atividade realizada (Registrar Ativo Reutilizável, Avaliar a Base de Ativos Reutilizáveis ou Avaliar Ativo Modificado),
e-mails são encaminhados aos interessados de cada ativo informando a situação e a ação realizada
(inclusão, alteração ou descontinuidade).
2.2. O Processo de Desenvolvimento para Reutilização
O processo inicia-se com a identificação de potenciais domínios para reutilização sistemática na organização e, a partir disso, da avaliação da capacidade efetiva de implantação de um programa de
reutilização. O programa de reutilização da organização inicia-se com a definição de uma estratégia
de reutilização da organização que inclui as metas, propósitos, objetivos e escopo de reutilização. As
atividades descritas neste processo devem ser executadas, quando aplicável, de acordo com as regras
e procedimentos definidos pelo processo Gerência de Reutilização.
A Figura 2 mostra a seqüência de atividades do processo de Desenvolvimento para Reutilização. A
organização inicia a execução do processo visando à busca do desenvolvimento de ativos reutilizáveis
identificando seus Domínios de atuação. Nesta atividade, os domínios nos quais devem ser investigadas oportunidades de reutilização ou onde se pretende praticar a reutilização na organização são
identificados e documentados. Esta atividade pode ser executada de forma periódica para garantir
que possíveis novos domínios de atuação sejam identificados de acordo com a evolução do cenário
atual e futuro de desenvolvimento de software na organização. Em geral, os domínios podem ser
refinados e ter seus escopos modificados à medida que mais informações sobre os domínios da
WAMPS 2009 131
Artigos aceitos
organização e os planos de futuros produtos de software são disponibilizadas ou quando os domínios são analisados. Em seguida, analisa-se o potencial de reutilização associado a cada um desses
domínios de atuação. Devem-se analisar, neste momento, possíveis ativos de domínio preexistentes
na organização e a possibilidade de adquirir ativos de domínio no mercado. Deve-se analisar o custobenefício de cada domínio identificado além de sua importância estratégica para a organização e
para o nível de maturidade e estabilidade do domínio em questão.
Figura 2. Processo de Desenvolvimento para Reutilização
Deve ser avaliada também a capacidade da organização em estabelecer o programa de Reutilização,
ou seja, uma vez que domínios de aplicação tenham sido identificados, deve-se garantir que haja
condições suficientes para que o programa de Reutilização sistemática na organização possa ser
executado (recursos financeiros, humanos, etc.). Caso a avaliação da capacidade da organização
não tenha resultados positivos, devem-se planejar ações corretivas visando à criação de condições
necessárias para a adoção do programa de reutilização. O gerente de reutilização deve garantir que
as ações sejam executadas, gerenciando a sua execução, conforme pertinente. Caso avalie-se que
a organização possui a capacidade de estabelecimento de um programa de Reutilização, deve-se
planejar a execução desse Programa. Neste planejamento é definido o escopo, o propósito, as metas
e os recursos necessários para alcançar as metas. Deve-se garantir que sejam previstos marcos ou
pontos de controle que permitam a monitoração da execução do programa de reutilização sistemática. O programa de Reutilização Sistemática é então executado e implantado de acordo com o
planejamento realizado. Ajustes nos planos devem ser feitos sempre que necessário de acordo com
os procedimentos de monitoração estabelecidos.
Tendo identificado domínios de aplicação e estabelecido um programa de Reutilização Sistemática
com os recursos adequados, é o momento de iniciar a documentação desses domínios. Na atividade
“Definir Forma de Representação” define-se uma notação adequada de representação dos modelos
de domínio e das arquiteturas de domínio, em diferentes níveis de abstração, a ser adotada de forma
132 WAMPS 2009
A Experiência de Implantação dos Processos Gerência de Reutilização e Desenvolvimento
a facilitar a difusão do conhecimento relacionado a um domínio específico. Utilizando as formas de
representação definidas, inicia-se o trabalho de documentação dos domínios identificados. O objetivo da atividade “Descrever Modelos de Domínio” é definir modelos de domínio para todos os domínios no escopo do programa de reutilização, de acordo com a notação previamente estabelecida.
Deve-se procurar identificar as necessidades atuais e futuras dos interessados com os produtos de
software no contexto de cada domínio. Os modelos construídos devem ser submetidos à Biblioteca
de Ativos Reutilizáveis.
A partir da identificação e documentação dos domínios de aplicação da organização, executa-se
a atividade “Desenvolver Arquiteturas de Domínio”. Nesta atividade são definidas arquiteturas de
domínio para todas as famílias de aplicações de um dado domínio identificadas a partir do detalhamento dos modelos de domínio, de acordo com a notação previamente estabelecida. O objetivo é
possibilitar a identificação de quais são os ativos de domínio e como eles se relacionam. Cada ativo de
domínio pertencente à arquitetura de domínio deve ser analisado com o intuito de perceber a sua importância para a organização. A partir dessa análise, uma priorização para a especificação dos ativos
de domínio é feita. As arquiteturas construídas também devem ser submetidas à Biblioteca de Ativos
Reutilizáveis. Os ativos de domínio identificados na arquitetura de domínio devem ser especificados
ou adquiridos seguindo a priorização previamente definida. Durante a especificação devem-se detalhar as funcionalidades do ativo de domínio de forma a viabilizar o seu desenvolvimento ou aquisição.
Depois de desenvolvidos ou adquiridos, os ativos de domínio devem ser disponibilizados na biblioteca
de ativos reutilizáveis da organização de acordo com os controles e procedimentos estabelecidos.
3. Resultados Parciais
A partir da definição dos processos de apoio descritos nas seções anteriores, foi estabelecido um plano de execução dos processos, onde foram definidos todos os recursos necessários à execução. Para
executar e controlar as atividades definidas nos processos de reutilização foi estabelecido um Grupo
de Reutilização na organização. Este grupo contava com líderes de processo (analistas de sistemas
com forte domínio/conhecimento dos sistemas da empresa) que possuíam visão dos sistemas de
apoio a cada processo de negócio da organização.
Num esforço inicial de busca em sistemas legados da organização, foram identificados 4 potenciais
ativos reutilizáveis. Destes, 3 foram aprovados nos critérios de aceitação e certificação e passaram a
fazer parte da Biblioteca de Ativos Reutilizáveis. Dados referentes à utilização desses ativos nos projetos são mantidos através de um registro de utilização. Outros possíveis candidatos a ativos reutilizáveis foram identificados, mas não foram submetidos à aprovação, pois sabia-se de antemão que não
estariam aptos à reutilização sistemática. A atividade de avaliação da Biblioteca de Ativos Reutilizáveis
foi executada, mas nenhuma modificação nos ativos foi solicitada. Também não houve registro de
descontinuidade de qualquer ativo.
Durante a execução do processo de Desenvolvimento para Reutilização, identificaram-se uma lista
inicial de 9 domínios de atuação da organização, equivalentes aos processos de negócio apoiados
pelos sistemas desenvolvidos pela empresa. Destes, apenas três foram avaliados com algum potencial
de reutilização sistemática e, por isso, foram analisados mais detalhadamente. Os demais processos
não seguem uma linha formal de desenvolvimento compatível com os princípios de reutilização. A
WAMPS 2009 133
Artigos aceitos
avaliação da capacidade de reutilização da organização mostrou que havia recursos escassos para o
estabelecimento de um programa de reutilização adequado. Porém, foi estabelecido um plano para a
execução desse programa onde foram definidos os recursos necessários para sua execução. Baseada
neste plano, a organização definiu ações para estabelecer a capacidade necessária à efetiva execução
do programa.
A elaboração dos artefatos produzidos dos processos teve o apoio de editores de texto, planilhas
eletrônicas e um sistema de controle de versão baseado em SubVersion.
Durante a implantação dos processos de reutilização na organização, alguns desafios ao programa
de reutilização foram identificados e são listados a seguir. Outros desafios conhecidos podem ser
encontrados em [SCHÄFER et al., 1994].
• Custo do Programa de Reutilização: Estabelecer um programa de reutilização não é trivial. Existe
um custo associado à busca de ativos reutilizáveis em sistemas legados da organização, documentação e padronização desses ativos, refatoração dos ativos e dos sistemas existentes para
que estes utilizem os ativos, entre outros. Trata-se de um investimento de longo prazo que pode
trazer ganhos de produtividade, mas a organização necessita fornecer os recursos adequados ao
Programa de Reutilização para que este seja efetivo.
• Capacitação dos membros do Grupo de Reutilização: Por ser uma disciplina ainda imatura na
indústria, existem poucos profissionais com conhecimento adequado de como implantar e manter um programa de reutilização. Notou-se que o desconhecimento das técnicas relacionadas à
engenharia de domínio e reutilização de software pode gerar grande impacto na efetividade do
programa.
• Estruturação do Programa de Reutilização: É necessário estruturar o programa de reutilização de
forma que este consiga ter uma visão geral dos projetos e sistemas existentes na organização.
Pôde-se perceber que muitas vezes o grupo de reutilização desconhecia projetos em execução na
organização, de forma que não era possível contribuir tanto para o projeto, fornecendo ativos
reutilizáveis, quanto para a base de ativos reutilizáveis, através da identificação de potenciais ativos reutilizáveis.
• Critérios de Avaliação dos Ativos Candidatos: Caso os critérios de avaliação dos ativos candidatos fossem muito rigorosos, nenhum ativo identificado seria certificado, o que comprometeria
a alimentação da base. Contudo, é necessário desenvolver esses ativos para que eles tenham os
padrões e qualidade suficientes para uma efetiva reutilização.
• Interesse no Programa de Reutilização: Observou-se que os grandes interessados no Programa
de Reutilização apresentavam um perfil mais técnico, já que suas atividades seriam diretamente
afetadas, de forma que era mais fácil observar os benefícios. Porém, uma iniciativa de mudança
cultural, como a de um programa de reutilização, deve contar com apoio de níveis mais altos de
gerência para que se tenha sucesso.
134 WAMPS 2009
A Experiência de Implantação dos Processos Gerência de Reutilização e Desenvolvimento
4. Conclusão
Este artigo apresentou detalhes da implementação dos processos de Gerência de Reutilização e
Desenvolvimento para Reutilização na Synapsis-Brasil. Foram detalhados os processos de apoio a
execução das atividades de reutilização de ativos dessa organização. Também foram discutidos alguns resultados da implementação e execução desses processos, objetivando a obtenção do nível C
do MPS.BR.
Diversas perspectivas futuras permeiam essa implementação dos processos de Gerência de Reutilização
e Desenvolvimento para Reutilização. Pode-se observar um número ainda reduzido de ativos reutilizáveis, sendo que estes ativos já existiam nos sistemas legados da organização. Portanto, espera-se que
no futuro esse número cresça tanto com a identificação de novos ativos reutilizáveis quanto com o
desenvolvimento de novos ativos. Outro ponto que também merece atenção refere-se às ferramentas
de apoio ao programa de reutilização. Por se tratar de uma experiência nova, foram utilizadas ferramentas de apoio pouco especializadas, como editores de texto e planilhas eletrônicas. É necessário
melhorar as formas de comunicação relativas aos processos de reutilização, já que esta ainda é feita
basicamente via e-mails enviados de forma manual. É também necessária uma ferramenta especializada que facilite o armazenamento, catalogação, busca, recuperação, manutenção e divulgação dos
ativos reutilizáveis. Uma iniciativa neste sentido pode ser encontrada em [WERNER et al., 2009].
O processo de Desenvolvimento para Reutilização foi considerado fora de escopo durante a avaliação
final devido à falta de resultados concretos sobre o desenvolvimento de ativos reutilizáveis. Espera-se
que a organização não abandone os esforços de reutilização e invista recursos no programa para que
sua capacidade de reutilização sistemática seja potencializada.
Referências
FRAKES, W. B., KANG, K., 2005, “Software Reuse Research: Status and Future”, IEEE Transactions on
Software Engineering, v. 31, n. 7, pp. 529-536.
IEEE, 2004, “Std 1517 - IEEE Standard for Information Technology - Software Life Cycle Processes Reuse Processes”, Institute of Electrical and Electronics Engineers.
KRUEGER, C.W., 1992, “Software Reuse”, ACM Computing Surveys, v. 24, n. 2 (June), pp. 131-183.
SEI, 2006, “CMMI for Development”, v 1.2, Software Engineering Institute.
SILVA FILHO, R. C., 2008, KATSURAYAMA, A. E. ; SANTOS, G., MURTA, L., ROCHA, A. R. C., “A
Experiência na Implantação do Processo de Gerência de Reutilização no Laboratório de Engenharia
de software da COPPE/UFRJ”, ProQuality (UFLA), v. 4, p. 21-26.
SOFTEX, 2007, “MPS.BR: Melhoria de Processo do Software Brasileiro”, Guia Geral v. 1.2, Disponível
em: http://www.softex.br/mpsbr.
SCHÄFER W, PRIETO-DIAZ, R., MATSUMOTO, M., 1994, “Managerial and organizational issues - starting and running a software reuse program”, cap. 3, Ellis Horwood.
MARINHO, A. S. ; SANTOS, R. P. ; SILVA, M. A. ; MURTA, L. G. P. ; WERNER, C. M. L., 2009, “Towards
a Component and Service Marketplace with Brechó Library”. Proceedings of the IADIS WWW/
Internet 2009, IADIS International Conference, Rome, Italy.
WAMPS 2009 135
Artigos aceitos
Estudo de Viabilidade de Domínio para
Avaliar o Potencial da Organização Quanto à
Implementação do Processo Desenvolvimento
para Reutilização do MR-MPS
Mylene Lisbôa Cabral, Thiago Moreira da Costa, Cláudia Maria Lima Werner {mylene, thiagom, werner}@cos.ufrj.br
COPPE/UFRJ – Universidade Federal do Rio de Janeiro Programa de Engenharia de Sistemas e Computação Av. Horácio Macedo, 2030, Prédio do Centro de Tecnologia, Bloco H, Sala 319 Caixa Postal 68511 – CEP 21941-914 – Rio de Janeiro, RJ
Resumo. A reutilização em projetos de software visa desenvolver software de qualidade, com baixo custo e
com time-to-market reduzido. Considerando a importância da introdução de reutilização no processo de desenvolvimento de software das organizações, o MR-MPS introduziu na sua versão 1.2 o processo Gerência de
Reutilização (Nível E) e o processo Desenvolvimento para Reutilização (Nível C). O processo Desenvolvimento
para Reutilização, no seu primeiro resultado esperado (DRU1), estabelece que a organização deve avaliar o
potencial de reutilização de seus domínios de atuação e decidir, por meio de um processo formal de decisão, a
adoção ou não de um programa de reutilização. O presente trabalho apresenta abordagens de estudo de viabilidade de domínio encontradas na literatura como métodos de avaliação do potencial da organização quanto
ao processo Desenvolvimento para Reutilização do MR-MPS.
1. Introdução
Para atuar no mercado atual, altamente competitivo, uma organização de software precisa desenvolver software de qualidade, com baixo custo e time-to-market reduzido. Neste contexto, os métodos
de engenharia de software tradicionais têm se mostrado inadequados e a reutilização vem sendo
considerada a melhor forma de se fazer engenharia de software (Frakes e Kang, 2005).
Considerando a importância da introdução de reutilização no processo de desenvolvimento de
software das organizações, a norma ISO/IEC 12207, que fornece um conjunto de processos de ciclo
de vida, introduziu em sua última versão (2008) os processos de reutilização de software, que incluem: Processo de Engenharia de Domínio, Processo de Gerência de Ativos Reutilizáveis e Processo
de Gerência de Programa de Reutilização (ISO/IEC, 2008). O MR-MPS (Modelo de Referência para
Melhoria de Processo do Software Brasileiro), para permanecer aderente a esta norma, também
introduziu na sua versão 1.2 o processo Gerência de Reutilização (Nível E) (SOFTEX, 2009a) e o processo Desenvolvimento para Reutilização (Nível C) (SOFTEX, 2009b).
O processo Desenvolvimento para Reutilização (DRU) do MR-MPS define em seu resultado esperado
DRU1 que “a não existência de domínios com potencial de reutilização na organização pode justificar
a não adoção de um programa de reutilização” (SOFTEX, 2009b).
136 WAMPS 2009
Estudo de Viabilidade de Domínio para Avaliar o Potencial da Organização
Neste contexto, o presente artigo propõe a utilização de abordagens de estudo de viabilidade de
domínio como mecanismo formal de tomada de decisão para avaliar o potencial da organização
com relação à adoção do processo Desenvolvimento para Reutilização (DRU). A seção 2 descreve
brevemente o resultado esperado DRU1 do processo Desenvolvimento para Reutilização (DRU) e sua
intercessão com o processo Gerência de Decisões (GDE). Na seção 3, são apresentadas quatro abordagens para o estudo de viabilidade de domínio, bem como uma tabela comparativa. A seção 4 traz
as considerações finais e a conclusão do trabalho.
2. O Processo Desenvolvimento para Reuso (DRU) no MPS.BR
A Engenharia de Domínio, também conhecida por desenvolvimento de linha de produto ou desenvolvimento de ativos de núcleo, é sinônimo de Desenvolvimento para Reutilização (Czarnecki, 2005) e
tem como proposta reduzir tempo e custo de produção e aumentar a qualidade do software através
da incorporação de ativos de domínio que já foram previamente desenvolvidos (Moon, Yeom et al.,
2005).
A primeira etapa do Desenvolvimento para Reutilização é a identificação do potencial e da capacidade de reutilização da organização, visando reduzir o risco de implantação de um programa de reutilização (SOFTEX, 2009b) Uma vez identificado que o Desenvolvimento para Reutilização se aplica, a
etapa seguinte é a análise, projeto e implementação de ativos de domínio.
O modelo de referência MPS (SOFTEX, 2009b) define o processo Desenvolvimento para Reutilização
no Nível C (Definido), que tem como propósito “identificar oportunidades de reutilização sistemática
de ativos na organização e, se possível, estabelecer um programa de reutilização para desenvolver
ativos a partir de engenharia de domínios de aplicação”. Dentre os resultados esperados da implantação adequada deste processo, o modelo espera que:
• DRU1 - Domínios de aplicação em que serão investigadas oportunidades de reutilização de ativos
ou nos quais se pretende praticar reutilização são identificados, detectando os respectivos potenciais de reutilização.
Neste resultado a organização deve identificar seus domínios de atuação e, para cada um destes
domínios, analisar seus potenciais para reutilização, levando em consideração a importância do domínio para projetos futuros, além do seu nível de maturidade e estabilidade. A não existência de
domínios com potencial de reutilização pode justificar a não adoção deste processo. Porém, esta
justificativa deve ser realizada por meio de um mecanismo formal de tomada de decisão, de acordo
com o processo Gerência de Decisões (GDE) (SOFTEX, 2009b).
O foco deste trabalho é apoiar a análise de potencialidade dos domínios da organização para a implantação de um programa de reúso, adotando o estudo de viabilidade de domínio como método
formal de avaliação.
WAMPS 2009 137
Artigos aceitos
3. Abordagens para Estudo de Viabilidade de Domínio
A partir de um estudo de revisão bibliográfica, que compreendeu pesquisa nas bases Scopus e
Compendex, além de análise de teses e relatórios técnicos sobre o tema, foram identificadas quatro
abordagens para estudo de viabilidade de implementação de programa de reutilização:
• Estudo de Viabilidade no ODM (Organization Domain Modeling) (Simos, Creps et al., 1996);
• Estudo de Viabilidade no Odyssey-DE (Braga, 2000);
• PuLSE-Eco V2.0 (Schmid, 2001).
• Avaliação de Linha de Produto Orientada a Objetivos (Geppert e Weiss, 2003);
Para complementar o estudo, as referências de cada uma das abordagens foram analisadas, com o
intuito de localizar outros trabalhos relacionados ao tema. Os artigos que citam as abordagens também foram estudados, objetivando identificar abordagens mais recentes.
A seguir serão apresentadas as abordagens para a realização de estudo de viabilidade de domínio
identificadas. Estas abordagens selecionadas têm como finalidade a seleção dos domínios com potencial de reutilização.
O fato de o estudo de viabilidade não selecionar um domínio com potencial pode significar que: (i) a
organização não possui um domínio de atuação; ou (ii) a organização ainda não está preparada para
a implementação do processo Desenvolvimento para Reutilização (DRU). Desta forma, a não seleção
de domínios com potencial de reutilização pode ser um critério de decisão para a exclusão definitiva
ou adiamento da implementação deste processo.
3.1. Estudo de Viabilidade no ODM (Simos, Creps et al., 1996)
O ODM (Organization Domain Modeling) é um modelo de processo de engenharia de domínio, cujo
objetivo principal é sistematizar aspectos chave do processo de modelagem de domínio e fornecer
um arcabouço para um ciclo de vida de engenharia de domínio.
O modelo ODM é dividido em três fases: Planejamento do Domínio, Modelagem do Domínio e
Construção da Base de Ativos. Concentraremo-nos apenas na fase Planejamento do Domínio por
nela conter um estudo de viabilidade, objeto deste trabalho.
O planejamento do domínio define três atividades principais:
• Definir objetivos: estabelece os objetivos do projeto de introdução da engenharia de domínio na
organização, bem como os stakeholders e seus interesses;
• Definir escopo do domínio: caracteriza os domínios de interesse, define critérios de seleção de domínios baseado nos objetivos do projeto e, por fim, baseado no estudo de viabilidade do domínio,
seleciona o domínio de foco;
• Definir domínio: estabelece o escopo relativo de aplicabilidade para o domínio, o escopo de características inclusas no domínio e sua relação com outros domínios.
138 WAMPS 2009
Estudo de Viabilidade de Domínio para Avaliar o Potencial da Organização
O estudo de viabilidade do ODM está contido na subfase definir escopo do domínio e é iniciado com
a identificação de domínios candidatos, baseada nos interesses dos stakeholders. Em seguida, são
documentados os critérios para seleção de domínios alinhados com os objetivos do projeto.
Nesta etapa, também é definido um mapeamento de critérios de seleção de domínios com os objetivos do projeto onde, para cada critério de seleção de domínio, é verificado se os objetivos do projeto
suportam, conflitam ou são neutros.
Com os critérios de seleção de domínio estabelecidos, definem-se pesos para cada um destes critérios
de acordo com as suas prioridades. Em seguida, realiza-se uma caracterização para cada domínio de
interesse, determinando se o domínio satisfaz ou conflita com cada um dos critérios. Baseado nos
pesos e valores registrados para cada domínio de interesse, produz-se uma lista ordenada de domínios candidatos (Tabela 1).
Caso nenhum domínio seja pontuado acima de zero, significa que a organização ainda não está
preparada para o processo Desenvolvimento para Reutilização (DRU).
Tabela 1 - Matriz Domínio/Critério
Domínios de
foco candidatos
Critérios de seleção de domínio
Total
Critério 1
Critério 2
Critério 3
Critério 4
Pesos
1
1
2
1
Domínio 1
-
+
+
+
+3
Domínio 2
-
-
+
0
+0
Domínio 3
+
+
+
+
+5
Domínio 4
-
-
+
+
+1
3.2. Estudo de Viabilidade no Odyssey-DE (Braga, 2000)
Odysey-DE é um processo de engenharia de domínio, com ênfase em DBC (desenvolvimento baseado
em componentes), que une aspectos de reutilização e entendimento do domínio, além de detalhamento do desenvolvimento de componentes.
O Odyssey-DE é organizado em cinco fases: planejamento, análise de risco, análise de domínio, projeto do domínio e implementação do domínio. Abordaremos apenas a subfase denominada Estudo
de Viabilidade de Domínio da fase Planejamento.
A primeira etapa do estudo de viabilidade do Odyssey-DE é a seleção dos domínios candidatos, que
é realizada através de um brainstorming entre especialistas de áreas estratégicas para a organização,
engenheiros de domínio e desenvolvedores de aplicações.
A próxima etapa é a seleção de critérios para avaliação de domínios. O Odyssey-DE disponibiliza alguns critérios agrupados em três áreas principais: técnicos, organizacionais e sociais. Dependendo do
domínio a ser avaliado, novos critérios, claramente justificados, podem ser agregados.
WAMPS 2009 139
Artigos aceitos
Uma vez definidos os critérios a serem avaliados, dá-se início à fase de pontuação e totalização dos
critérios de seleção. É atribuído a cada um dos critérios um peso de acordo com a sua relevância no
processo de engenharia de domínio. Em seguida, aplica-se a seguinte fórmula:
Pontuação = Peso * Valor
A pontuação total do domínio é definida pela soma da pontuação de cada critério. Baseado em projetos anteriores e/ou na experiência dos especialistas, estima-se uma pontuação mínima que deve ser
alcançada para cada domínio. Caso a pontuação para um determinado domínio fique abaixo da pontuação mínima estabelecida, isto significa que este domínio não é viável. Se nenhum dos domínios
candidatos atingirem a pontuação mínima, a introdução da engenharia de domínio na organização
deve ser adiada.
3.3. PuLSE-Eco V2.0 (Schmid, 2001)
PuLSE™ é uma metodologia para desenvolvimento de linhas de produto de software composta por
várias etapas que descrevem os processos de personalização, modelagem, definição de escopo da
linha de produto e de arquiteturas, além do desenvolvimento, evolução e gerenciamento de infraestrutura de linhas de produtos.
O PuLSE-Eco (DeBaud e Schmid, 1999) é o componente de processo do PuLSE™ responsável pela
definição do escopo da linha de produto. O PuLSE-Eco V2.0 é uma extensão deste trabalho e consiste de três fases: mapeamento da linha de produto, avaliação de potencial de domínio e escopo da
infraestrutura de reúso. Para este trabalho, concentraremo-nos apenas nas duas primeiras fases.
O mapeamento da linha de produto consiste basicamente de uma análise de domínio em alto nível.
Esta fase descreve a linha de produto, seus domínios técnicos e características relevantes, a partir
de informações existentes sobre o portfólio de produtos planejado, sistemas existentes, planos de
produtos disponíveis, conhecimento de especialistas (a partir de entrevistas) etc. Neste ponto, uma
versão inicial da matriz característica/produto é desenvolvida.
Tabela 2 - Matriz inicial de característica/produto (Schmid, 2002)
Domínio 1
Sub-domínio 1.1
Planejado
Existente
P1
P2
P3
Potencial
P4
Característica 1.1.1
X
X
X
X
Característica 1.1.2
-
X
X
X
Característica 1.1.3
X
X
-
X
…
…
…
…
…
…
Sub-domínio 1.n
Característica 1.n.1
X
-
X
X
…
…
…
…
…
Sub-domínio 2.1
Característica 2.1.1
-
X
X
-
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
Característica m.1.1
-
X
-
X
Domínio 2
140 WAMPS 2009
Estudo de Viabilidade de Domínio para Avaliar o Potencial da Organização
Por meio de um survey, os autores identificaram alguns aspectos que foram denominados dimensões
de avaliação (Tabela 3). Seguindo uma abordagem estruturada e orientada a objetivos, como GQM
(goal-question-metric) (van Solingen e Berghout, 1999), cada uma destas dimensões foi subdividida
em questões principais e questões detalhadas, em um total de 25 questões principais e 93 questões
detalhadas.
Tabela 3 - Dimensões de avaliação
Dimensões de Viabilidade
Dimensões de Benefícios
Maturidade
Potencial de mercado – externo
Estabilidade
Potencial de mercado – interno
Restrições de recursos
Similaridade e variabilidade
Restrições organizacionais
Acoplamento e coesão
Ativos existentes
Os especialistas de domínio são entrevistados fazendo uso de questionários como ilustrado na
Figura 1. As questões devem ser respondidas em uma escala estabelecida: Totalmente, Largamente,
Parcialmente, Nenhum.
Estabilidade
A. Padronização
1. Existem padrões para interfaces?
2. Existem padrões para subsistemas?
3. ...
B. ...
Figura 1- Exemplo de decomposição de avaliação
Com base nas entrevistas, é estabelecido um julgamento final dos benefícios e riscos relacionados
à implementação de reuso em cada um dos domínios e um relatório contendo quais domínios têm
maior potencial de reuso é desenvolvido.
3.4. Avaliação de Linha de Produto Orientada a Objetivos (Geppert e Weiss,
2003)
A abordagem considera que a introdução da engenharia de domínio em uma organização tem maiores chances de sucesso quando os objetivos da engenharia de domínio são diretamente derivados
dos objetivos de negócio da organização. Por esta razão, foram identificados dois objetivos que são
considerados para a seleção dos domínios: o impacto corporativo do domínio, ou seja, se o domínio
poderá ajudar a organização a alcançar seus objetivos; e a probabilidade do domínio aumentar as
chances de sucesso da engenharia de domínio.
WAMPS 2009 141
Artigos aceitos
Os objetivos de impacto corporativo e probabilidade de sucesso foram decompostos em critérios e
subcritérios mais detalhados que permitirão avaliar a adequação dos domínios da organização de
acordo com seus objetivos (Figura 2). Estes critérios foram separados em quatro categorias:
• Rentabilidade: considera o quão rentável o domínio é para a organização;
• Atividade: avalia o quão ativo um domínio é;
• Independência: quanto mais dependente um domínio for de outros, mais difícil será desenvolvê-lo
independentemente em uma linha de produtos;
• Viabilidade: leva em consideração a complexidade, maturidade, tempo e custo para desenvolvimento e restrições de recursos para o domínio.
A cada critério é atribuído um peso que define o seu grau de relevância para a engenharia de
domínio.
Baseado no paradigma GQM (goal-question-metric) (van Solingen e Berghout, 1999), um conjunto
de questões de entrevista foi definido com o intuito de obter medidas para estes critérios. Para cada
domínio candidato, as medidas são obtidas por meio de entrevista com especialistas do domínio ou,
quando possível, fazendo uso de uma base histórica. Para projetos específicos, pode ser necessário
o ajuste ou inclusão de novas questões. As questões, quando qualitativas, devem ser respondidas
dentro de uma escala de zero a um.
A graduação dos critérios é obtida por meio de fórmulas que relacionam cada critério através da
média ponderada dos valores atribuídos para seus subcritérios (Figura 2).
Figura 2 – Decomposição de objetivos em critérios de seleção de domínios
142 WAMPS 2009
Estudo de Viabilidade de Domínio para Avaliar o Potencial da Organização
Os resultados destas graduações são aplicados em mais duas fórmulas para a obtenção da graduação de cada um dos objetivos (Figura 3).
Figura 3 - Graduação dos objetivos
Com base nas graduações dos objetivos, cada domínio é alocado em um diagrama xy, onde x corresponde ao objetivo de probabilidade de sucesso e y corresponde ao objetivo de impacto corporativo
(Figura 4). Os domínios localizados no quadrante mais alto e mais à direita são aqueles considerados
mais promissores para a realização da engenharia de domínio, ou seja, aqueles com mais alto impacto corporativo e mais alta probabilidade de sucesso. Os domínios localizados no quadrante mais
baixo e mais à esquerda têm baixo potencial para reutilização.
Figura 4 – Diagrama para avaliação de objetivos
3.5. Comparação entre as Abordagens
Com o intuito de auxiliar organizações na escolha da abordagem que melhor se adéqua às suas características, uma tabela comparativa foi elaborada (Tabela 4).
WAMPS 2009 143
Artigos aceitos
Tabela 4 - Tabela comparativa das abordagens
Características
Abordagens
1*
2**
3***
4****
Critérios/questões pré-definidos
Não
Sim
Sim
Sim
Valor esperado para critério/
questão
1. Satisfaz (+) 2. Conflita (-) 3. Neutro (0)
Não especifica
1. Totalmente Entre 0 e 1
2. Largamente 3. Parcialmente 4. Nenhum
Definição de pesos para
critérios/questões
Sim
Sim
Sim
Não
Forma de totalização dos
pontos
Fórmula
Fórmula
Julgamento de
especialistas
Fórmula
Definição dos domínios
com algum potencial para
reutilização
Domínios
com maior
pontuação
Domínios com
pontuação
acima da
mínima
estabelecida
Julgamento de
especialistas
Domínios NÃO
localizados no
quadrante inferior
esquerdo do
diagrama
Definição dos domínios sem
potencial para reutilização
Domínios com
pontuação 0
(zero)
Domínios com
pontuação
abaixo da
mínima
estabelecida
Julgamento de
especialistas
Domínios localizados
no quadrante
inferior esquerdo do
diagrama
Apresenta subjetividade na
valoração de critérios/questões
Sim
Sim
Sim
Sim
Mecanismo para minimizar a
subjetividade
Não apresenta
Não apresenta
Opções préestabelecidas:
T, L, P e N
Não apresenta
* Estudo de Viabilidade no ODM. ** Estudo de Viabilidade no Odyssey-DE. *** PuLSE-Eco V2.0.
**** Avaliação de Linha de Produto Orientada a Objetivos
4. Conclusão
Este artigo apresentou quatro abordagens para estudo de viabilidade de domínio que podem ser
utilizadas como mecanismo de seleção de domínios com potencial para reutilização e mecanismo de
tomada de decisão formal para avaliar se a organização está ou não preparada para a implementação do processo Desenvolvimento para Reutilização (DRU) do MR-MPS. A adoção de uma das abordagens possibilita o atendimento do resultado esperado DRU1.
A subjetividade é um dos maiores problemas das abordagens apresentadas, pois minimiza a precisão
do estudo de viabilidade. Porém, ela pode ser reduzida com o estabelecimento de escalas de valores
para alguns dos critérios/questões definidos. Ademais, também é possível que ela seja minimizada a
cada nova execução do estudo de viabilidade, pois o conhecimento dos especialistas de domínio da
organização tende a aumentar ao longo do tempo e o histórico de execuções do estudo de viabilidade permite que ele seja calibrado constantemente.
144 WAMPS 2009
Estudo de Viabilidade de Domínio para Avaliar o Potencial da Organização
Apesar de os estudos sobre engenharia de domínio e engenharia de linha de produtos estarem em
evidência, pouca atenção tem sido dada a questões relacionadas a estudos de viabilidade. Neste
sentido, os próximos passos deste estudo são: (i) realizar uma revisão sistemática para garantir uma
cobertura maior quanto ao tema em questão; (ii) tentar definir um método de medição objetivo (sem
julgamento humano) para cada um dos critérios/questões especificados em algumas das abordagens
identificadas, a fim de eliminar a subjetividade.
Referências
Braga, R. M. M. (2000). Busca e Recuperação de Componentes em Ambientes de Reutilização de
Software. COPPE. Rio de Janeiro, Universidade Federal do Rio de Janeiro. D.Sc.: 264.
Czarnecki, K. (2005). Overview of Generative Software Development. Unconventional Programming
Paradigms: 326-341.
DeBaud, J. e K. Schmid (1999). A systematic approach to derive the scope of software product
lines. Proceedings of the 21st international conference on Software engineering. Los Angeles,
California, United States, ACM.
Frakes, W. B. e K. Kang (2005). “Software reuse research: status and future.” Software Engineering,
IEEE Transactions on 31(7): 529-536.
Geppert, B. e D. M. Weiss (2003). Goal-oriented assessment of product-line domains. Software
Metrics Symposium, 2003. Proceedings. Ninth International. Sydney, Australia, IEEE Computer
Society: 180-188.
ISO/IEC (2008). “12207: Information Technology – Software Life Cycle Processes.”
Moon, M., K. Yeom, et al. (2005). “An approach to developing domain requirements as a core asset based on commonality and variability analysis in a product line.” Software Engineering, IEEE
Transactions on 31(7): 551-569.
Schmid, K. (2001). An assessment approach to analyzing benefits and risks of product lines. Computer
Software and Applications Conference, 2001. COMPSAC 2001. 25th Annual International.
Chicago, Illinois: 525-530.
Schmid, K. (2002). A comprehensive product line scoping approach and its validation. Proceedings of
the 24th International Conference on Software Engineering. Orlando, Florida, ACM.
Simos, M., D. Creps, et al. (1996). Organization Domain Model (ODM) Guidebook, Informal Technical
Report for STARS, STARS-VC-A025/001/00.
SOFTEX (2009a). MPS.BR - Melhoria de Processo do Software Brasileiro, Guia de Implementação Parte 3. 2009.
SOFTEX (2009b). MPS.BR - Melhoria de Processo do Software Brasileiro, Guia de Implementação Parte 5. 2009.
van Solingen, R. e E. Berghout (1999). Goal/Question/Metric Method: A Practical Guide for Quality
Improvement of Software Development, McGraw-Hill Publishing Company.
WAMPS 2009 145
Trabalhos em andamento
Identificação e Seleção de Inovações
Tecnológicas e de Processo em Organizações de
Software
Cristina Cerdeiral, Ana Regina Rocha {cerdeiral, darocha}@cos.ufrj.br
COPPE/UFRJ – Universidade Federal do Rio de Janeiro Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brasil
Abstract. One of the requirements for the organizations to reach higher levels of maturity is the capability
of identifying and implementing technological innovations adequate to its business and that mean process
improvements, increasing its capability to reach quality and performance goals. However, identifying potential
innovations, selecting the adequate ones and implementing them in a reliable way, assuring the statistically
controlled sub-processes stability, the quality improvement and the return of investment are not trivial activities.
This work presents an approach to identify and select potential innovations.
Resumo. Um dos requisitos para as organizações alcançarem os níveis mais altos de maturidade é a capacidade de identificar e implantar inovações tecnológicas que sejam adequadas ao seu negócio e que signifiquem
melhorias em seus processos, aumentando sua capacidade de atingir objetivos de qualidade e de desempenho. Entretanto, identificar potenciais inovações, selecionar as adequadas e implantá-las de forma confiável,
garantindo a estabilidade dos sub-processos controlados estatisticamente, a melhoria da qualidade e o retorno
do investimento não são atividades triviais. Este trabalho apresenta uma abordagem para a identificação e a
seleção de potenciais inovações.
1. Introdução
A inovação aborda a criação e o desenvolvimento de novas idéias e soluções [Papinniemi, 1999],
transformando oportunidades em utilização prática [Tidd et al., 1997]. Inovação de processos significa desempenhar uma atividade de uma forma nova radical, e normalmente envolve a utilização
de ferramentas e tecnologias específicas para auxiliar na modelagem e transformação dos processos
de negócio [Davenport, 1993]. A inovação é considerada um dos fatores mais importantes para a
competitividade das organizações, melhorando seu desempenho [Christensen, 1997; Papinniemi,
1999; den Hengst et al., 2004; Aversano et al., 2005; Han e Kang, 2007; Khazanchi et al., 2007; Koc
e Ceylan, 2007; Brad et al., 2008]. Atualmente, com as rápidas mudanças no mercado de produtos e
serviços, a inovação de processos e produtos se torna uma necessidade [Presley et al., 2000].
Na área de Engenharia de Software, os custos com a manutenção de softwares são crescentes.
Segundo estimativas do IEEE, existem mais de 10 bilhões de linhas de código nos Estados Unidos,
custando cerca de 70 bilhões de dólares em manutenção por ano [Lerner, 1994]. Esta “crise do
software” em conjunto com a crescente demanda por software e a falta de profissionais qualificados, têm levado à criação de inovações, como novos paradigmas, métodos e ferramentas de
desenvolvimento, buscando produzir softwares com maior qualidade e em menor tempo [Agarwal
146 WAMPS 2009
Identificação e Seleção de Inovações Tecnológicas e de Processo em Organizações de Software
e Prasad, 2000]. Estas inovações de processo são novas formas de construir softwares [Fichman e
Kemerer, 1997], e variam no grau com o qual alteram o processo de desenvolvimento de software.
Atualmente, uma das grandes dificuldades na área é a adaptação às rápidas mudanças, tanto nos
paradigmas, métodos e ferramentas de desenvolvimento, como nas necessidades de negócio do
mercado e no papel que o software possui nas organizações [Lee, 1999].
Um dos requisitos para as organizações alcançarem os níveis mais altos de maturidade do MR MPS.BR [Softex,
2009] é serem capazes de identificar e implantar inovações tecnológicas que sejam adequadas a seu negócio e
que signifiquem melhorias em seus processos, aumentando sua capacidade de atingir objetivos de qualidade e
de desempenho. Entretanto, identificar potenciais inovações, selecionar as adequadas e implantá-las de forma
confiável, garantindo a estabilidade dos sub-processos controlados estatisticamente, a melhoria da qualidade
e o retorno do investimento não são atividades triviais. Se realizadas de forma não adequada prejudicam a
organização em vez de atingir a melhoria desejada.
É necessário, portanto, estabelecer um processo sistemático para identificação e seleção de potenciais
inovações bem como para sua implantação de forma confiável. Este trabalho apresenta uma abordagem para a identificação de potenciais inovações tecnológicas e de processo no mercado e na literatura e para a seleção das propostas de inovação mais adequadas ao contexto das organizações.
2. Fundamentação Teórica
2.1. Gerência de Conhecimento e Inovação no Setor de Serviços
A literatura demonstra que as empresas de serviços inovam ou ao menos desenvolvem atividades de
pesquisa, e que a importância da inovação neste setor é crescente, onde o conhecimento é a maior
fonte de competitividade [Aranda e Molina-Fernandez, 2002; Zhang e Lu, 2008]. Como as inovações
neste setor são copiadas pelas demais organizações em um curto espaço de tempo, novas inovações
são sempre necessárias para manter uma vantagem competitiva [Aranda e Molina-Fernandez, 2002].
Existem vários estudos relacionando os conceitos de inovação e gestão do conhecimento [Aranda e
Molina-Fernandez, 2002; Garcia-Muina et al., 2007; Tarafdar e Gordon, 2007; Cheng et al., 2008;
He, 2008; Johannessen, 2008; Zhang e Lu, 2008]. Abaixo são citados alguns desses estudos e seus
resultados.
Aranda e Molina-Fernadez [2002] realizam um estudo com 71 empresas de consultoria de engenharia
espanholas buscando relacionar as disciplinas de inovação e conhecimento. Três hipóteses são apoiadas pelos resultados do estudo: (i) um maior conhecimento das necessidades dos clientes aumenta o
grau de inovação das empresas (relacionando inovação e aquisição de conhecimento), (ii) melhores
tecnologias para a integração de conhecimento levam a maiores níveis de inovação (relacionando
inovação e integração de conhecimento) e (iii) pequenas percepções de necessidades de inovação
levam a esforços pequenos de inovação (relacionando inovação e aplicação do conhecimento).
Zhang e Lu [2008] estabelecem um framework conceitual para o relacionamento entre a gerência
de conhecimento dos clientes e a capacidade de inovação de serviços. Os autores definem três tipos
de conhecimento: (i) conhecimento para clientes, como o conhecimento provido pelas organizações
para satisfazer às necessidades dos clientes, (ii) conhecimento sobre clientes, como o conhecimento
para compreender as motivações dos clientes, e (iii) conhecimento de clientes, como o conhecimento
WAMPS 2009 147
Trabalhos em andamento
que os clientes possuem sobre produtos, serviços, fornecedores e mercados. O framework proposto
permite aos profissionais utilizar o conhecimento para, sobre, de clientes e co-desenvolvido com os
clientes para alcançar um desempenho superior no processo de inovação de serviços.
He [2008] realiza um estudo do tipo survey utilizando 259 questionários respondidos buscando analisar os relacionamentos entre gerência de conhecimento, o aprendizado organizacional e a inovação
organizacional. Três hipóteses são apoiadas pelos resultados do estudo: (i) a gerência do conhecimento promove a inovação organizacional, indicando que as organizações modernas devem buscar
inovações utilizando a perspectiva de gerência do conhecimento, (ii) a gerência do conhecimento
possui uma influência muito forte no aprendizado organizacional, indicando que a gerência do
conhecimento aumenta a eficiência e eficácia do aprendizado organizacional, e (iii) o aprendizado
organizacional possui um impacto muito forte e direto na inovação organizacional, demonstrando
que a gerência do conhecimento possui uma influência indireta na inovação organizacional, através
do aprendizado organizacional.
2.2. Fatores de Influência para a Adoção e Implantação de Inovações
Num mundo de conhecimento altamente distribuído, uma organização não pode correr o risco de se
basear apenas nas suas próprias pesquisas e experimentos, e sim deve comprar ou licenciar processos, idéias ou mesmo invenções de outras organizações. Além disso, inovações internas a uma organização não sendo utilizadas em negócios críticos devem ser exportadas pela organização através de
vários mecanismos benéficos, como licenças ou joint ventures [Chesbrough e Crowther, 2006; Fallah
e Lechler, 2008]. Iniciativas de inovação abertas se baseiam nestas idéias e, apesar da importância
crescente de inovações abertas e de seus benefícios para a comunidade de negócio, ainda é um
desafio fazer com que organizações participem desta iniciativa [Brad et al., 2008]. Alguns autores
buscam evidenciar a importância e os desafios do acesso às inovações e conhecimento globalizados
[Maqsood et al., 2007; Fallah e Lechler, 2008] e prover mecanismos para auxiliar a troca de conhecimento entre as organizações [Brad et al., 2008].
Rifkin [2001] analisa os motivos que levam as organizações a não adotarem inovações de processos de software. Segundo o autor, um dos principais motivos é que o que muitas das inovações de
processos de software oferecem não é estratégico para as organizações. Caso a inovação não seja
alinhada com a estratégia de negócio da organização, a adoção da inovação é menos provável de
ocorrer com sucesso.
A decisão de adotar uma nova tecnologia normalmente parte da alta gerência da organização, que
acredita que os profissionais, com o treinamento para aprender a utilizar a nova tecnologia, vão
adotá-la. Na prática, porém, vários esforços demonstram que aprender a utilizar uma nova tecnologia não é suficiente para sua utilização na organização, existindo problemas de aceitação, como a
aceitação de cada profissional à nova tecnologia [Agarwal e Prasad, 2000; Gallivan, 2002; Gallivan,
2003; Gallivan, 2004; Leiponen, 2005]. Existem vários estudos na literatura que buscam identificar
fatores que podem influenciar a habilidade de adoção de inovações pelos profissionais, como opiniões acerca das inovações [Agarwal e Prasad, 2000], estilos de criatividade dos profissionais [Gallivan,
2002], sexo dos profissionais [Gallivan, 2003], tolerância a ambigüidade e predisposição a novas experiências [Gallivan, 2004], habilidades técnicas dos profissionais [Leiponen, 2005], dentre outros.
148 WAMPS 2009
Identificação e Seleção de Inovações Tecnológicas e de Processo em Organizações de Software
Gallivan [1996] analisa as estratégias de implantação utilizadas pelos departamentos de sistema
de informação para adotar e difundir novas inovações de processos de TI para desenvolvimento de
software. Os resultados sugerem que a estratégia de implantação de inovações depende de quatro
fatores: (i) atributos individuais de quem vai adotar a inovação, (ii) tipo de inovação (de produto ou
de processo), (iii) atributos da própria inovação e (iv) complexidade ou extensão da implantação da
inovação na organização. Além disso, um conjunto de guias para estratégias apropriadas de implantação de inovações, de acordo com os fatores acima, são sugeridas.
3. Abordagem Proposta
A abordagem proposta pode ser visualizada nas figuras 1 e 2 e possui componentes para auxiliar na
identificação de oportunidades de inovação, na análise das oportunidades de inovação identificadas
e na seleção de uma oportunidade de inovação para ser implantada no próximo ciclo de melhoria de
forma controlada.
Figura 1 – Componentes para auxiliar na identificação de oportunidades de inovação
O componente “Apoio para a identificação de inovações tecnológicas de mercado e da literatura”
tem como função buscar informações na internet sobre as inovações do mercado e da literatura relacionadas com os sub-processos controlados estatisticamente nas organizações. Ele é composto de
outros componentes com funções mais específicas:
• Alertas sobre tecnologias: provê alertas com novas notícias relacionadas com as tecnologias utilizadas nas atividades dos sub-processos controlados estatisticamente nas organizações, através
WAMPS 2009 149
Trabalhos em andamento
de pesquisas na internet utilizando os mecanismos de alertas disponíveis nas máquinas de busca
[Google ; Microsoft ; Yahoo!].
• Alertas e páginas amarelas sobre autores: provê uma base do tipo páginas amarelas com os autores, suas áreas de pesquisa e páginas pessoais. Desta forma, auxilia as organizações a identificar
os autores que realizam pesquisas relacionadas com as atividades dos sub-processos controlados
estatisticamente. Além disso, o componente provê alertas específicos com novas notícias relacionadas com os autores selecionados, como novas notícias publicadas em suas páginas pessoais,
através de pesquisas na internet utilizando os mecanismos de alertas disponíveis nas máquinas de
busca [Google ; Microsoft ; Yahoo!].
• Alertas e páginas amarelas sobre congressos: provê uma base do tipo páginas amarelas com os
congressos, suas áreas de interesse e páginas oficiais, com informações como local e data de
ocorrência. Desta forma, auxilia as organizações a identificar os principais congressos nos quais
são apresentadas pesquisas relacionadas com as atividades dos sub-processos controlados estatisticamente. Além disso, o componente provê alertas específicos com novas notícias relacionadas
com os congressos selecionados, como novas notícias publicadas em suas páginas oficiais, através
de pesquisas na internet utilizando os mecanismos de alertas disponíveis nas máquinas de busca
[Google ; Microsoft ; Yahoo!]. Por último, o componente fornece um calendário para lembrar as
datas e locais dos congressos selecionados como mais importantes pelas organizações.
• Sugestões e Tendências de Pesquisa: provê sugestões de possíveis tecnologias relacionadas com as
atividades dos sub-processos controlados estatisticamente nas organizações, através da ferramenta Google Squared [Google, 2009], disponível na internet pelo Google. Além disso, o componente
provê tendências de pesquisa relacionadas com as tecnologias observadas pelas organizações,
através da ferramenta Google Insights [Google, 2008; Shimshoni et al., 2009], disponível na internet pelo Google.
O componente “Apoio para sugestões de melhorias” tem como função auxiliar as organizações a
identificar e registrar oportunidades de melhoria inovadoras em seus sub-processos controlados estatisticamente, a partir da aplicação das informações obtidas do mercado e da literatura.
Periodicamente, depois do registro de algumas oportunidades de melhoria inovadoras, são realizadas
análises destas melhorias sugeridas, buscando auxiliar as organizações na seleção de melhorias mais
adequadas ao seu contexto. O componente “Análise de Adequação com os Objetivos Estratégicos e
com os Objetivos de Capacidade e Desempenho” visa analisar cada melhoria sugerida com relação
ao atendimento dos objetivos estratégicos das organizações, e com relação ao atendimento dos
objetivos de capacidade e desempenho definidos a partir destes para os sub-processos controlados
estatisticamente. O componente “Análise de Retorno do Investimento Esperado” visa analisar o investimento necessário para implantar cada melhoria sugerida e o retorno previsto com a implantação
destas. O componente “Análise de Riscos, levando em consideração Barreiras e Facilitadores” visa
analisar os riscos da implantação de cada melhoria sugerida nas organizações, levando em consideração barreiras e facilitadores presentes na cultura e contexto das organizações para a adoção das melhorias pelos profissionais. O componente “Simulação dos Resultados” visa utilizar uma ferramenta
de simulação para avaliar os efeitos de cada melhoria no desempenho dos sub-processos controlados
estatisticamente pelas organizações.
150 WAMPS 2009
Identificação e Seleção de Inovações Tecnológicas e de Processo em Organizações de Software
Figura 2 – Componentes para auxiliar na análise das oportunidades de inovação e na seleção de uma
oportunidade de inovação para ser implantada
Para possibilitar a avaliação dos efeitos e resultados das melhorias inovadoras implantadas nas organizações, cada melhoria deve ser implantada em um ciclo de melhoria e avaliada após a sua utilização
em alguns projetos. Para auxiliar na seleção da melhoria mais adequada, o componente “Priorização
com base em Critérios” prioriza as melhorias com base em critérios definidos pelas organizações,
relacionados com as análises previamente realizadas. O componente “Seleção de uma Melhoria”
então, sugere a melhoria mais adequada ao contexto da organização.
4. Conclusão
Este trabalho apresentou uma abordagem para auxiliar as organizações desejosas de implantar inovações tecnológicas e de processos na identificação e seleção de potenciais inovações. A abordagem
se encontra em processo de refinamento e de criação de protótipos para a verificação de sua viabilidade e evolução.
Referências
Agarwal, R., Prasad, J. (2000) “A field study of the adoption of software process innovations by information systems professionals”, Engineering Management, IEEE Transactions on, v. 47, n. 3, pp.
295-308.
Aranda, D.A., Molina-Fernandez, L.M. (2002) “Determinants of innovation through a knowledgebased theory lens”, Industrial Management and Data Systems, v. 102, n. 5-6, pp. 289-296.
Aversano, L., Bodhuin, T., Canfora, G., et al. (2005) “Technology-driven business evolution”, Journal
of Systems and Software, v. 79, n. 3, pp. 314-338.
Brad, S., Fulea, M., Mocan, B., et al. (2008) “Software platform for supporting open innovation”. In:
Automation, Quality and Testing, Robotics, 2008. AQTR 2008. IEEE International Conference on,
v. 3, pp. 224-229.
WAMPS 2009 151
Trabalhos em andamento
Cheng, W., Hailin, L., Hongming, X. (2008) “An integrated model of management innovation in transition China”. In: Proceedings - ISECS International Colloquium on Computing, Communication,
Control, and Management, CCCM 2008, v. 3, pp. 304-308, Piscataway, NJ 08855-1331, United
States.
Chesbrough, H., Crowther, A.K. (2006) “Beyond high-tech: early adopters of open innovation in
other industries”, R&D Management, v. 36, n. 3 (Junho), pp. 229-236.
Christensen, C.M. (1997) The Innovator’s Dilemma: When New Technologies Cause Great Firms to
Fail., Harvard Business School Press, Cambridge.
Davenport, T., H. (1993) Process innovation: reengineering work through information technology,
Harvard Business School Press.
den Hengst, M., Hlupic, V., Currie, W.L. (2004) “The increasing need for integrating simulation and
collaboration to support change management programs”. In: System Sciences, 2004. Proceedings
of the 37th Annual Hawaii International Conference on, pp. 8 pp.
Fallah, M.H., Lechler, T.G. (2008) “Global innovation performance: Strategic challenges for multinational corporations”, Journal of Engineering and Technology Management - JET-M, v. 25, n. 1-2,
pp. 58-74.
Fichman, R.G., Kemerer, C.F. (1997) “The assimilation of software process innovations: An organizational learning perspective”, Management Science, v. 43, n. 10, pp. 1345-1363.
Gallivan, M.J. (1996) “Strategies for implementing new software processes: an evaluation of a contingency framework”, pp. 313-325, Denver, CO, USA.
Gallivan, M.J. (2002) “The influence of software developers’ creative style on their attitudes to and
assimilation of a software process innovation”, Information and Management, v. 40, n. 5, pp.
443-465.
Gallivan, M.J. (2003) “Examining gender differences in IT professionals’ perceptions of job stress in
response to technological change”, ACM, Philadelphia, Pennsylvania.
Gallivan, M.J. (2004) “Examining IT professionals’ adaptation to technological change: the influence
of gender and personal attributes”, ACM, v. 35, n. 3, pp. 28-49.
Garcia-Muina, F.E., Pelechano-Barahona, E., Navas-Lopez, J.E. (2007) “Knowledge codification
and technological innovation success: Empirical evidence from Spanish biotech companies”. In:
Portland International Conference on Management of Engineering and Technology, pp. 10621071, Portland, OR 97207 - 0751, United States.
Google (2009) “Google Alerts”. In: http://www.google.com/alerts, accessed in 23 de agosto.
Google (2009) “Google Insights for Search”. In: http://www.google.com/insights/search/, accessed
in 23 de agosto.
Google (2009) “Google Squared”. In: http://www.google.com/squared, accessed in 23 de agosto.
Han, K.H., Kang, J.G. (2007) “Two-stage process analysis using the process-based performance measurement framework and process simulation”, pp. 31-37, Busan, South Korea.
He, L. (2008) “The theoretical and empirical research on organization innovation from the knowledge
management perspective”. In: Proceedings - 1st International Workshop on Knowledge Discovery
and Data Mining, WKDD, pp. 179-184, Piscataway, NJ 08855-1331, United States.
152 WAMPS 2009
Identificação e Seleção de Inovações Tecnológicas e de Processo em Organizações de Software
Johannessen, J.-A. (2008) “Organisational innovation as part of knowledge management”,
International Journal of Information Management, v. 28, n. 5, pp. 403-412.
Khazanchi, S., Lewis, M.W., Boyer, K.K. (2007) “Innovation-supportive culture: The impact of organizational values on process innovation”, Journal of Operations Management, v. 25, n. 4, pp.
871-884.
Koc, T., Ceylan, C. (2007) “Factors impacting the innovative capacity in large-scale companies”,
Technovation, v. 27, n. 3, pp. 105-114.
Lee, D.M.S. (1999) “Information seeking and knowledge acquisition behaviors of young IS workers:
Preliminary analysis”. In: Proceedings of the 5th Americas Conference on Information Systems, pp.
856-858, Milwaukee, Wisconsin, USA, August 13-15.
Leiponen, A. (2005) “Skills and innovation”, International Journal of Industrial Organization, v. 23,
n. 5-6, pp. 303-323.
Lerner, M. (1994) “Software maintenance crisis resolution. The New IEEE Standard”, IEEE Software
Development, v. 2, n. 8 (August), pp. 65-72.
Maqsood, T., Walker, D.H.T., Finegan, A.D. (2007) “Facilitating knowledge pull to deliver innovation
through knowledge management: A case study”, Engineering, Construction and Architectural
Management, v. 14, n. 1, pp. 94-109.
Microsoft (2009) “Windows Live Alertas”. In: http://alerts.live.com/Alerts/, accessed in 23 de agosto.
Papinniemi, J. (1999) “Creating a model of process innovation for reengineering of business and manufacturing”, International Journal of Production Economics, v. 60-61, pp. 95-101.
Presley, A., Sarkis, J., Liles, D.H. (2000) “A soft-systems methodology approach for product and process innovation”, Engineering Management, IEEE Transactions on, v. 47, n. 3, pp. 379-392.
Rifkin, S. (2001) “Why software process innovations are not adopted”, Software, IEEE, v. 18, n. 4,
pp. 112-111.
Shimshoni, Y., Efron, N., Matias, Y. (2009) On the Predictability of Search Trends, Google, Israel
Labs.
Softex (2009) “MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral”.
Tarafdar, M., Gordon, S.R. (2007) “Understanding the influence of information systems competencies
on process innovation: A resource-based view”, Journal of Strategic Information Systems, v. 16,
n. 4, pp. 353-392.
Tidd, J., Bessant, J., Pavitt, K. (1997) Managing Innovation: integrating technological, managerial and
organizational change Wiley, Chichester, UK, John Wiley & Sons. Ltd (2ª edição, 2001).
Yahoo! (2009) “Yahoo! Help”. In: http://help.yahoo.com/l/us/yahoo/alerts/, accessed in 23 de
agosto.
Zhang, H., Lu, R. (2008) “A model for the relationship between customer knowledge management
and service innovation capability”. In: 5th International Conference Service Systems and Service
Management - Exploring Service Dynamics with Science and Innovative Technology, ICSSSM’08,
pp. 4598460, Piscataway, NJ 08855-1331, United States.
WAMPS 2009 153
Trabalhos em andamento
Implantação do MPS.BR (Melhoria do Processo
de Software Brasileiro), Nível F, com TFS (Team
Foundation Server) no Desenvolvimento
Eficiente de Sistemas
Larissa Lopes de Araujo e Adriana Barreto Mello {larissa, abarreto}@ecosistemas.com.br
ECO Sistemas / RioSoft Endereço: Rua Presidente Backer, 149 – 12º andar Icaraí – Niterói – Rio de Janeiro • 24220-045
Resumo. Este artigo descreve a experiência da ECO Sistemas com a implementação do MPS.BR – Melhoria
de Processos de Software Brasileiro - utilizando o TFS – Team Foundation Server, para apoiar os processos
de Gerenciamento de Projeto; Gerência de Requisitos; Garantia da Qualidade; Gerência de Configuração e
Medição. Os resultados obtidos indicam aumento de produtividade da Empresa, com ganhos de produtividade
e velocidade no desenvolvimento de softwares, além da formação de base histórica.
1. Introdução
Estamos vivendo plenamente a busca contínua por Qualidade, no aspecto mais amplo da palavra.
A qualidade do meio ambiente, da qualidade de vida, dos produtos consumidos, da sociedade em
que vivemos, do mundo em que deixamos para os nossos filhos. Qualidade nunca foi tanto querida,
almejada, desejada e trabalhada.
Antes da primeira guerra vivíamos com o conceito que qualidade era inspeção – detectar o problema
e corrigi-lo. Este conceito evoluiu na década de 50 para a garantia da qualidade, onde a prevenção do
problema com ações proativas era incentivada. Na época, gurus da Qualidade, como Joseph Juran,
conduziam cursos de controle da qualidade com o foco em Planejamento da Qualidade, Controle da
Qualidade e Melhoria Contínua. E mais, definiam conceitos, como qualidade é a conformidade aos
requerimentos do cliente, mais a adequação ao uso.
Controlar o processo, de acordo com os requisitos do cliente, para se especializar e fazer melhor, este é o conceito! A Qualidade do processo. Este conceito se popularizou e todas as Empresas buscaram agregar este valor
aos seus ativos intangíveis, procurando modelos de processos. Organizações de Classe Mundial, empresas que
se destacam no mundo por sua gestão organizacional, foram utilizadas como exemplos por adotar práticas
focadas em resultados.
A busca da excelência dos produtos oferecidos e a contribuição para a melhoria da qualidade de vida da sociedade são alvos estratégicos de toda a Organização que deseja se posicionar no mercado em que atua, principalmente a indústria de software. Por tratar a “Informação” como matéria-prima para sua evolução, a ECO
Sistemas buscou adotar uma metodologia reconhecida mundialmente como padronizadora dos seus processos
de software: o CMMI.
154 WAMPS 2009
Implantação do MPS.BR, Nível F, com TFS no Desenvolvimento Eficiente de Sistemas
Por se tratar de um conceito, Qualidade depende de vários fatores culturais, sociais e fatores inerentes à própria área de atuação da Organização. Por este motivo, aplicando a metodologia do CMMI à
realidade brasileira, a ECO decidiu pela implantação do MPS.BR (Melhoria do Processo de Software
Brasileiro), buscando alcançar os resultados esperados dos processos do nível F – Gerenciado, e com
um grande desafio: evitar processos burocráticos e o consumo exagerado de papel e inúmeras árvores de nosso planeta! Afinal, temos responsabilidade social.
A partir dos conceitos preconizados pelo PMI – Project Management Institute – foi utilizada a metodologia de gerenciamento de projetos, baseado no PMBok®. Tais metodologias foram alinhadas
com os resultados esperados dos processos MPS.BR, cuja implementação foi apoiada pela consultoria
da IOGE (Instituições Organizadoras de Grupos de Empresas) Riosoft, em 12 meses. O nosso mérito
foi aplicar todas estas técnicas à ferramenta de gerenciamento de projetos de desenvolvimento, TFS
- Team Foundation Server da Microsoft.
A idéia inicial, a utilização do TFS para implementar apenas o processo GCO (Gerência de Configuração)
caiu por terra: a ferramenta poderia apoiar um pouco mais. A ferramenta conseguiria dar apoio a
grande parte dos resultados esperados, na maioria dos Processos, tanto do modelo MPS.BR, quanto
ao modelo CMMI.
A ECO Sistemas implementou o MPS.BR – Melhoria de Processos de Software Brasileiro - utilizando o
TFS – Team Foundation Server, para apoiar os seguintes processos: GPR – Gerenciamento de Projeto;
GRE – Gerência de Requisitos; GQA – Garantia da Qualidade; GCO – Gerência de Configuração; MED
– Medição, apresentando os resultados obtidos em produtividade na Empresa, ganhando produtividade e velocidade no desenvolvimento de Softwares.
A Qualidade dos processos de softwares hoje é medida e monitorada, com ganhos de produtividade.
A utilização de documentos eletrônicos é a nossa preocupação com o meio ambiente. É a qualidade
de processo e qualidade de vida gerando ganhos para todos.
2. A TFS - Team Foundation Server
O TFS – Team Foundation Server – é uma aplicação de apoio e gerenciamento do ciclo de vida de
todo o desenvolvimento de software, da Microsoft, conhecida como ALM - Aplicattion Lifecycle
Management, para times locais ou remotos.
Construído com o objetivo de ser um repositório único de ferramentas de desenvolvimento, o TFS
apóia a equipe ao centralizar o gerenciamento do projeto e o do código fonte em um único repositório, com controle de versão e acesso, além de ser uma ferramenta de apoio ao desenvolvimento,
teste, build, deployment e controle de release, conforme apresenta a figura abaixo:
WAMPS 2009 155
Trabalhos em andamento
Figura 1. Workflow lógico do TFS – (TFSGuide 2007-08-02.2)
Utilizado em Organização com múltiplas equipes de desenvolvimentos, cada equipe gerencia seu
projeto no TFS, através do repositório separado de código fonte, com respectivas permissões de
acesso e comunicação através dos workitens e alertas.
Os workitens, ou tarefas, podem ser abertas para vários fins, dentre eles a definição dos requisitos
do software, de análise, tarefas de desenvolvimento, para o acompanhamento de bugs, de nãoconformidades encontradas, além de poder criar novos WI, otimizados.
Como infra-estrutura para a esta implantação, é necessário um servidor, para o Team Foundation
Server com um servidor de banco de dados, um servidor web e as estações de desenvolvimento,
conforme apresentado abaixo:
Figura 2. Topologia – (TFSGuide 2007-08-02.2)
O TFS é desenhado para apoiar o ciclo de vida do desenvolvimento, através da utilização de várias
facilidades como controle de acesso, work tracking, relatórios gerenciamentos de projetos e automatização de processos, além de disponibilizar poderosa ferramenta web para acesso a maioria das
funcionalidades remotamente, para qualquer nível de acesso.
156 WAMPS 2009
Implantação do MPS.BR, Nível F, com TFS no Desenvolvimento Eficiente de Sistemas
3. A implantação do modelo MPS.BR
As maiores barreiras na implantação do modelo MPS.BR são as barreiras técnicas e de conhecimento.
Inúmeros templates nos são apresentados para ser adotado para este ou para aquele resultado esperado de processo, mas qual o objetivo de cada documento? O que quero controlar?
Alguns cursos são essenciais para a adoção do modelo: Introdução ao MPS.BR (C1), contagem por
ponto de função e gerenciamento de projetos (PMP). Com os adequados conhecimentos básicos em
relação aos pontos principais a serem realizados nos processos é possível se retirar a “poeira” da burocracia e se enxergar o que realmente interessa ao controle do processo, o “filé mignon” do MPS.BR
e, assim, poder implantar soluções inteligentes aos controles, de forma automatizada e profissional.
O MPS.BR define que o nível F é Gerenciado. Para tal, é necessário implantar os seguintes processos: GPR - Gerenciamento de Projeto, GRE – Gerência de Requisitos, AQU – Aquisição (não apoiado pelo TFS e não será detalhado neste case); GQA – Garantia da Qualidade, GCO – Gerência de
Configuração e MED – Medição. Para cada resultado esperado, soluções de apoio foram encontradas
na ferramenta TFS.
4. GPR - Gerenciamento de Projeto implementado com TFS - Team
Foundation Server
O gerente do projeto acompanha facilmente a evolução das tarefas designadas, de acordo com a
atualização do tempo gasto para sua execução, com a abertura dos work itens do tipo requirement,
tasks, bugs, change request e issues, totalmente alinhado com o Project 2003.
A ferramenta permite a configuração, específica por projeto, do envio de emails automáticos, préconfigurados (Team Explorer/<nome do Projeto/Alerts), que facilitam as comunicações pertinentes
ao perfil. Por exemplo, a definição de envio de e-mail de alterações de work itens do tipo change
request, para o grupo responsável pela aprovação de mudança.
As não-conformidades podem ser aberta através de work itens do tipo Issue, e nela detectado o
impacto no projeto, descrita a análise do problema e sugerido o plano de ação corretiva. Nos casos
em que o escalonamento se torne necessário deve ser identificado no work itens e associado à nova
tarefa designada. Abaixo, resultados esperados do processo GPR apoiados no TFS:
• GPR 5: O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são
estabelecidos e mantidos. TFS: disponibilização dos histories dos documentos, criação de baselines das pastas e rastreabilidade baseada em work itens do tipo requirement, task, bugs e change
request;
• GPR 6: Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados. TFS: gerenciamento dos riscos através
de work itens do tipo risks, com sua descrição, ação de mitigação e plano de contingência;
• GPR 8: As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são
planejados. TFS: abertura de work itens do tipo requirement e task;
WAMPS 2009 157
Trabalhos em andamento
• GPR 9: Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta,
armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança. TFS: configuração da segurança de acesso, com a política de segurança (plano de Gerência de Configuração de artefatos), através do Team Members
e estrutura de diretório padronizados;
• GPR 13: (Até o nível F). O progresso do projeto é monitorado com relação ao estabelecido no
Plano do Projeto e os resultados são documentados. TFS: disponibilização dos histories dos documentos e abertura de work itens do tipo issues para a area path “monitoração”, sendo executada
no TFS, com suas respectivas atribuição de tempo realizado e vínculos aos artefatos atualizados e
ações produzidas (links a outros work itens e change set);
• GPR 14: O envolvimento das partes interessadas no projeto é gerenciado. TFS: configuração de
emails automáticos pelo TFS. Os recursos do projeto são informados sobre ações pertinentes ao
seu perfil de envolvimento no projeto, como inclusão de uma nova tarefa, task, ou uma solicitação
de mudança, change request;
• GPR 15: Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento.
TFS: revisão dos documentos nos marcos, no TFS. Após aprovação, baselines são geradas e nãoconformidades, work itens do tipo issues, para a area path “monitoração”, são abertas com este
registro. Nessas issues são detectados o impacto no projeto, a análise do problema e o plano de
ação corretiva. A solução aplicada pode ser observada no mesmo work item, assim como o link
com os artefatos porventura alterados, facilitando o acompanhamento. Para os casos em que o
escalonamento se torne necessário deve ser identificado no work item e linkado novo work item
com a tarefa designada;
• GPR 16: Registros de problemas identificados e o resultado da análise de questões pertinentes,
incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas. TFS: realizar o registro de problema identificado através do registro de work itens do tipo issue;
• GPR 17: Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão. TFS:
acompanhar os work itens do tipo issues, através da avaliação da causa do problema, descrita
no próprio work itens e sua ação corretiva, necessária para a correção definitiva do problema. Ao
final do desenvolvimento da ação, os artefatos produzidos devem ser vinculados à tarefa com seu
respectivo change set.
158 WAMPS 2009
Implantação do MPS.BR, Nível F, com TFS no Desenvolvimento Eficiente de Sistemas
5. GRE – Gerência de Requisitos implementada com TFS – Team
Foundation Server
Com o foco no gerenciamento dos requisitos, a ferramenta permite fazer a rastreabilidade entre os
requisitos do cliente, através de todas as tarefas relacionadas àqueles requisitos até o artefato final.
São criadas os work itens do tipo requirement, tasks, change request, bug, risk.
Os links entre as tarefas devem ir até o nível dos artefatos produzidos, e desta forma encontramos
rapidamente um requisito que não possua associações para seu atendimento. Abaixo, resultados
esperados do processo GRE apoiados no TFS:
• GRE 3: A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida
e mantida. TFS: gerar a rastreabilidade horizontal e vertical a partir dos work itens criados no TFS,
do tipo requirement, task, bugs, change request, conforme fluxo apresentado acima;
• GRE 4: Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar
e corrigir inconsistências em relação aos requisitos. TFS: abertura de work item, do tipo change
request, após as revisões dos planos ou após a avaliação da necessidade de qualquer alteração
nos documentos e nos requisitos;
• GRE 5: Mudanças nos requisitos são gerenciadas ao longo do projeto. TFS: gerenciar os work itens
abertos, do tipo change request, são monitorados até a sua conclusão e registradas as ações na
aba details. Após sua realização, deve ser linkado os artefatos alterados, para que seja concluída
toda a rastreabilidade, desde os requisitos até os pedidos de mudança. Outro apoio realizado pelo
TFS são os comentários de implementação de mudança de requisitos no histórico dos artefatos.
Na Figura 3 é apresentada a forma necessária da abertura dos diversos tipos de work itens para
apoiar a rastreabilidade horizontal e vertical.
WAMPS 2009 159
Trabalhos em andamento
Figura 3. Rastreabilidade dos workitens
6. GCO - Gerência de Configuração implementada com TFS – Team
Foundation Server
O TFS disponibiliza um conjunto de funcionalidade para segurança de acesso, criação de baselines,
política de check out e check in, criação das regras de acesso para grupos e usuários de acordo com
o estabelecidos no plano de gerência de configuração e histories dos documentos.
160 WAMPS 2009
Implantação do MPS.BR, Nível F, com TFS no Desenvolvimento Eficiente de Sistemas
Outro benefício que a ferramenta nos trás é a criação de baselines para apoiar o processo de auditoria. A baseline é criada com a aplicação de um label, na pastas main, sendo composta pelo código
fonte da aplicação (source) e da sua documentação (DNs – Documentos Normatizados).
A padronização dos diretórios é a forma de garantir que os documentos formais e códigos fontes de
uma versão estão na baseline, através das estruturas filhas ao diretório Main.
Outro processo importante é a política de check out e check in, possibilitando a manipulação de
documentos com controle. A cada check in é gerada um change set, possibilitando a visualização do
documento alterado. Abaixo, resultados esperados do processo GCO apoiados no TFS:
• GCO 1: Um Sistema de Gerência de Configuração é estabelecido e mantido. TFS: a ferramenta;
• GCO 2: Os itens de configuração são identificados. TFS: definição de níveis de acesso dos colaboradores no TFS, aos artefatos organizacionais;
• GCO 3: Os itens de configuração sujeitos a um controle formal são colocados sob baseline. TFS:
aplicação dos itens de configuração do projeto e organizacional sob gestão de configuração no
TFS e baselines formais da ferramenta;
• GCO 4: A situação dos itens de configuração e das baselines é registrada ao longo do tempo e
disponibilizada. TFS: criação e disponibilização de baselines, estrutura de rastreabilidade criadas a
partir dos work itens e abertura de não-conformidades com work itens do tipo issues;
• GCO 5: Modificações em itens de configuração são controladas e disponibilizadas. TFS: abertura
de não-conformidades com work itens do tipo issues com seus respectivos planos de ação e documentos controlados por gestão de configuração;
• GCO 6: Auditorias de configuração são realizadas objetivamente para assegurar que as baselines
e os itens de configuração estejam íntegros, completos e consistentes. TFS: criação de baselines
das pastas e rastreabilidade;
• GCO 7: O armazenamento, o manuseio e a liberação de itens de configuração e baselines são
controlados. TFS: disponibilização dos histories dos documentos, criação de baselines das pastas,
buildings e rastreabilidade.
7. GQA – Garantia de Qualidade implementada com TFS – Team
Foundation Server
A ferramenta realiza toda gestão das não-conformidades abertas nas avaliações de GQA, com a
abertura de work itens do tipo issues, com suas respectivas avaliação de causas e plano de ação, assim como a disponibilização de relatórios específicos para a monitoração destas atividades. Abaixo,
resultados esperados do processo GQA apoiados no TFS:
• GQA 1: A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é
avaliada objetivamente, antes dos produtos serem entregues ao cliente e em marcos predefinidos
ao longo do ciclo de vida do projeto. TFS: abertura de work itens do tipo issues, com a avaliação
WAMPS 2009 161
Trabalhos em andamento
da causa do problema, e descrição da ação corretiva necessária, com o acompanhamento até a
resolução e avaliação da eficácia da ação. Ao final do desenvolvimento da ação, os artefatos produzidos devem ser vinculados à tarefa com seu respectivo change set.
• GQA 2: A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente. TFS: abertura de work itens do tipo issue;
• GQA 3: Os problemas e as não-conformidades são identificados, registrados e comunicados. TFS:
abertura de work itens do tipo issue e agendamento de calendário com envio de e-mail;
• GQA 4: Ações corretivas para não-conformidades são estabelecidas e acompanhadas até as suas
efetivas conclusões. Quando necessário, o escalonamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução. TFS: abertura de work itens do tipo issue,
conforme detalhamento acima, calendário com envio de e-mail automático, histories, com todas
as ações realizadas e por quem, relatórios de issues, além da política de acesso aos artefatos.
8. MED – Medição implementada com TFS – Team Foundation Server
O TFS realiza o controle das agendas, com envio alerta, facilitando a comunicação nos marcos. O
repositório das medições é gerido no source control, com confiabilidade e registrando seus histories.
Abaixo, resultados esperados do processo MED apoiados no TFS:
• MED 1: Objetivos de medição são estabelecidos e mantidos a partir dos objetivos da organização
e das necessidades de informação de processos técnicos e gerenciais. TFS: registro dos calendários
com envio de e-mails de alerta;
• MED 2: Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado
e/ou definido, priorizado, documentado, revisado e atualizado. TFS: utilização do source control;
• MED 3: Os procedimentos para a coleta e o armazenamento de medidas são especificados. TFS:
Registro dos calendários com envio de e-mails de alerta e política de acesso, através da utilização
do source control;
• MED 5: Os dados requeridos são coletados e analisados. TFS: armazenamento das medidas coletadas no TFS, com respectivos controle de acesso;
• MED 6: Os dados e os resultados de análises são armazenados. TFS: armazenamento das medidas
coletadas no TFS, com respectivos controle de acesso e histories;
• MED 7: As informações produzidas são usadas para apoiar decisões e para fornecer uma base
objetiva para comunicação aos interessados. TFS: abertura de não-conformidade, work itens do
tipo issues, para a area path “MED”, com a análise da causa e o plano de ação corretiva.
162 WAMPS 2009
Implantação do MPS.BR, Nível F, com TFS no Desenvolvimento Eficiente de Sistemas
9. Resultado
Podem ser elencados diversos resultados que o próprio modelo MPS.BR preconiza. Todos foram
atingidos: um efetivo controle sobre as horas, onde o desvio médio apresentado nos projetos foi de
25%; o efetivo controle de versões; comparativos entre o orçado e o realizado, onde chegamos a
uma média de valor de custo de software de R$ 40.000,00; a produtividade real do ponto de função,
na organização, que foi estimada no início por 10h/PF, mas foi recalculada, com base histórica para
6,5h/PF: a rastreabilidade real de requisitos, documentos e códigos-fonte.
Retirada a poeira da dificuldade em se implementar este modelo, através da quebra de paradigmas
organizacionais (barreiras internas), com a mudança de ferramenta de gestão e de produção de
software, e capacitação de muita gente, verifica-se que alcançamos o nosso objetivo maior: garantir
o desenvolvimento eficiente de sistemas, com identificação de seu tamanho (foram construídos
sistemas que variam de 165 PF à 440 PF), custo e identificação exata do tempo médio de desenvolvimento, variando de 4 meses à 6 meses de desenvolvimento. E com ganhos de Qualidade, com uma
média de bugs encontrados de 12% por ponto de função.
Controles que, muitas vezes, poderiam resultar em uma redução da produtividade, tornaram-se
transparentes por estarem automatizados com TFS, propiciando a segurança dos dados e integração
dos diversos atores responsáveis em um processo de desenvolvimento eficiente de produtos.
Esta percepção, além da redução do tempo de implantação do MPS.BR, é refletida na própria consolidação da contagem por ponto de função na conclusão do projeto, cujo indicador organizacional
de produtividade por ponto de função é base para futuras estimativas.
A implementação do MPS.BR alinhado com a ferramenta TFS – Team Foundation Server garante o
Desenvolvimento Eficiente de Sistemas.
10. Referências
SOFTEX. MPS – Melhoria do Processo de Software Brasileiro. Guia Geral V.1.2. Disponível em: <http://www.softex.br/mpsbr/_guias/default.asp >. Acesso em: 20 nov 2008.
Project Management Institute, Product Team of. Um conjunto de Conhecimentos sobre Gerenciamento
de Projetos (Guia PMBok®). Terceira Edição. Project Management Institute, Four Campus Boulevard,
Newtown Square, © 2004. PA 19073-3299 EUA.
Minium, Dennis. Team Foundation Server Fundamentals: A Look at the Capabilities and Architecture.
Program Manager, Visual Studio Team System, January 2005. Disponível em: <http://msdn. microsoft.com/en-us/library/ms364062(VS.80).aspx>, Último acesso: 29/09/2009.
Microsoft Corporation, Product Team of. Work Item Tracking in Microsoft Visual Studio 2005 Team
System. Microsoft Corporation, September 2005. Disponível em: <http://msdn.microsoft.com/ en-us/library/ms364081(VS.80).aspx>, Último acesso: 29/09/2009.
WAMPS 2009 163
Trabalhos em andamento
Uma Proposta de Mapeamento dos Processos
Existentes no Guia de Aquisição do MPS.BR e no
CMMI-ACQ
Julio Cezar Costa Furtado1,2, Sandro Ronaldo Bezerra Oliveira1,2
[email protected], [email protected]
Programa de Pós-Graduação em Ciência da Computação (PPGCC) – Universidade Federal do Pará (UFPA)
Rua Augusto Corrêa, 01 - Guamá - Belém - PA - Brasil
1
SWQuality Consultoria e Sistemas Ltda.
Av. Barbosa Lima, n. 149 - Recife - PE - Brasil
2
Resumo. Este artigo vem apresentar uma proposta para mapeamento dos processos de aquisição e serviços
existentes, aderente às orientações fornecidas pelo modelo MPS.BR, em seu Guia de Aquisição, e aderente ao
CMMI-ACQ. Este resultado é exposto na forma de um estudo comparativo entre os modelos com um mapeamento entre as atividades em busca de equivalências. Por fim, é apresentada uma análise da proposta, com os
principais resultados esperados, assim como seus pontos fortes e fracos.
1. Introdução
Muitas organizações têm necessidades específicas que os produtos comerciais de prateleira
(Commercial of the Shelf Software – COTS) e os produtos modificáveis de prateleira (Modified of
the Shelf Software – MOST) nem sempre estão aptos a contemplar [Guerra & Alves 2004]. Assim, as
organizações se vêem obrigadas a procurar uma maneira de desenvolver este produto que atenda às
suas necessidades e muitas vezes a solução mais eficiente, ou economicamente viável, é a terceirização deste serviço.
Assim surgiu a necessidade do adquirente ter um maior acompanhamento sobre este processo de
compra. E junto com esta necessidade surgiram também os modelos, guias e normas que visam
orientar as organizações com as boas práticas para o processo de aquisição de Software e Serviços
Correlatos (S&SC), no qual se pode citar os processos sobre aquisição no modelo CMMI (Capability
Maturity Model Integration) [SEI 2001], MPS.BR (Melhoria do Processo de Software Brasileiro) [SOFTEX
2009a], na norma ISO/IEC 12207 [ISO 2008] e modelos específicos para aquisição, como o SA-CMM
(Software Acquisition Capability Maturity Model) [Copper & Fisher 2002], CMMI-ACQ [SEI 2006] e o
Guia de Aquisição do MPS.BR [SOFTEX 2009b]. Estes dois últimos são o foco do estudo realizado.
Neste contexto, adotar um modelo específico para aquisição de software baseado nas melhores práticas existentes nesta área promove a mitigação dos problemas mais comuns encontrados, tendo em vista que a maioria
das organizações adquirentes de S&SC enfrenta sérios problemas para orçar, licitar, contratar e gerir de maneira
adequada os projetos para desenvolvimento dos produtos de software que precisam construir [Guerra & Alves
2004]. Ocorrendo, assim, casos onde o S&SC adquirido não atende devidamente os objetivos para os quais foi
desenvolvido ou possui custo bem mais elevado do que o esperado. Existe também uma grande dificuldade
para acompanhar o processo de desenvolvimento junto ao fornecedor.
164 WAMPS 2009
Uma Proposta de Mapeamento dos Processos Existentes no Guia de Aquisição do MPS.BR e no CMMI-ACQ
Este artigo tem como objetivo fornecer um mapeamento entre os processos estudados que servirá de base
para oferecer uma proposta de definição de um processo específico para aquisição, flexível à cultura da organização, que englobe as boas práticas dos modelos em estudo. Processo este que será sistematizado em uma
ferramenta de software livre para apoio. Com essa suite de processo e ferramenta, o objetivo é simplificar a
implantação de processos para aquisição em organizações com pouca ou nenhuma experiência em engenharia
de software e gerência de projetos.
O artigo está estruturado nas seguintes seções: a Seção 2 fornece a fundamentação sobre processo
de aquisição e uma breve explicação sobre os modelos deste estudo; a Seção 3 trata sobre o estudo
comparativo entre os dois modelos; na Seção 4 a proposta deste trabalho é exposta, assim como sua
análise; e a Seção 5 aborda as considerações finais sobre o trabalho.
2. O Processo de Aquisição
Segundo Humphrey (1989), a busca pela qualidade em software tem sido realizada em duas direções: a qualidade do processo, que tem foco nos processos geradores do produto como forma de
obter a melhoria da qualidade; e a qualidade do produto, que se baseia na busca e identificação das
características tangíveis dos produtos a serem desenvolvidos, estabelecendo-se, a partir delas, diretrizes que nortearão o processo de desenvolvimento.
O processo de software é um conjunto de atividades realizadas para construir software, levando em
consideração os produtos sendo construídos, as pessoas envolvidas e as ferramentas com as quais
trabalham.
Para o processo de aquisição de software, a qualidade deve-se compreender da adequação deste
software adquirido às necessidades da empresa adquirente, sejam estas necessidades funcionais,
não-funcionais ou mesmo gerenciais, como custo e prazo de implantação.
O propósito do processo de aquisição é adquirir o S&SC que atenda às necessidades expressas pelo
cliente e assegurar a qualidade do produto de software. O foco principal do processo de aquisição é a
seleção do fornecedor e o acompanhamento dos produtos e processos, com o objetivo de assegurar
a qualidade do produto que está sendo adquirido.
A aquisição de produtos e serviços de software é um processo complexo, principalmente no que diz
respeito à caracterização dos requisitos necessários ao Software e Serviços Correlatos e às condições
envolvidas na contratação como, por exemplo, qualidade esperada, forma de aceitação, gestão de
mudanças, artefatos esperados, entre outros [SOFTEX 2009b]. O Processo de Aquisição de Software
define os passos para se obter um sistema ou serviço, e todas as atividades efetuadas pelo comprador durante o ciclo de vida do projeto. Esse processo é iniciado com a definição da necessidade de
adquirir um sistema, um produto ou um serviço de software.
Por esta razão, normas e modelos foram desenvolvidos visando apoiar e orientar as organizações
fornecedoras e adquirentes quanto à melhoria de processos. A seguir será apresentada uma contextualização dos processos do Guia de Aquisição do MPS.BR e do CMMI-ACQ.
WAMPS 2009 165
Trabalhos em andamento
2.1. O Guia de Aquisição do MPS.BR
O modelo MPS.BR tem como base os conceitos de maturidade e capacidade de processo para a
avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos
[SOFTEX 2009a]. Assim, o modelo possui três componentes: o Modelo de Referência do MPS.BR, o
Método de Avaliação do MPS.BR e o Modelo de Negócios; que são descritos através dos guias: Guia
Geral, Guia de Avaliação, Guia de Implementação e o Guia de Aquisição.
Em se tratar do Guia de Aquisição, este descreve um processo de aquisição de software que pode ser
adaptado à realidade das empresas fornecedoras de software que tenham sido avaliadas de acordo
com o MA-MPS ou modelo equivalente. O processo é subdividido em quatro atividades: Preparação
da Aquisição, Seleção do Fornecedor, Monitoração do Contrato e Aceitação pelo Cliente. O mesmo
é destinado, mas não limitado, a instituições interessadas em aquisição de S&SC, especialmente para
contextos onde o adquirente não tem experiência com desenvolvimento de software.
A introdução da aquisição de S&SC, como parte do MPS.BR, tem como finalidade orientar as organizações que adquirem S&SC, por meio de um processo de aquisição onde são descritas as atividades
e tarefas fundamentais para a garantia da qualidade do contrato e respectivos produtos e serviços
entregues pelo fornecedor [SOFTEX 2009b].
O guia, também, fornece orientações sobre as tarefas previstas para se atingir os objetivos e obter os
resultados previstos de cada atividade, assim como os produtos requeridos para executar cada tarefa
prevista na atividade e os produtos gerados pela execução da atividade.
2.2. O CMMI-ACQ
O CMM é um modelo de maturidade de processo baseado na capacidade da organização de definir, gerenciar e melhorar seus processos. A experiência do SEI (Software Engineering Institute) com
os modelos CMM possibilitou a evolução para o modelo CMMI, que apresenta os modelos: CMMI
for Service (CMMI-SVC), publicado em 2009, e foca no estabelecimento de um serviço, gerência e
entrega; o CMMI for Developer (CMMI-DEV), publicado em 2006, com foco em desenvolvimento
do produto; e o CMMI for Acquisition (CMMI-ACQ), publicado em 2007, com foco no processo de
aquisição e terceirização de bens e serviços.
O modelo CMMI-ACQ fornece orientação para a aplicação das melhores práticas do CMMI por parte
do adquirente. Embora os fornecedores possam dispor de artefatos úteis para gerir os processos
abordados pelo modelo, o foco principal é integrar os padrões de conhecimento que são essenciais
para um adquirente [SEI 2006].
Ao integrar esses padrões de conhecimento, o modelo fornece um conjunto abrangente das melhores
práticas para a aquisição de produtos e serviços. O CMMI-ACQ possui 22 áreas de processo, onde 6
áreas focam nas práticas específicas para aquisição: Gerenciamento do Contrato, Desenvolvimento de
Requisitos para Aquisição, Gerenciamento Técnico da Aquisição, Validação da Aquisição, Verificação
da Aquisição e Solicitação e Acordo de Desenvolvimento com o Fornecedor.
166 WAMPS 2009
Uma Proposta de Mapeamento dos Processos Existentes no Guia de Aquisição do MPS.BR e no CMMI-ACQ
3. Estudo Comparativo
Tendo em vista que o modelo CMMI é um modelo para aquisição de software mais abrangente que o
processo de aquisição proposto pelo MPS.BR, esse estudo apenas tratará da comparação das 6 áreas
específicas para aquisição do CMMI com o Guia de Aquisição do MPS.BR
A comparação foi feita tomando as atividades do MPS.BR como base e mostrará como o equivalente
é atingido pelo CMMI-ACQ, tomando como foco os objetivos específicos e práticas do mesmo.
3.1. Preparação da Aquisição
A primeira atividade descrita no MPS.BR é a Preparação da Aquisição. Esta atividade é fundamental
para o estabelecimento da estratégia para a condução de todo o processo de aquisição, pois nesta
atividade se define as necessidades e requisitos da aquisição, assim como, comunica-os aos possíveis
fornecedores.
Dentro do CMMI-ACQ, esta atividade é contemplada pelo atendimento dos objetivos específicos
SG1, SG2 e SG3 da área de processo Desenvolvimento de Requisitos, que tem como propósito o
desenvolvimento e análise dos requisitos do comprador e de contrato, e o objetivo específico SG1 da
área de processo Solicitação e Acordo de Desenvolvimento com o Fornecedor, onde serão especificados os critérios para seleção do fornecedor dentro do pacote de solicitação.
A Tabela 1 exibe o relacionamento das tarefas necessárias para a conclusão desta atividade do MPS.
BR com as das áreas de processo envolvidas no CMMI-ACQ, mostrando a equivalência.
Tabela 1. Relacionamento das tarefas de Preparação da Aquisição
Guia de Aquisição do MPS.BR
CMMI-ACQ
Estabelecer as necessidades: determina quais
os objetivos a serem atendidos com a aquisição.
Essa atividade tem como propósito analisar as
necessidades e resultados que o adquirente
pretende atingir com a aquisição. Essa etapa é
fundamental, pois indica a primeira tomada de
decisão referente aos objetivos e os resultados
esperados durante o andamento da aquisição.
Desenvolvimento de Requisitos para Aquisição
SG 1 Gerenciar requisitos do cliente SP 1.1 Elicitar necessidades dos interessados
Definir os requisitos: identifica os requisitos
do adquirente para o S&SC. Essa etapa deve
especificar os requisitos a serem considerados.
Desenvolvimento de Requisitos para Aquisição
SG 1 Gerenciar requisitos do cliente SP 1.2 Desenvolver e priorizar as necessidades dos clientes SG 2 Desenvolver os requisitos contratuais SP 2.1 Estabelecer os requisitos contratuais SP 2.2 Alocar exigências contratuais
WAMPS 2009 167
Trabalhos em andamento
Revisar requisitos: analisar os requisitos
estabelecidos com relação às necessidades
da aquisição. Etapa com o intuito de validar
os requisitos para reduzir problemas e não
entendimento por parte dos fornecedores.
Desenvolvimento de Requisitos para Aquisição
SG 3 Analisar e validar os requisitos SP 3.1 Estabelecer conceitos e cenários operacionais SP 3.2 Analisar requisitos SP 3.3 Analisar requisitos para atingir o equilíbrio SP 3.4 Validar requisitos
Desenvolver uma estratégia de aquisição:
desenvolver uma estratégia para comparar as
necessidades esperadas com a aquisição. A
apresentação da estratégia será através do plano
de aquisição para a elaboração do pedido de
proposta, que contempla itens como: termos
financeiros, termos contratuais, termos técnicos,
critérios de aceitação do S&SC.
Atendido pelo processo Project Planning (PP),
do modelo CMMI, não sendo um dos processos
específicos para Aquisição.
Definir os critérios de seleção de
fornecedores: estabelecer critérios de seleção,
bem como a forma de avaliação.
Solicitação e Acordo de Desenvolvimento com
o Fornecedor
SG 1 Preparar solicitação e acordo com fornecedor SP 1.1 Identificar potenciais fornecedores SP 1.2 Estabelecer um pacote de solicitação SP 1.3 Revisar o pacote de solicitação SP 1.4 Distribuir e manter o pacote de solicitação
3.2. Seleção do Fornecedor
O propósito da atividade de Seleção do Fornecedor é selecionar o fornecedor que será responsável
pelo desenvolvimento e entrega do S&SC. A execução desta atividade busca identificar o fornecedor
ideal levando em consideração os requisitos e o plano da aquisição, definidos na atividade anterior.
No CMMI-ACQ, a atividade se equivale aos objetivos específicos SG2 e SG3 da área de processo
Solicitação e Acordo de Desenvolvimento com o Fornecedor, com o propósito de avaliar as soluções
dos possíveis fornecedores e selecionar a melhor, negociando assim um contrato entre as partes, e
com o objetivo específico SG1 da área de processo Gerenciamento de Contrato, onde esse acordo
contratual negociado será efetivado.
A Tabela 2 exibe o relacionamento das tarefas necessárias para a conclusão desta atividade do MPS.
BR com as das áreas de processo envolvidas no CMMI-ACQ.
168 WAMPS 2009
Uma Proposta de Mapeamento dos Processos Existentes no Guia de Aquisição do MPS.BR e no CMMI-ACQ
Tabela 2. Relacionamento das tarefas de Seleção do Fornecedor
Guia de Aquisição do MPS.BR
CMMI-ACQ
Avaliar a capacidade dos fornecedores: analisar
as características dos fornecedores mediante aos
requisitos e critérios aplicados para a seleção de
fornecedores.
Solicitação e Acordo de Desenvolvimento com
o Fornecedor
SG 2 Selecionar fornecedores SP 2.1 Avaliar soluções propostas
Selecionar o fornecedor: selecionar o fornecedor
a partir da avaliação das propostas recebidas,
considerando fatores como o entendimento do
problema e as devidas soluções sugeridas conforme
os requisitos determinados para o S&SC.
Solicitação e Acordo de Desenvolvimento com
o Fornecedor
SG 2 Selecionar fornecedores SP 2.3 Selecionar o fornecedor
Preparar e negociar um contrato: negociar um
contrato com o potencial fornecedor selecionado,
mostrando as expectativas do adquirente e as
responsabilidades de ambas as partes envolvidas
(adquirente e fornecedor).
Solicitação e Acordo de Desenvolvimento com
o Fornecedor
SG 2 Selecionar fornecedores SP 2.2 Estabelecer plano de negociação SG 3 Estabelecer acordo com o fornecedor SP 3.1 Estabelecer um entendimento do acordo SP 3.2 Estabelecer acordo com o fornecedor
3.3. Monitoração do Contrato
A atividade de Monitoração do Contrato tem como objetivo garantir a interação entre o adquirente e
o fornecedor e monitorar o fornecedor para garantir que o desenvolvimento do S&SC esteja conforme os termos acordados no contrato. O monitoramento e a avaliação realizada durante o processo
auxiliam a identificar os problemas além de permitir a tomada de decisões gerenciais para minimizar
riscos futuros.
Dentro do CMMI-ACQ, a equivalência se dá através dos objetivos específicos SG1 e SG2 da área
de processo Gerenciamento Técnico da Aquisição, onde é executada a avaliação técnica de suas
soluções e produtos, com o objetivo específico SG1 de Gerenciamento de Contrato, onde ocorre a
monitoração dos processos do fornecedor, assim como a aderência aos termos e as condições contratuais são verificadas. Também através dos objetivos específicos da área de processo de Verificação
da Aquisição.
A Tabela 3 exibe o relacionamento das tarefas necessárias para a conclusão desta atividade do MPS.
BR com as das áreas de processo envolvidas no CMMI-ACQ.
WAMPS 2009 169
Trabalhos em andamento
Tabela 3. Relacionamento das tarefas de Monitoração da Aquisição
Guia de Aquisição do MPS.BR
CMMI-ACQ
Estabelecer e manter comunicações:
manter uma canal de comunicação
entre o adquirente e o fornecedor. Etapa
fundamental para determinar a forma
de comunicação entre as partes (por
exemplo, cronograma, documentos
utilizados reuniões).
Gerenciamento Técnico da Aquisição
SG 2 Realizar gestão de interface SP 2.1 Selecionar interface para gerenciar SP 2.2 Gerenciar interface selecionada Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.1 Executar o acordo com o fornecedor
Trocar informações sobre o progresso
técnico: utilizar o canal estabelecido
para trocar informações técnicas com o
fornecedor, além de verificar informações
de custo e auxiliar na identificação de
possíveis riscos. Essa troca de informação
geralmente ocorre nas atividades típicas
do desenvolvimento do projeto (por
exemplo, reuniões, levantamento de
requisitos).
Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.2 Monitorar os processos do fornecedor selecionado Gerenciamento Técnico da Aquisição
SG 1 Avaliar soluções técnicas SP 1.1 Selecionar soluções técnicas para análise Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.1 Executar o acordo com o fornecedor
Revisar o desempenho do fornecedor:
realizar frequentemente inspeções para
avalizar junto ao fornecedor questões
técnicas, questões de qualidade,
questões de custo e de prazo durante o
desenvolvimento do S&SC, tendo como
base os termos do contrato. A inspeção é
um evento formal que ocorre durante o
projeto. Essa atividade pode ser executada
pelo próprio adquirente ou dependendo
dos casos, pode requerer avaliação de
terceiros.
Gerenciamento Técnico da Aquisição
SG 1 Avaliar soluções técnicas SP 1.2 Analisar soluções técnicas selecionadas SP 1.3 Realizar revisões técnicas Verificação da Aquisição
SG 1 Preparar a verificação SP 1.1 Selecionar produtos de trabalho para verificação SP 1.2 Estabelecer o ambiente de verificação SP 1.3 Estabelecer critérios e procedimentos de verificação SG 2 Executar revisões por pares SP 2.1 Preparar revisão por pares SP 2.2 Conduzir revisão por pares SP 2.3 Analisar dados da revisão por pares SG 3 Verificar produtos de trabalho selecionados SP 3.1 Executar verificação SP 3.2 Analisar os resultados da verificação
Monitorar a aquisição: A monitoração
é utilizada como base para tomada
de eventuais ações gerenciais, como
revisão de prazos, alocação de recursos,
aplicação de penalidades ou até mesmo a
interrupção do contrato.
Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.1 Executar o acordo com o fornecedor SP 1.2 Monitorar os processos do fornecedor selecionado
Obter acordo quanto às alterações:
negociar as alterações propostas por
qualquer uma das partes, seja ela o
adquirente ou fornecedor e documentar
os resultados no contrato.
Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.1 Executar o acordo com o fornecedor
170 WAMPS 2009
Uma Proposta de Mapeamento dos Processos Existentes no Guia de Aquisição do MPS.BR e no CMMI-ACQ
Acompanhar problemas: registrar a
execução dos problemas que surgirem
durante a execução do contrato e
acompanhar até solução pelas partes.
Ações sobre os dados obtidos ajudam
evitar a ocorrência de problemas,
melhorando a qualidade e eficácia do
processo adotado.
Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.1 Executar o acordo com o fornecedor SP 1.2 Monitorar os processos do fornecedor selecionado
3.4. Aceitação pelo Cliente
A atividade de Aceitação pelo Cliente tem o propósito de validar e aprovar o S&SC entregue pelo
fornecedor mediante todos os critérios estabelecidos. Não havendo conformidade com os critérios
estipulados, o S&SC pode sofrer alterações e ajustes para que seja submetido a uma nova validação,
até que tudo esteja de acordo e satisfeito por parte do adquirente.
As áreas de processo do CMMI-ACQ que possuem equivalência ao MPS.BR nesta atividade, são a
Gerência de Contrato, com o objetivo específico SG1, a Validação de Aquisição e Verificação da
Aquisição, ambas com todos os seus objetivos envolvidos. A relação é visualizada na Tabela 4.
Tabela 4. Relacionamento das tarefas de Aceitação pelo Cliente
Guia de Aquisição do MPS.BR
CMMI-ACQ
Preparar a aceitação: estabelecer
os critérios e a forma de aceitação do
S&SC. Os critérios são definidos em
relação aos requisitos do contrato. Essa
atividade tem uma relação entre os
requisitos especificados e as funções do
produto que foram implementadas.
Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.1 Executar o acordo com o fornecedor Validação da Aquisição
SG 1 Preparar a validação SP 1.1 Selecionar produtos para validação SP 1.2 Estabelecer a validação do ambiente SP 1.3 Estabelecer os critérios e procedimentos de validação Verificação da Aquisição
SG 1 Preparar a verificação SP 1.1 Selecionar produtos de trabalho para verificação SP 1.2 Estabelecer o ambiente de verificação SP 1.3 Estabelecer critérios e procedimentos de verificação
WAMPS 2009 171
Trabalhos em andamento
Avaliar o S&SC entregue: avaliar
o S&SC com base nas informações e
requisitos de aceitação definidos.
Validação da Aquisição
SG 2 Validar componentes e produtos selecionados SP 2.1 Executar validação SP 2.2 Analisar os resultados da validação Verificação da Aquisição
SG 2 Executar revisões por pares SP 2.1 Preparar revisão por pares SP 2.2 Conduzir revisão por pares SP 2.3 Analisar dados da revisão por pares SG 3 Verificar produtos de trabalho selecionados SP 3.1 Executar verificação SP 3.2 Analisar os resultados da verificação
Manter conformidade com o
contrato: resolver qualquer aspecto
relacionado a aceitação do software,
de acordo com os procedimentos
estabelecidos no contrato.
Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.1 Executar o acordo com o fornecedor
Aceitar o S&SC: aceitar o S&SC
e comunicar a sua aceitação ao
fornecedor. Deverá ser complementada
com os relatórios produzidos nos
processo de avaliação e pela observação
dos critérios de aceitação definidos.
Gerenciamento de Contrato
SG 1 Satisfazer acordo com o fornecedor SP 1.3 Aceitar o produto adquirido SP 1.4 Gerenciar fatura do fornecedor
4. Proposta de Definição de Processo
A maioria das organizações adquirentes de S&SC enfrenta sérios problemas para orçar, licitar, contratar e gerir de maneira adequada os projetos para desenvolvimento dos produtos de software que precisam construir. Ocorrendo, assim, casos onde o S&SC adquirido não atende devidamente os objetivos
para os quais foi desenvolvido e possui custo bem mais elevado do que o esperado. Existe também,
uma grande dificuldade para acompanhar o processo de desenvolvimento junto ao fornecedor.
E junto a isto, a comunidade especializada dispõe do Guia de Aquisição do MPS.BR, um documento
que fornece um processo pronto para as organizações adquirentes de S&SC, onde são descritas as
atividades e tarefas fundamentais para a garantia da qualidade do contrato e respectivos produtos e
serviços entregues pelo fornecedor. Porém, o processo ainda possui um número muito baixo (apenas
5 em 23/9/2009, de acordo com o sítio da SOFTEX) de consultores certificados pela instituição mantenedora do modelo, a SOFTEX, tornando complicada a implantação do processo em uma organização com pouca ou nenhuma experiência em engenharia de software, pois o mesmo contém muitas
regras e premissas a serem consideradas, se tornando complexo a olhos menos experientes.
Assim, esta problemática foi a motivação para um projeto inicial de desenvolvimento de uma ferramenta de suporte ao Guia de Aquisição do MPS.BR, porém, levantou-se o fato de tornar a organização adquirente, interessada na melhoria de seu processo de aquisição, aderente não só ao modelo
MPS.BR, como também a outro modelo para aquisição de software. Então, o CMMI-ACQ por ser um
172 WAMPS 2009
Uma Proposta de Mapeamento dos Processos Existentes no Guia de Aquisição do MPS.BR e no CMMI-ACQ
modelo internacionalmente aceito, bem estabelecido no mercado, uma evolução de outro modelo já
bem aceito pela comunidade, o SA-CMM, sendo eleito para, junto das recomendações do modelo
MPS.BR, formarem um terceiro processo. Processo esse que englobe as recomendações e atividades
dos dois modelos, tornando assim a organização que o utilizar, aderente aos dois modelos em apenas
um único esforço de implantação. Reduzindo, assim, visivelmente custos e esforços para esta tarefa.
Vale ressaltar que este processo também deve ser flexível, de tal maneira que seja adequado à cultura das organizações interessadas, para uma empresa privada e para organizações públicas, onde o
processo deverá contemplar as recomendações feitas pela IN SLTI/MP 4/2008 e os Acórdãos 1.603 e
2.471/2008-TCU-Plenário.
E então, este será o processo a ser sistematizado em uma ferramenta de software, pois ela tenderá
a facilitar o aprendizado, implantação e a execução do processo pelas organizações envolvidas no
contrato, melhorando o acompanhamento da empresa adquirente junto ao fornecedor e facilitando
também o canal de comunicação e demonstração de resultados por parte do fornecedor.
Neste contexto, a proposta tem como focos principais o estudo destas orientações fornecidas pelo
Guia de Aquisição do MPS.BR e pelo CMMI-ACQ e, com base neste estudo, definir um único processo
e com este processo definido, elaborar a especificação de uma ferramenta de software que apóie
estas orientações. O projeto contemplará as metas:
1. Definição e análise de um processo para aquisição de software que seja aderente ao MPS.BR e ao
CMMI-ACQ;
2. Especificação e Desenvolvimento de uma ferramenta de software livre de suporte a este processo
a ser definido;
3. Apoio para que as empresas nacionais, existentes ou em criação, que desenvolvam contratos de
aquisição e desenvolvam atividades inovadoras em termos tecnológicos (P,D&I) de impacto comercial ou social com qualidade, a partir da implantação deste processo e ferramenta de software
livre;
4. Avaliação do estado atual dos processos de aquisição de produtos de software de empresas locais, regionais e nacionais com vistas a aumentar o nível de capacidade em aquisição de software
através da utilização da ferramenta desenvolvida;
5. Implantação da proposta (processo e ferramenta) em uma organização adquirente e o acompanhamento da realização de pelo menos um projeto de aquisição nesta organização, se utilizando
destes produtos gerados pela proposta.
WAMPS 2009 173
Trabalhos em andamento
5. Análise da Proposta
Esta seção permite um entendimento das análises e resultados esperados a partir do desenvolvimento da proposta apresentada na Seção 4.
5.1. Resultados Esperados
Com a completude das atividades e objetivos descritos, espera-se como resultados a disseminação
do conhecimento sobre o processo de aquisição na região e o estabelecimento de um processo para
aquisição junto com seu ferramental de software livre de apoio no cenário nacional, evidenciados
por:
1. Redução dos custos e tempo para a implantação e execução do processo;
2. Redução dos custos e tempo envolvidos em um contrato de aquisição de software;
3. Atendimento das necessidades regionais e nacionais;
4. Melhoria do desempenho das organizações adquirentes nos problemas enfrentados no que diz
respeito a orçar, licitar, contratar e gerir de maneira adequada os projetos de aquisição;
5. Envolvimento da comunidade com a adesão de novas parcerias;
6. Desenvolvimento das competências da comunidade em relação ao processo proposto;
7. Incorporação contínua do ferramental proposto por novas organizações.
5.2. Pontos Fortes e Fracos
Como principal ponto forte tem-se o crescente mercado de aquisição de S&SC no Brasil, com uma
grande oportunidade de expansão do processo de aquisição do MPS.BR, tendo em vista que não
existem ferramentas que reconhecidamente oferecem suporte a execução de tal processo e junto a
Recomendação do Tribunal de Contas da União (TCU) de 2007 na adoção do modelo MPS.BR como
elemento de pontuação diferenciada para a contratação de produtos e serviços na área de software,
se cria assim, uma necessidade no mercado que até o momento não é atendida, fornecendo a oportunidade para que este projeto.
Porém, como este projeto tem que ser fortemente vinculado ao interesse de organizações adquirentes, corre-se o risco destas não proverem a participação necessária para que o trabalho possa fluir naturalmente, ou até mesmo, perderem o interesse nos produtos do projeto com o passar do tempo.
174 WAMPS 2009
Uma Proposta de Mapeamento dos Processos Existentes no Guia de Aquisição do MPS.BR e no CMMI-ACQ
6. Considerações Finais
Este artigo apresentou uma proposta de mapeamento dos processos no Guia de Aquisição do MPS.
BR e no CMMI-ACQ, assim como uma proposta para processo de aquisição de software e serviços
aderente aos dois modelos. Processo este que trará benefícios às organizações interessadas, tendo
em vista a complexidade de processos como o CMMI-ACQ para organizações adquirentes que não
tem experiência com desenvolvimento de software.
Como próximos passos deste projeto pretendem-se: (1) Definição, validação e implantação do processo proposta em uma empresa parceira; (2) Especificação e Desenvolvimento de uma ferramenta
de apoio ao processo, facilitando a sua implantação e execução; e com os resultados das etapas
anteriores, (3) prover melhoria no processo e ferramenta proposto, provendo a maior flexibilidade
possível para melhor adequar-se a realidade das organizações interessadas.
Agradecimentos
O desenvolvimento deste trabalho está tendo apoio financeiro do CNPq através do Edital MCT/CNPq
Nº 70/2008.
Referências
COOPER, Jack & FISHER, Matt. Software Acquisition Capability Maturity Model (SA-CMM), Version
1.03, Software Engineering Institute, CMU/SEI-2002-TR-010,ESC-TR-2002-010, 2002.
GUERRA, A. e ALVES, A., Aquisição de Produtos e Serviços de Software. Rio de Janeiro: Campus,
2004.
HUMPHREY, Watts S., Managing the Software Process, The SEI Series in Software Engineering.
Addison-Wesley, 1989.
SEI, Capability Maturity Model Integration (CMMI) for Software Engineering, Version 1.1, Carnegie
Mellon, USA, 2001.
SEI, Capability Maturity Model Integration (CMMI) for Acquisition, Version 1.2, Carnegie Mellon,
USA, 2006.
SOFTEX, Melhoria do Processo de Software Brasileiro (MPS.BR) - Guia Geral 2009, 2009a
SOFTEX, Melhoria do Processo de Software Brasileiro (MPS.BR) - Guia de Aquisição 2009, 2009b.
ISO/IEC 12207: Systems and Software Engineering – Software Life Cycle Processes, 2nd edition,
2008.
WAMPS 2009 175
Trabalhos em andamento
Riscos e Fatores de Influência na definição de
Estratégias para Projetos de Implementação de
Melhoria de Processos de Software em Grupos
de Empresas
Gisele Villas Bôas, Ana Regina Cavalcanti Rocha {giselevb, darocha}@cos.ufrj.br
Programa de Engenharia de Sistemas e Computação – COPPE/UFRJ Caixa Postal 68.511 – CEP 21945-970 – Rio de Janeiro – RJ – Brasil
Resumo: Este artigo apresenta um levantamento dos riscos e fatores críticos que exercem influência nas
iniciativas de projetos de implementação de melhoria de processos de software no contexto de grupos de
empresas. Propõe uma observação criteriosa destes riscos e fatores, visando contemplar um conjunto de ações
capazes de orientar a identificação de estratégias que auxiliem as Instituições Organizadoras e as Instituições
Implementadoras no que diz respeito à captação das empresas candidatas a participarem dos grupos e à seleção das empresas captadas e dispostas a aderirem ao projeto. Visa também, orientar a definição de estratégias
que estabeleçam as ações de monitoramento ao longo do ciclo de vida destas iniciativas e, ao mesmo tempo,
um conjunto de ações pertinentes que motivem as empresas já avaliadas de modo a garantir a implementação
da melhoria contínua ou, ao menos, a manutenção do nível obtido.
1. Introdução
Desde sua criação em 2003, o Programa MPS.BR [SOFTEX, 2005] vem estimulando, inclusive com
apoio financeiro, a formação de grupos de empresas para a condução conjunta de projetos visando
à implementação de melhoria em processos de software com o Modelo de Referência para Melhoria
do Processo de Software (MR-MPS) [SOFTEX, 2009b].
O Programa MPS.BR trata aspectos técnico-científicos, de mercado e gerencial com o objetivo de
desenvolver e disseminar o Modelo de Referência MR-MPS (2009). Quanto aos aspectos de mercado
o Programa define o Modelo de Negócio para Melhoria de Processo de Software (MN-MPS) [SOFTEX,
2009e], onde descreve dois tipos de modelo para estas implementações de melhoria: (i) o Modelo
de Negócio Específico (MNE), adequado para grandes organizações; e (ii) o Modelo de Negócio
Cooperado (MNC) que é um pacote para grupos próprio para Pequenas e Médias Empresas (PME) que
desejam compartilhar custos e esforços na implementação do modelo MPS [Santos e Weber, 2008].
Às Instituições Organizadoras de Grupos de Empresas (IOGE) cabe a organização destes grupos, às
Instituições Implementadoras (II-MPS) a consultoria para execução dos projetos de implementação
de melhoria de processos nas empresas e às Instituições Avaliadoras (IA-MPS), ao final do projeto de
implementação, a avaliação da aderência dos processos destas empresas ao Modelo de Referência
MR-MPS (2009), segundo o Método de Avaliação (MA-MPS) [SOFTEX, 2009a]. Este trabalho trata
aspectos inerentes às atribuições tanto das IOGEs quanto das IIs.
176 WAMPS 2009
Riscos e Fatores de Influência na definição de Estratégias para Projetos de Implementação
Implementações de melhoria de processos baseadas em modelos podem resultar em projetos de
longo prazo e altos investimentos e estes são fatores que exercem grande pressão dentro das organizações, em especial nas PMEs, que operam sob fortes restrições financeiras [Staples et al., 2007] e
que formam a maior parte da indústria de software brasileira (cerca de 70%) [MCT, 2007].
Embora a formação de grupos de empresas, promovida e apoiada pela ASSOCIAÇÃO PARA
PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX dentro do Programa MPS.BR, seja um fator crítico de sucesso deste programa e, consequentemente, facilitador na implementação de
melhoria de processos de software nas PMEs [Santos e Weber, 2008], e ainda que se saiba do sucesso
obtido pelo programa no que tange ao alcance das metas estabelecidas no seu início, o número de
empresas avaliadas ainda é pequeno levando-se em conta a base de empresas instalada no país.
Pode-se observar pela análise dos dados publicados que depois de terem sido avaliadas com sucesso,
obtendo o nível desejado, poucas empresas destes grupos dão continuidade com novos projetos de
melhoria de processos de software [SOFTEX, 2009c].
São desconhecidos os riscos e fatores de influência no contexto específico da formação de grupos
de empresas, pois, embora possam ser encontrados na literatura alguns trabalhos que citam fatores
de insucesso em projetos de implementação [Rocha et al., 2005; Niazi et al., 2006], de fato, pouco
se fala sobre grupos e, mesmo que se possa entender, analogamente, que eles – os fatores de insucesso - exerçam influência também sobre empresas participantes de grupos, é necessário considerar
com maior aprofundamento a aplicação, tanto destes quanto de outros fatores de influência, neste
contexto específico. Existem diversos trabalhos que apontam problemas e riscos inerentes à condução de um programa de melhoria de processo de software como pode ser visto em [Aguiar, 2008],
[Mendes et al., 2007] e [Rouiller et al., 2006], porém, também nestes trabalhos não são tratados
estes problemas e riscos apenas no contexto específico de grupos de empresas.
Não é possível saber, por exemplo, quais fatores influenciaram algumas empresas participantes dos
grupos, após atingirem as primeiras metas estabelecidas (em geral atingir os níveis G e F do MRMPS), a não participarem de novos grupos para darem continuidade à implementação de melhoria
de processo de software. Também não estão claros os motivos pelos quais alguns grupos não são
formalizados, apesar dos esforços aplicados por parte das IOGEs (ou de outras instituições organizadoras de grupos).
Este trabalho está dividido em três seções e, além desta introdução, apresenta na seção dois a contextualização de alguns aspectos relacionados à necessidade de ter-se uma visão de negócio no que
diz respeito aos projetos de implementação de melhoria de processo em grupos cooperados. Ainda
nesta seção há uma reflexão sobre a importância de IOGEs e IIs terem estratégias bem definidas
quanto à condução destas iniciativas e uma consolidação destacando aspectos relevantes do levantamento realizado dos riscos e fatores de influência nos projetos de melhoria de processo em grupos
de empresas, tratando em especial, aspectos específicos a este contexto.
Na seção três é apresentada uma conclusão resumindo algumas percepções a cerca do tema. Também
aqui são discutidas as perspectivas de trabalhos futuros.
Por fim, são apresentadas as referências visitadas para realização deste trabalho.
WAMPS 2009 177
Trabalhos em andamento
2. Contextualização
2.1. A visão de negócio dos grupos cooperados
Do ponto de vista da IOGE, é importante que seja entendido o contexto da formação dos grupos
analogamente ao contexto de prestação de serviços em organizações comerciais.
Santos e Weber (2008), citando [Teboul, 2006], apresentam o triângulo de serviços – Cliente, Empresa
e Colaborador de Linha de Frente – e fazem um paralelo deste triângulo com o modelo de negócios
MN-MPS mostrando que, nesta relação, a Empresa representa o próprio Programa MPS.BR e a atuação de linha de frente fica a cargo das instituições que formam o próprio programa, entre elas, as IIs
e IOGEs que estão em contato direto com o Cliente, neste caso, as empresas participantes dos grupos
cooperados. Destacam, ainda, que são estas entidades e pessoas de linha de frente responsáveis por
grande parte da imagem que os clientes têm do modelo MPS e estão em pé de igualdade com eles
na responsabilidade pelo sucesso do projeto.
No relato de lições aprendidas da IOGE FUMSOFT [Barbieri e Mendonça, 2008] destacam a importância de se estabelecer um relacionamento formal entre as partes, por exemplo, por meio de um
contrato de prestação de serviços que defina direitos e obrigações e de um projeto técnico que trate
os aspectos da execução da implementação. Entretanto, além destes, é necessário que se dê tratamento a alguns aspectos e critérios estratégicos considerando a visão de negócio.
Analisando os dados das implementações em grupos de empresas publicados pela SOFTEX [SOFTEX,
2009d], referentes a cerca de 20 grupos formados1, é possível entender que caso estes aspectos e
critérios não sejam adequadamente observados, embora sejam de suma importância para a empreitada de formação de grupos, os resultados bem-sucedidos fiquem comprometidos quanto (i) à
captação das empresas candidatas a participarem dos grupos; e (ii) à seleção das empresas captadas
e dispostas a aderirem ao projeto.
Sabemos, pela nossa própria experiência nos últimos anos com a formação de grupos pela IOGE
RIOSOFT [RIOSOFT, 2009] e, também, por relatos de outras IOGEs que, de fato, as ações de captação comumente adotadas não resultam num leque de empresas tal que possibilite uma seleção
realmente eficaz e criteriosa. Como consequência, durante o projeto de melhoria algumas empresas
apresentam dificuldades ao longo do andamento do projeto, por deficiências de sua infraestrutura,
nos seus recursos ou no seu volume de projeto, outras, por estes mesmos problemas, demandam
um esforço maior de parte da II e IOGE no que diz respeito ao gerenciamento e monitoramento do
projeto de implementação visando uma avaliação de sucesso.
Sendo assim, torna-se necessária a adoção de melhores práticas para a captação inicial das empresas. Isto permitirá que critérios mais apropriados possam ser aplicados e fará com que uma avaliação
cuidadosa identifique as empresas que estejam, realmente, aptas a investirem seus recursos, tanto
financeiros quanto humanos, no projeto de melhoria de processos com o Modelo MPS.
1) Não estão considerados os grupos alcançados pelos dois últimos comunicados publicados pela SOFTEX em 17/06/2009.
178 WAMPS 2009
Riscos e Fatores de Influência na definição de Estratégias para Projetos de Implementação
2.2. A importância de estratégias bem definidas
Tendo em vista os aspectos de negócios apresentados, consideramos então que, assim como nas
organizações comerciais, também as IOGEs e IIs necessitam conduzir os seus projetos baseados em
estratégias definidas. Não basta apenas o planejamento das ações, mas é necessário que estas ações
estejam alinhadas com as estratégias de cada organização. Toda instituição precisa raciocinar estrategicamente em termos de qual é e qual deve ser o seu negócio; deve decidir porque seus clientes são
seus clientes; deve perguntar o que eles consideram “valor” [Drucker, 1980]. Estas indagações são
igualmente importantes para instituições não-lucrativas de serviço público e para empresas comerciais. Mesmo que aqui consideremos as peculiaridades do Programa MPS.BR e das instituições ligadas a ele, é possível traçar um paralelo destas com as instituições citadas pelo autor e verificar que,
mesmo assim, a necessidade de definições estratégicas é aplicável. Ainda segundo Druker (1980)
toda instituição deve analisar seus pontos fortes e verificar se são adequados e pertinentes, e se estão
sendo empregados onde são capazes de produzir resultados.
Com base nas reflexões anteriores e visando o aumento das chances de sucesso na formação de grupos, acredita-se que é necessário então que sejam definidas estratégias para captação com o objetivo
de se ter um maior número de empresas candidatas, bem como de estratégias específicas que possibilitem uma condução de seleção das empresas de forma mais criteriosa. E, além destas, também
estratégias para o monitoramento das atividades do grupo podem levar a um melhor gerenciamento
dos problemas e a uma maior assertividade na tomada das ações corretivas necessárias.
2.3. Um levantamento de riscos e fatores de influência específicos ao contexto
Com o propósito de apresentar recomendações que auxiliem na definição de tais estratégias, estamos pesquisando riscos e fatores de influência específicos, considerando que o cenário de projetos
conduzidos em grupos cooperados enfrenta desafios próprios tanto durante as etapas de captação
e seleção quanto no monitoramento ao longo do ciclo de vida do projeto de melhoria. Além destes
desafios existe, ainda, o de conseguir que as empresas participantes dos grupos sintam-se motivadas
e estimuladas ao longo do projeto de forma a assegurar o sucesso do grupo como um todo.
Este trabalho propõe uma identificação adequada dos riscos possibilitando ações mais assertivas de
contingência e/ou mitigação. Propõe também uma observação criteriosa dos fatores de influência
permitindo que ações sejam tomadas no sentido de evitar fatores negativos e de criar um cenário
propício para que a ocorrência dos fatores positivos seja estimulada, aumentando assim as chances
de êxito do grupo.
A percepção e o entendimento acurado dos efeitos dos riscos e fatores de influência podem permitir
que melhores estratégicas sejam adotadas quanto à organização dos grupos e, no que concerne ao
fato de algumas empresas abandonarem o programa de melhoria após serem avaliadas, pode, também, ajudar a definir ações corretivas apropriadas. Estas ações devem ser catalisadoras no sentido de
propiciar que os benefícios esperados pelas empresas sejam alcançados, facilitando assim a adoção de
um programa de melhoria contínua ou, ao menos, a manutenção dos níveis de maturidade obtidos.
A Tabela 1 apresenta alguns problemas, riscos e fatores de influência (dificuldades e fatores de sucesso) coletados da literatura [Rocha et al., 2005; Niazi et al., 2006; Rouiller et al., 2006; Mendes et al.,
2007; Aguiar, 2008]. As colunas identificam as diversas formas como os trabalhos relacionam estes
WAMPS 2009 179
Trabalhos em andamento
itens. Neste levantamento foi possível perceber, por exemplo, que questões relacionadas aos recursos
a serem empregados nos projetos de melhoria aparecem como “problema” (Escassez de recursos),
como “risco” (Insuficiência de Recursos Humanos qualificados), como dificuldade (Recursos financeiros) e como “Fator de sucesso” (Recursos disponíveis na empresa). Também questões relacionadas
ao comprometimento dos envolvidos podem ser identificadas como “problema” (Falta de comprometimento), “risco” (Falta de compromisso da equipe), dificuldade (Comprometimento) e “Fator de
sucesso” (Comprometimento da empresa).
Tabela 1 - Problemas, Riscos e Fatores de Influência nos Projetos de Melhoria
Problemas
Riscos
Dificuldades
Fatores de Sucesso
Falta de pessoal
qualificado
Falta de compromisso da
equipe
Cultura organizacional
Alinhamento dos
processos com as
estratégias de negócio da
empresa
Baixo envolvimento das
equipes
Não alinhamento com os Comprometimento
objetivos organizacionais
Recursos disponíveis na
empresa
Falta de
comprometimento
Insuficiência de Recursos
Humanos qualificados
Estrutura da empresa
Retorno do investimento
Apoio da alta gerência
Indisponibilidade de
tecnologias de apoio
Recursos financeiros
Estratégia de
implementação
Escassez de recursos
Expectativas não realistas Motivação
da alta gerência
Motivação
Disparidade entre as
empresas que compõem
o grupo
Perda de apoio financeiro Apoio ferramental
ao programa de MPS
Comprometimento da
empresa
No contexto específico de grupos de empresas, a nossa fonte principal para este levantamento são os
artigos e relatos apresentados nos Workshops Anuais do MPS já realizados. Estes trabalhos concentram um conjunto de experiências e lições aprendidas que certamente estão relacionados com os fatores que, de alguma forma, influenciaram nos projetos de melhoria de software nos grupos formados
até o momento. Além disso, foram realizadas entrevistas informais com alguns dos principais envolvidos com as IIs e IOGEs credenciadas pela SOFTEX. Desta forma, além dos riscos e fatores de influência
apresentados na Tabela 1, é importante refletir sobre alguns aspectos que mereceram realce.
São recorrentes, por exemplo, as afirmações sobre a importância da captação e da seleção das empresas para a formação do grupo e vários são os relatos que trazem este como o ponto mais difícil.
A necessidade de despertar o interesse dos empresários mostrando vantagens e ganhos mostra-se
importante e demandante de ações fortes de divulgação. Entretanto, enquanto uns direcionam a
busca por grupos sinérgicos (i) visando um melhor alcance dos marcos, (ii) procurando ter no grupo
empresas com características afins entre si, (iii) considerando importante que estas empresas estejam no mesmo nível de maturidade, (iv) que não sejam concorrentes diretos e (v) que tenham bom
relacionamento com as outras empresas do grupo, outros chegam a considerar como positiva a
experiência de troca quando existe, em um mesmo grupo, empresas pequenas, com baixo nível de
180 WAMPS 2009
Riscos e Fatores de Influência na definição de Estratégias para Projetos de Implementação
maturidade e pequena quantidade de colaboradores, e aquelas maiores, onde já existe alguma utilização de conceitos de metodologias de controle de processos e um número de colaboradores tal que
permita o estabelecimento adequado e bem definido de papéis. Ressaltam estes últimos, apenas, que
deve ser observado e monitorado o foco no projeto de implementação evitando temas e discussões
paralelos [Tsukumo et al., 2006; Yoshida e Tavares, 2008].
Outros, ainda, destacam a necessidade de um programa flexível visando atender às especificidades
de cada empresa, contrastando com lições aprendidas que buscam a manutenção do ritmo do grupo
facilitando a realização de eventos e tarefas comuns a todas as empresas.
Em seu relato Tsukumo (2006) chama atenção para as dificuldades encontradas em algumas empresas, destacando 3 fatores: (i) falta de entendimento do significado da implementação de melhoria
de processos; (ii) falta de prática em gerência de projetos e; (iii) deficiência no entendimento de conceitos básicos de engenharia de software por parte dos colaboradores da empresa. Outro aspecto
apontado diz respeito ao trabalho dos implementadores e cita que interpretações diversas do modelo
MPS podem influenciar de alguma forma no projeto de melhoria de processos.
Os cursos oficiais do MPS.BR (2009) oferecidos pela SOFTEX, em especial o C1 (Curso de Introdução),
também foram citados como um fator de influência positiva que pode auxiliar no entendimento das
empresas do significado da implementação de melhoria de processos e das vantagens do Programa
como um todo, em contrapartida o seu custo aparece como uma dificuldade para que se formem
turmas em algumas regiões do país.
Também aspectos relacionados à cultura organizacional das empresas e, mesmo aspectos mais amplos como, culturas regionais, puderam ser observados no nosso levantamento como fatores de influência. Em muitos casos a colaboração entre empresas aparece como um fator positivo, cabendo às
IOGEs, nestes casos, o papel de estimular a realização de workshops, encontros técnicos e apresentações do andamento dos trabalhos. Por vezes este é um trabalho árduo que exige forte intervenção
e perseverança até que a almejada colaboração torne-se natural. Em outros casos, entretanto, a falta
de colaboração, devido a timidez e a resistência das empresas, aparecem como um relato, porém,
não chega a ser julgado como um fator que exerça forte influência negativa ao projeto. É chamado
à atenção, inclusive, o fato de que a confidencialidade das informações das empresas precisa ser
preservada [Thiry et al., 2007; Junior, 2008; Lima e Gomes, 2008].
Treinamentos, workshops, seminários e palestras são aspectos percebidos como relevantes durante
todo o projeto. Em sua maioria as instituições realizam treinamentos iniciais visando capacitar os colaboradores das empresas e alinhar os Resultados Esperados dos Processos aos seus conhecimentos
em engenharia de software, gerenciamento de projetos e outras áreas necessárias. De outro modo,
foram levantadas necessidades mais específicas. Por exemplo, algumas instituições realizam cursos
para patrocinadores e coordenadores locais visando diminuir o impacto de fatores negativos como a
falta de comprometimento ou a deficiência na capacitação destes envolvidos para gerenciar e controlar os processos e suas equipes.
A formalização de parcerias também é um fato que pode trazer aspectos positivos e negativos.
Pecegueiro do Amaral [Amaral, 2008], em seu relato destaca a parceria bem-sucedida da IOGE
RIOSOFT com a II – COPPE como um dos fatores críticos de sucesso que resultou em dezenas de em-
WAMPS 2009 181
Trabalhos em andamento
presas participantes de grupos obterem êxito na avaliação da aderência de seus processos ao Modelo
MPS.BR e algumas também ao CMMI [SEI, 2006].
Esta e outras experiências nos levam a refletir que, em particular, a participação das universidades nos
projetos seja um fator crítico de influência. Se não pela participação direta nas implementações, ao
menos pela participação indireta durante a formação de implementadores, instrutores e, por vezes,
também dos colaboradores das empresas.
Ainda em seu relato Pecegueiro (2008) destaca a importância de se exercer esforços de modo a assegurar a continuidade do grupo, buscando evitar a “mortalidade” das empresas ao longo do ciclo de
vida do projeto, fator este que pode influenciar na moral do grupo com um todo.
3. Conclusão e Trabalhos Futuros
O sucesso do Programa MPS.BR é um fato. As metas e resultados alcançados são a prova disto.
Entretanto, atualmente o número de empresas avaliadas ainda é pequeno levando-se em conta a
base de empresas instalada no país. Estratégias adequadas para captação e seleção das empresas e
um conhecimento mais aprofundado dos riscos, dificuldades e fatores críticos de sucesso, por certo
auxiliarão as IOGEs na formação destes grupos, assim como, a definição de estratégias adequadas
para o monitoramento dos projetos de melhoria de processos neste cenário, ajudará IOGEs e IIs a
alcançarem os resultados almejados.
Neste contexto acreditamos que para a expansão dos resultados obtidos até o momento e para que os
próximos resultados impactem de forma positiva e significativa na indústria brasileira de desenvolvimento de software, é imprescindível a formação regular e bem-sucedida de grupos cooperados, em todas
as regiões do país, de modo a alcançar uma quantidade mais expressiva de empresas beneficiadas.
Para um melhor entendimento das questões discutidas neste artigo sobre grupos de empresas formados para melhoria de processos, um trabalho de pesquisa está em andamento visando à identificação
das estratégias adotadas e dos fatores que influenciaram os projetos de implementação de melhoria
de processos no âmbito dos grupos de empresas formados até o momento.
Ao final deste trabalho de pesquisa esperamos obter um conjunto de recomendações para a construção de estratégias que auxiliem as Instituições Organizadoras na captação de empresas candidatas
à formação de grupos e as Instituições Organizadoras e Implementadoras no gerenciamento dos
problemas inerentes à implementação de processos de melhoria em grupos de empresas para potencializar as chances de sucesso destas iniciativas.
Do mesmo modo, é nosso objetivo estabelecer um mapeamento detalhado que propicie um maior
entendimento sobre os riscos e os fatores de influência (positiva e negativa), identificando o que
facilita e o que dificulta a implementação de melhoria de processo em grupos de empresas, como,
também, relacionar um conjunto de ações pertinentes que motivem as empresas já avaliadas de modo a garantir a implementação da melhoria contínua ou, ao menos, a manutenção do nível obtido.
Espera-se também aplicar e avaliar as estratégias propostas no contexto real de formação de grupos
de empresas com o envolvimento da RIOSOFT e da COPPE.
182 WAMPS 2009
Riscos e Fatores de Influência na definição de Estratégias para Projetos de Implementação
Referências
Aguiar, H.V. (2008) Uma metodologia para implantação de melhoria de processo de software em
grupos de empresas, Universidade Federal de Pernambuco - UFPE, Recife - PE - Brasil.
Amaral, M.P.d. (2008) “Lições aprendidas em Seis anos de Projeto Qualisoft”, ProQuality: Nucleo de
Estudos em Engenharia de Software, v. 4, n. 1807 - 5061, Recife/PE.
Barbieri, C.V.P., Mendonça, R.M.L.O. (2008) “Lições Aprendidas da IOGE FUMSOFT na Organização
de Grupos de Empresas no Projeto MPS.BR”, ProQuality: Núcleo de Estudos em Engenharia de
Software, v. 4, n. 1807 - 5061, Recife/PE.
Drucker, P.F. (1980) Administração em tempos turbulentos São Paulo, Enio Matheus Guazzelli & Cia
Ltda.
Junior, E.P. (2008) “Lições aprendida pela IOGE SOFTEX CAMPINAS com Implementação do Modelo
MPS em Empresas”, ProQuality: Nucleo de Estudos em Engeharia de Software, v. 4, n. 1807 5061, Recife/PE.
Lima, G.N., Gomes, M.A. (2008) “Fatores Críticos de Sucesso na IOGE SOFTEXRECIFE em Programas
de Melhoria de Processo de Forma Cooperada”, ProQuality: Nucleo de Estudos em Engeharia de
Software, v. 4, n. 1807 - 5061, Recife/PE.
MCT (2007) “Ministério da Ciência e Tecnologia”. In: www.mct.gov.br, accessed in Abril de 2007.
Mendes, F.F., Oliveira, J.L., Fernandes, P.G., et al. (2007) “Análise de Riscos na Implantação de Melhorias
de Processos de Software”.
Niazi, M., Wilson, D., Zowghi, D. (2006) “Critical success factors for software process improvement
implementation: An empirical study”, Software Process Improvement and Practice, v. 11, n. 2, pp.
193-211.
RIOSOFT (2009) “Site da RIOSOFT - Sociedade Núcleo de Apoio à Produção e Exportação de Software
do Rio de Janeiro”.
Rocha, A.R., Montoni, M., Santos, G., et al. (2005) “Fatores de Sucesso e Dificuldades na Implementação
de Processos de Software Utilizando o MR-MPS e o CMMI”. In: PROQUALITY – Qualidade na
Produção de Software, apresentado no I Encontro de Implementadores de MPS.BR, pp. 13-18,
Brasília, Brasil, Junho.
Rouiller, A.C., Lima, G.N., Aguiar, H.V., et al. (2006) “Metodologia e Análise das Implantações MPS.
BR Realizadas pela SWQuality”, Proqualiti, II Workshop de Implementadores MPS.BR, v. 2, n. 2
(Novembro).
Santos, G., Weber, K.C. (2008) “Lições Aprendidas na Gestão do Programa MPS.BR”, SOFTEX –
Associação para Promoção da Excelência do Software Brasileiro, pp. 12, Campinas, SP.
SEI (2006) CMMI® for Development (CMMI-DEV), V1.2, CMU/SEI-2006-TR-008, Software Engineering
Institute.
WAMPS 2009 183
Trabalhos em andamento
SOFTEX (2005) “MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral (v. 1.0)”,
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO - SOFTEX, v. v. 1.0,
pp. 61, Abril de 2005.
SOFTEX (2009) “MPS.BR – Melhoria de Processo do Software Brasileiro, Guia de Avaliação (v. 2009)”.
In: http://www.softex.br/mpsbr/_guias/default.asp.
SOFTEX (2009) “MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral:2009”. In: http://
www.softex.br/mpsbr/_guias/default.asp.
SOFTEX (2009) “Site do MPS.BR - Melhoria de Processos do Software Brasileiro”. In: http://www.
softex.br/mpsbr, accessed in 15/08/2009.
SOFTEX “Site do MPS.BR - Melhoria de Processos do Software Brasileiro, Implementações em Grupos
de Empresas”. In: http://www.softex.br/mpsbr/_implementacoes/default.asp, accessed in Setembro
de 2009.
SOFTEX “Site do MPS.BR - Melhoria de Processos do Software Brasileiro, Modelo de Negócio”. In:
http://www.softex.br/mpsbr/_outros/MN-MPS.pdf, accessed in Setembro de 2009.
Staples, M., Niazi, M., Jeffery, R., et al. (2007) “An exploratory study of why organizations do not
adopt CMMI”, Journal of Systems and Software, v. 80, n. 6, pp. 883-895.
Teboul, J. (2006) SERVICE IS FRONT STAGE: Positioning services for value advantage, Palgrave
MacMillan.
Thiry, M., Wangenhein, C.G.v., Zoucas, A. (2007) “Implementação do MPS.BR em Grupos de Empresas
da ACATE em Florianópolis”, ProQuality: Nucleo de Estudos em Engeharia de Software, v. 3, n.
1807 - 5061, Recife/PE.
Tsukumo, A.N., De Martino, W.R., Sergio, M.P., et al. (2006) “Lições aprendidas na aplicação do
Método Coop-MPS para Projetos Cooperativos de Melhoria de Processo de Software com MPS.
BR”, ProQuality: Núcleo de Estudos em Engenharia de Software, v. 2, n. 1807 - 5021, Recife/PE.
Yoshida, D., Tavares, M.B.d.M. (2008) “Lições aprendidas pela II-ITS no Projeto de Implementação
MPS.BR Nível G no Grupo de Empresas em Salvador”, ProQuality: Nucleo de Estudos em Engenharia
de Software, v. 4, n. 1807 - 5061, Recife/PE.
184 WAMPS 2009
Riscos e Fatores de Influência na definição de Estratégias para Projetos de Implementação
WAMPS 2009 185
186 WAMPS 2009
WAMPS 2009 187
188 WAMPS 2009
WAMPS 2009
O V Workshop Anual do MPS (WAMPS 2009) tem por
objetivo reunir os representantes da Indústria, Governo,
Academia, SOFTEX, ETM, FCC, BID e países latinoamericanos envolvidos e interessados na utilização e
evolução tanto do Modelo MPS quanto do Programa
MPS.BR – Melhoria de Processo do Software Brasileiro.
Este evento anual permite que os diferentes
colaboradores e usuários possam compartilhar suas
experiências e adquirir informações atualizadas sobre o
Modelo MPS e o Programa MPS.BR.
Apoio:
Ministério da
Ciência e Tecnologia
ISBN 978–85–99334–17–1
www.softex.br/mpsbr
334171
V Workshop Anual do MPS
Campinas-SP, 19 a 22 de outubro de 2009
Nestes Anais do WAMPS 2009 (V Workshop Anual do
MPS) encontram-se as palestras convidadas (position
papers), os artigos aceitos e os trabalhos em andamento.
9 788599
WAMPS 2009